Présentation de l'enregistrement des transactions

 

S’applique à : Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Dernière rubrique modifiée : 2007-08-30

Cette rubrique décrit l'enregistrement des transactions dans Microsoft Exchange Server 2007 et inclut une brève présentation de l'enregistrement circulaire.

L'enregistrement des transactions Exchange Server est un mécanisme de récupération robuste de l'ESE (Extensible Storage Engine) conçu pour restaurer de manière fiable une base de données Exchange dans un état cohérent après tout arrêt soudain de la base de données. Le mécanisme d'enregistrement est également utilisé pour restaurer les sauvegardes en ligne.

Enregistrement des transactions Exchange

Avant que des modifications ne soient apportées à un fichier de base de données Exchange, Exchange écrit les modifications dans un fichier journal des transactions. Une fois qu'une modification a été enregistrée en toute sécurité, elle peut être écrite dans le fichier de base de données. En général, les utilisateurs finaux peuvent accéder à ces modifications après qu'elles ont été enregistrées dans le journal des transactions, mais avant qu'elles ne soient écrites dans le fichier de base de données.

Exchange utilise un système de gestion de mémoire interne sophistiqué. Réglé pour des performances élevées, ce système peut gérer de façon efficace la mise en cache de dizaines de giga-octets (Go) de pages de base de données. Par conséquent, l'écriture physique des modifications dans le fichier de base de données est une tâche secondaire dans le cadre du fonctionnement normal.

Si une base de données s'arrête soudainement, les modifications mises en cache ne sont pas perdues même si le cache mémoire a été détruit. Au redémarrage de la base de données, Exchange analyse les fichiers journaux, reconstruit et applique toutes les modifications non encore écrites dans le fichier de base de données. Ce processus est appelé relecture des fichiers journaux. La base de données est structurée de telle façon qu'Exchange peut déterminer si les opérations figurant dans les fichiers journaux ont déjà été appliquées à la base de données, doivent être appliquées à la base de données ou n'appartiennent pas à la base de données.

Plutôt que d'écrire les informations journalisées dans un fichier volumineux, Exchange utilise une série de fichiers journaux d'un mégaoctet (ou 1 024 kilo-octets) chacun. Lorsqu'un fichier journal est plein, Exchange le ferme et le renomme avec un numéro de séquence. Le nom du premier journal rempli se termine par Enn00000001.log. nn correspond à un nombre à deux chiffres appelé nom de base ou préfixe de journal.

Les fichiers journaux de chaque groupe de stockage sont identifiés par des noms de fichier constitués de préfixes numérotés (par exemple, E00, E01, E02 ou E03). Le fichier journal en cours pour un groupe de stockage se nomme simplement Enn.log ; un numéro de séquence lui est affecté une fois qu'il est rempli et fermé.

Le fichier de point de contrôle (Enn.chk) suit la progression d'Exchange de l'écriture des informations enregistrées dans les fichiers de base de données. Un fichier de point de contrôle est associé à chaque flux de journal. Il y a un flux de journal pour chaque groupe de stockage. Dans un groupe de stockage, toutes les bases de données partagent un flux de journal unique. Ainsi, un fichier journal contient souvent des opérations pour plusieurs bases de données.

Les fichiers journaux sont numérotés en hexadécimal, de sorte que le fichier journal après E0000000009.log et E000000000A.log et non E0000000010.log. Vous pouvez convertir les numéros de séquence de fichier journal en valeurs décimales à l'aide de la Calculatrice Windows (Calc.exe) en mode Scientifique. Pour ce faire, exécutez le programme Calc.exe, puis dans le menu Affichage, cliquez sur Scientifique.

Pour afficher le numéro de séquence d'un fichier journal spécifique, vous pouvez examiner son en-tête à l'aide de l'outil Utilitaires de base de données Exchange Server (Eseutil.exe). La première page de 4 Ko de chaque fichier journal contient des informations d'en-tête qui décrivent et identifient le fichier journal et les bases de données associées. La commande Eseutil /ml [nom de fichier journal] affiche les informations d'en-tête. Pour plus d'informations sur l'outil Eseutil, consultez la rubrique Eseutil.

Si vous utilisez un commutateur incorrect pour afficher un en-tête, (par exemple, si vous utilisez /ml avec un en-tête de base de données au lieu de /mh), une erreur s'affiche ou les informations d'en-tête affichées peuvent être tronquées ou incorrectes.

