Exchange, opération stub et récupération d’espace de base de données

Article d’origine publié le mardi 28 août 2012

Exchange 2010 SP2 RU1 contenait le correctif d’un problème lié à la récupération d’espace de base de données. Comme cette question semble générer une certaine confusion, j’aimerais expliquer la nature du problème ainsi que celle du correctif, et discuter des attentes lorsque l’utilisation de produits tiers génère un stub des éléments dans la base de données (l’opération stub est le processus permettant de remplacer un message par un objet pointeur et de stocker la version originale dans un répertoire externe).

Le problème et le correctif

Dans Exchange 2010, nous avons trouvé que l’espace de base de données n’était pas récupéré dans plusieurs scénarios où les éléments sont supprimés définitivement (lorsque l’élément a été supprimé du magasin). Il s’agit notamment de scénarios d’archivage, où les éléments sont supprimés en bloc en fonction de la date, de scénarios d’opération stub où les pièces jointes sont supprimées, et d’autres scénarios tels que les boîtes aux lettres de journalisation et la réplication de dossiers publics. Ce problème a touché un large éventail de clients et concernait le fonctionnement de la suppression d’éléments.

Exchange 2010 essaie généralement de nettoyer la ligne d’un élément supprimé, une à deux minutes après la suppression définitive de l’élément. Cependant, le nettoyage échoue si des références à l’éléments sont encore ouvertes, par exemple dans les scénarios possibles suivants : l’indexation de contenu est en train d’indexer le message ; un autre client est en train de lire le message, etc. Si des références sont ouvertes, le nettoyage échoue. Avant le correctif, si le nettoyage échouait à ce moment, cet espace était effectivement perdu et ne pouvait pas être récupéré sans déplacer la boîte aux lettres.

Il s’est trouvé que des références en attente sur les messages supprimés étaient particulièrement courantes dans les boîtes aux lettres de journalisation, ou lors de l’utilisation d’un logiciel d’archivage tiers. La plupart des clients qui ont connu ce problème l’ont donc associé à l’un de ces deux scénarios. Mais techniquement, n’importe quel client peut laisser une référence ouverte et empêcher le nettoyage d’un élément.

Le correctif inclus dans SP2 RU1 corrige le problème en ajoutant un mécanisme de nouvelle tentative de nettoyage Si celui-ci échoue en raison d’une référence restée ouverte, le magasin réessayera régulièrement jusqu’à ce qu’il réussisse.

L’opération stub est-elle « corrigée » ?

L’opération stub désigne un processus où un produit d’archivage tiers prend un long message et le transforme en plus petit élément, ou stub. Il le fait généralement en supprimant les pièces jointes et en modifiant le corps du message pour en réduire la taille.

Dans la mesure où l’opération stub supprime les pièces jointes, elle peut être affectée par ce bug, car le nettoyage de ces pièces jointes supprimées pourrait échouer en raison de références ouvertes. Mais en dehors de ça, ce bug ne concernait pas vraiment l’opération stub.

Et si l’opération stub ne me donne pas autant d’espace que ce que j’attends ?

La Banque d’informations Exchange a beaucoup changé au fil des ans, mais même dans Exchange 2003 et 2007, l’opération stub rendait les bases de données bien plus volumineuses que prévu lors de l’ajout de tailles de boîte aux lettres. Cela était principalement dû à deux types de surcharges.

Le premier type de surcharge concerne des propriétés qui ne comptent simplement pas dans la taille du message. Regardez la taille d’un message dans Outlook, celle que vous voyez n’est pas la taille totale de toutes les données que stocke Exchange pour ce message. Nous stockons certaines propriétés qui ne sont pas comptées par rapport à l’utilisateur et qui ne sont pas reflétées dans la taille du message. Il peut s’agir de propriétés documentées publiquement, telles que PR_URL_NAME ou autres propriétés internes auxquelles les clients ne peuvent pas accéder.

Le deuxième type de surcharge est la fragmentation de page. La taille de page de base de données a changé au fil des années, passant de 4 Ko dans Exchange 2003 à 8 Ko dans Exchange 2007, puis à 32 Ko dans Exchange 2010. Chaque enregistrement dans la base de données doit être organisé sur ces pages, et en fonction de notre efficacité à le faire, il reste de l’espace sur la page. Ceci est la fragmentation de page, qui génère des espaces vides qui ne peuvent pas être récupérés par la maintenance de base de données. Les plus grandes tailles de pages des dernières versions d’Exchange facilitent l’organisation de plusieurs petits éléments sur une seule page, ce qui réduit la fragmentation, mais une certaine quantité de fragmentation sera toujours là.

