EMS logo

Produits

SQL Backup for SQL Server

Notre statut de partenariat

Microsoft Certified Partner
Oracle Certified Partner
Embarcadero Technology Partner

EMS SQL Backup for SQL Server

FAQ - Produits

Automatisation du processus d'expédition des journaux à EMS Backup SQL

Le mécanisme d'expédition de journal est envisagé pour augmenter la protection du basculement de la configuration des BD dans Microsoft SQL Server. Son essence se réduit à la copie des fichiers de sauvegarde du journal des transactions des BD d'une instance unique de SQL Server à une autre instance et à leur restauration ensuite dans la base de données cible sans fournir un accès partagé. Le contrôle du processus de copie et de restauration du fichier de sauvegarde pendant l'automatisation de l'expédition des journaux peut présenter une certaine difficulté, car tout fichier de sauvegarde "manqué" sur le serveur cible entraînera l'impossibilité d'appliquer les fichiers suivants et la nécessité à restaurer à partir de la sauvegarde complète de BD.

EMS SQL Backup fournit des outils pratiques d'automatisation et de contrôle du processus d'expédition de journal qui doivent être examinés dans cet article avec une référence spécifique.

Afin d'ajuster l'expédition des journaux dans le programme, il faut effectuer les actions préparatoires suivantes:

  • Enregistrer les deux instances de SQL Server (primaire et secondaire) dans la console d'administration de SQL Backup;
  • Installer les composants du côté du serveur de SQL Backup dans les deux instances enregistrées;
  • Dans l'intérêt de la commodité de la gestion des politiques, on peut créer une solution distincte et faire glisser les serveurs là-bas.

Création de la politique

Maintenant, nous pouvons commencer à créer et à configurer la politique d'expédition de journal. Pour créer une politique, nous devons cliquer avec le bouton droit de la souris sur la solution et sélectionner ‘Maintenance Policies | Create New Policy’ dans le menu contextuel.

Lors de la première étape de l'assistant ouvert, nous devrions entrer le nom de la politique et définir la règle de l'application de l'heure de son exécution dans la section ‘In different time zones schedule tasks on basis of’. Pour l'expédition des journaux, il est important de fournir la synchronisation de l'exécution des tâches sur les serveurs principal et secondaire qui peuvent être dans des fuseaux horaires différents, c'est pourquoi il est nécessaire de choisir la valeur ‘Home time zone...’.

Dans ce cas, l'heure de début de la politique sur chaque instance de SQL Server sera calculée de telle sorte qu'elle coïncide avec le temps requis de la machine client (sur laquelle la console EMS SQL Backup est installée). Il est à noter que la synchronisation incorrecte du temps d'exécution de la tâche sur deux instances n'entraînera pas l'échec de la politique. Si au début de la première démarche de la politique l'initiation de la tâche sur le serveur cible se déroule plus tôt que sur le principal, l'état de la première performance est erroné, mais tous les démarrages ultérieurs réussiront.

À la première étape de l'assistant de création de la politique, il est nécessaire d'ajouter l'étape de la tâche et de définir sa planification. Lors de l'ajout de la première étape, sélectionnez le type ‘Transaction Log Shipping’ pour ouvrir l'assistant pour la configuration de l'étape d'expédition du journal. À la deuxième étape de cet assistant, nous devons choisir l'instance principale de SQL Server dans la liste déroulante 'Source server' et l'instance cible dans la liste déroulante 'Destination server'. Toutes les bases de données du serveur principal seront représentées dans le tableau:

La base de données cible doit être sélectionnée dans la liste 'Destination DB', puis il faut cliquer sur l'option 'Overwrite'. Si l'option 'Overwrite' est cochée lors de la création et de l'application des paramètres de la stratégie, la copie complète de sauvegarde de la base de données sera transférée et restaurée avec l'option de remplacement sur le serveur cible. Pendant la restauration les fichiers de base de données seront créés dans les répertoires définis dans les champs 'Data folder' et 'Log folder' du serveur cible. Les répertoires peuvent être modifiés si nécessaire.

