sys.sql_modules przechowuje definicje procedur, funkcji, widoków i wyzwalaczy jako tekst poleceń.
Widok sys.sql_modules – czym jest i jakie informacje przechowuje
Widok sys.sql_modules jest katalogowym źródłem informacji o modułach programowalnych utworzonych w bazie danych Microsoft SQL Server. W tym kontekście modułem jest obiekt zawierający zapis poleceń T-SQL, między innymi procedura składowana, funkcja, widok albo wyzwalacz. Zamiast analizować każdy obiekt oddzielnie, można odczytać definicje wielu elementów za pomocą jednego widoku systemowego. Ułatwia to rozpoznanie, jakie operacje są wykonywane, z jakich tabel korzysta kod oraz czy w bazie pozostały obiekty zawierające starsze rozwiązania.
Najważniejszą kolumną jest definition. Przechowywany jest w niej tekst modułu, czyli instrukcje zapisane podczas utworzenia lub ostatniej modyfikacji obiektu. Pozostałe kolumny wskazują między innymi identyfikator obiektu, identyfikator schematu oraz nazwę kolekcji katalogowej. Dzięki temu definicję można połączyć z innymi widokami systemowymi, na przykład z sys.objects, sys.schemas, sys.tables albo sys.columns. Sam widok nie wykonuje kodu i nie zastępuje dokumentacji, lecz pokazuje zapis źródłowy dostępny w metadanych bazy.
Przykładowe zapytanie może wyglądać następująco:
SELECT
o.name,
o.type_desc,
s.name AS schema_name,
sm.definition
FROM sys.sql_modules AS sm
JOIN sys.objects AS o
ON o.object_id = sm.object_id
JOIN sys.schemas AS s
ON s.schema_id = o.schema_id
ORDER BY s.name, o.name;
Takie zestawienie pozwala zobaczyć nazwę obiektu, jego rodzaj, schemat oraz tekst definicji. W praktyce przydatne jest filtrowanie wyników według type_desc, nazwy schematu albo fragmentu znajdującego się w definicji. Należy pamiętać, że wynik może zależeć od uprawnień osoby wykonującej zapytanie. Jeżeli definicja została ukryta przy tworzeniu obiektu, w kolumnie definition nie będzie dostępnego zwykłego tekstu źródłowego.
Widok sys.sql_modules a katalog obiektów i zależności
sys.sql_modules skupia się na treści modułu, natomiast informacje o samym obiekcie są rozdzielone pomiędzy kilka widoków katalogowych. sys.objects opisuje typ obiektu, datę utworzenia i datę ostatniej zmiany. sys.schemas pomaga ustalić jego przestrzeń nazw, a sys.sql_expression_dependencies może dostarczyć informacji o elementach, do których odwołuje się kod. Takie rozdzielenie jest celowe: tekst polecenia, właściwości obiektu i zależności są różnymi rodzajami metadanych.
W porównaniu z bezpośrednim korzystaniem z polecenia OBJECT_DEFINITION, widok zapewnia wygodniejszy dostęp do wielu definicji naraz. Funkcja OBJECT_DEFINITION jest praktyczna, gdy znany jest konkretny identyfikator obiektu i potrzebny jest pojedynczy wynik. Z kolei sp_helptext bywa używane do wyświetlania tekstu jednego modułu, lecz do przeglądów większego zbioru obiektów bardziej przejrzyste jest zapytanie do widoków katalogowych. W przypadku analizy zmian często łączy się oba podejścia: najpierw wyszukuje się obiekty w sys.sql_modules, a następnie szczegółowo sprawdza wybrane definicje.
Warto odróżnić definicję widoku od wyników zwracanych przez ten widok systemowy. Jeżeli moduł jest widokiem utworzonym przez użytkownika, jego zapytanie pojawi się jako tekst w kolumnie definition. Nie oznacza to jednak, że sys.sql_modules przechowuje dane zwracane przez tamten widok. Dane biznesowe znajdują się w tabelach, a sys.sql_modules opisuje kod zapisany w metadanych. Podobnie procedura składowana nie przechowuje w tym miejscu historii uruchomień, parametrów przekazanych podczas wywołań ani rezultatów wykonania.
W porównaniu z tabelą przeznaczoną na dane aplikacyjne widok katalogowy ma charakter opisowy. Nie powinno się go traktować jako miejsca do ręcznej edycji tekstu. Zmiany modułów wykonuje się przez polecenia takie jak CREATE OR ALTER PROCEDURE, CREATE OR ALTER FUNCTION, ALTER VIEW lub ALTER TRIGGER, zgodnie z typem obiektu i przyjętym sposobem wdrażania. Po zmianie kodu odczyt z sys.sql_modules może służyć do potwierdzenia, że zapis w bazie odpowiada oczekiwanej wersji.
Widok sys.sql_modules – typowe problemy podczas odczytu
Jednym z częstszych problemów jest pusty wynik w kolumnie definition. Może to wynikać z ukrycia definicji modułu albo z braku odpowiednich uprawnień. W takiej sytuacji nie należy zakładać, że obiekt nie zawiera kodu. Najpierw sprawdza się nazwę obiektu, jego typ, schemat oraz zakres uprawnień używanego konta. Znaczenie ma także kontekst bazy danych, ponieważ katalogi systemowe dotyczą bazy, w której wykonano zapytanie.
Drugą trudnością bywa niepełne rozpoznanie obiektów. Nie każda konstrukcja zawierająca kod SQL musi być prezentowana w identyczny sposób. Warto zweryfikować, czy analizowany element jest procedurą, funkcją, widokiem lub wyzwalaczem, korzystając z type_desc w sys.objects. Dla wyzwalaczy dodatkowe znaczenie ma informacja, do jakiego obiektu są przypisane. Sam tekst definicji może nie wyjaśniać całego sposobu działania, jeśli logika zależy od ustawień, uprawnień, obiektów zewnętrznych lub danych konfiguracyjnych.
Problemem może być również wyszukiwanie tekstu za pomocą prostego operatora LIKE. Nazwa tabeli lub kolumny może występować w komentarzu, ciągu znaków albo w nieużywanym fragmencie kodu. Z drugiej strony odwołanie może być zapisane z nawiasami, kwalifikacją schematu lub innym formatowaniem. Dlatego wyniki wyszukiwania tekstowego traktuje się jako listę kandydatów do dalszego sprawdzenia, a nie jako kompletny dowód zależności. W bardziej wymagającej analizie łączy się tekst modułu z katalogiem zależności i testem kompilacji.
Na uwagę zasługuje także sposób przechowywania długich definicji. Tekst może być obszerny, dlatego przy prezentacji w narzędziu administracyjnym może zostać zawinięty albo skrócony przez interfejs. Nie należy oceniać kompletności na podstawie samego widoku tabeli wynikowej. Pełny rezultat powinien zostać zapisany lub wyświetlony w sposób obsługujący długie wartości znakowe. Podczas porównywania wersji warto uwzględnić białe znaki, komentarze, wielkość liter oraz różnice formatowania.
Widok sys.sql_modules – praktyczne wskazówki do pracy
Przy tworzeniu zapytań diagnostycznych zaleca się zawsze pokazywać schemat razem z nazwą obiektu. Dwa obiekty o tej samej nazwie mogą istnieć w różnych schematach, a pominięcie tej informacji prowadzi do błędnej identyfikacji. Przydatny zestaw kolumn obejmuje schema_name, nazwę obiektu, type_desc, datę modyfikacji oraz definition. Datę można pobrać z sys.objects.modify_date, pamiętając, że oznacza ona zmianę obiektu, a niekoniecznie zmianę każdej zależnej tabeli.
Do wyszukiwania określonej instrukcji można zastosować filtr, lecz należy zachować ostrożność przy znakach specjalnych i różnych sposobach zapisu. Przykładowe zapytanie wyszukujące moduły odwołujące się do frazy może wyglądać tak:
SELECT
OBJECT_SCHEMA_NAME(sm.object_id) AS schema_name,
OBJECT_NAME(sm.object_id) AS object_name,
o.type_desc,
sm.definition
FROM sys.sql_modules AS sm
JOIN sys.objects AS o
ON o.object_id = sm.object_id
WHERE sm.definition LIKE N'%Customer%'
ORDER BY schema_name, object_name;
Przed wykorzystaniem takiego filtra w większej bazie dobrze jest ustalić, czy wyszukiwana fraza jest nazwą obiektu, częścią polecenia, komentarzem czy wartością tekstową. Przy analizie bezpieczeństwa zwraca się uwagę na dynamiczne budowanie instrukcji, nietypowe uprawnienia, wyłączone sprawdzanie zależności oraz odwołania do elementów, których nie ma już w schemacie. Sam odczyt metadanych nie naprawia problemu, ale pozwala zawęzić obszar dalszych prac.
Rozsądne jest także przechowywanie definicji w systemie kontroli wersji albo w zatwierdzonym repozytorium dokumentacji. sys.sql_modules pokazuje stan bieżący, natomiast nie dostarcza pełnej historii poprzednich wersji. Porównanie bieżącego tekstu z wcześniejszym plikiem może ujawnić przypadkową zmianę, usunięty warunek albo niezamierzoną modyfikację. Przed wdrożeniem zmian wskazane jest sprawdzenie składni, zależności oraz wpływu na wywołujące moduły.
Kiedy sprawdzić widok sys.sql_modules w serwisie komputerowym
Analiza sys.sql_modules jest przydatna, gdy pojawiają się trudne do wyjaśnienia błędy aplikacji, rozbieżności pomiędzy środowiskami, nieoczekiwane wyniki zapytań albo problemy po zmianie struktury bazy. Warto po nią sięgnąć również wtedy, gdy potrzebne jest ustalenie, który moduł odwołuje się do określonej tabeli lub kolumny. Przed rozpoczęciem zmian powinno się przygotować kopię konfiguracji, opisać obserwowany objaw i wskazać, czy problem dotyczy jednego obiektu, czy większego fragmentu systemu.
W przypadku komputera, na którym narzędzia bazodanowe działają niestabilnie, występują błędy dostępu do plików, problemy z dyskiem albo nieprawidłowe działanie systemu, przydatna może być konsultacja z firmą Warszawskie Pogotowie Komputerowe 24/7. Przed przekazaniem urządzenia dobrze jest zabezpieczyć kopie danych i przygotować informacje o komunikatach błędów. Sama definicja z sys.sql_modules nie powinna być zmieniana przypadkowo, ponieważ nawet drobna modyfikacja może wpłynąć na działanie aplikacji korzystających z danego modułu.
Jeżeli problem dotyczy wyłącznie logiki SQL, potrzebna może być weryfikacja kodu przez osobę zajmującą się projektowaniem baz danych. Jeżeli równocześnie występują objawy sprzętowe lub systemowe, takie jak zawieszanie się narzędzi, błędy odczytu, utrata połączeń lokalnych albo nagłe zamykanie aplikacji, warto najpierw ustalić stan komputera i nośnika danych. Dopiero po wykluczeniu problemów technicznych można rzetelnie ocenić, czy źródłem trudności jest definicja odczytana z sys.sql_modules, konfiguracja połączenia, uprawnienia czy sama aplikacja.
