Partager via

Présentation de la banque d’informations Exchange 2010

  • Article

 

S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3

Dernière rubrique modifiée : 2016-11-28

La banque d’informations Exchange est une plate-forme de stockage qui offre un référentiel unique permettant de gérer divers types d’informations au sein d’une même infrastructure. La banque Exchange (store.exe) est le principal référentiel de stockage de données pour MicrosoftExchange Server 2010.

Contenu de cette rubrique

Bases de données dans les éditions d’Exchange 2010

Composants logiques de la banque d’informations Exchange

Structure de fichiers de la banque d’informations Exchange

Présentation de l’enregistrement des transactions

Moteur de stockage extensible

Intégrité de la banque

Espace disque faible sur les journaux ou les lecteurs de bases de données

Limites de la banque d’informations Exchange

Bases de données dans les éditions d’Exchange 2010

Exchange 2010 se décline en deux éditions serveur : Standard Edition et Enterprise Edition. Exchange 2010 Standard Edition est conçu pour répondre aux besoins de messagerie et de collaboration des petites et moyennes entreprises ; cette version peut également convenir pour des rôles serveurs spécifiques ou des succursales. Exchange 2010 Enterprise Edition est conçu pour les grandes entreprises.

Exchange 2010 Standard Edition prend en charge jusqu’à cinq bases de données. Exchange 2010 Enterprise Edition prend en charge jusqu’à 100 bases de données.

Composants logiques de la banque d’informations Exchange

Les principaux composants de la banque Exchange sont des bases de données de boîtes aux lettres et des bases de données de dossiers publics. Ces composants peuvent résider sur un serveur unique ou être répartis sur plusieurs serveurs.

Les bases de données de boîtes aux lettres contiennent les données, les définitions de données, les index, les sommes de contrôle, les indicateurs et d’autres informations relatives aux boîtes aux lettres dans Exchange 2010. Les bases de données de boîtes aux lettres contiennent des données associées à un utilisateur individuel et des dossiers de boîte aux lettres générés lors de la création d’une boîte aux lettres pour cet utilisateur. Une base de données de boîtes aux lettres est stockée sous forme de fichier (.edb) de base de données Exchange.

Les bases de données de dossiers publics contiennent les données, les définitions de données, les index, les sommes de contrôle, les indicateurs et d’autres informations relatives aux dossiers publics dans votre organisation Exchange.

Dans Exchange 2010, vous gérez les dossiers publics à l’aide de l’environnement de ligne de commande Exchange Management Shell. (Vous pouvez effectuer un nombre limité des tâches de gestion de base de données de dossiers publics dans la console de gestion Exchange.) Pour plus d’informations sur la gestion des dossiers publics, consultez les rubriques Gestion des dossiers publics et Présentation des dossiers publics.

Bases de données dans les éditions d’Exchange 2010

Structure de fichiers de la banque d’informations Exchange

Vous pouvez gérer la banque d’informations Exchange en manipulant ses composants logiques, tels que les bases de données. Toutefois, Exchange 2010 stocke les données dans un ensemble spécialisé de fichiers de données, tels que des fichiers de base de données Exchange (.edb), des fichiers journaux de transactions (.log) et des fichiers de point de contrôle (.chk). À moins que vous ne sauvegardiez ou restauriez les données, vous travaillez rarement directement avec ces fichiers. Le tableau suivant décrit chacun de ces fichiers en détail.

Structure de fichiers de la banque Exchange

Fichier de données Description

Base de données Exchange (.edb)

Ces fichiers sont le référentiel pour les données de boîte aux lettres. Ils sont accessibles directement via le moteur de stockage ESE (Extensible Storage Engine) et disposent d’une arborescence B conçue pour offrir un accès rapide. Cela permet aux utilisateurs d’accéder à n’importe quelle page de données dans un cycle d’entrées/sorties (E/S), ce qui représente une augmentation de quatre fois par rapport à Microsoft Exchange Server 2007. Les bases de données Exchange se composent de plusieurs arborescences B, avec des arborescences connexes qui opèrent avec l’arborescence principale en hébergeant l’indexation et les vues.

