Comment supprimer les fichiers du journal des transactions Exchange Server

Journaux des transactions de base de données Exchange Server enregistrer toutes les modifications apportées à une base de données Exchange Server. Avec le temps, ces fichiers journaux s'accumulent et utilisent tout l'espace disque disponible si elles ne sont pas supprimées périodiquement à partir du disque dur.

Fichiers du journal des transactions Exchange avoir une taille fixe. Pour Microsoft Exchange Server 2003 et toutes les versions antérieures d'Exchange Server, cette taille est exactement 5 mégaoctets. Lorsque le journal des transactions est plein, le journal des transactions est renommé avec un numéro de séquence numérique et un nouveau journal actuel est généré.

Le journal des transactions en cours est celui plus récemment créé par Exchange Server. Dans Microsoft Exchange Server 5.5, le journal des transactions en cours est toujours nommé EDB.log . Dans Microsoft Exchange 2000 Server et dans Exchange Server 2003, le journal actuel est nommé par le préfixe du groupe de stockage. Pour plus d'informations, reportez-vous à la section ? groupes de stockage ?.

Exchange supprime automatiquement les fichiers journaux inutiles à l'aide de l'une des méthodes suivantes :

• Si l'enregistrement circulaire est activé, Exchange Server supprime les journaux des transactions peu après que qu'ils ont été écrites dans le fichier de base de données. Ce processus peut provoquer un retard sur certains systèmes inactives jusqu'à ce que le fichier Exx.log actuel du groupe de stockage approprié ou le fichier Edb.log dans Exchange Server 5.5 devient complet et doit être renommé. Pour accélérer la création de fichier journal et la suppression automatique, vous pouvez vous envoyer un message électronique avec une pièce jointe (Mo) de 5 mégaoctets.
  
  note Par défaut, l'enregistrement circulaire est activé dans Exchange Server 5.5. Par défaut, l'enregistrement circulaire n'est pas activé dans Exchange 2000 Server ou Exchange Server 2003.
• Si l'enregistrement circulaire est désactivé, Exchange Server supprime journaux excédentaires après complète ou incrémentielle sauvegarde en ligne toutes les bases de données d'un groupe de stockage est effectuée.

Pour plus d'informations sur comment fonctionne le mécanisme de journalisation d'Exchange et sur la façon pour le modifier, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft : Si l'une des conditions suivantes est remplie, les fichiers du journal des transactions sont augmentée dans nombre jusqu'à ce que l'espace disque dur est épuisé :

• Le programme de sauvegarde ne supprime pas les fichiers du journal des transactions.
• Le programme de sauvegarde a arrêté l'exécution.
• Les fichiers du journal des transactions sont purgés pas à l'aide une autre méthode.

Vous devrez peut-être parfois supprimer manuellement les fichiers du journal des transactions si vous avez exécuté manque d'espace disque dur. Ou, vous devrez parfois supprimer manuellement transaction journal fichiers si vous envisagez de manque d'espace disque dur avant d'exécuter une sauvegarde en ligne complète ou incrémentielle de toutes les bases de données dans un groupe de stockage particulier. Si vous supprimez un journal qui contient des données qui n'ont pas encore été écrites dans les fichiers de base de données, les bases de données pourra plus être montées après un arrêt anormal. Par conséquent, vous devez déterminer les journaux sont sûrs supprimer avant de vous supprimer manuellement les fichiers du journal des transactions Exchange Server.

note Pour les besoins de cet article, supprimer un fichier du journal des transactions signifie déplacer ce fichier du journal des transactions vers un autre point où le fichier du journal des transactions peut être sauvegardé, stockée ou supprimés, en fonction de vos besoins. Pour les besoins de cet article, « suppression » d'un fichier journal des transactions fait référence à du type de suppression ne vous laisse soit pour sauvegarder ou restaurer ce fichier du journal des transactions.

Suppression manuellement des fichiers de journaux de transaction qui ne sont pas nécessaires

Pour supprimer correctement les fichiers journaux des transactions en trop, procédez comme suit :