La quantité de surcharge ne change généralement pas beaucoup entre les messages. Un petit message aura presque autant de surcharge qu’un gros. Par conséquent, lorsque vous remplissez une base de données avec de petits éléments, la surcharge devient beaucoup plus visible.

Imaginez par exemple un scénario où vous avez rempli une base de données avec des éléments de 1 Mo, et tous ces éléments ont 1 Ko de surcharge. Cela signifie que votre base de données a environ 0,09 % de surcharge. Vous générez un stub pour tous les éléments de la base de données, réduisant leur taille à 4 Ko. La surcharge de 1 Ko devient alors bien plus visible, puisqu’elle occupe 25 % de la base de données. J’ai moi-même créé une fois une base de données Exchange 2003 avec 70 % de surcharge en la remplissant de petits éléments et en générant un stub pour l’ensemble.

Qu’en est-il d’Exchange 2010 ?

Dans Exchange 2010, il y a un facteur supplémentaire qui peut affecter la récupération d’espace de l’opération stub : le changement de conception de la base de données.

Exchange 2010 a fait d’énormes progrès pour réduire le nombre d’E/S par seconde (IOPS) de la base de données. Il a notamment été question de se débarrasser de l’ancien processus de défragmentation en ligne qui moulinait la base de données de manière agressive la nuit et déplaçait les éléments pour optimiser l’espace. Dans Exchange 2010, nous nous sommes focalisés sur le stockage du contenu de la boîte aux lettres sur des pages contiguës pour réduire l’E/S, même si cela veut dire qu’il y restera de l’espace non utilisé ici et là. Autrement dit, Exchange 2010 n’a pas été conçu pour récupérer de l’espace de manière agressive lorsqu’un message est soudainement réduit. C’est un scénario que nous avons minimisé dans l’architecture pour améliorer notre E/S. Pour plus d’informations sur les modifications concernant la maintenance, voir Maintenance de base de données dans Exchange 2010.

Cela signifie-t-il que l’opération stub ne permet pas d’économiser de l’espace disque ? Pas forcément. Les produits de l’opération stub suppriment généralement les pièces jointes, on peut donc s’attendre à ce que cet espace soit libéré. Et bien qu’il n’ait pas été conçu pour ça, nous avons vu qu’Exchange 2010 libère de l’espace même lorsque les éléments sans pièces jointes subissent une opération stub.

Cependant, comme cela ne fait pas partie de la conception d’Exchange 2010, nous ne pouvons pas vous dire quoi attendre concernant la quantité d’espace qui doit être libéré à l’aide de l’archivage de stub. Vous vous ferez une idée en effectuant vous-même des tests ou à partir de données fournies par votre revendeur de logiciel d’archivage.

Autrement dit, nous ne pouvons rien prétendre concernant la récupération d’espace lorsqu’un élément est modifié pour réduire la taille de ses propriétés. Si la réduction de la taille d’un élément ne libère pas du tout d’espace, on peut considérer que c’est ainsi dans Exchange 2010 par conception. Comme toujours, l’examen de support des problèmes d’espace de la base de données lors de l’utilisation de produits tiers pourrait nous conduire à vous orienter vers le tiers en question pour obtenir une assistance si Exchange fonctionne par conception.

Conclusion

Exchange 2010 SP2 RU1 comprend un correctif aidant les clients à procéder à n’importe quel type d’archivage, opération stub ou autre, car il rend fiable le nettoyage des éléments supprimés définitivement. Cependant, toute économie d’espace disque réalisée par opération stub doit être validée par vous et votre revendeur de logiciel d’archivage. Lors de l’approvisionnement de votre stockage, nous vous suggérons de suivre le guide de conseils (qui indique aussi comment exploiter des boîtes aux lettres de grande capacité pour ne pas avoir à recourir à des solutions d’archivage tierces) et les outils que nous avons publiés, pour être sûr de disposer d’un espace adéquat pour vos données Exchange.

Bill Long

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la pageExchange, Stubbing, and Database Space Reclamation