Vous ne pouvez pas afficher l'en-tête d'une base de données lors du montage de la base de données. Vous ne pouvez pas non plus afficher l'en-tête du fichier journal actuel (Enn.log) lors du montage d'une base de données dans le groupe de stockage. Exchange conserve le fichier journal en cours ouvert tant que la base de données l'utilise. Vous pouvez toutefois afficher l'en-tête du fichier de point de contrôle pendant le montage des bases de données. Exchange met à jour le fichier de point de contrôle toutes les trente secondes et son en-tête est consultable sauf lorsque des mises à jour interviennent.

En tant qu'administrateur Exchange, il est important de comprendre les en-têtes de fichier Exchange. Si vous comprenez les en-têtes de fichier, vous pouvez identifier les fichiers journaux associés à une base de données, ainsi que les fichiers nécessaires pour l'exécution d'une récupération.

Dans l'exemple d'en-tête de fichier journal suivant, notez les quatre premières lignes.

Base name: e00
Log file: e00.log
lGeneration: 11 (0xB)
Checkpoint: (0xB,7DC,6F)

Ces lignes d'en-tête de fichier journal montrent qu'il s'agit du fichier journal en cours car le nom de fichier journal n'inclut pas de numéro de séquence. La ligne lGeneration montre que lorsque le journal est rempli et fermé, son numéro de séquence est B, ce qui correspond à la valeur décimale 11. Le nom de base étant e00, le nom du fichier journal final sera E000000000B.log.

La valeur Checkpoint de l'exemple d'en-tête précédent n'est pas lue à partir de l'en-tête de fichier journal mais est affichée comme si c'était le cas. Eseutil.exe lit la valeur Checkpoint directement à partir de Enn.chk de sorte que vous n'avez pas à entrer de commande distincte pour déterminer l'emplacement du fichier de point de contrôle. Si le fichier de point de contrôle a été détruit, la valeur Checkpoint est NOT AVAILABLE. Dans ce cas, le point de contrôle est le fichier journal en cours (0xB) ; les numéros 7DC et 6F indiquent la progression du point de contrôle dans le fichier journal. Notez que vous aurez rarement besoin de ces informations.

Si le fichier de point de contrôle est détruit, Exchange peut quand même effectuer une récupération et relire correctement les fichiers journaux. Pour ce faire, Exchange lance l'analyse des fichiers journaux en commençant par le fichier le plus ancien disponible (et par le journal correspondant au point de contrôle). Exchange ignore les données déjà appliquées à la base de données et passe en revue les journaux de façon séquentielle jusqu'à rencontrer des données devant être appliquées.

En général, l'analyse par Exchange d'un fichier journal déjà appliqué à la base de données dure d'une à deux secondes. S'il y a des opérations dans un fichier journal qui doivent être écrites dans la base de données, leur application peut prendre entre 10 secondes et plusieurs minutes. En moyenne, le contenu d'un fichier journal peut être écrit dans la base de données en 30 secondes ou moins.

Lorsqu' une base de données Exchange est arrêtée normalement, toutes les données en attente sont écrites dans les fichiers de base de données. Après un arrêt normal, l'ensemble des fichiers de base de données est considéré comme cohérent et Exchange le détache de son flux de journal. Cela signifie que les fichiers de base de données sont désormais auto-contenus et donc totalement actualisés. Les journaux des transactions ne sont pas requis pour démarrer les fichiers de base de données.

Vous pouvez déterminer si une base de données a été arrêtée correctement en exécutant la commande Eseutil /mh et en examinant les en-têtes de fichier.

Tous les fichiers journaux peuvent être supprimés en toute sécurité sans affecter les bases de données lorsque toutes les bases de données d'un groupe de stockage sont déconnectées et en état d'arrêt correct. Si vous supprimez ensuite tous les fichiers journaux, Exchange génère une nouvelle séquence de journaux commençant par le fichier Enn00000001.log. Les fichiers de base de données peuvent même être déplacés sur un autre serveur ou groupe de stockage comportant des fichiers journaux existants ; les bases de données s'associent d'elles-mêmes à un autre flux de journal.

Notes

Même s'il est possible de supprimer les fichiers journaux après l'arrêt des bases de données d'un groupe de stockage, cela affecte les possibilités de restauration des sauvegardes antérieures et de reprise. La base de données en cours n'a plus besoin des fichiers journaux existants mais ceux-ci peuvent être nécessaires si vous devez restaurer une ancienne base de données.

