Exchange 2010 et la maintenance

Récemment, un de mes clients s'est interrogé sur le fait que lors du passage de la défragmentation en ligne sur sa base Exchange, aucun évènement n’était présent dans les journaux indiquant un gain d'espace.

Selon Microsoft, beaucoup de chose ont changées dans Exchange 2010 (cf. http://technet.microsoft.com/en-us/library/bb125040.aspx)

Je vous propose donc un petit résumé de ce qui se passe dans vos bases Exchange 2010 au travers de ce post.

Bonne lecture :)

Base de données exchange :

Une base de données exchange utilise le moteur ESE.

Comme toute base de données il existe des fichiers de données, et des journaux de transactions (logs).

Les données présentes dans la base de données sont stockées dans une arborescence, elle-même stockée dans une page.

Dans exchange 2010 ces pages ont pour taille 32KO.

Un fichier de base de données se voit à un instant T attribuer une certaine taille, par exemple 1024MO.

Si aucun éléments n’était supprimés dans la base, nous pourrions considérer qu’il y aurait dans notre exemple 32000 pages.

Chaque fois qu’un élément est ajouté, il ajouter à la fin de la database, par conséquent, si un élément est supprimé dans cette database, l’espace est vide.

Dans notre exemple, une database de 1024MO pourrait en réalité contenir seulement 300 pages, donc contenir 31700 pages blanches et ainsi nous faire perdre 1014,4 MO

La défragmentation en ligne :

La défragmentation en ligne consiste à reporter les pages non utilisés à la fin de la database, et à rendre contigüe les données présentes dans les pages allouées.

Exchange 2010 dispose d’une particularité : La défragmentation en ligne est effectuée « au fil de l’eau » et non plus planifiée comme dans les versions précédentes. Par conséquent, aucun événement système n’apparait dans le journal d’évènements (notamment l’événement 1221), et il est nécessaire d’activer les compteurs de performance pour suivre ces défragmentations, mais il ne faut pas activer les compteurs sur une plage de temps particulière : il est nécessaire de le faire tout au long de la journée.

Une autre solution consisterait à suivre la taille occupée par les éléments dans la database et la taille physique des fichiers de base de données.

Défragmentation « hors ligne » :

Ce processus manuel est effectué par l’administrateur et permet de « compacter » la base ese.

En réalité, un nouveau fichier de base de donnée est créée et les pages utilisées dans la base initiale sont copiées dans cette nouvelle base.

Les blancs sont ainsi « supprimés » de la base de donnée et l’espace disque est réellement retrouvé

Maintenance de la base de donnée en arrière-plan (24x7ESE scanning) :

Cette « maintenance » n’en est pas une à proprement parlé : C’est un passage effectué par le moteur de base de données afin d’effectuer des CRC (checksum) sur les données et valider ainsi que la base n’a pas subi d’endommagement.

Exchange 2010 considère qu’une base est entièrement analysée en 7 jours. Si au-delà de cette période l’ensemble de la base n’a pas été analysée, alors un événement remonte dans l’observateur d’événements.

Cette option, active par défaut, fonctionne parfaitement mais est surtout adaptée à des bases de données importante supérieur à 1TO

Maintenance planifié :

Cette maintenance est là pour effectuer plusieurs tâches.

La première de ses tâches est la maintenance des boites exchange :

·         « Suppression » des boites aux lettres « supprimé » (pour rappel, quand une boite au lettre est supprimé dans exchange, la boite n’est pas immédiatement supprimée, mais seulement marquée pour suppression) ;

·         Suppression définitive des boites aux lettres marquées pour suppression après expiration des période de rétention ;

·         Suppression des dumpster (conteneurs des éléments supprimés par les utilisateurs) de chaque boites aux lettres, après expiration des éléments conformément à la stratégie de rétention.

Sa dernière tâche est l’exécution du CRC (checksum). Par conséquent si la maintenance d’arrière-plan n’est pas active, un CRC de l’ensemble de la base est effectué à ce moment précis. Si la taille de la base est supérieur à 1TO, beaucoup de temps peut être nécessaire et par conséquent il se peut que ce scan ne tienne pas dans le plan de maintenance et qu’après 7 jours un message apparaisse dans l’eventlog.

Conclusion :

En conséquence de çà, il est tout à fait normal que les informations de vos compteurs ne soient pas pertinente sur la plage horaire choisit.

Si vous souhaitez suivre ce qui est stocké dans votre base de données et estimer la perte, je vous invite plutôt à utiliser des scripts tiers.

Voici un de mes favoris J http://gmergit.blogspot.fr/2012/01/connaitre-lespace-occupe-par-les-mails.html