Nouvelles fonctionnalités de banque d’informations principales dans Exchange
S’applique à : Exchange Server 2010 SP2
Dernière rubrique modifiée : 2016-11-28
Microsoft Exchange Server 2010 inclut de nombreuses améliorations dans l’architecture de base de données Exchange :
La création de rapports de dossiers publics a été améliorée.
Les bases de données ne sont plus associées à des groupes de stockage. Les groupes de stockage ont été supprimés.
Les investissements en terme d’optimisation du schéma de la banque d’informations et du moteur ESE (Extensible Storage Engine) ont permis de réduire les opérations d’ES/s de 70 %.
Les sections suivantes reviennent en détail sur ces améliorations.
Contenu de cette rubrique
Amélioration de la création de rapports pour les dossiers publics
Gestion de la base de données
Modifications de la banque d’informations
Nouvelles fonctionnalités du moteur ESE
Amélioration de la création de rapports pour les dossiers publics
La création de rapports de dossiers publics a été améliorée afin de visualiser les modifications initiées par l’utilisateur sur n’importe quel élément du dossier public. Vous pouvez afficher ces informations à l’aide de la cmdlet Get-PublicFolderStatistics dans l’environnement de ligne de commande Exchange Management Shell. Pour plus d’informations, consultez la rubrique Utilisation de PowerShell avec Exchange 2010 (environnement de ligne de commande Exchange Management Shell).
Gestion de la base de données
Les bases de données ne sont plus associées à des groupes de stockage. Dans Exchange 2010, la fonctionnalité de groupe de stockage a été déplacée vers la base de données.
Dans Exchange 2010, vous pouvez gérer les bases de données de boîtes aux lettres et de dossiers publics dans le nœud Configuration de l’organisation de la console de gestion Exchange. (Dans Exchange Server 2007, la gestion de la base de données s’effectuait dans le nœud Configuration du serveur.)
Bien que la gestion de la base de données de dossiers publics ait été déplacée du nœud Configuration du serveur vers le nœud Configuration de l’organisation avec les bases de données de boîtes aux lettres, la fonctionnalité des bases de données de dossiers publics n’a pas été modifiée dans Exchange 2010. Tout comme dans Exchange 2007, vous ne pouvez pas créer de copies des bases de données de dossiers publics, pas plus que vous ne pouvez ajouter de bases de données de dossiers publics à un groupe de disponibilité de base de données. Toutefois, les bases de données de dossiers publics peuvent être hébergées sur des serveurs de boîtes aux lettres faisant partie d’un groupe de disponibilité de base de données, même si les bases de données de dossiers publics ne feront pas l’objet d’envoi de journaux ni d’autres fonctionnalités de groupe de disponibilité de base de données.
Modifications des cmdlets de base de données
Avec la suppression des groupes de stockage dans Exchange 2010, les cmdlets de groupe de stockage utilisées dans Exchange 2007 ont été supprimées. Les cmdlets de base de données Exchange 2010 fournissent désormais cette fonctionnalité, comme décrit dans les tableaux suivants.
Cmdlets de base de données dans Exchange 2010 remplaçant les cmdlets de groupe de stockage d’Exchange 2007
Cmdlet Exchange 2007 | Description de la modification de fonctionnalité dans Exchange 2010 |
---|---|
New-StorageGroup |
Cette cmdlet a été supprimée et les paramètres de configuration ont été déplacés sur les cmdlets New-MailboxDatabase et New-PublicFolderDatabase. |
Remove-StorageGroup |
Cette cmdlet a été supprimée et les paramètres de configuration ont été déplacés sur les cmdlets Remove-MailboxDatabase et Remove-PublicFolderDatabase. |
Set-StorageGroup |
Cette cmdlet a été supprimée et les paramètres de configuration ont été déplacés sur les cmdlets Set-MailboxDatabase et Set-PublicFolderDatabase. |
Get-StorageGroup |
Cette cmdlet a été supprimée et les paramètres de configuration ont été déplacés sur les cmdlets Get-MailboxDatabase et Get-PublicFolderDatabase. |
Move-StorageGroupPath |
Cette cmdlet a été supprimée et les paramètres de configuration ont été déplacés sur la cmdlet Move-DatabasePath. |
Cmdlets de base de données dans Exchange 2010 disposant de fonctionnalités étendues par rapport aux cmdlets d’Exchange 2007
Cmdlet Exchange 2010 | Description des fonctionnalités étendues dans Exchange 2010 |
---|---|
New-MailboxDatabase New-PublicFolderDatabase |
Ces cmdlets ont été étendues avec les paramètres et fonctionnalités provenant de la cmdlet New-StorageGroup. Elles mettent également à jour l’objet serveur avec un lien vers la nouvelle base de données et l’objet de base de données avec le nom du serveur d’hébergement. |
Remove-MailboxDatabase Remove-PublicFolderDatabase |
Ces cmdlets ont été étendues avec les paramètres et fonctionnalités provenant de la cmdlet Remove-StorageGroup. En outre, elles mettent également à jour l’objet serveur avec le lien vers la nouvelle base de données et l’objet de base de données avec le nom du serveur d’hébergement. |
Set-MailboxDatabase Set-PublicFolderDatabase |
Ces cmdlets ont été étendues avec les paramètres et fonctionnalités provenant de la cmdlet Set-StorageGroup. Lors de la modification des serveurs hôtes, elles mettent également à jour l’objet serveur avec le lien vers la nouvelle base de données et l’objet de base de données avec le nom du serveur d’hébergement. |
Get-MailboxDatabase Get-PublicFolderDatabase |
Ces cmdlets ont été étendues avec les paramètres et fonctionnalités provenant de la cmdlet Get-StorageGroup. Le paramètre Status est étendu pour renvoyer les informations d’état actuellement retournées par la cmdlet Get-StorageGroupCopyStatus. |
Move-DatabasePath |
Cette cmdlet a été étendue avec les paramètres et fonctionnalités provenant de la cmdlet Move-StorageGroupPath. |
Outre les modifications de la cmdlet précédente, les cmdlets StorageGroupCopy ont été supprimées. Pour plus d’informations, consultez la rubrique Gestion de copies de base de données de boîtes aux lettres.
Modifications de la banque d’informations
Dans Exchange 2010, le schéma de la banque d’informations a été modifié pour supprimer la dépendance des bases de données de boîtes aux lettres sur l’objet serveur. De plus, le nouveau schéma a été amélioré pour permettre de réduire les Ops d’ES/s en refactorisant les tables utilisées pour stocker les informations. La refactorisation des tables permet une plus grande contiguïté logique et localité de référence. Ces modifications réduisent la dépendance de la banque vis-à-vis des index secondaires gérés par le moteur ESE. Par conséquent, la banque n’est plus sensible aux problèmes de performance liés aux index secondaires.
La résilience et le bon fonctionnement de la banque ont également été améliorés en ajoutant plusieurs fonctionnalités liées à la détection et à la correction d’erreurs, ainsi qu’à la fourniture d’alertes, notamment :
Quarantaine sur boîtes aux lettres non fiables
Coupure du transport sur les bases de données disposant de moins de 1 Go d’espace
Détection et création de rapports sur le délai d’attente de thread
Pour plus d’informations sur la résilience et le bon fonctionnement de la banque d’informations, consultez la rubrique Présentation de la banque d’informations Exchange 2010.
La fonctionnalité de banque d’informations principale a bénéficié de nombreuses modifications pour améliorer les fonctionnalités de haute disponibilité. La haute disponibilité a été intégrée à l’architecture principale d’Exchange 2010 pour permettre aux organisations de toutes tailles de tous les secteurs industriels de déployer un service de continuité de messagerie économique. Pour plus d’informations sur les modifications de haute disponibilité disponibles dans Exchange 2010, consultez la rubrique Présentation de la haute disponibilité et de la résilience de site.
Nouvelles fonctionnalités du moteur ESE
Le moteur ESE (Extensible Storage Engine) a été amélioré dans Exchange 2010 pour réaliser les objectifs suivants :
E/S plus grandes et E/S séquentielles pour réduire les Ops d’ES/s
Optimisation pour le stockage d’articles
Réduction de la gestion de base de données
Défragmentation en ligne
Analyse de base de données en ligne
E/S plus grandes et séquentielles
En augmentant la taille des E/S et en réduisant la fréquence des opérations de lecture/écriture dans Exchange 2010, ESE est en mesure d’augmenter les performances. De plus, ESE peut augmenter les performances de manière à ce que les données de la base de données soient plus séquentielles, ce qui augmente la probabilité que les données associées se trouvent dans le même voisinage que l’arborescence B.
Dans Exchange, toutes les données se trouvant à l’intérieur de la base de données sont stockées dans les arborescences B, ces dernières étant alors scindées en pages. Dans Exchange 2007 et ses versions antérieures, les données stockées dans les arborescences B (B-trees) ne sont pas contiguës. En fait, les versions précédentes d’Exchange procédaient à des opérations de lecture/écriture aléatoires sur la base de données. Cela signifie que les données associées risquent de ne pas se trouver dans le même voisinage sur le disque dur. Les données non contiguës nécessitent davantage de passages pour la lecture et l’écriture sur le disque dur.
Défragmentation de l’arborescence B
Le processus de défragmentation de l’arborescence B a été amélioré pour réduire les opérations d’E/S en conservant les données contiguës dans l’arborescence B.
La défragmentation de l’arborescence B s’effectue sur place (au lieu de créer une nouvelle arborescence B et de renommer les index et tables) avec trois nouvelles opérations :
Déplacement de page Un déplacement de page consiste à déplacer toutes les données d’une page sur une page nouvellement allouée.
Fusion gauche partielle Une fusion gauche partielle revient au même qu’une fusion droite dans Exchange 2007 ou les versions antérieures, sauf que les données sont déplacées de la page de gauche vers la page de droite.
Fusion gauche complète Une fusion gauche complète revient au même qu’une fusion droite complète dans Exchange 2007 ou les versions antérieures.
La défragmentation a été modifiée des fusions droites vers les fusions gauches pour optimiser les performances. Les données sont lues et écrites sur le disque dur de droite à gauche. Si la base de données est défragmentée dans la même direction que les opérations de lecture/écriture, la défragmentation entrera en conflit avec les opérations de lecture/écriture. En outre, l’allocation d’espace permet d’allouer la page suivante dans une extension, mais pas la page précédente. Du fait qu’un déplacement de page doit allouer une nouvelle page, la défragmentation de la base de données de gauche à droite est bien plus efficace.
Le Gestionnaire de défragmentation est un nouvel événement d’ESE qui analyse les arborescences B nécessitant une défragmentation et celles déjà défragmentées. Il compile une liste des arborescences B dans toutes les bases de données montées devant être défragmentées. Quand elles sont détectées, les arborescences B sont enregistrées avec le Gestionnaire de défragmentation qui les traitera.
Augmentation de taille de la page à 32 Ko
Toutes les données se trouvant à l’intérieur de la base de données sont stockées dans les arborescences B, ces dernières étant scindées en pages. La taille de la page correspond à la taille minimale de lecture et d’écriture dans la base de données. Il s’agit également de la taille d’unité utilisée pour la mise en cache de la base de données. La lecture à partir du disque est plus lente que l’exécution d’opérations dans la mémoire, par conséquent, en augmentant la taille de la page à 32 Ko, ESE réduit les Ops d’ES/s, ce qui augmente les performances en mettant en cache la taille de la page la plus importante en mémoire.
Optimisation du stockage d’articles
L’un des autres objectifs d’ESE dans Exchange 2010 consiste à réduire les coûts du capital et de fonctionnement relatifs au déploiement d’Exchange. Il suffit pour cela de réduire les coûts de stockage et d’optimiser les stockage d’articles à l’aide de disques durs de classe JBOD et SATA.
Les sous-systèmes de disque sont plus efficaces dans la gestion d’E/S moins nombreuses mais plus volumineuses. Dans Exchange 2010 ou les versions antérieures, la taille de la page représente la taille minimale de lecture/écriture et de mise en cache de la base de données. La fusion des E/S fait référence au processus de combinaison des opérations de page de base de données en une opération unique d’E/S, produisant par conséquent des opérations d’E/S moins nombreuses mais plus volumineuses.
L’augmentation des tailles moyennes d’E/S de base de données par le biais de la fusion des E/S présente les avantages suivants :
Augmentation de l’efficacité d’utilisation du disque Les disques sont plus efficaces pour traiter des E/S volumineuses. Plus le disque est utilisé de manière efficace, plus les boîtes aux lettres peuvent être hébergées sur ce disque.
Augmentation du délai de mise en route du cache La mise en route du cache est un processus qui permet de réduire les délais d’exécution en effectuant un préchargement des requêtes initiales exécutées sur une base de données lors du dernier démarrage de celle-ci. Après un redémarrage, un basculement ou un changement de serveur, les E/S les plus volumineuses autorisent ESE à augmenter le délai de mise en route du cache.
Maintenance de base de données
L’un des objectifs d’ESE dans Exchange 2010 consiste à réduire les coûts de maintenance et de gestion d’une base de données. La maintenance d’une base de données comporte plusieurs tâches qui permettent de gérer et de conserver l’intégrité de votre base de données de boîtes aux lettres.
La maintenance de base de données est répartie comme suit :
Maintenance de la boîte aux lettres de la banque d’informations
Maintenance de base de données ESE
Dans Exchange 2007, la maintenance de la base de données ESE nécessitait beaucoup de ressources disques. Dans Exchange 2010, des améliorations ont été apportées pour améliorer les performances. Dans Exchange 2010, sur les gros serveurs ou les serveurs au profil lourd, la tâche de maintenance de la boîte aux lettres de la banque d’informations ne dure que 45 minutes environ, alors que la maintenance de la base de données ESE prenait généralement six à huit heures par nuit sur des bases de données Exchange 2007 volumineuses (quotas de 2 Go).
Dans Exchange 2010, des améliorations ont été apportées afin de prendre en charge à la fois les bases de données volumineuses, le stockage JBOD et le stockage sans recours à RAID.
Remarque : |
---|
Toutes les fonctions de maintenance de base de données axées sur la banque d’informations Exchange, telles que le nettoyage des éléments récupérables, sont identiques dans Exchange 2010 et Exchange 2007. Seuls les fonctions ESE, la défragmentation en ligne et le contrôle de parité de la base de données ont été modifiés. |
Défragmentation de la base de données
La défragmentation rend les pages internes d’une base de données Exchange contiguës. La défragmentation peut être effectuée automatiquement par le système pendant que la base de données est en ligne (défragmentation en ligne) ou manuellement par l’administrateur lorsque la base de données est hors connexion (défragmentation hors connexion).
Défragmentation en ligne
Dans Exchange 2010, l’architecture de la défragmentation en ligne a changé. La défragmentation en ligne a été supprimée du processus de maintenance des bases de données de boîtes aux lettres. La défragmentation en ligne s’exécute désormais en arrière-plan 24h/24 et 7j/7. Etant donné que la défragmentation en ligne s’exécute tout le temps, Exchange ne publie plus d’événements dans le journal des événements indiquant la quantité d’espaces blancs dans la base de données. Lors de la maintenance de la base de données en arrière-plan, les éléments marqués pour suppression sont supprimés de la base de données, ce qui libère des pages de la base de données. Le pourcentage d’espaces blancs est en constante évolution en raison des efforts du processus continu de défragmentation en ligne.
Vous pouvez estimer la quantité d’espaces blancs d’une base de données si vous connaissez la quantité de messages envoyés et reçus par les utilisateurs possédant des boîtes aux lettres dans celle-ci. Par exemple, si disposez d'une base de données incluant cent boîtes aux lettres de 2 Go (totalisant 200 Go) et que les utilisateurs échangent en moyenne 10 Mo de messages par jour, la quantité d'espaces blancs est égale à 1 Go environ (100 boîtes aux lettres x 10 Mo par boîte aux lettres). La quantité d’espaces blancs peut être supérieure à cette estimation si la maintenance de la base de données en arrière-plan ne peut pas être effectuée en totalité.
Vous n’avez pas besoin de configurer de paramètres pour cette fonctionnalité. Exchange analyse la base de données en cours d’utilisation, et de légères modifications sont apportées au fil du temps afin qu’elle reste défragmentée en termes d’espaces et de contiguïté. Si la base de données analyse une plage de pages et constate qu’elles ne respectent pas l’aspect séquentiel défini, la base de données démarre un thread asynchrone pour défragmenter cette section de la table/de l’arborescence B. La défragmentation en ligne est également limitée afin de n’avoir aucun impact négatif sur les performances du client.
Utilisez le jeu de compteurs de performance ESE Base de données MSExchange ==> Tâches de défragmentation pour visualiser les tâches effectuées. Pour plus d’informations, consultez la rubrique Procédure d’activation des compteurs de performance étendus ESE.
Défragmentation hors connexion
La défragmentation hors connexion est un processus manuel effectué par un administrateur pendant que la base de données est à l’état démonté (hors connexion). Durant ce processus, l’outil ESEUTIL est utilisé pour lire le fichier de base de données et écrire un nouveau fichier de base de données utilisant le contenu de manière contiguë. Le processus de défragmentation hors connexion ne copie pas les espaces blancs de la base de données d’origine ; pour cette raison, la taille de la nouvelle base de données est inférieure à celle de la base de données d’origine sur le disque (voire très inférieure, en fonction de la quantité d’espaces blancs dans la base de données). Historiquement, les raisons typiques pour la défragmentation hors connexion d’une base de données étaient les suivantes :
Pour réduire la taille du fichier de base de données sur disque
Pour récupérer des espaces blancs dans une base de données
Pour éviter le manque d’espace disque disponible
Pour réparer une base de données endommagée (la deuxième étape de la réparation après ESEUTIL /p)
La défragmentation hors connexion n’a jamais fait partie de la maintenance régulière des bases de données Exchange et, il y a déjà un certain temps, Microsoft s’est prononcé contre une défragmentation régulière et proactive hors connexion de bases de données. Cette recommandation a été faite pour des raisons variées, y compris les raisons suivantes :
Elle aboutit à un temps d’arrêt parce que vous devez prendre la base de données en mode hors connexion.
Dans l’environnement d’une base de données de boîtes à lettres répliquée, il faut donc réamorcer toutes les copies passives d’une copie active ayant été défragmentée hors connexion, donc toutes les copies passives ayant été défragmentées hors connexion. (Vous ne devriez donc jamais effectuer de défragmentation hors connexion de la copie d’une base de données passive.)
Ceci aboutit à la création d’une nouvelle base de données, avec une nouvelle signature de base de données, ce qui élimine la possibilité de restaurer des fichiers journaux depuis une sauvegarde de la base de données effectuée avant la défragmentation hors connexion.
Comme alternative à la défragmentation hors connexion, nous recommandons que les clients créent une nouvelle base de données et déplacent les boîtes à lettres vers cette nouvelle base de données. Dans un environnement Exchange 2010, les boîtes à lettres sont déplacées en ligne sans interruption du service pour les utilisateurs finaux. De plus, lorsque vous déplacez toutes les boîtes à lettres d’une base de données existante vers une nouvelle base de données, le résultat final est le même : une base de données défragmentée avec des pages écrites de manière contiguë et sans espaces blancs notables dans le fichier de base de données. Une fois ce processus achevé, il ne vous reste plus qu’à effacer l’ancienne base de données (maintenant vide). Ces recommandations concernent uniquement la défragmentation hors ligne proactive pour récupérer des espaces blancs. Vous devriez quand même effectuer une défragmentation si le support technique de Microsoft vous le demande.
Analyse de base de données en ligne
L’analyse de base de données en ligne (également appelée Contrôle de parité de la base de données) a également été modifiée. Dans Exchange 2007 Service Pack 1 (SP1), vous pouviez utiliser la moitié du délai de défragmentation en ligne pour ce processus d’analyse de base de données (pour vous assurer qu’Exchange lisait chaque page de votre base de données dans un délai donné afin de détecter toute corruption).
Dans Exchange 2010, l’analyse de base de données en ligne contrôle la parité de la base de données et exécute des opérations de blocage de banque Exchange 2010. L’espace peut être perdu en raison des blocages, l’analyse de base de données en ligne recherche et récupère l’espace perdu. Le système présent dans Exchange 2010 est conçu en considérant que chaque base de données est intégralement analysée une fois tous les sept jours. Un événement d’avertissement est déclenché si une base de données n’est pas entièrement analysée dans ce délai. Dans Exchange 2010, il existe désormais deux nœuds pour exécuter l’analyse de base de données en ligne sur les copies de base de données actives :
Exécuter en tant que dernière tâche dans le processus de maintenance de la base de données de boîtes aux lettres. Vous pouvez configurer la durée d’exécution en modifiant la planification de la maintenance de la base de données de boîtes aux lettres. Vous pouvez utiliser cette option avec des bases de données plus petites (taille inférieure à 1 téraoctet). Dans ce cas, l’analyse complète dure moins longtemps.
Exécuter en arrière-plan 24h/24 et 7j/7, comportement par défaut. Cette option fonctionne bien, quelle que soit la taille des bases de données, mais elle est plus adaptée aux bases de données volumineuses (1 à 2 To). Exchange analyse la base de données une fois par jour au plus. Cette E/S en lecture est séquentielle à 100 % (et donc facile à lire sur le disque) et revient à un taux d’analyse d’environ 5 mégaoctets (Mo)/s sur la plupart des systèmes.
Pour plus d’informations sur la configuration de la maintenance de base de données, consultez la rubrique Gérer des bases de données de boîtes aux lettres.
© 2010 Microsoft Corporation. Tous droits réservés.