Journal des transactions (.log)

Ces fichiers sont le référentiel des opérations de base de données telles que la création ou la modification d’un message. Les opérations validées sont ensuite consignées dans la base de données elle-même (dans un fichier .edb). Cette approche garantit que toutes les transactions achevées et incomplètes sont enregistrées pour préserver l’intégrité des données en cas d’interruption du service. Chaque base de données a son propre jeu de journaux des transactions.

Point de contrôle (.chk)

Ces fichiers sont le référentiel de données qui indique qu’une opération est enregistrée dans la base de données sur le disque dur. Exchange 2010 utilise des fichiers .chk pour permettre à une instance du moteur ESE de relire automatiquement les fichiers journaux dans une base de données incohérente en cas de récupération suite à une interruption de service interruption en commençant par la transaction non écrite suivante. Les fichiers .chk sont placés là où se trouvent les fichiers .log.

Bases de données dans les éditions d’Exchange 2010

Présentation de l’enregistrement des transactions

L’enregistrement des transactions Exchange est un mécanisme de récupération robuste du moteur ESE conçu pour restaurer de manière fiable une base de données Exchange dans un état cohérent après un arrêt soudain de la base de données. Le mécanisme d’enregistrement est également utilisé pour restaurer les sauvegardes en ligne. Cette section décrit l’enregistrement des transactions Exchange 2010 et inclut une brève présentation de l’enregistrement circulaire.

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 est enregistrée en toute sécurité, elle peut être écrite dans le fichier de base de données. En général, les utilisateurs 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 gère de façon efficace la mise en cache de dizaines de giga-octets (Go) de pages de base de données. 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 base de données 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 ouvert pour une base de données est nommé Enn.log. Il ne possède pas de numéro de séquence tant qu’il n’est pas complété 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 base de données.