Si une base de données est dans un état d'arrêt incorrect, tous les journaux des transactions existants à partir du point de contrôle doivent être présents avant que vous puissiez à nouveau monter la base de données. Si ces journaux ne sont pas disponibles, vous devez réparer la base de données en exécutant la commande Eseutil /p pour que la base de données soit cohérente et prête à démarrer.

Attention :

Si vous devez réparer une base de données, certaines données sont perdues. La perte de données est souvent minime ; elle peut toutefois être catastrophique. Après l'exécution de la commande Eseutil /p sur une base de données, vous devez réparer totalement la base de données via les deux opérations suivantes : Dans un premier temps, exécutez Eseutil/d pour défragmenter la base de données. Cette opération supprime et recrée les index et arborescences de la base de données. Dans un deuxième temps, exécutez le vérificateur d'intégrité de la banque d'informations (Isinteg.exe) en mode –fix. Cet outil analyse la base de données en recherchant les incohérences logiques créées lors de la suppression des journaux des transactions en attente. Par exemple, il peut y avoir des références dans la base de données qui ne sont pas actualisées les unes par rapport aux autres. Isinteg.exe tente de corriger de tels problèmes en minimisant autant que possible les pertes de données.

En plus de permettre à Exchange d'effectuer une récupération de façon fiable suite à un arrêt inattendu de la base de données, l'enregistrement des transactions est également essentiel pour créer et restaurer les sauvegardes en ligne. Pour plus d'informations sur la création et la restauration des sauvegardes en ligne, consultez la rubrique Sauvegarde et restauration de base de données.

Enregistrement circulaire

Bien que ce ne soit pas une pratique recommandé, vous pouvez activer l'enregistrement circulaire dans Exchange afin de gagner de l'espace disque. L'enregistrement circulaire permet à Exchange de remplacer les fichiers journaux des transactions une fois les données contenues dans les fichiers journaux validées dans la base de données. Toutefois, si l'enregistrement circulaire est activé, vous pouvez récupérer les données depuis la dernière sauvegarde complète uniquement.

Dans l'enregistrement standard des transactions utilisé par Exchange 2007, chaque transaction de base de données dans un groupe de stockage est consignée dans un fichier journal, puis dans la base de données. Lorsqu'un fichier journal atteint la taille d'un mégaoctet, il est renommé et un autre fichier journal est créé. Avec le temps, vous obtenez un ensemble de fichiers journaux. En cas d'arrêt inattendu d'Exchange, vous pouvez récupérer les transactions en relisant les données depuis ces fichiers journaux dans la base de données. L'enregistrement circulaire écrase et réutilise le premier fichier journal une fois ses données écrites dans la base de données.

L'enregistrement circulaire est désactivé par défaut dans Exchange 2007. Si vous l'activez, vous réduisez l'espace de stockage nécessaire sur les lecteurs. Toutefois, sans un ensemble complet de fichiers journaux des transactions, vous ne pouvez récupérer aucune donnée postérieure à la dernière sauvegarde complète. L'enregistrement circulaire n'est dès lors pas recommandé dans un environnement de production normal.

Pour des informations sur l'activation et la désactivation de l'enregistrement circulaire dans Exchange 2007, consultez la rubrique Procédure d'activation ou de désactivation d'un enregistrement circulaire pour un groupe de stockage.

Réplication continue et enregistrement circulaire

Vous pouvez combiner un enregistrement circulaire avec une réplication continue. Dans cette configuration, vous avez un nouveau type d'enregistrement circulaire nommé enregistrement circulaire avec réplication continue (CRCL), qui diffère de l'enregistrement circulaire ESE décrit plus haut dans cette rubrique. Tandis que l'enregistrement circulaire ESE est effectué et géré par le service Banque d'informations de Microsoft Exchange, le CRCL est effectué et géré par le service de réplication de Microsoft Exchange.

Une fois activé, l'enregistrement circulaire ESE ne génère pas de fichiers journaux supplémentaires mais remplace le fichier journal en cours si nécessaire. Toutefois, dans un environnement de réplication continue, des fichiers journaux sont nécessaires pour l'envoi et la relecture de journal. Par conséquent, lorsque vous activez le CRCL, le fichier journal en cours n'est pas remplacé et des fichiers journaux fermés sont générés pour le processus d'envoi et de relecture de journal. Plus particulièrement, le service de réplication de Microsoft Exchange gère le CRCL de façon à ce que le journal soit tenu à jour en permanence et à ce qu'aucun journal ne soit supprimé par la fonction de suppression de journal s'il est encore nécessaire pour la réplication. C'est pourquoi, l'activation du CRCL ne doit pas affecter négativement la réplication.

