Widok sys.procedures

sys.procedures zwraca listę procedur składowanych zdefiniowanych w bieżącej bazie danych.

Widok sys.procedures — czym jest i do czego służy

Widok sys.procedures jest katalogowym źródłem informacji o procedurach składowanych zapisanych w aktualnie używanej bazie danych. Pozwala sprawdzić, jakie obiekty tego rodzaju istnieją, bez konieczności przeszukiwania skryptów wdrożeniowych, plików projektu albo dokumentacji utrzymywanej poza systemem. Dzięki temu można rozpocząć analizę od danych widocznych bezpośrednio w metadanych bazy.

Wynik zapytania do sys.procedures zawiera między innymi nazwę procedury, identyfikator obiektu, identyfikator schematu, typ obiektu oraz informacje związane z datą utworzenia i ostatniej modyfikacji. Sam widok opisuje procedurę jako obiekt, ale nie pokazuje jej pełnego kodu. Do odczytania definicji potrzebne jest dodatkowe odwołanie do metadanych modułów, na przykład za pośrednictwem sys.sql_modules albo funkcji OBJECT_DEFINITION.

Podstawowe zapytanie może wyglądać następująco:

SELECT name, object_id, schema_id, create_date, modify_date
FROM sys.procedures
ORDER BY name;

Takie zestawienie jest przydatne podczas inwentaryzacji bazy, przygotowywania migracji, sprawdzania zakresu zmian oraz szukania obiektu, którego nazwa została podana w komunikacie błędu lub dokumentacji aplikacji. Należy pamiętać, że widok odnosi się do kontekstu konkretnej bazy. Zmiana bazy poleceniem USE powoduje, że kolejne zapytanie może zwrócić zupełnie inną listę.

Widok sys.procedures — kontekst techniczny i porównanie z innymi katalogami

sys.procedures należy do katalogowych widoków systemowych SQL Server. Jego przeznaczeniem jest filtrowanie obiektów rozpoznawanych jako procedury składowane. W praktyce stanowi wygodniejszy punkt startowy niż ogólny widok sys.objects, gdy potrzebne są wyłącznie procedury. Z kolei sys.objects obejmuje szerszy zakres obiektów, między innymi tabele, widoki, funkcje, wyzwalacze i inne elementy schematu.

Różnica między sys.procedures a sys.sql_modules jest istotna. Pierwszy widok odpowiada przede wszystkim na pytanie, jakie procedury istnieją i jakie mają podstawowe właściwości. Drugi przechowuje tekst definicji modułów, o ile został zachowany i jest dostępny dla bieżącego użytkownika. Połączenie obu źródeł pozwala uzyskać zarówno listę obiektów, jak i ich kod.

Przykładowe połączenie może zostać zapisane w formie:

SELECT p.name, SCHEMA_NAME(p.schema_id) AS schema_name, p.modify_date, m.definition
FROM sys.procedures AS p
LEFT JOIN sys.sql_modules AS m ON m.object_id = p.object_id
ORDER BY schema_name, p.name;

Warto odróżnić procedury składowane od funkcji. Funkcje są dostępne w katalogu sys.objects oraz w wyspecjalizowanych widokach sys.all_objects i sys.objects z odpowiednim filtrowaniem typów, natomiast nie powinno się zakładać, że każda funkcja pojawi się w sys.procedures. Podobnie procedura systemowa i procedura użytkownika mogą wymagać odrębnego podejścia podczas analizy, zwłaszcza gdy zakres zapytania obejmuje obiekty dostarczane wraz z instalacją silnika.

Widoki katalogowe pokazują stan odczytany z metadanych. Nie są rejestrem historii zmian. Pole modify_date wskazuje ostatnią zmianę obiektu w rozumieniu metadanych, ale nie dostarcza pełnego dziennika wszystkich wcześniejszych wersji kodu. Do kontroli historii potrzebny jest system wersjonowania skryptów, dziennik wdrożeń albo inne rozwiązanie audytowe.

Widok sys.procedures — typowe problemy podczas odczytu

Jednym z częstszych problemów jest otrzymanie pustego wyniku mimo przekonania, że procedura istnieje. Przyczyną może być połączenie z inną bazą niż zakładana, literówka w nazwie, użycie niewłaściwego schematu albo brak odpowiednich uprawnień do wyświetlania metadanych. Warto najpierw sprawdzić kontekst poleceniem SELECT DB_NAME(), a następnie wyszukać obiekt po nazwie wraz z nazwą schematu.

W wielu bazach ta sama nazwa procedury może występować w różnych schematach. Odwołanie dbo.PobierzDane nie jest równoważne odwołaniu raporty.PobierzDane, nawet jeżeli końcowy człon nazwy wygląda identycznie. Dlatego w skryptach administracyjnych należy zwracać uwagę na schema_id, a nazwę schematu wygodnie uzyskuje się przez SCHEMA_NAME(schema_id).

