Wprowadzenie
W poprzednim artykule podkreśliliśmy, że baza msdb przechowuje praktycznie wszystkie obiekty związane z automatyzacją. W tym artykule omówimy przypadek przenoszenia zadań i obiektów między instancjami SQL Server.
Zacznijmy od listy obiektów przechowywanych w msdb na tej instancji SQL Server.
Mamy kilka zadań utworzonych z planem konserwacji (zobacz artykuł Tworzenie planów konserwacji w SQL Server). Mamy też dwa alerty i jednego operatora. Msdb przechowuje również alerty i operatorów (patrz Rysunek 1). Usuniemy te obiekty, a następnie odzyskamy je, przywracając kopię zapasową bazy danych msdb.
Wyświetlanie obiektów przechowywanych w msdb
Jeśli zapytamy o odpowiednie obiekty systemowe, zobaczymy również te obiekty zwrócone jako zbiór wyników. (Patrz Listing 1, Rysunek 2). Msdb przechowuje również katalogi systemowe z zapisami zadań, dziennikami kopii zapasowych, operatorami, miejscami konserwacji, pocztą bazy danych i innymi elementami związanymi z automatyzacją.
-- Listing 1: Check List of Jobs in the Instance
use msdb
go
select @@SERVERNAME as ServerName
select name from sysjobs;
Msdb kopii zapasowej
Aby zilustrować koncepcję pojedynczej instancji SQL Server, najpierw wykonujemy kopię zapasową bazy danych msdb. W scenariuszach produkcyjnych regularne tworzenie kopii zapasowych baz danych systemu powinno być częścią strategii. Zwykle są wystarczająco małe, aby wygodnie zmieścić się w codziennym harmonogramie pełnych kopii zapasowych.
Oczywiście, gdy odnoszę się do systemowej bazy danych, nie obejmuje to koniecznego tempdb. Co więcej, codzienna kopia zapasowa modelowej bazy danych również może nie być wymagana – wystarczy cotygodniowa kopia zapasowa. Aby uzyskać pełne dzienne kopie zapasowe, rozważ master i msdb.
Używając prostego kodu z Listingu 2, wykonujemy kopię zapasową bazy danych msdb.
-- Listing 2: Backup msdb Database
backup database msdb to disk = 'E:\DriveF\msdb_18072020.bak';
Porzucanie ofert pracy
Gdy kopia zapasowa jest gotowa, zrzucamy zadania na instancję. Należy zauważyć, że usunięcie zadań utworzonych przez plan konserwacji wymaga usunięcia planów konserwacji, które je utworzyły (patrz rysunek 3).
Zwykłe zadania można usunąć, usuwając je za pomocą GUI. Innym sposobem jest uruchomienie kodu z Listingu 3, a następnie kodu z Listingu 4.
Listing 3 generuje zestaw skryptów niezbędnych do usunięcia zadań. Następnie na Listingu 4 wykonujemy skrypty wygenerowane na Listingu 3.
Możesz użyć tego podejścia, nawet jeśli nazwy zadań w Twojej instancji są prawdopodobnie inne niż moje.
-- Listing 3: Generate Script to Drop Jobs
USE [msdb]
GO
select 'EXEC msdb.dbo.sp_delete_job @job_name=N''' + [name] + ''', @delete_unused_schedule=1' from sysjobs;
GO
-- Listing 4: Drop SQL Agent Jobs
EXEC msdb.dbo.sp_delete_job @job_name=N'DB1_BackupTransactionLog', @delete_unused_schedule=1
EXEC msdb.dbo.sp_delete_job @job_name=N'syspolicy_purge_history', @delete_unused_schedule=1
Po odrzuceniu ofert pracy możemy zweryfikować, czy nie ma już żadnych ofert pracy. Użyj tego samego skryptu, jak pokazano na Listingu 1. Rozważamy dwa sposoby scenariusza:
- Ktoś przypadkowo usunął zadania i podobne obiekty w instancji.
- Chcemy zaimportować zadania z jednej instancji do drugiej.
Przywracanie msdb
Operację przywracania inicjujemy za pomocą skryptu z Listingu 5. W tym skrypcie zaczynamy od ustawienia bazy danych w tryb single_user. Ponieważ ktoś lub coś (konto SQL Agent?) może być zalogowany do tej bazy danych, jest to konieczne.
Następnie wydajemy polecenie „restore” i ustawiamy nową bazę danych msdb na multi_user. Zauważ, że użyliśmy opcji REPLACE w instrukcji restore. Jeśli migrujesz msdb do nowego wystąpienia, klauzula REPLACE będzie konieczna. Bez tego SQL Server może zwrócić błąd dotyczący zestawu kopii zapasowej, który nie należy do bazy danych msdb na instancji.
-- Listing 5: Restore msdb database
use master
go
alter database msdb set single_user with rollback immediate;
GO
restore database msdb from disk = 'E:\DriveG\msdb_18072020.bak'
with replace;
GO
alter database msdb set multi_user;
GO
Po zakończeniu operacji przywracania brakujące zadania i inne obiekty powracają. Przychodzą wraz ze swoimi historiami pracy. Wszystkie relacje między zadaniami z bazami danych i innymi obiektami są nienaruszone. Zadania działają tak, jakby nikt i nic ich nie usuwało.
Wniosek
Możemy łatwo migrować zadania i podobne obiekty z jednej instancji SQL Server do drugiej. W tym celu potrzebujemy procesu tworzenia kopii zapasowej i przywracania msdb. Podobnie, możemy odzyskać te obiekty na instancji SQL Server, jeśli z jakiegoś powodu zostaną utracone.