Les réglages de la troisième étape de l'assistant peuvent être laissés inchangés et nous allons à la 4ème étape. Le répertoire réseau sur lequel les fichiers de sauvegarde des journaux seront copiés doit être configuré dans le champ ‘Network shared folder’.

Le répertoire peut être situé sur la machine du serveur SQL principal, secondaire ou sur la troisième machine qui se trouve dans le réseau local et accessible via NetBIOS. Le chemin d'accès est défini dans le format UNC (Universal Naming Convention) tel qu'il est illustré dans l'exemple. Le plus souvent, le dossier partagé sur la machine serveur cible est utilisé. Il faut se rappeler qu'il sera adressé au nom des services de SQL Backup fonctionnant sur les deux machines (instances SQL Server principales et secondaires). La fonctionnalité des paramètres de l'autorisation de réseau de l'utilisateur explicitement donnés (section ‘Authorization’) est envisagée dans le programme afin d'éviter la confusion des privilèges d'accès appliqués. La vérification de l'accès au dossier réseau avec les paramètres donnés des deux machines est réalisée en cliquant sur le bouton ‘Check’. Notre recommandation: vérifiez toujours les paramètres définis de cette façon. Il faut spécifier le chemin d'accès sur la machine cible dans le champ ‘Destination folder’ où les fichiers de restauration directe seront copiés. En outre, nous devrions définir les options de restauration de base de données cible.

La base de données cible est inaccessible pour les modifications, mais on peut choisir l'un des deux états où elle restera après la restauration des journaux. Une fois cette option définie, nous continuons jusqu'à la dernière étape de l'assistant et complétons l'addition de l'étape d'expédition du journal.

Après avoir retourné à l'assistant de création de la politique, il est nécessaire d'ajouter la planification d'exécution. Si l'expédition du journal doit se produire toutes les demi-heures, la planification peut être ajusté comme suit:

Une fois les paramètres de la planification appliqués, l'arborescence des politiques démontrera la seule tâche qui contient une étape (opération) et une seule planification.

Cela signifie que les paramètres sont corrects et que vous pouvez passer à l'étape suivante du réglage des propriétés de la politique – réglage de la notification. Il suffit de choisir uniquement l'instance du serveur cible pour l'alerte, car l'état de la restauration est plus important que l'état de la sauvegarde et est en fait l'état de la politique entière, après quoi nous devrions définir l'événement et la e-mail.

Après cela, vous devriez passer à l'étape 4 et appliquer la politique en cliquant sur le bouton ‘Finish’. Tout en déployant les paramètres de la politique sur les deux serveurs, la copie de sauvegarde complète de la base de données sera également transférée.

Contrôle d'exécution

Pour voir l'état d'exécution de la tâche d'expédition de journal, il faut sélectionner la solution et la politique créées dans la section ‘Policies’. L'état général de la politique sera reflété dans la colonne ‘Status’ de la section ‘Policies’. Les statuts des exécutions séparées seront reflétés dans le champ ‘Status’ de la section ‘Launches’.

Si une erreur se produit sur l'un des serveurs pendant l'exécution, il faut développer les tâches de la politique dans la section ‘Policies’ pour voir les détails, puis choisir la tâche ayant l'état ‘Fail’, choisir le lancement avec l'état ‘Fail’ dans la section ‘Launches’, déplier ses étapes et cliquer sur ‘Show details’.

Tout le journal des étapes sera affiché dans la fenêtre ouverte. Si le problème est éliminé, vous pouvez choisir un démarrage échoué, cliquer avec le bouton droit de la souris et sélectionner ‘Ignore error for selected launches’. Cela corrigera l'état de la politique globale.

En conclusion, il convient de noter que si la tâche a échoué à cause d'une raison quelconque sur le serveur cible, au moment du prochain lancement, le programme tentera de restaurer tous les fichiers de sauvegarde de journaux non restaurés précoces pour fournir l'exactitude de l'état de la base de données et la possibilité d'opérations de restauration ultérieures.