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

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)?

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

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?

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

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.

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 :)

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).