SQL Server przez Remote Desktop

Dostęp do SQL Server przez Remote Desktop ogranicza się do administracji, nie zastępuje bezpośredniego połączenia z bazą.

Rola Remote Desktop w dostępie do SQL Server

SQL Server przez Remote Desktop oznacza pracę na zdalnym pulpicie systemu Windows, na którym uruchomione są narzędzia administracyjne, na przykład SQL Server Management Studio (SSMS), sqlcmd albo aplikacje służące do konfiguracji instancji. Remote Desktop Protocol (RDP) dostarcza obraz pulpitu, obsługę klawiatury i myszy oraz przekazuje dane wejściowe do zdalnej sesji. Sam protokół RDP nie wykonuje zapytań SQL i nie jest protokołem komunikacji z silnikiem SQL Server.

Po zalogowaniu przez RDP można uruchomić SSMS bezpośrednio na serwerze i połączyć się z lokalną albo inną dostępną instancją SQL Server. W takim układzie połączenie z bazą tworzy SSMS, a nie klient RDP. Zdalny pulpit jest więc warstwą dostępu do systemu operacyjnego, natomiast SQL Server nadal korzysta z własnego mechanizmu uwierzytelniania, protokołów sieciowych i portów skonfigurowanych dla danej instancji.

Jak przebiegają dwa odrębne połączenia

Typowy scenariusz obejmuje co najmniej dwa niezależne połączenia. Pierwsze prowadzi z komputera użytkownika do usługi pulpitu zdalnego systemu Windows. RDP standardowo korzysta z portu TCP 3389, chociaż port usługi może zostać zmieniony w konfiguracji systemu. Drugie połączenie powstaje dopiero po uruchomieniu narzędzia SQL Server w zdalnej sesji. Jego parametry zależą od nazwy serwera, nazwy instancji, zastosowanego protokołu oraz konfiguracji SQL Server.

Dla domyślnej instancji SQL Server często używany jest port TCP 1433, ale nie jest to uniwersalna reguła dla każdej instalacji. Nazwane instancje mogą korzystać z portów dynamicznych, a odnalezienie portu przez nazwę instancji może wykorzystywać usługę SQL Server Browser działającą z użyciem UDP 1434. Jeżeli SSMS działa na tym samym komputerze co SQL Server, połączenie może być lokalne i nie wymagać przechodzenia przez sieć w taki sam sposób jak połączenie z osobnego stanowiska. RDP nie zmienia tych zasad; zapewnia jedynie dostęp do środowiska, w którym uruchamiany jest klient SQL Server.

Administracja a bezpośrednie połączenie z bazą

Sesja RDP może być przydatna do wykonywania czynności administracyjnych, ponieważ pozwala pracować z narzędziami zainstalowanymi na serwerze. W takiej sesji można sprawdzić stan usług SQL Server, konfigurację instancji, dzienniki systemowe i aplikacyjne, ustawienia protokołów w SQL Server Configuration Manager oraz działanie SSMS. Można również przeanalizować błędy logowania, problemy z uruchomieniem usługi, brak dostępu do instancji albo nieprawidłowy wybór portu.

RDP nie zastępuje jednak bezpośredniego połączenia aplikacji z bazą. Program korzystający z danych musi nawiązać własne połączenie z SQL Server za pomocą właściwego sterownika i parametrów serwera. Dotyczy to między innymi nazwy hosta, instancji, portu, sposobu uwierzytelniania oraz nazwy bazy. Fakt, że administrator może otworzyć SSMS przez pulpit zdalny, nie oznacza, że aplikacja uruchomiona na innym komputerze ma poprawną trasę sieciową lub uprawnienia do tej samej instancji.

Diagnostyka problemów z SQL Server przez RDP

Podczas diagnostyki należy najpierw rozdzielić problem logowania do systemu Windows od problemu połączenia z SQL Server. Jeżeli nie można nawiązać sesji RDP, trzeba sprawdzić dostępność hosta, konfigurację usługi pulpitu zdalnego, reguły zapory oraz uprawnienia konta systemowego. Jeżeli RDP działa, ale SSMS nie łączy się z instancją, przyczyny należy szukać w konfiguracji SQL Server, nazwie instancji, porcie, stanie usługi, protokole TCP/IP, zaporze albo sposobie uwierzytelniania.

Ważne jest także sprawdzenie, gdzie uruchomiono narzędzie. Połączenie z SSMS działającego na serwerze może być poprawne, podczas gdy połączenie z aplikacji na komputerze użytkownika nadal będzie odrzucane. Taki wynik wskazuje na różnicę między dostępem lokalnym i sieciowym, a nie na awarię samego silnika. Weryfikacja powinna obejmować dokładną nazwę instancji, rzeczywisty port nasłuchiwania, dostępność tego portu z sieci oraz komunikat błędu zwracany przez klienta. Dopiero po rozdzieleniu warstwy RDP, systemu Windows, sieci i SQL Server można ustalić, która część przepływu danych wymaga korekty.