Comment migrer des travaux SQL Server d'une instance SQL Server vers une autre

Présentation

Dans un article précédent, nous avons souligné que la base de données msdb stocke pratiquement tous les objets liés à l'automatisation. Dans cet article, nous examinerons le cas du déplacement de tâches et d'objets entre les instances SQL Server.

Commençons par la liste des objets stockés dans msdb sur cette instance de SQL Server.

Nous avons plusieurs travaux créés avec un plan de maintenance (voir l'article Création de plans de maintenance dans SQL Server). Nous avons également deux alertes et un opérateur. Msdb stocke également les alertes et les opérateurs (voir Figure 1). Nous allons supprimer ces objets, puis les récupérer en restaurant une sauvegarde de la base de données msdb.

Affichage des objets stockés dans msdb

Si nous interrogeons des objets système pertinents, nous voyons également ces objets renvoyés comme ensemble de résultats. (Voir Liste 1, Figure 2). Msdb stocke également les catalogues système avec les enregistrements des travaux, les journaux de sauvegarde, les opérateurs, les emplacements de maintenance, le courrier de la base de données et d'autres éléments liés à l'automatisation.

-- Listing 1: Check List of Jobs in the Instance
use msdb
go
select @@SERVERNAME as ServerName
select name from sysjobs;

Sauvegarder msdb

Pour illustrer le concept d'une instance unique de SQL Server, nous effectuons d'abord une sauvegarde de la base de données msdb. Dans les scénarios de production, des sauvegardes régulières de vos bases de données système doivent faire partie de votre stratégie. Ils sont généralement suffisamment petits pour s'intégrer confortablement dans un programme de sauvegarde complet quotidien.

Bien sûr, lorsque je fais référence à une base de données système, cela n'inclut pas tempdb nécessaire. De plus, une sauvegarde quotidienne d'une base de données modèle peut ne pas être nécessaire non plus - une sauvegarde hebdomadaire est suffisante. Pour les sauvegardes quotidiennes complètes, considérez master et msdb.

En utilisant le code simple du Listing 2, nous effectuons une sauvegarde de la base de données msdb.

-- Listing 2: Backup msdb Database 
backup database msdb to disk = 'E:\DriveF\msdb_18072020.bak';

Suppression d'emplois

Une fois la sauvegarde prête, nous déposons les jobs sur l'instance. Notez que la suppression des travaux créés par un plan de maintenance nécessite de supprimer les plans de maintenance qui les ont créés (voir Figure 3).

Les tâches régulières peuvent être supprimées en les supprimant avec l'interface graphique. Une autre méthode consiste à exécuter le code du Listing 3, suivi du code du Listing 4.

Le Listing 3 génère l'ensemble des scripts nécessaires pour supprimer les tâches. Ensuite, dans le Listing 4, nous exécutons les scripts générés dans le Listing 3.

Vous pouvez utiliser cette approche même si les noms de tâches dans votre instance sont probablement différents des miens.

-- 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

Après avoir supprimé les travaux, nous pouvons vérifier qu'il ne reste plus de travaux. Utilisez le même script, comme indiqué dans le Listing 1. Nous considérons deux manières pour le scénario :

1. Quelqu'un a accidentellement supprimé des tâches et des objets similaires dans une instance.
2. Nous souhaitons importer des tâches d'une instance vers une autre.

Restauration de msdb

Nous lançons l'opération de restauration à l'aide du script du Listing 5. Dans ce script, nous commençons par définir la base de données en mode single_user. Comme quelqu'un ou quelque chose (compte SQL Agent ?) peut être connecté à cette base de données, c'est nécessaire.

Ensuite, nous lançons la commande "restore" et définissons la nouvelle base de données msdb sur multi_user. Notez que nous avons utilisé l'option REPLACE dans l'instruction de restauration. Si vous migrez msdb vers une nouvelle instance, la clause REPLACE sera nécessaire. Sans cela, SQL Server peut renvoyer une erreur indiquant que le jeu de sauvegarde n'appartient pas à la base de données msdb sur l'instance.

-- 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

Une fois l'opération de restauration terminée, les travaux et autres objets manquants sont de retour. Ils sont accompagnés de leurs historiques de travail respectifs. Toutes les relations entre les travaux avec les bases de données et les autres objets sont intactes. Les travaux fonctionnent comme si personne ni rien ne les avait jamais supprimés.

Conclusion

Nous pouvons facilement migrer des travaux et des objets similaires d'une instance SQL Server vers une autre. Pour cela, nous avons besoin d'un processus de sauvegarde et de restauration de msdb. De même, nous pouvons récupérer ces objets sur une instance SQL Server en cas de perte pour une raison quelconque.