Inspecter et superviser Log Shipping

Monitor spécial que l’on place en principe sur un serveur moniteur séparé.

Où SQL Server 2000 stocke-t-il les informations de log shipping ? Il y a un total de sept tables log shipping dans la base de données msdb dans les éditions SQL Server 2000 Enterprise et Developer :

·	log_shipping_plans

·	log_shipping_plan_databases

·	log_shipping_databases

·	log_shipping_plan_history

·	log_shipping_monitor

·	log_shipping_primaries

·	log_shipping_secondaries

Chacune de ces tables existe sur les trois serveurs : primaire, secondaire et moniteur. Chaque serveur n'utilise que certaines des tables pour stocker les données, selon le rôle que joue le serveur dans le log shipping.

Inspecter log shipping sur le serveur primaire. A partir d'Enterprise Manager, vous pouvez vous connecter au serveur primaire et inspecter et superviser le log shipping. Si une base de données est impliquée dans log shipping, l'onglet General de la boîte de dialogue Properties de cette base de données indique le rôle de celle-ci (source ou destination) ainsi que quel serveur contient le Log Shipping Monitor. Vous pouvez visualiser l'état et l'historique du job de sauvegarde du journal de transactions de log shipping dans le noeud Jobs de SQL Server Agent d'Enterprise Manager.
Le serveur primaire ne peuple que deux des tables log shipping msdb. Dans log_shipping_databases, SQL Server insère une ligne reliant l'ID du plan de maintenance de base de données à  la base de données log shipping source. Dans la table log_shipping_monitor, SQL Server insère une ligne contenant le nom du serveur moniteur et le type de login.

Inspecter log shipping sur le serveur secondaire. Le plan log shipping réside sur le serveur secondaire. A partir de là , vous pouvez superviser les jobs SQL Agent qui copient les fichiers transaction-log sur le serveur et restaurent ces logs dans la base de données de destination. Vous pouvez également inspecter la boîte de dialogue Properties de la base de données de destination pour déterminer le rôle de la base de données dans le processus log shipping.
Sur le serveur secondaire, SQL Server utilise quatre des tables log shipping msdb. Après avoir créé le plan de log shipping, SQL Server insère une ligne dans la table log_shipping_plans, indiquant les noms du serveur primaire et secondaire, les emplacements des fichiers, et les ID du job de copie et de restauration (qu'il obtient de la table système sysjobs sur le serveur secondaire). Dans la table log_shipping_plan_databases, SQL Server relie le plan aux noms des bases de données source et de destination et stocke les informations concernant les derniers fichiers copiés et chargés. La table log_shipping_plan_history enregistre chaque événement de copie et de restauration du plan log shipping, en même temps que des informations diverses : si le job a réussi, par exemple. Dans la table log_shipping_monitor, SQL Server insère également une ligne qui fait référence au serveur moniteur.
Si vous avez choisi (quand vous avez installé log shipping dans le Database Maintenance Plan Wizard) de laisser la base de données de destination assumer un rôle primaire, vous verrez un élément supplémentaire important sur le serveur secondaire : un autre plan de maintenance de base de données avec le même nom que le plan que vous avez créé mais sans log shipping activé. Vous verrez également un job SQL Agent désactivé pour faire des sauvegardes du journal de transactions de cette base de données. Vous jugerez peut-être que ces éléments supplémentaires rendent les choses plus compliquées. Bien qu'il porte le même nom, ce plan supplémentaire n'est pas le même que celui que vous avez créé. SQL Server tient simplement ce second plan en réserve pour le cas où vous feriez un changement de rôle entre le serveur primaire et secondaire.

Superviser log shipping sur le serveur moniteur. Une fois log shipping en place, SQL Server active l'utilitaire Log Shipping Monitor d'Enterprise Manager sur le serveur moniteur. En outre, SQL Server crée deux alert jobs SQL Agent : un pour la sauvegarde et l'autre pour des conditions de désynchronisation.
Pour employer l'utilitaire, ouvrez Enterprise Manager et connectez-vous au serveur moniteur, allez jusqu'au noeud Management, et sélectionnez le Log Shipping Monitor. Quand vous sélectionnez l'utilitaire, il présente une liste de paires de log shipping. Faites un clic droit sur l'une des paires pour voir son historique de sauvegarde, copie et restauration. Les historiques de copie et restauration sont particulièrement utiles parce qu'ils offrent un accès rapide à  des informations d'erreurs plus détaillées que celles que l'on pourrait trouver dans les
historiques des jobs copy et restore de SQL Agent du serveur secondaire.

Quand vous ouvrez la boîte de dialogue Properties d'une paire et allez à  l'onglet Status, illustré figure 5, vous pouvez voir l'état des processus de sauvegarde, de copie, et de restauration de la paire. L'état peut être Normal ou Out-of-Sync. Si le SQL Server Agent n'a pas encore copié ou restauré un journal de transactions, la boîte de dialogue affichera le nom du fichier log comme first_file_000000000000.trn. Ce n'est pas le nom d'un fichier réel mais simplement un moyen pour l'utilitaire d'indiquer que le SQL Server Agent n'a encore traité aucun fichier. L'onglet Status montre également les deltas Backup, Copy et Load (c'est-à -dire restauration) en minutes à  l'heure courante. Il faut fermer et réouvrir la boîte de dialogue pour rafraîchir les données de cet onglet, car elles ne le font pas automatiquement.
SQL Server n'utilise que deux des tables log shipping msdb pour stocker les informations sur les paires log shipping. Dans chaque table, SQL Server attribue un ID aux entrées de lien, et une contrainte de clé étrangère dans log_shipping_secondaries fait référence au primary-id de log_shipping_primaries. (Ces deux tables sont les seules tables log shipping contenant une relation de clé étrangère.) La table log_shipping_primaries contient une ligne pour chaque base de données source de log shipping, l'état du job de sauvegarde du journal de transactions, et des informations de panne planifiées (qui servent à  éviter des alertes injustifiées). La table log_shipping_secondaries contient une ligne pour chaque base de données de destination qui appartient à  une base de données source log shipping particulière. Les lignes liées constituent les paires de log shipping qui apparaissent sans le Log Shipping Monitor.
La boîte de dialogue Log Shipping Pair Properties de chaque paire de log shipping contient un onglet Source et un onglet Destination, permettant d'ajuster les informations concernant les seuils des alertes de défaillance de sauvegarde et des alertes de désynchronisation, respectivement. Ces alertes font référence à  deux jobs SQL Agent s'exécutant sur le serveur moniteur : Log Shipping Alert Job - Backup et Log Shipping Alert Job - Restore. Par défaut, chacun des jobs s'exécute une fois par minute. Ces jobs génèrent une erreur dans le journal Windows 2000 ou Windows NT Application quand le délai de sauvegarde de n'importe quelle paire de log shipping dépasse le seuil d'alerte de sauvegarde ou quand le processus de copie et de restauration de la paire est retardé au-delà  du seuil de désynchronisation.