1. Arrêtez tous les les bases de données dans le groupe de stockage.
2. Vérifiez l'état de chaque fichier de base de données dans le groupe de stockage particulier. Pour savoir comment faire pour vérifier l'état de chaque fichier de base de données, reportez-vous à la section États de base de données.
3. Effectuez l'une des actions suivantes :
   • Si un ou plusieurs des bases de données se trouvent dans un état d'arrêt incorrect ou Inconsistent , déterminer les fichiers du journal des transactions peuvent être supprimés sans affecter la cohérence de la base de données. Pour plus d'informations, reportez-vous à la section « Enregistrer les fichiers ».
   • Si toutes les bases de données se trouvent dans un état Arrêt correct ou cohérente , vous pouvez supprimer tous les fichiers de journaux de transaction, sauf pour le fichier journal de transactions en cours. Supprimer le fichier journal en cours lorsque toutes les bases de données sont dans un état d'arrêt correct va provoquer une réinitialisation de la séquence de fichier journal. Cela n'empêche pas bases de données de démarrer. Cependant, une réinitialisation de la séquence de fichier journal affecte la possibilité de restaurer une base de données par progression à partir d'une sauvegarde précédente si la situation se produit.
4. Copier tous les fichiers du journal transaction que vous souhaitez supprimer à un autre emplacement avant de façon permanente les supprimer du disque dur journal des transactions. Ne définitivement supprimez pas les fichiers du journal des transactions jusqu'à ce que vous ayez correctement terminé une sauvegarde de toutes les les bases de données du groupe de stockage en ligne complète.

Les sections suivantes décrivent la relation entre la base de données Exchange Server et les fichiers du journal des transactions. Les sections fournissent également des instructions détaillées sur la façon de déterminer quels fichiers journaux sont sans danger supprimer.

États de la base de données

Si une base de données Exchange Server n'a pas été arrêté correctement, la base de données reste liée » à son flux de journal de transaction. Cela signifie que pas toutes les données à partir du fichier journal des transactions a été sécurisées dans les fichiers de base de données. Lors du démarrage suivant de la base de données, Exchange Server détecte cette condition. Exchange Server applique ensuite les données manquantes aux fichiers de base de données. Si les fichiers journaux qui contiennent ces données ne sont pas disponibles, Impossible de démarrer la base de données.

Lorsqu'une base de données Exchange Server est arrêté correctement, cette base de données « détache » à partir de ses flux de journal de transaction. Dans ce cas, la base de données ne nécessite pas de fichiers du précédent journal des transactions lorsque que la base de données suivante démarre. Toutefois, ces fichiers journaux peuvent s'avérer utiles si une copie de sauvegarde ou une version antérieure de la base de données venait à être restauré. Les fichiers journaux doit servir à restaurer la base de données vers l'avant à partir du moment de la sauvegarde. Par conséquent, fichiers du journal des transactions ne doivent pas être définitivement supprimés jusqu'à ce que vous soyez sûr de ne pas vouloir à relire les dans une version antérieure de la base de données.

Avant de supprimer manuellement les fichiers du journal des transactions, vous devez déterminer l'état de toute base de données utilisé les fichiers journaux des transactions particulier. Dans ce cas, déterminent le joindre » ou « détacher l'état de chaque base de données utilisé les fichiers journaux des transactions particulier. Vous pouvez déterminer si une base de données est attaché ou détachée en examinant l'en-tête du fichier de base de données en utilisant /mh commande commutateur l'utilitaire Eseutil . Par exemple, exécutez la commande suivante à partir d'une invite de commandes où database_name est le nom de la base de données que vous voulez examiner : Par exemple, pour examiner la base de données de Mailbox Store (Server1), tapez note Pour examiner l'en-tête d'une base de données à l'aide de la commande eseutil , la base de données doit être arrêté.

Après avoir exécuté cette commande, examinez la valeur état dans les informations d'en-tête qui s'affiche. La valeur d'état fournit les informations suivantes sur si la base de données a été détachée correctement :

