Des richesses insoupçonnées à  portée de la main

Avez-vous déjà  réfléchi à  la manière d’actualiser un serveur
de reprise sur sinistre hors site ou de déployer un serveur de
secours à  chaud afin de réduire les délais de reprise locaux ?
Ou que pensez-vous de créer un serveur « miroir » afin de décharger
votre système transactionnel fortement sollicité des
tâches de reporting opérationnel ? J’ai souvent rencontré des
structures qui utilisent des serveurs de secours pour atteindre
ces trois objectifs. Nombre d’entre elles effectuent
une sauvegarde nocturne des bases de données, la copie sur
le réseau, puis la restaure sur un autre serveur. D’autres organisations
placent souvent leurs systèmes de production
hors ligne, détachent la base de données, copient les fichiers
de données et les fichiers journaux sur le réseau, puis réattachent
les bases de données sur les serveurs source et de destination.
Les deux approches — sauvegarde/restauration et
détachement/attachement — fonctionnent, mais elles sont
limitées. Dans les deux cas de figure, vous devez déplacer la
base de données dans son ensemble, d’où un grand nombre
d’opérations d’E/S sur disque, ainsi qu’un trafic réseau
conséquent. Cela pose également un problème d’évolutivité
car, au final, le cycle d’actualisation ne vous laissera pas suffisamment
de temps pour effectuer le processus complet. La
méthode de détachement/attachement requiert également
une mise hors service du système à  chaque actualisation.

L’envoi des journaux constitue une alternative souvent
méconnue de mise à  jour des serveurs en
miroir. Elle utilise les fonctions de sauvegarde
et de récupération intégrées pour
suivre les modifications des données via
une sauvegarde du journal des transactions.
Elle copie automatiquement ce dernier
vers le nouveau serveur et applique
le journal. En déplaçant uniquement les
données modifiées, l’envoi des journaux
évite les opérations d’E/S sur disque fréquentes,
le trafic réseau et les problèmes
d’évolutivité précités. La fonction d’envoi
des journaux a vu le jour dans SQL Server 7.0 et a été considérablement
étendue dans SQL Server 2000 Edition
Enterprise, grâce à  la prise en charge et à  l’automatisation intégrée
du processus d’établissement et de gestion du processus
d’envoi des journaux. L’Edition Standard inclut également
l’envoi des journaux mais, comme dans SQL Server 7.0,
son utilisation nécessite une configuration manuelle. Pour
une présentation détaillée de la mise en place et de la gestion
d’un environnement d’envoi des journaux, consultez les articles
suivants rédigés par Ron Talmage : « Log Shipping dans
SQL Server 2000, Partie 1 » (mars 2002) et « Log Shipping
dans SQL Server 2000, Partie 2 » (mars 2002) ou sur www.itpro.
fr