Archive for April, 2010

Czy kiedykolwiek zdarzyło Ci się, że trzeba było przenosić zadania (ang. jobs) usługi SQL Server Agent? Dość oczywistym sposobem jest wykorzystanie mechanizmu skryptowania dostępnego w SQL Server Management Studio. Po kolei:

1. Łączymy się z instancją SQL Server 2008 za pomocą okna Object Explorer (wciśnij F8, by to okno zobaczyć).
2. Przechodzimy w drzewie do węzła SQL Server Agent – Jobs.
3. Otwieramy okno Object Explorer Details (wciśnij F7, by to okno zobaczyć).
4. Zaznaczamy wszystkie zadania w oknie Object Explorer Details, klikamy prawym przyciskiem myszy i wybieramy Script Job as – CREATE To i wybieramy odpowiednią dla nas opcję (do pliku, do nowego okna skryptu, do schowka).

Wszystko dobrze, ale co, gdy taką kopię zapasową zadań musimy wykonywać cyklicznie? Chcemy mieć do tego zadania automat. Pierwsza myśl – użyć T-SQL. Trzeba się jednak nieźle naklepać kodu, by napisać takie narzędzie. Druga myśl – użyć tego, czego używa Management Studio – .NET i bibliotek SMO. Dobry pomysł, ale nadal sporo kodu do napisania. Czy na pewno? Otóż nie, bo z odsieczą przychodzi nam… PowerShell!

A zatem – otwieramy na początek konsolę sqlps.exe (klikamy prawym przyciskiem myszy na nazwie instancji w oknie Object Explorer i wybieramy Start PowerShell).

Na powyższym zrzucie 0809-001 to nazwa mojej maszyny, a DEFAULT oznacza oczywiście instancję domyślną. Gdy nie wiemy, dokąd dalej nawigować w oknie konsoli PowerShell, wystarczy uruchomić komendę dir (jest to tutaj alias na odpowiedni commandlet). Teraz nawigujemy (cd jest kolejnym przydatnym aliasem – działa zupełnie jak w konsolach DOS i umożliwia nawigację po “folderach” SQL Servera) do zbioru zadań usługi SQL Server Agent. U mnie to wyglądało tak:

• cd JobServer
• cd Jobs
• dir

I mamy listę zadań. W konsoli PowerShell wiele klasy SMO są dostępne bez pokrętnego dodawania bibliotek. Praktycznie każdy obiekt dysponuje metodą Script() i ten fakt właśnie można wykorzystać. Gdy w konsoli PowerShell pojawił się prompt:

PS SQLSERVER:\SQL\0809-001\DEFAULT\JobServer\Jobs>

wpisałem coś takiego:

dir | %{$_.Script()}

I dostałem kod T-SQL zawierający definicje zadań. Kod niestety niedoskonały, ale w zasadzie brakowało w nim jedynie odseparowania każdej definicji końcem wsadu (słowem GO).

Czyli skryptować zadania w PowerShell już umiem. Teraz zapis do pliku. Nic prostszego. Lekka modyfikacja dopiero co uruchomionego skryptu:

dir | %{$_.Script()} >> C:\jobs.sql

I mam zapisane definicje zadań w pliku C:\jobs.sql. Oczywiście – warunkiem jest to, by wskazać folder, do którego SQL Server (a w zasadzie konto Windows przydzielone do tej usługi) ma prawo zapisu.

I teraz ostateczny szlif. Jak spowodować, żeby – po pierwsze – taki skrypt PowerShell był uruchamiany cyklicznie i – po drugie – by za każdym razem wynikowy kod T-SQL lądował w nowym pliku (np. oznaczonym datą i godziną)?

Skoro cyklicznie, to pewnie wypada użyć zadania usługi SQL Server Agent. Tworzymy więc nowe zadanie:

1. W oknie Object Explorer przechodzimy do węzła SQL Server Agent – Jobs.
2. Klikamy prawym przyciskiem myszy na węźle Jobs i wybieramy New Job….
3. Wpisujemy nazwę zadania (pole Name) i po lewej stronie okna New Job wybieramy opcję Steps, a następnie klikamy na przycisku New…
4. Wpisujemy nazwę nowego kroku zadania (pole Name), a następnie z rozwijanej listy Type wybieramy PowerShell.
5. W polu Command wpisujemy skrypt PowerShell. W moim przypadku wyglądał on tak:

$data = Get-Date –Format yyyyMMddHHmm

dir SQLSERVER:\SQL\0809-001\DEFAULT\JobServer\Jobs | %{$_.Script() + “GO”} >> C:\backup_jobs_$data.sql

Pierwsza linijka skryptu ustawia jako obiekt $data bieżącą datę i czas zapisaną w odpowiednim formacie. Druga linijka dla każdego zadania uruchamia metodę Script(), dokleja do treści zadania zamknięcie wsadu (GO), a całość zeskryptowanego kodu T-SQL zapisuje do pliku o zmiennej nazwie, np. C:\backup_jobs_201004282220.sql.

Teraz pozostaje już tylko wybrać harmonogram dla zadania i przetestować (oczywiście, usługa SQL Server Agent musi być uruchomiona). U mnie działa. Wykorzystałem ten mechanizm także u klienta, który miał potrzebę przenoszenia zadań między serwerami zawierającymi bazy sprzężone mechanizmem log shippingu. PowerShell zaoszczędził mi w tym przypadku wiele pracy.

Przy okazji – polecam sesje Łukasza Grali poświęcone wykorzystaniu PowerShell do administracji systemem SQL Server 2008. Sesje te są organizowane przez portal VirtualStudy.pl (gratulacje dla prowadzących portal z okazji rocznicy istnienia portalu – tak trzymać!).