• Si la base de données a été correctement détachée, la valeur d'état est soit Arrêt correct cohérent , selon la version d'Exchange Server est en cours d'exécution.
• Si la base de données n'a pas été détachée correctement, la valeur d'état est Arrêt incorrect ou Inconsistent . Cela signifie que certaines des fichiers existants du journal des transactions contenir des transactions en souffrance qui sont requis par la base de données. Si vous supprimez les fichiers du journal des transactions dans cette situation, la base de données ne peut pas être démarré à nouveau, sauf si vous restaurez la base de données à partir d'une sauvegarde ou si vous réparez la base de données à l'aide de la commande eseutil et la commande isinteg .
  
  Pour plus d'informations sur la façon de réparer une base de données Exchange Server, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
  812357  (http://support.microsoft.com/kb/812357/ ) Comment gérer votre base de données Exchange après la réparation à l'aide de l'outil de /p Eseutil dans Exchange Server 5.5, dans Exchange 2000 Server et dans Exchange Server 2003

Deux réserver des fichiers journaux des transactions qui agissent qu'espaces réservés et cet espace disque réserve sont également disponibles dans le cas où le disque dur sur lequel les fichiers du journal des transactions sont stockés devient complet. Ces fichiers journaux des transactions réserve sont nommés Res1.log et Res2.log . Si le disque dur où se trouvent les fichiers journaux transaction devient complet, Exchange Server utilise ces fichiers journaux deux réserve des transactions pour continuer à ouvrir une session suffisamment longtemps pour arrêter proprement la base de données. Lorsque Exchange Server ne peut pas créer un fichier du journal des transactions supplémentaires car le disque journal est plein, Res2.log est renommée et est utilisé comme le journal suivant. Si nécessaire, Res1.log également servira.

Parfois, la capacité des fichiers du journal des transactions réserve peut être dépassée. Ainsi, toutes les bases de données dans le groupe de stockage arrêté dans un état d'arrêt incorrect ou Inconsistent .

Avertissement Si vous exécutez manque d'espace disque sur le lecteur du journal des transactions, les bases de données ne peut-être en mesure d'arrêter proprement. Si un ou plusieurs des bases de données se trouvent dans un état d'arrêt incorrect ou Inconsistent et si vous supprimez tous les fichiers du journal des transactions afin de libérer de l'espace disque, aucuns les groupes de stockage concerné bases de données ne seront montées à nouveau sans être réparé ou restauré. Vous ne devez pas supprimer les fichiers journaux qui sont toujours requis par une ou plusieurs des bases de données.

Groupes de stockage

Bases de données Exchange Server sont organisées en groupes de stockage. Un groupe de stockage est un ensemble de bases de données qui partagent un flux de fichier journal transaction unique. Dans Exchange Server 5.5, il est un groupe de stockage banque d'informations unique qui contient au maximum deux fichiers de base de données. Ces fichiers de base de données deux sont nommés Priv.edb et Pub.edb respectivement. En outre, Exchange Server 5.5 contient un groupe de stockage Directory unique qui contient un fichier de base de données unique nommé Dir.edb .

Dans Exchange 2000 Server et dans Exchange Server 2003, il n'est aucun groupe de stockage service d'annuaire. Dans Exchange 2000 Server et dans Exchange Server 2003, peut contenir jusqu'à quatre groupes de stockage banque d'informations par serveur. Chacun de ces groupes de stockage peut contenir jusqu'à cinq bases de données. Les noms de ces bases de données sont configurables par l'administrateur.

Si le lecteur du journal des transactions devient complet, toutes les bases de données dans le groupe de stockage va s'arrêter immédiatement. Lorsque vous démarrez une base de données dans un groupe de stockage, l'état de toutes les bases de données dans le groupe de stockage est vérifiée. N'importe quel relecture du fichier journal des transactions requis est effectuée conjointement pour toutes les bases de données avant que la première base de données puisse commencer. Opérations de relecture transaction journal fichier et les événements s'appliquent généralement à toutes les bases de données dans un groupe de stockage, pas à une base de données individuel.

important Vous devez vérifier que chaque fichier de base de données est dans un état d'arrêt correct ou cohérent . Un ou plusieurs bases de données dans un groupe de stockage particulier peuvent être correctement détachées même si la base de données un autre dans ce même groupe de stockage est correctement détachée. Ne suppose pas que toutes les bases de données dans un groupe de stockage soient dans un état Arrêt correct en fonction de l'état de la première base de données que vous examinez.

note Pour Exchange Server 5.5, vous devez examiner chaque base de données contenues dans un fichier unique .edb à l'aide de la commande eseutil . Pour Exchange 2000 Server et Exchange Server 2003, chaque base de données est divisée en deux fichiers. Les deux fichiers sont un fichier .stm et un fichier .edb . Examiner l'état du fichier .stm et le fichier .edb à l'aide de la commande eseutil .

Fichiers journaux

Pour déterminer les fichiers du journal des transactions sont requis par les bases de données dans un groupe de stockage particulier, procédez comme suit.

Pour Exchange Server 5.5

important Cette section, la méthode ou la tâche, contient des étapes qui vous indiquent comment modifier le Registre. Toutefois, des problèmes graves peuvent se produire si modification incorrecte du Registre. Par conséquent, assurez-vous que ces étapes avec soin. Pour la protection supplémentaire, sauvegarder le Registre avant de le modifier. Ensuite, vous pouvez restaurer le Registre si un problème se produit. Pour plus d'informations sur la façon sauvegarder et restaurer le Registre, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :

1. Dans le programme Administrateur Exchange Server, afficher le chemin de travail de la base de données.
   
   Emplacements de chemin d'accès sont trouvent sur la page de propriétés de base de données les chemins d'accès de l'objet Server. Le fichier point de contrôle ( Edb.chk ) se trouve dans ce chemin d'accès. Si le programme Administrateur n'est pas disponible, vous pouvez afficher le chemin d'accès au travail dans le Registre système. Exécutez l'Éditeur du Registre et développent les sous-clés de Registre suivantes.
   
   Pour la banque d'informations :
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Working Directory
   Pour le répertoire :
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDS\Parameters\DSA Working Directory
2. À partir d'une invite de commandes, déplacer vers le dossier chemin d'accès au travail. Afficher l'en-tête du fichier Edb.chk à l'aide de la commande eseutil :
   Eseutil /mk edb.chk
   Notez que la sortie d'écran est semblable au suivant :

   Microsoft(R) Windows NT(TM) Server Database Utilities
   Version 5.5
   Copyright (C) Microsoft Corporation 1991-1998. All Rights Reserved.
   
   Initiating FILE DUMP mode...
   Checkpoint file: edb.chk
   
   LastFullBackupCheckpoint (0,0,0)
   Checkpoint (157,2860,500)    comment: Checkpoint is in log 157 decimal
   FullBackup (90,8,10)
   FullBackup time:1/15/1999 18:18:36
   IncBackup (0,0,0)
   IncBackup time:0/0/1900 0:0:0
   . . .
   						

   les trois numéros de la ligne de point de contrôle représentent le numéro de génération du fichier journal, un secteur de décalage dans le fichier journal et un octet décalage dans le secteur. Notez le numéro de génération.
3. Convertir le numéro de génération en hexadécimal. Dans cet exemple, décimale 157 se traduit par le nombre hexadécimal 9D. Fichiers du journal Exchange Server sont numérotées avec cinq chiffres hexadécimaux. Par exemple, un fichier journal peut être nommé comme Edb12345.log. Les zéros non significatifs sont utilisées pour ajouter le numéro du journal à cinq chiffres. Par conséquent, le fichier journal point de contrôle dans l'exemple précédent est Edb0009d.log.
   
   note Vous pouvez utiliser le mode scientifique de la calculatrice Windows pour convertir décimal en hexadécimal. Démarrer la Calculatrice. Ensuite, cliquez sur scientifique dans le menu Affichage . Entrez le nombre décimal, puis cliquez sur hexadécimal .
4. Le journal point de contrôle et tous les journaux générés après le journal point de contrôle requises pour démarrer une base de données lorsque la base de données est dans un état Inconsistent . Vous peut ne pas trouvez un fichier journal qui correspond à la valeur point de contrôle que vous avez calculé. Cela peut se produire si le point de contrôle est dans le fichier journal plus récent est nommé EDB.log . Jusqu'à ce que ce journal est plein puis jusqu'à ce qu'un nouveau journal est généré, le nom de fichier du journal actuel n'inclut pas le numéro de séquence de journal.
   
   Vous pouvez vérifier numéro du fichier EDB.log séquence interne réel en affichant l'en-tête du fichier journal à l'aide de la commande eseutil suivante :
   eseutil /ML EDB.log
   Le champ lGeneration de l'en-tête du fichier journal reflète du numéro de séquence réel du fichier journal. Vous devez convertir la valeur de lGeneration hexadécimal.
5. Vous pouvez supprimer en toute sécurité numérotés tous les journaux inférieur le journal point de contrôle. Toutefois, ne supprimez pas le journal point de contrôle lui-même. Dans cet exemple, vous pouvez supprimer Edb0009c.log, Edb0009b.log et ainsi de suite, mais pas Edb0009d.log ou le journal actuel.
   N'oubliez pas de déplacer, pas de supprimer les fichiers journaux. Vous devez arrêter le service de base de données à supprimer fichiers journal sont antérieures à la point de contrôle.

Si vous devez restaurer une sauvegarde, vous devez également restaurer tous les fichiers journaux qui sont créés après cette sauvegarde si vous souhaitez complètement restaurer par progression la base de données. S'il existe un saut dans la séquence des journaux, vous ne pouvez pas restaurer par progression après le saut.

Pour Exchange 2000 Server et Exchange Server 2003

1. Pour déterminer le chemin d'accès et le nom de fichier des fichiers .edb et .stm pour une base de données, utilisez le Gestionnaire système Exchange pour afficher l'onglet base de données de la boîte de dialogue Propriétés pour chaque objet de base de données.
2. À partir d'une invite de commandes, déplacer vers le chemin d'un fichier de base de données.
3. Exécutez la commande eseutil suivante pour afficher l'en-tête du fichier de base de données :
   Eseutil /mh database_file
4. Examiner le champ journal requis dans l'en-tête du fichier de base de données. Le champ journal requis indique la plage de fichiers journaux numérotés nécessaires au démarrage de cette base de données. Si la plage est 0 - 0, aucun fichier journal ne requis pour démarrer cette base de données. Cela signifie que la base de données est dans un état Arrêt correct ou cohérent .
   
   note Pour examiner l'en-tête d'une base de données à l'aide de la commande eseutil , la base de données doit être arrêté. Toutefois, dans toutes les versions d'Exchange Server, vous pouvez examiner l'en-tête du fichier point de contrôle lorsque exécutent des bases de données. La procédure pour examiner le fichier point de contrôle est identique pour toutes les versions d'Exchange Server et est décrit dans la section ? pour Exchange Server 5.5 ?. Afficher la valeur point de contrôle vous permet de déterminer quels fichiers journaux peuvent être supprimés sans devoir arrêter les bases de données. Fichiers journaux qui sont plus ancien que le journal point de contrôle et qui n'incluent pas le journal point de contrôle peuvent être supprimés.
5. Si vous exécutez une version de Exchange Server qui est antérieure à Exchange Server 2003 Service Pack 1 (SP1), vous devez convertir la plage décimale qui est répertoriée dans le champ journal requis aux valeurs hexadécimales. Par exemple, si la valeur journal requis est 28217 ? 28221, les fichiers journaux de 06E3906E3D sont requises par cette base de données. Dans Exchange Server 2003 SP1, le champ journal requis a été amélioré afin rapport valeurs décimales et hexadécimales.
   
   note Vous pouvez utiliser le mode scientifique de la calculatrice Windows pour convertir décimal en hexadécimal. Démarrer la calculatrice, puis cliquez sur scientifique dans le menu Affichage . Entrez le nombre décimal, puis cliquez sur hexadécimal .
   
   note Dans Exchange Server 5.5, fichiers journaux sont nommés Edbxxxxx.log, où "xxxxx" est un nombre hexadécimal à cinq chiffres. Étant donné que vous pouvez devoir jusqu'à quatre groupes de stockage dans Exchange 2000 Server et dans Exchange Server 2003 avec chaque groupe de stockage ayant un jeu spécifique de fichiers journaux, le préfixe « edb » n'apparaît pas dans les noms de fichier des journaux de transactions. Dans Exchange 2000 Server et dans Exchange Server 2003, le préfixe « edb » est remplacée par « E00 », « E03 E01, « « E02, » ». » Dans un groupe de stockage de récupération, préfixe « edb » est remplacé par R00. Préfixe de nom pour le fichier journal stockage groupe apparaît dans Exchange Gestionnaire de système dans l'onglet Général de la boîte de dialogue Propriétés de l'objet de groupe de stockage particulier. Par conséquent, si le groupe de stockage préfixe est « E01 » et si l'écriture de journal requis est 28217 ? 28221 (0x06E39 ? 0x06E3D), les journaux réels qui sont nécessaires sont E0106E39.log à E0106E3D.log.
   
   Vous devez examiner les valeurs journal requis pour chaque base de données dans un groupe de stockage avant de supprimer des journaux pour ce groupe de stockage.

Vous pouvez supprimer en toute sécurité tous les fichiers journaux numérotés sont inférieures à l'écriture plus faible dans n'importe quel champ journal requis d'une base de données dans le groupe de stockage. N'oubliez pas de déplacer, pas de supprimer les fichiers journaux.

note Le champ journal requis peut indiquer une tranche d'un journal, mais le fichier journal numéroté correspondant est introuvable. Par exemple, le champ journal requis peut indiquer une plage de 28221 28221, mais le fichier journal est numéroté 28221 est introuvable. Cela peut se produire si le point de contrôle est dans le fichier journal plus récent. Le fichier journal plus récent est toujours nommé avec uniquement le préfixe du groupe de stockage. Par exemple, le fichier journal plus récent peut être nommé E01.log. Jusqu'à ce que ce journal est plein puis jusqu'à ce qu'un nouveau journal est généré, le nom de fichier du journal actuel n'inclut pas le numéro de séquence de journal.

Vous pouvez vérifier numéro du fichier journal actuel réel séquence interne en affichant l'en-tête du fichier journal à l'aide de la commande eseutil suivante : Par exemple, si le préfixe de journal est E01, utilisez eseutil /ML E01 .log . Le champ lGeneration de l'en-tête du fichier journal reflète du numéro de séquence réel du fichier journal.

Si vous devez restaurer une base de données Exchange Server à partir d'une sauvegarde et si vous souhaitez récupérer la base de données Exchange Server sans perte de données, vous devez également restaurer tous les fichiers de journaux transaction créés après cette sauvegarde a été effectuée. S'il existe un saut dans la séquence des journaux des transactions, vous ne pouvez pas restaurer par progression après ce saut. Dans ce cas, vous devez supprimer tous les journaux hautes numérotées après la rupture. Cela inclut le fichier journal en cours.

note Même si toutes les bases de données dans un groupe de stockage sont dans un Arrêt correct ou un état cohérent , vous devez supprime pas le fichier journal le plus récent. Si vous supprimez le fichier journal le plus récent, un nouvel ensemble de fichiers du journal est généré, commençant par le numéro de séquence 0x000001. Ce nouvel ensemble de journaux fichiers empêche une base de données Exchange Server à partir d'une sauvegarde précédente est reporté avant.

Pour plus d'informations sur la façon de réparer une base de données Exchange Server, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :