Stratégies de récupération d'une base de données

  • Article

 

Dernière rubrique modifiée : 2006-06-12

Cette section explique la structure d'une base de données et aborde les stratégies de récupération d'une base de données.

Présentation de la structure d'une base de données

Pour comprendre la structuration d'une base de données, vous devez comprendre les niveaux de page, les niveaux de table ESE (Exchange Store Engine) et les niveaux d'application d'une base de données. Chaque niveau est décrit rapidement ci-dessous :

Niveau de page : Le fichier contient une série de pages ordonnée (généralement 4 kilo-octets ou un multiple de 4 kilo-octets), chaque page partageant une structure d'organisation commune. Chaque page dispose d'informations d'en-tête de page et de données de page. Les informations d'en-tête incluent les totaux de contrôle de la page permettant à Exchange de vérifier l'intégrité des données et de corriger les erreurs mono bit sur la page.

Niveau de table ESE : Les groupes de pages sont détenus par les tables gérées par le moteur de base de données ESE. Une base de données Exchange classique contient des milliers de tables individuelles.

Niveau d'application : Le moteur ESE est une base de données polyvalente pouvant être utilisée par différentes applications. Par exemple, Exchange et le service d'annuaire d'Active Directory utilisent tous les deux le moteur ESE. Le moteur de base de données ESE stocke des informations dans ses tables, dirigé par une application spécifique. Le moteur ESE lui-même ne comprend ni les relations entre les tables définies par l'application ni la signification des données stockées dans chaque table.

Présentation des stratégies de récupération d'une base de données

La stratégie la plus simple pour remédier à des dégâts dans les fichiers de base de données est de restaurer une copie de qualité de la base de données à partir d'une sauvegarde et de reprendre cette base de donnée à l'aide des fichiers journaux de transactions générés. L'utilisation de cette stratégie nécessite l'application des trois hypothèses suivantes :

  • Vous avez une sauvegarde de qualité de la base de données.
  • Tous les fichiers journaux de transactions générés depuis la sauvegarde sont disponibles et ne sont pas endommagés.
  • Le problème dans la base de données n'est causé ni par une corruption logique ni par une suppression involontaire. Par exemple, si un antivirus corrompt les messages ou les supprime, ces corruptions et suppressions sont enregistrées dans les fichiers journaux de transactions et relus dans la base de données restaurée à partir de la sauvegarde.

D'autres stratégies de récupération d'une base de données sont décrites ci-dessous.

Déplacement de boîtes aux lettres

Lorsque vous déplacez une boîte aux lettres vers une base de données différente, son contenu est traité par la banque d'informations Exchange au moment de sa création. Les articles endommagés sont ignorés. Par conséquent, le déplacement de toutes les boîtes aux lettres vers une nouvelle base de données est une excellente stratégie pour supprimer les articles endommagés tout en maximisant la récupération du contenu utilisateur.

Après le déplacement d'une boîte aux lettres, les profils des clients Outlook sont mis à jour automatiquement pour pointer les clients vers la nouvelle base de données ou le nouveau serveur. Pour cela, le serveur précédent doit rester en ligne avec son service de banque d'informations exécuté jusqu'à ce que tous les clients se soient connectés une fois et aient été redirigés. Si le serveur précédent n'est pas maintenu en ligne, les profils des clients Outlook doivent être mis à jour manuellement ou via des scripts.

Les fichiers client en mode mis en cache ou hors connexion restent actifs après le déplacement de la boîte aux lettres. Les fonctionnalités de règle client sont également préservées lors du déplacement de la boîte aux lettres.

Le déplacement d'une boîte aux lettres a le même effet sur le serveur de destination que la restitution simultanée de tous les articles dans une boîte aux lettres. Par conséquent, si vous déplacez plusieurs boîtes aux lettres, il est conseillé d'effectuer l'opération pendant les heures creuses et de fournir des informations client préalablement quant au moment du déplacement et à la procédure à suivre pour bénéficier d'une aide en cas de problèmes de connexion après le déplacement.

Le déplacement de plusieurs boîtes aux lettres entraîne la génération d'un plus nombre plus grand qu'à l'ordinaire de fichiers journaux des transactions pour la base de données de destination. Vous devez contrôler attentivement l'espace disque des journaux de transaction sur le serveur de destination lors d'une opération de déplacement de boîtes aux lettres en bloc. Si l'espace disque des journaux de transactions est sur le point de devenir insuffisant, vous pouvez exécuter une sauvegarde en ligne complète ou incrémentielle pour supprimer les fichiers journaux ou activer l'enregistrement circulaire dans le fichier journal avant le déplacement et le désactiver juste après le déplacement.

Le déplacement de toutes les boîtes aux lettres vers une nouvelle base de données et le rejet de la base de données précédente maximise la conservation du contenu utilisateur récupérable tout en minimisant les temps d'arrêt de la base de données.

Pour plus d'informations sur la procédure de déplacement d'une base de données Exchange vers un autre serveur ou groupe de stockage, voir la rubrique sur le Déplacement d'une base de données de boîtes aux lettres Exchange vers un autre serveur ou groupe de stockage.

Réparation de la base de données

Généralement, vous ne devez réparer une base de données que lorsqu'il est impossible de la restaurer et de la reprendre. Fréquemment, la réparation d'une base de données prend davantage de temps que la restauration à partir d'une sauvegarde.

Remarque   En cas de base de données sévèrement endommagée, la réparation nécessite encore davantage de temps et la probabilité de succès est inférieure. Si vous effectuez une réparation sur une base de données non ou légèrement endommagée à l'aide du matériel de serveur pour entreprise classique, le processus prendra généralement une heure pour 5 Go de données. Si vous considérez les temps de réparation comme faisant partie de la conception des contrats de niveau de service, vous devez réaliser vos propres critères d'évaluation sur un matériel de suivi de la base de données classique identique à celui utilisé pour Exchange dans votre organisation. Si une base de données a été sévèrement endommagée, les temps de réparation peuvent augmenter d'un facteur 10 ou plus.

Pour plus d'informations sur l'utilisation de l'utilitaire Eseutil pour la réparation d'une base de données, voir la rubrique sur le Mode Réparation d'Eseutil /P.

Restauration, réparation et fusion

La restauration, la réparation et la fusion d'une base de données sont souvent appelées stratégie hybride. Elle peut être utilisée lorsque vous disposez d'une sauvegarde de qualité mais pas de tous les journaux des transactions créés après la sauvegarde.

Dans ce cas, vous pouvez restaurer la sauvegarde et, en parallèle, réparer la copie endommagée de la base de données dans un groupe de stockage de récupération sur le même serveur ou sur un serveur de laboratoire. Vous pouvez alors utiliser la fonctionnalité Groupe de stockage de récupération pour monter séparément les deux copies de la base de données et fusionner les données de la base de données réparée vers la base de données restaurée.

Si la réparation réussit, cette stratégie permettra de récupérer presque autant de données que si vous aviez pu utiliser les journaux de transactions. Pour plus d'informations sur les diverses stratégies hybrides utilisant les groupes de stockage de récupération, voir le guide sur l'utilisation des groupes de stockage de récupération d'Exchange Server 2003 (en anglais) (https://go.microsoft.com/fwlink/?LinkId=47589).

Pour plus d'informations

Pour plus d'informations, voir les rubriques suivantes du Guide de l'Utilitaire de base de données d'Exchange Server :