SSMS a Azure SQL

SSMS łączy się z Azure SQL tak samo jak z instancją lokalną, wymaga jedynie poprawnej reguły zapory po stronie chmury.

SSMS i Azure SQL: podobny sposób połączenia, inna lokalizacja serwera

SQL Server Management Studio, czyli SSMS, może służyć do łączenia się zarówno z lokalną instalacją SQL Server, jak i z usługą Azure SQL Database działającą w chmurze Microsoft Azure. W obu przypadkach administrator wybiera typ uwierzytelniania, podaje nazwę serwera oraz nawiązuje sesję z użyciem protokołu TDS (Tabular Data Stream). Po połączeniu można wykonywać zapytania w języku Transact-SQL, przeglądać obiekty bazy, sprawdzać właściwości połączenia i uruchamiać narzędzia diagnostyczne dostępne dla danego typu usługi.

Najważniejsza różnica polega na tym, że Azure SQL Database nie jest zwykłą bazą umieszczoną na komputerze użytkownika. Jest usługą zarządzaną, w której Microsoft odpowiada za część infrastruktury, system operacyjny i warstwę utrzymania platformy. SSMS pozostaje aplikacją kliencką, natomiast właściwy serwer znajduje się w centrum danych Azure. Z tego powodu poprawnie skonfigurowane SSMS nie wystarczy, jeżeli połączenie blokuje zapora sieciowa albo wybrano nieprawidłową nazwę logicznego serwera.

Nazwa logicznego serwera i parametry połączenia

W przypadku Azure SQL Database w oknie łączenia SSMS podaje się nazwę logicznego serwera Azure SQL, zwykle w postaci zakończonej domeną .database.windows.net. Nie jest to adres konkretnego komputera, który można lokalnie uruchomić lub zrestartować. Nazwa wskazuje logiczny punkt dostępu do baz należących do danej usługi. W polu bazy danych można wskazać konkretną bazę użytkownika; bez tego SSMS może próbować połączyć się z bazą domyślną, zależnie od użytego mechanizmu uwierzytelniania i parametrów połączenia.

Połączenie z Azure SQL Database wykorzystuje szyfrowaną komunikację TLS. Standardowym portem dla połączeń SQL jest port TCP 1433, choć możliwość jego wykorzystania zależy również od reguł sieciowych obowiązujących po stronie usługi i środowiska, z którego wykonywane jest połączenie. W SSMS można użyć uwierzytelniania SQL, podając login i hasło utworzone dla serwera logicznego, albo uwierzytelniania Microsoft Entra, wcześniej znanego jako Azure Active Directory. Drugi wariant wymaga odpowiedniej konfiguracji tożsamości oraz uprawnień w dzierżawie Microsoft Entra.

Reguły zapory Azure SQL przed uruchomieniem zapytania

Jeżeli SSMS nie może połączyć się z Azure SQL, pierwszym elementem do sprawdzenia jest zapora sieciowa usługi. Azure SQL odrzuca połączenia z adresów IP, które nie zostały dopuszczone przez reguły serwera lub reguły sieci wirtualnej. W praktyce oznacza to konieczność dodania publicznego adresu IP komputera, z którego uruchomiono SSMS, albo skonfigurowania dostępu przez odpowiednią sieć prywatną. Sam fakt, że strona Azure Portal otwiera się w przeglądarce, nie oznacza jeszcze, że połączenie TCP do bazy jest dozwolone.

Reguła zapory musi odpowiadać rzeczywistemu adresowi źródłowemu widzianemu przez usługę Azure SQL. W sieci firmowej może to być publiczny adres routera lub bramy, a nie prywatny adres komputera przydzielony przez DHCP. Zmiana sieci, połączenie przez VPN, przełączenie z Wi-Fi na sieć komórkową albo zmiana adresu publicznego może spowodować, że wcześniej działająca konfiguracja przestanie działać. Komunikaty o błędach związanych z brakiem dostępu do serwera należy odróżniać od błędów logowania: zapora blokuje drogę do usługi, natomiast nieprawidłowe dane uwierzytelniające są sprawdzane dopiero po osiągnięciu punktu dostępu.

Zakres pracy SSMS po uzyskaniu dostępu

Po poprawnym połączeniu SSMS umożliwia między innymi tworzenie i wykonywanie zapytań T-SQL, odczytywanie danych, analizowanie schematu, przeglądanie tabel, widoków, procedur składowanych oraz sprawdzanie uprawnień dostępnych dla użytego konta. Można także obserwować plan wykonania zapytania i analizować jego wpływ na wydajność, o ile dana funkcja oraz wymagane uprawnienia są dostępne w Azure SQL Database. Warto pamiętać, że interfejs SSMS może wyglądać podobnie jak przy pracy z lokalnym SQL Server, ale nie każdy element lokalnego silnika jest dostępny w usłudze Azure SQL Database.

Problemy z połączeniem należy rozdzielać na kilka warstw: nazwę serwera, rozwiązywanie DNS, dostępność portu TCP, reguły zapory Azure, wybór bazy danych, metodę uwierzytelniania oraz uprawnienia konta. Dopiero po przejściu tych etapów ma sens analiza samego zapytania lub struktury bazy. Przy diagnostyce warto zapisać pełny komunikat SSMS, nazwę użytej usługi, metodę logowania i moment wystąpienia błędu. Taki zestaw informacji pozwala ustalić, czy problem dotyczy sieci, konfiguracji Azure SQL, tożsamości użytkownika, czy składni albo uprawnień w konkretnej bazie.