Les fichiers journaux sont numérotés en hexadécimal, de sorte que le fichier journal après E0000000009.log est 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 [log file name] affiche les informations d’en-tête.

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 voir non plus l’en-tête du fichier journal en cours (Enn.log) lorsqu’une base de données est montée. Exchange conserve le fichier journal en cours ouvert tant que la base de données l’utilise. Toutefois, vous pouvez afficher l’en-tête de fichier de point de contrôle lorsque les bases de données sont montées. Exchange met à jour le fichier de point de contrôle toutes les trente secondes, et son en-tête est visible sauf pendant l’exécution d’une mise à jour.

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 avez 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 commence l’analyse des fichiers journaux par le fichier le plus ancien disponible, au lieu de débuter par le journal du 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 (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 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 être déplacés sur un autre serveur comportant des fichiers journaux existants ; les bases de données s’associent d’elles-mêmes à un autre flux de journal.

RemarqueRemarque :
Même s’il est possible de supprimer les fichiers journaux après l’arrêt des bases de données, 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.

AttentionAttention :
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 Eseutil /p sur une base de données, vous devez exécuter 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.

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 Présentation de la sauvegarde, de la restauration et de la récupération d'urgence.

Bases de données dans les éditions d’Exchange 2010

Enregistrement circulaire

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 uniquement depuis la dernière sauvegarde complète. Par exemple, vous pouvez activer l’enregistrement circulaire au moment d’utiliser la protection Exchange native des données, qui ne permet pas d’effectuer de sauvegardes. Pour empêcher la création de fichiers journaux, vous devez activer l’enregistrement circulaire.

Dans l’enregistrement standard des transactions utilisé par Exchange 2010, chaque transaction de base de données est inscrite 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 2010. 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. La journalisation circulaire n’est pas recommandée dans un environnement de production normal.

Pour des informations sur l’activation et la désactivation de la journalisation circulaire, consultez la rubrique Configurer les propriétés de la base de données de boîtes aux lettres.

Bases de données dans les éditions d’Exchange 2010

Moteur de stockage extensible

Les bases de données de boîtes aux lettres Exchange et la file d’attente sur les serveurs de transport Hub et les serveurs de transport Edge utilisent la base de données ESE. Le moteur ESE se compose d’un gestionnaire de tables ISAM (Indexed Sequential Access Method) multi-utilisateur qui offre des fonctionnalités complètes en matière de langage de manipulation de données (DML) et de langage de définition de données (DDL). Le moteur ESE permet aux applications de stocker des enregistrements et de créer des index pour y accéder de différentes manières. Pour plus d’informations sur ESE, consultez la rubrique sur l’architecture Extensible Storage Engine. Pour en savoir plus sur les améliorations apportées à Exchange 2010 ESE, voir Nouvelles fonctionnalités de banque d’informations principales dans Exchange.

Bases de données dans les éditions d’Exchange 2010

Intégrité de la banque

La banque Exchange peut détecter et corriger plusieurs scénarios risquant d’entraîner un défaut de fonctionnement. La banque Exchange peut gérer les boîtes aux lettres incohérentes et les dépassements de délai de thread, utiliser les fonctionnalités de rapport et d’alerte pour signaler un état défaillant de la banque Exchange, détecter et résoudre les problèmes de bases de données de boîtes aux lettres et de dossiers publics.

Détection et correction des boîtes aux lettres incohérentes

Dans certains cas, une seule boîte aux lettres contenant des données endommagées (logiques ou physiques) risque de générer une erreur de la banque Exchange, et de rejeter le service pour toutes les boîtes aux lettres hébergées par le serveur. De même, une boîte aux lettres incohérente peut provoquer des erreurs répétées de la banque Exchange. Cette section décrit les mesures prises par la banque Exchange pour détecter et tronquer les boîtes aux lettres incohérentes.

Isolement de la boîte aux lettres incohérente

Il existe plusieurs types d’événements pour lesquels la banque Exchange associe une balise à une boîte aux lettres indiquant une menace potentielle :

  • Si les opérations effectuées par un thread pour cette boîte aux lettres échouent

  • Si plus de cinq threads dans cette boîte aux lettres n’ont montré aucune progression pendant un long moment

Une boîte aux lettres représentant une menace potentielle est balisée et le nombre de fois qu’elle est balisée est indiqué. Ces informations sont stockées dans le registre. La banque Exchange conserve également les informations sur la date d’identification de la boîte aux lettres comme une menace potentielle.

Lors du montage d’une base de données, la banque Exchange prend connaissance de l’heure à laquelle les boîtes aux lettres ont été identifiées comme des menaces potentielles. Si plus de deux heures se sont écoulées, la clé de registre de la boîte aux lettres est supprimée. Le fait de conserver cette information dans le registre constitue un avantage car, dans un environnement à haute disponibilité, elle est répliquée par la base de données de cluster. Même au cours du basculement d’une banque Exchange, les autres ordinateurs disposent de l’information. La sous-clé de Registre permettant d'isoler la boîte aux lettres incohérente est HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Nom du serveur>\Private-{db guid}\QuarantinedMailboxes\{mailbox guid}. Les clés de ce chemin sont CrashCount et LastCrashTime.

Les paramètres liés au nombre d'échecs aboutissant à la mise en quarantaine d'une boîte aux lettres et à la durée de la quarantaine sont enregistrés dans les clés MailboxQuarantineCrashThreshold et MailboxQuarantineDurationInSeconds de la sous-clé HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Nom du serveur>\Private-{db guid}.

Les valeurs par défaut de ces clés sont trois échecs pour MailboxQuarantineCrashThreshold et 21 600 secondes (six heures) pour MailboxQuarantineDurationInSeconds.

Agir sur une boîte aux lettres incohérente

Par défaut, si une boîte aux lettres est identifiée comme générant trois erreurs ou blocages en l’espace de deux heures, la banque Exchange lui associe une balise de mise en quarantaine dans le registre. Aucun accès à la boîte aux lettres n’est autorisé à moins que la balise soit OPEN_AS_ADMIN transmise. Aucun processus Exchange (par exemple, l’indexation de contenu ou les assistants de boîte aux lettres) ne peut se connecter. Les clés de registre QuarantineState et QuarantineTime permettent de déterminer si la boîte aux lettres est mise en quarantaine ou pas. Si la boîte aux lettres n’a pas généré d’erreur au cours des deux dernières heures et n’est pas mise en quarantaine, le chemin du registre de la boîte aux lettres est nettoyé par la banque Exchange. Si une boîte aux lettres a été mise en quarantaine pour une durée supérieure à la valeur MailboxQuarantineDurationInSeconds depuis l’heure LastCrashTime, elle est libérée automatiquement de la quarantaine.

Réinitialisation de la boîte aux lettres mise en quarantaine

Lorsque la cause de la boîte aux lettres incohérente a été identifiée et corrigée, la clé de registre de la boîte aux lettres mise en quarantaine doit être réinitialisée manuellement en étant supprimée. Toutefois, si vous omettez cette étape manuelle, la banque Exchange réinitialise automatiquement les boîtes aux lettres en quarantaine six heures après l’attribution de la balise correspondante. Si le problème n’est pas résolu pendant ce laps de temps, cela peut entraîner une série d’erreurs déclenchant à nouveau la mise en quarantaine de la boîte aux lettres ou du message.

RemarqueRemarque :
La base de données hébergeant la boîte aux lettres doit être remontée, ou la banque Exchange redémarrée, pour que la réinitialisation de la boîte aux lettres en quarantaine soit prise en compte.

La période de réinitialisation des boîtes aux lettres en quarantaine peut être contrôlée par la clé de registre HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Nom du serveur>\Private-{db guid}\QuarantinedMailboxes\MailboxQuarantineDurationInSeconds.

Reporting et alertes

La cmdlet Get-MailboxStatistics permet de notifier l’état de quarantaine d’une boîte aux lettres. La banque Exchange est dotée d’un compteur de contrôle des performances pour les boîtes aux lettres en quarantaine. Le nom du compteur est MSExchangeIS Mailbox\Quarantined Mailbox Count.

La banque Exchange enregistre également un événement chaque fois qu’elle met une boîte aux lettres en quarantaine, qui précise le nom de la boîte et l’horodatage. L’événement 10018 identifie une boîte aux lettres en quarantaine.

Bases de données dans les éditions d’Exchange 2010

Réparation de la base de données

Dans le Exchange 2010 Service Pack 1 (SP1), vous pouvez utiliser la cmdlet New-MailboxRepairRequest pour détecter et réparer les corruptions de boîtes aux lettres. Vous pouvez exécuter cette cmdlet sur une boîte aux lettres ou sur une base de données de boîtes aux lettres spécifique. Pendant l’exécution de cette tâche, l’accès aux boîtes aux lettres en cours de réparation est suspendu. Si vous exécutez cette cmdlet sur une base de données de boîtes aux lettres, seul l’accès à la boîte aux lettres en cours de réparation est interrompu. Toutes les autres boîtes aux lettres de la base de données continuent de fonctionner. Pour plus d’informations, consultez la rubrique Créer une demande de réparation de boîte aux lettres.

La cmdlet New-MailboxRepairRequest détecte et répare les types de corruptions de boîte aux lettres suivants :

  • Recherche des corruptions de dossier (à l’aide de la valeur SearchFolder du paramètre CorruptionType)

  • Ajout de décomptes sur les dossiers ne présentant par les valeurs correctes (à l’aide de la valeur AggregateCounts du paramètre CorruptionType)

  • Affichages des dossiers ne renvoyant par le contenu correct (à l’aide de la valeur FolderView du paramètre CorruptionType)

  • Les dossiers configurés pointant de manière incorrecte vers des dossiers parents non configurés (à l’aide de la valeur ProvisionedFolder du paramètre CorruptionType)

Lorsque vous avez exécuté la cmdlet New-MailboxRepairRequest, vous pouvez utiliser l’Observateur d’événements pour afficher les détails de la demande. Pour plus d’informations, consultez la rubrique Afficher les entrées des demandes de réparation de boîte aux lettres dans l’Observateur d’événements.

Vous pouvez également utiliser la cmdlet New-PublicFolderDatabaseRepairRequest pour détecter et résoudre les problèmes de réplication dans la base de données de dossiers publics. Les dossiers publics stockés dans la base de données de dossiers publics restent accessibles pendant l’exécution de la demande. En revanche, aucun accès au dossier public en cours de réparation n’est disponible. Pour plus d’informations, consultez la rubrique Créer une demande de réparation d’une base de données de dossiers publics.

Bases de données dans les éditions d’Exchange 2010

Détection de délai d’attente et reporting

Un autre signe indiquant qu’une banque d’informations Exchange n’est pas saine est lorsque des threads sont bloqués ou ne progressent plus. S’il existe plus de cinq threads dans une seule boîte aux lettres, dix threads dans une seule base de données ou vingt threads sur un seul serveur qui ne montrent aucune progression depuis une minute, un délai d’attente est signalé sur le serveur. Le compteur de performance qui indique les délais d’attente détectés est MSExchangeIS\ RPC Request Timeout Detected.

La banque Exchange écrit également les événements suivants sur le serveur :

  • 10025, qui signale un délai d’attente sur le serveur Exchange

  • 10026, qui signale un délai d’attente sur la base de données

  • 10027, qui signale un délai d’attente dans une boîte aux lettres individuelle

Si le délai d’attente est détecté sur une seule boîte aux lettres, cette dernière peut être considérée comme étant potentiellement contaminée. Elle est alors traitée comme un échec en augmentant la valeur de la clé CrashCount. Cela la rend susceptible d’être mise en quarantaine.

Bases de données dans les éditions d’Exchange 2010

Espace disque faible sur les journaux ou les lecteurs de bases de données

Lorsque la banque Exchange détecte que l’espace disponible sur un journal ou un lecteur de base de données est inférieur à 1 Go, elle interrompt tout processus de remise à cette base de données. Cela évite au disque de manquer d’espace. Lorsqu’un disque est à court d’espace, la base de données ne peut pas être montée ni déboguée. L’espace de base de données ne peut pas être récupéré non plus. Il s’agit d’un mécanisme d’auto-protection qui se déclenche uniquement si vous ignorez les avertissements liés aux problèmes d’espace émis par votre infrastructure d’analyse.

Lorsque l’espace disque franchit le seuil de 1,5 Go, la banque Exchange autorise la poursuite des remises. Les compteurs de performance suivants indiquent ce comportement :

  • Boîte aux lettres MSExchangeIS \ Remise bloquée : Espace faible dans la base de données

  • Boîte aux lettres MSExchangeIS \ Remise bloquée : Espace faible dans le journal

La banque Exchange écrit également les événements suivants sur le serveur :

  • 10014, qui indique que l’espace disque est faible dans le journal

  • 10015, qui indique que l’espace disque est faible dans la base de données

Si vous êtes confronté à des problèmes d’espace disque faible, vous pouvez prendre les mesures suivantes pour les corriger :

Bases de données dans les éditions d’Exchange 2010

Limites de la banque d’informations Exchange

Dans Exchange 2010, les limites d’utilisation et de connexion se trouvent dans la banque Exchange pour empêcher une application unique ou un utilisateur unique d’utiliser toutes les connexions disponibles à la banque Exchange. Si un utilisateur ou une application se sert de toutes les connexions, d’autres utilisateurs ou applications ne pourront pas accéder à la banque Exchange, ce qui peut entraîner un temps d’arrêt.

Pour plus d’informations, consultez la rubrique Limites de la banque d’informations Exchange.

Bases de données dans les éditions d’Exchange 2010

 © 2010 Microsoft Corporation. Tous droits réservés.