API SMO (SQL Management Objects)

API SMO, czyli SQL Management Objects, to zestaw klas .NET umożliwiających programowe zarządzanie obiektami serwera SQL.

SMO jako obiektowy interfejs do Microsoft SQL Server

API SMO, czyli SQL Management Objects, to biblioteka klas platformy .NET przeznaczona do programowego zarządzania instancjami Microsoft SQL Server. Zamiast budować każdą operację wyłącznie jako tekst polecenia Transact-SQL, aplikacja może korzystać z obiektów reprezentujących serwer, bazę danych, tabelę, widok, procedurę składowaną, indeks, login, użytkownika, zadanie SQL Server Agent albo kopię zapasową. Klasy SMO znajdują się przede wszystkim w przestrzeni nazw Microsoft.SqlServer.Management.Smo, a klasy wspólne dla połączeń i komunikacji są udostępniane między innymi przez Microsoft.SqlServer.Management.Common.

SMO nie jest silnikiem bazy danych, sterownikiem do wykonywania zapytań aplikacyjnych ani zamiennikiem samego Microsoft SQL Server. Jest warstwą programistyczną, która pozwala automatyzować czynności administracyjne wykonywane wobec istniejącej instancji. Program korzystający z SMO musi nadal uzyskać połączenie z serwerem, użyć właściwych danych uwierzytelniających i posiadać uprawnienia wymagane do konkretnej operacji. Biblioteka nie omija mechanizmów bezpieczeństwa SQL Server.

Hierarchia obiektów i sposób odwzorowania instancji

Najwyższym elementem podstawowej hierarchii SMO jest obiekt Server. Pod nim znajdują się obiekty opisujące instancję oraz jej zasoby, w tym kolekcja baz danych, loginy, role serwerowe i konfiguracja. Obiekt Database udostępnia kolekcje tabel, widoków, procedur składowanych, funkcji, użytkowników, ról, schematów i innych elementów należących do konkretnej bazy. Dzięki temu kod może przechodzić po strukturze serwera podobnie jak po zwykłym modelu obiektowym.

Utworzenie instancji obiektu SMO w pamięci nie musi od razu zmieniać stanu serwera. Przykładowo obiekt opisujący nową bazę danych może zostać przygotowany w aplikacji, ale baza pojawi się na instancji dopiero po wywołaniu odpowiedniej metody, takiej jak Create(). Analogicznie zmiany właściwości obiektu wymagają wywołania metody zapisującej zmianę, na przykład Alter(), a usunięcie obiektu jest wykonywane przez Drop(). Rozdzielenie modelu w pamięci od operacji zatwierdzającej pomaga kontrolować moment modyfikacji środowiska.

Automatyzacja kopii, skryptów i konfiguracji

SMO może służyć do tworzenia i odtwarzania kopii zapasowych, zarządzania bazami danych, generowania skryptów obiektów oraz obsługi wybranych funkcji SQL Server Agent. Klasy związane z backupem i restore pozwalają opisać operację jako zestaw obiektów i właściwości, a następnie wykonać ją wobec wskazanej instancji. Przy generowaniu skryptów SMO może uwzględniać zależności między obiektami, co ma znaczenie wtedy, gdy kolejność tworzenia tabel, kluczy, widoków lub procedur wpływa na poprawność odtworzenia struktury.

Biblioteka udostępnia także mechanizmy odczytu właściwości serwera i obiektów bazodanowych. Program może sprawdzić między innymi listę baz, rozmiary plików, indeksy, schematy, konfigurację zadań oraz informacje o uprawnieniach, zależnie od zakresu obsługiwanego przez daną klasę i uprawnień konta. Model SMO korzysta również z pojęcia URN, czyli Unique Resource Name, które jednoznacznie identyfikuje obiekt w hierarchii SQL Server. W osobnej gałęzi modelu znajduje się ManagedComputer, reprezentujący usługi SQL Server i część ustawień sieciowych dostępnych przez dostawcę WMI.

Instalacja biblioteki i ograniczenia praktyczne

W nowszych projektach SMO jest dostarczane jako pakiet NuGet Microsoft.SqlServer.SqlManagementObjects. Aplikacja musi dobrać zgodne zależności oraz środowisko uruchomieniowe .NET, a przy wdrażaniu należy uwzględnić różnice między wersją biblioteki, obsługiwaną wersją SQL Server i używanym sposobem uwierzytelniania. Samo dodanie pakietu nie gwarantuje poprawnego połączenia: znaczenie mają także nazwa instancji, dostępność portu, protokół sieciowy, certyfikaty oraz uprawnienia loginu.

SMO jest szczególnie przydatne przy powtarzalnych zadaniach administracyjnych, migracjach struktury, inwentaryzacji obiektów i budowie własnych narzędzi zarządzających Microsoft SQL Server. Przy operacjach zmieniających dane lub konfigurację konieczne jest jednak kontrolowanie wyjątków, transakcji, kolejności działań i skutków częściowego wykonania. Błąd połączenia, brak uprawnień, niezgodność właściwości z daną wersją SQL Server albo przerwanie operacji może pozostawić proces zakończony tylko częściowo, dlatego kod powinien rejestrować wynik każdej istotnej czynności i weryfikować stan serwera po jej wykonaniu.