Wykonywanie skryptu PowerShell

Wykonywanie skryptu PowerShell z poziomu Agenta pozwala automatyzować zadania administracyjne poza T-SQL.

Rola PowerShell w zadaniu SQL Server Agent

Wykonywanie skryptu PowerShell z poziomu SQL Server Agent oznacza uruchomienie kodu PowerShell jako kroku zadania agenta. Pozwala to połączyć operacje wykonywane przez silnik SQL Server z czynnościami systemowymi, których nie realizuje sam język T-SQL. Skrypt może na przykład sprawdzić obecność pliku, utworzyć katalog roboczy, odczytać właściwości systemu Windows, wywołać program wiersza poleceń albo przygotować pliki używane przez kolejne kroki zadania. PowerShell nie zastępuje T-SQL, lecz uzupełnia go tam, gdzie potrzebny jest dostęp do systemu operacyjnego lub poleceń administracyjnych.

Krok PowerShell jest częścią definicji zadania SQL Server Agent i może być wykonywany według harmonogramu, po wystąpieniu określonego zdarzenia albo jako następstwo innego kroku. Wynik działania wpływa na dalszy przebieg zadania. Zakończenie skryptu kodem powodzenia pozwala przejść do następnego kroku, natomiast nieobsłużony błąd lub jawne zakończenie z kodem błędu może zatrzymać zadanie albo skierować je do ścieżki obsługi niepowodzenia. Z tego powodu sam fakt uruchomienia procesu PowerShell nie potwierdza jeszcze poprawnego wykonania całego przepływu.

Przygotowanie kroku PowerShell i przekazywanie danych

W konfiguracji zadania należy wskazać typ kroku PowerShell oraz treść skryptu lub sposób jego pobrania. Skrypt może korzystać ze zmiennych środowiskowych, parametrów i wartości zapisanych wcześniej w tabeli albo przekazanych przez mechanizmy SQL Server Agent. Dane wyjściowe powinny mieć jednoznaczny format, zwłaszcza gdy następny krok ma je interpretować. W praktyce bezpieczniej jest przekazywać ścieżki, identyfikatory i statusy w przewidywalnej postaci niż opierać logikę na przypadkowych komunikatach wyświetlanych w konsoli.

Jeżeli PowerShell wykonuje zapytania wobec SQL Server, skrypt musi używać dostępnych w danym środowisku poleceń i modułów, a sposób uwierzytelnienia powinien odpowiadać kontu wykonującemu krok. Nie należy zakładać, że konto administratora uruchamiające narzędzie SQL Server Management Studio będzie tym samym kontem, którego używa usługa SQL Server Agent. Różnica ta często powoduje brak dostępu do udziału sieciowego, katalogu, klucza rejestru lub zasobu zewnętrznego. W zadaniach wymagających innych uprawnień stosuje się konto proxy skonfigurowane dla podsystemu PowerShell, zamiast nadawać usłudze szersze uprawnienia niż potrzebne.

Obsługa błędów, uprawnień i skutków ubocznych

Skrypt uruchamiany przez SQL Server Agent powinien sprawdzać rezultaty operacji, a nie tylko wykonywać kolejne polecenia. Sam brak komunikatu na standardowym wyjściu nie oznacza, że kopiowanie pliku, połączenie z zasobem lub wywołanie programu zakończyło się prawidłowo. Warto rozróżnić błędy kończące działanie polecenia od ostrzeżeń, które PowerShell może traktować jako niekończące wykonania. Dla operacji krytycznych należy jawnie przechwytywać wyjątki, zapisywać istotny kontekst i zwracać stan zgodny z oczekiwaniami SQL Server Agent.

Znaczenie ma również bieżący katalog procesu, dostępność profilu użytkownika oraz ograniczenia polityki wykonywania skryptów obowiązujące w systemie Windows. Skrypt nie powinien zależeć od interaktywnego okna, ręcznego potwierdzenia ani mapowanego dysku widocznego wyłącznie w sesji zalogowanego użytkownika. Ścieżki do plików należy podawać jednoznacznie, a operacje modyfikujące dane lub pliki wykonywać idempotentnie, czyli tak, aby ponowne uruchomienie po częściowym błędzie nie powodowało niekontrolowanego powielania albo uszkodzenia wyników. Przy diagnostyce trzeba porównać historię zadania, dziennik SQL Server Agent oraz logi generowane przez sam skrypt.

Weryfikacja działania przed użyciem w harmonogramie

Przed włączeniem harmonogramu należy uruchomić skrypt w warunkach możliwie zbliżonych do rzeczywistego kroku agenta. Szczególnie ważne jest sprawdzenie konta wykonawczego, uprawnień do lokalnych i sieciowych ścieżek, dostępności wymaganych modułów PowerShell oraz zachowania przy braku pliku, niedostępnym serwerze lub pustym wyniku zapytania. Test powinien obejmować także ponowienie zadania po błędzie, ponieważ mechanizm retry może uruchomić ten sam skrypt ponownie i ujawnić problemy z częściowo utworzonymi plikami lub wpisami.

W środowisku naprawianego laptopa lub komputera PC podobna automatyzacja może być używana pomocniczo do zebrania informacji o systemie Windows, usługach, sterownikach i stanie dysków, ale każdą komendę trzeba dobierać do celu oraz uprawnień użytkownika. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, a w przypadku problemów z uruchamianiem skryptów analizuje między innymi konfigurację systemu, konto wykonawcze, błędy poleceń oraz zależności między kolejnymi etapami zadania.