La version de publication (RTM) d'Exchange 2007 prend en charge la combinaison de l'enregistrement circulaire avec la réplication continue en cluster (CCR) ou la réplication continue locale (LCR). Toutefois, cette solution n'est pas recommandée car elle ne permet pas d'effectuer une récupération par progression après restauration d'une sauvegarde. Exchange 2007 Service Pack 1 (SP1) permet également l'activation de l'enregistrement circulaire pour des groupes de stockage dans un environnement de CCR, de LCR ou de réplication continue de secours (SCR). Toutefois, cette pratique n'est pas non plus recommandée pour le motif indiqué précédemment. Lorsqu'elle est activée dans l'un de ces environnements, la fonctionnalité est CRCL et non l'enregistrement circulaire ESE (également appelé enregistrement circulaire JET (Joint Engine Technology)). Dans un environnement de CCR, de LCR ou de SCR, vous devez toujours utiliser le processus suivant pour activer ou désactiver l'enregistrement circulaire :

1. Suspendez la réplication continue à l'aide de la cmdlet Suspend-StorageGroupCopy.

2. Activez ou désactivez l'enregistrement circulaire. Pour obtenir la procédure détaillée d'activation ou de désactivation de l'enregistrements circulaire, consultez la rubrique Procédure d'activation ou de désactivation d'un enregistrement circulaire pour un groupe de stockage.

3. Démontez, puis montez la base de données dans la groupe de stockage en cours d'activation ou de désactivation pour l'enregistrement circulaire.

4. Reprenez la réplication continue à l'aide de la cmdlet Resume-StorageGroupCopy.

Pour les groupes de stockage dans un environnement de LCR, avant d'exécuter la cmdlet Enable-StorageGroupCopy pour activer la LCR pour un groupe de stockage, vous devez vous assurer que le paramétrage d'enregistrement circulaire actuel est détecté et utilisé par le service Banque d'informations Microsoft Exchange en démontant, puis en montant la base de données dans le groupe de stockage. Si le service Banque d'informations Microsoft Exchange nécessite un démontage, puis un montage de la base de données pour détecter et utiliser le changement de configuration, le service de réplication de Microsoft Exchange est capable de détecter et d'utiliser le changement de configuration de façon dynamique sans nécessiter de redémarrage. C'est pourquoi, en cas de non exécution de la procédure précédente, une base de données peut se retrouver dans une situation ou le service de réplication de Microsoft Exchange considère que l'enregistrement circulaire est désactivé (ou activé) tandis que le service Banque d'informations Microsoft Exchange considère que l'enregistrement circulaire est dans l'état opposé. Cela peut entraîner une troncature prématurée des fichiers journaux.

Notes

La désactivation de la LCR ou de la SCR permet que des sauvegardes ou un enregistrement circulaire suppriment des fichiers journaux sans effectuer de copie. Il n'y a toutefois pas d'option de désactivation dans la CCR. Que le CRCL soit activé ou non, dans une CCR, les journaux non répliqués ne sont jamais supprimés.

Pour contrôler la quantité de journaux des transactions créés, les administrateurs activent parfois l'enregistrement circulaire lors des déplacements de boîte aux lettres volumineuse. Comme un déplacement de boîte aux lettres est une opération impliquant deux bases de données différentes, vous pouvez activer l'enregistrement circulaire pour les deux bases de données durant le déplacement de boîte aux lettres.

Notes

Comme l'enregistrement circulaire interfère avec la possibilité de mettre à jour le groupe de stockage en cas d'échec, il n'est pas recommandé d'utiliser l'enregistrement circulaire pendant des périodes prolongées.

Vous pouvez activer le CRCL dans des environnements de CCR, de LCR et de SCR à des fins de déplacements de boîte aux lettres ou pour d'autres scénarios qui entraînent une création importante de fichiers journaux. En revanche, lorsque le CRCL est activé, vous ne pouvez pas effectuer de sauvegarde. Par conséquent, vous devez vous assurer de ce qui suit :

• Les déplacement de boîte aux lettres n'interfèrent pas avec les opérations de sauvegarde car si le CRCL est activé, vous ne pouvez pas effectuer de sauvegarde.

• Le CRCL est désactivé une fois les déplacements de boîte aux lettres effectués, de sorte que les sauvegardes peuvent reprendre.