> Data > Log Shipping dans SQL Server 2000 (Partie I)

Log Shipping dans SQL Server 2000 (Partie I)

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par Ron Talmage - Mis en ligne le 29/04/2002
Log Shipping augmente la disponibilité d'une base de données SQL Server en copiant et en restaurant les journaux de transactions de la base de données dans une autre base sur un serveur standby. Comme la base de données standby reçoit toutes les modifications apportées à  la base de données originale, elle en est le double exact ...... sauf pendant le court laps de temps de l'opération de copie/chargement. Donc, en cas d'indisponibilité du serveur primaire original, on peut transformer le serveur standby en un nouveau serveur primaire. Quand le serveur primaire original redevient disponible, on peut en faire un nouveau serveur standby - et inverser ainsi les rôles des deux serveurs. Dans les éditions SQL Server 2000 Enterprise et Developer, Microsoft fournit un utilitaire Log Shipping dans Enterprise Manager - dans le cadre du Database Maintenance Plan Wizard. Auparavant, il fallait construire votre propre système Log Shipping ou - dans le cas de SQL Server 7.0 - utiliser les outils de Log Shipping non supportés disponibles dans le Microsoft BackOffice 4.5 Resource Kit. Le nouveau wizard facilite les opérations de préparation, configuration et supervision du Log Shipping de SQL Server 2000. (Pour vérifier les détails techniques de cet article, j'ai utilisé SQL Server 2000 Enterprise Edition avec Service Pack 1 - SP1. Néanmoins, d'après la liste de corrections, SP1 ne corrige aucun des bogues associés au log shipping.)

Log Shipping dans SQL Server 2000 (Partie I)

Le serveur primaire est le serveur de production sur lequel s’effectue le vrai travail. Il contient la base de données source. Le serveur secondaire contient la base de données de destination dans laquelle on copie et restaure les journaux de transactions de la base de données source. Un serveur moniteur supervise les serveurs primaire et secondaire. Contrairement à  la méthode de supervision du log shipping à  partir du serveur secondaire de SQL Server 7.0, le log shipping de SQL Server 2000 se sert de l’utilitaire Log Shipping Monitor d’Enterprise Manager pour superviser chaque paire de log shipping. Microsoft conseille d’installer cet utilitaire sur un serveur moniteur distinct.

Pour préparer le log shipping de SQL Server 2000, utilisez Database Maintenance Plan Wizard d’Enterprise Manager. Mais avant d’utiliser le wizard, quelques préparations sont nécessaires. Pour commencer :

1. Identifiez les paires de log shipping (c’est-à -dire les combinaisons serveur primaire/serveur secondaire que vous voulez faire participer au log shipping). Bien que vous puissiez préparer le log shipping entre deux bases de données sur un serveur, cet article suppose que vous avez l’intention de le faire d’un serveur sur un autre.

2. Identifiez un serveur moniteur, qui doit être bien sûr distinct des serveurs primaire et secondaire.

3. Etablissez la sécurité vis-à -vis de tous les serveurs. Le compte Windows que vous utilisez pour installer le log shipping doit posséder les privilèges sa (systems administrator) de SQL Server sur tous les serveurs.

4. Créez des file shares primaire et secondaire. Commencez par créer un share pour le dossier dans lequel les journaux de transactions de la base de données source résideront. Ensuite, créez un share pour le dossier du serveur secondaire dans lequel vous envisagez de copier et de restaurer les fichiers log de transactions. Pour clarifier l’objectif du file share, indiquez les noms du serveur et de la base de données dans le file share. Si les file shares existent déjà , il faudra peut-être supprimer ou déplacer d’autres fichiers, particulièrement les anciens fichiers de sauvegarde des journaux de transactions, des shares. Accordez des autorisations sur ces file shares au compte Windows que le SQL Agent de chaque serveur utilise.

5. Décidez la manière de créer et de synchroniser initialement la base de données de destination. Vous pouvez laisser au processus d’installation du log shipping le soin de créer et de synchroniser initialement la base de données de destination, ou bien vous pouvez restaurer la sauvegarde de base de données complète initiale manuellement.

6. Enregistrez les trois serveurs (c’est-à -dire, primaire, secondaire et moniteur) dans Enterprise Manager.

Après ces préparations, vous êtes prêt à  utiliser le Database Maintenance Plan Wizard pour mettre en place log shipping. L’opération se divise en cinq étapes, illustrées figure 1.
Les deux premières étapes sont facultatives. Si vous n’avez pas encore synchronisé les bases de données source et de destination, l’étape 1 effectue cette tâche en sauvegardant d’un coup la base de données source. A l’étape 2, le wizard copie cette sauvegarde sur le serveur secondaire et la restaure sur la base de données de destination.

Le wizard effectue toujours les trois étapes restantes. A l’étape 3, il crée un job SQL Agent sur le serveur primaire. Ce job sauvegarde périodiquement les journaux de transactions sur des fichiers disque. Le wizard crée également un plan de maintenance de la base de données de log shipping sur le serveur secondaire. Ce plan est constitué de deux jobs SQL Agent : un pour copier les fichiers transaction-log sur le fichier secondaire (étape 4) et un autre pour restaurer les journaux de transactions sur la base de données de destination (étape 5).

Ces étapes créent une paire de log shipping (c’est-à -dire, deux bases de données en relation log shipping). Pour accentuer la redondance ou pour mettre en place un serveur de reporting, vous pouvez constituer d’autres paires de log shipping en établissant le log shipping du serveur primaire vers d’autres serveurs secondaires.

Téléchargez gratuitement cette ressource

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Data - Par iTPro.fr - Publié le 24 juin 2010