Brak tekstu definicji nie musi oznaczać uszkodzenia procedury. Kod może być ukryty za pomocą szyfrowania modułu albo niedostępny dla konta wykonującego zapytanie. W takim przypadku lista obiektów z sys.procedures może być widoczna, lecz kolumna definition w sys.sql_modules pozostanie pusta. Nie powinno się wtedy wnioskować, że procedura nie zawiera kodu.

Trudność może sprawiać również rozróżnienie daty utworzenia obiektu od daty zmiany jego treści. Modyfikacja definicji zwykle wpływa na modify_date, ale operacje pomocnicze, zależności oraz dane wejściowe procedury nie są przez ten widok przedstawiane. Nie da się na tej podstawie ustalić, kiedy procedura była ostatnio uruchamiana ani jak długo trwało jej wykonanie.

W środowiskach z ograniczonym dostępem katalog może być widoczny tylko częściowo. Widoczność metadanych zależy od uprawnień, właściciela obiektu i konfiguracji zabezpieczeń. Przy porównywaniu dwóch baz należy więc sprawdzić nie tylko same zapytania, ale też konto, z którego je wykonano, ponieważ różny zakres widoczności może dać pozornie sprzeczne wyniki.

Widok sys.procedures — praktyczne wskazówki użycia

Najbezpieczniej jest zwracać nazwę procedury razem z nazwą schematu, identyfikatorem obiektu i datą modyfikacji. Samo pole name może być niewystarczające podczas analizy większej bazy. Przy filtrowaniu warto stosować warunki oparte na jednoznacznych nazwach, a przy wyszukiwaniu częściowym pamiętać, że operator LIKE może zwrócić procedury o podobnych, lecz nieidentycznych nazwach.

Do sprawdzania konkretnego obiektu można użyć zapytania:

SELECT p.name, SCHEMA_NAME(p.schema_id) AS schema_name, p.create_date, p.modify_date
FROM sys.procedures AS p
WHERE p.name = N'PrzykladowaProcedura';

Jeżeli potrzebne są także informacje o parametrach, można połączyć sys.procedures z sys.parameters. Dzięki temu można ustalić nazwy argumentów, ich kolejność, typy danych oraz informację o parametrach wyjściowych. Taki zestaw jest pomocny przy sprawdzaniu zgodności procedury z kodem aplikacji lub przy przygotowywaniu dokumentacji interfejsu.

Przed zmianą procedury warto zapisać jej aktualną definicję w repozytorium skryptów i odnotować zależności. Lista z sys.procedures nie pokazuje automatycznie, które widoki, funkcje, tabele lub inne procedury są wykorzystywane w treści modułu. W tym celu potrzebne są dodatkowe mechanizmy analizy zależności, wyszukiwanie odwołań w kodzie albo narzędzia wspierające przegląd schematu.

Podczas eksportu listy należy również uwzględnić procedury o nazwach nietypowych, znaki narodowe i różnice w ustawieniach sortowania. W zapytaniach automatyzujących raportowanie przydatne może być jawne uporządkowanie po nazwie schematu i nazwie procedury. Ogranicza to zmiany kolejności wyników po aktualizacji danych katalogowych i ułatwia porównywanie raportów.

Nie należy używać sys.procedures jako zamiennika kopii zapasowej. Widok dostarcza informacji o bieżącym stanie obiektów, ale nie chroni przed przypadkowym usunięciem, nadpisaniem ani błędną migracją. Pełne skrypty definicji powinny być przechowywane niezależnie, z kontrolą zmian i możliwością odtworzenia poprzedniej wersji.

Widok sys.procedures — kiedy zgłosić się do serwisu

Wsparcie techniczne może być potrzebne, gdy problem z odczytem procedur nie wynika z samego zapytania, lecz z błędnej konfiguracji systemu, niedostępności środowiska, uszkodzeń nośnika danych albo nieprawidłowego działania komputera wykorzystywanego do pracy z bazą. Przed przekazaniem sprzętu warto zabezpieczyć kopie zapasowe, zanotować komunikaty błędów i opisać czynności, po których pojawiły się nieprawidłowości.

W Warszawie pomocą zajmuje się Warszawskie Pogotowie Komputerowe 24/7; naprawy są z reguły realizowane do 3 dni roboczych. Przy zgłoszeniu dobrze jest podać model urządzenia, używany system, rodzaj bazy, treść komunikatu oraz informację, czy problem dotyczy jednego obiektu, całej bazy, czy również uruchamiania aplikacji. Tak przygotowany opis ułatwia rozdzielenie problemu programowego od usterki sprzętowej i pozwala sprawniej dobrać dalsze czynności diagnostyczne.

W przypadku utraty dostępu do danych, nieoczekiwanych restartów, powtarzających się błędów odczytu albo podejrzenia uszkodzenia dysku nie powinno się wielokrotnie uruchamiać wymagających operacji bez wcześniejszego zabezpieczenia danych. Ostrożne postępowanie zmniejsza ryzyko nadpisania informacji potrzebnych do późniejszej analizy. Sam widok sys.procedures jest narzędziem diagnostycznym, lecz poprawna interpretacja wyniku wymaga uwzględnienia kontekstu bazy, uprawnień, schematów, definicji modułów i stanu komputera.