Obciążenie systemu wywołane działaniem kwerendy

0

Witam,
Jeżeli mam dwa serwery, A oraz B, i na serwerze A uruchomię kwerendę pobierającą dane z serwera B do tabeli na serwerze A, to ta kwerenda obciąża w jakiś sposób serwer B? Używam opcji NOLOCK?
W jaki sposób mogę sprawdzić obciążenie systemu wywołane przez działającą kwerendę (wykorzystać ExecutionPlan, Client Statistics)?

2

No oczywiście, ze obciąża, NOLOCK nie ma wpływu na obciążenie, przecież serwer B musi te dane wybrać i wysłać do serwera A, to nie jest operacja bezkosztowa.
Co rozumiesz przez obciążenie systemu.
Generalnie jeżeli Serwer A używa zapytania na serwerze B, to na B musisz oglądać statystyki, plany itd

0

Panczo, bardzo dziękuję za odpowiedź.
Ogólnie chodzi mi o to jaki wpływ ma kwerenda na działanie serwera. Nie wiem w jaki sposób można to sprawdzić, zobaczyć wykorzystanie procesora, pamięci, ruchu sieciowego czy operacji wejścia/wyjścia? A jeśli tak, to tak jak pisałeś, musiałbym to sprawdzić na serwerze, z którego dane są pobierane. To też dla mnie zagadka, jak sprawdzić statystyki serwera B skoro kwerendę uruchamiam na serwerze A?
Pewnie brzmi to chaotycznie ale robię to pierwszy raz i nie do końca łapię co mogę zrobić, jak zrobić itd?

1

Pytanie dlaczego chcesz to robić?

Zakladam, że mówimy tu o Linked Serverach. Tu nie ma zagadki, jeżeli na serwerze B puścisz zapytanie na serwerze A, to w planie zobaczysz Remote query z kosztem wykonania, jest to koszt w ramach serwera B, aby faktycznie zobaczyć jak to wygląda to musisz to zapytanie odpalić na serwerze A i tam podejrzeć plan. Obrazowo jeżeli ja (B) telefonicznie zadam Ci(A) pytanie o to ile masz przy sobie pieniędzy, to z mojej perspektywy A:

  1. Pytanie Ile masz pieniędzy?
  2. Oczekiwanie na odpowiedź.
  3. Otrzymanie odpowiedzi

Z Twojej B:

  1. Pytanie Ila mam pieniędzy?
  2. Wyciągnięcie portfela, przeliczenie, przeszukanie kieszeni itd.
  3. Zsumowanie calosci
  4. Odpowiedź

Nie wiem co robiłeś, wiem ile czekałem, tak samo jest z bazami B pyta i czeka na odpowiedź z A, dlatego jeżeli odpowiedź trwa za długo analizujemy serwer A nie B

1

Plany zapytania powinny pokazać Ci co się dzieje. Czasem bywa tak, że taniej jest przesłać dane z serwera B, a robotę wykonać na serwerze A.
np. Join dwóch tabel:

  • SerwerA - 1 milion wierszy
  • SerwerB - 10 wierszy

Nie ma sensu pchać 1 miliona przez sieć, przetworzyć na serwerze B i odesłać na serwerA.

Nie wiem jakie możliwości monitorowania użycia zasobów per query/sesja daje MSSQL, ale jak na silnik enterprajzowy przystało, to powinien mieć jakieś dane zbierane.

0

Bardzo dziękuję wszystkim za odpowiedzi.

Odpowiadam na pytanie "po co?"
Po pierwsze, polecenie służbowe, po drugie serwer A to serwer dedykowany naszemu zespołowi a serwer B to serwer dla całej firmy i pytanie jest, jak nasza kwerenda może wpłynąć na pracę reszty osób w firmie korzystających z serwera B :)

1

O ile dobrze pamiętam SQL Servera (2000), to to, że SELECT może blokować operacje UPDATE i zależy to od tego w jakim kontekście ten SELECT działa.
Jeśli selecta będziesz robił w trybie izolacji: READ COMMITED, to baza założy shared locka, więc update nie będzie mógł się wykonać.
Jeśli będziesz miał izolację typu: REPEATABLE READ lub SERIALIZABLE, to lock będzi trzymany do końca transakcji, w której robisz zapytanie (czyli możesz przyblokować transakcje osób pracujących na serwerze B).

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0