Ceci est une traduction de d’un post de Jonathan Lewis sur son blog – la deuxième partie d’une série de quatre sur la fragmentation (original en anglais). Il est conseillé de lire avant: Fragmentation – Introduction

Fragmentation Disque

Les tablespaces sont composés de fichiers, et les fichiers sont stockés sur disque. Il s’agit la plupart du temps de disques logiques (logical volumes) plutôt que de vrais disques directement (real devices).
Lorsqu’on fait une lecture sur un vrai disque, la taille des données qu’on peut lire en une seule opération physique est quelque chose comme 400Ko ou 500Ko. C’est le contenu d’une seule piste sur un seul plateau d’un disque physique. Une lecture plus large continue en passant sur un autre plateau (ce n’est pas un mouvement physique des têtes, mais une commutation ‘électronique’) , ou bien en passant sur une autre piste (c’est alors un mouvement physique, mouvement latéral de la tête), ou encore en passant sur un autre disque. Passer sur un autre disque, c’est rejoindre une autre file d’attente de disque, et dans ce cas le logiciel du SAN, ou l’équivalent, aura probablement anticipé les disques dont vous aurez besoin et aura lancé en parallèle ces demandes de lectures dans les files d’attentes correspondantes.

Lorsque vous créez un datafile sous Oracle, vous ne savez pas à quel point le fichier est dispersé sur les disques physiques du système. Au mieux, une lecture de 1Mo va impliquer 3 ou 4 rotations d’un même disque, avec seulement des passage d’un plateau à l’autre (commutations ‘électroniques’). Et au pire, j’ai déjà vu un seul I/O impliquer jusqu’à 32 opérations différentes sur les disques, à cause des nombreuses couches de logicielles utilisés pour stripper sur les disques, puis sur les groupes de disques (diskgroup), puis sur les volumes logiques (logical volumes), etc.
Si on est tout seul sur le SAN, ce dernier cas où la lecture est parallélisée sur tous les disques est vraiment optimal pour les performances. Mais sur un système en production, c’est une calamité pour les files d’attentes. C’est pour cette raison que c’est une bonne stratégie de présenter des disques ‘bruts’ à ASM, en ayant une seule couche logicielle entre Oracle et les disques, et il s’agit en plus d’une couche logicielle qui connaît le comportement et les données d’Oracle.

A retenir: Ne pas mettre trop de couches de logiciels ‘intelligents’ entre Oracle et les lecteurs de disque.

Fragmentation Tablespace

Bien sûr, vous pouvez créer un tablespace avec plusieurs fichiers. Alors, par définition, le tablespace est fragmenté, même si il n’y a à la base rien de négatif avec ce type de fragmentation. Mais comme je l’ai précisé dans la note précédente (introduction), cela peut avoir des effets de bord sur la disposition des extents d’un segment, et arriver à des cas où vous voulez faire une seule lecture d’un gros volume de données, et vous retrouver en fait à faire plusieurs I/O plus petits – avec pour conséquence une augmentation de l’attente sur les I/O.

Le cas de fragmentation que la plupart des gens ont à l’esprit quand ils parlent de fragmentation de tablespace, c’est à dire le fait qu’il y ait des ‘trous’ d’espace libre au milieu de l’espace alloué, est quelque chose qui a aussi été appelé ‘gruyèrisation’ (ou en anglais honey-combing ou bubbling). C’est un effet de bord lorsqu’on supprime (DROP) ou réduit (SHRINK) des objects, qu’on déplace des tables (MOVE) ou qu’on reconstruit des indexes (REBUILD). On finit par avoir des morceaux d’espace libre dispersés sur tout le tablespace. Chaque fois que vous réorganisez un objet, vous allez probablement remplir certains de ces morceaux, mais en laisser d’autres vides là où se trouvait l’objet avant.

Fondamentalement, il est rare que ce type de fragmentation pose un problème, parce que cet espace vide n’entraîne pas de travail supplémentaire, sauf lorsque on fait un backup du fichier. Si vous pensez que le temps passé à copier cet espace vide lors d’un backup a un impact important sur la durée de la sauvegarde (dans le cas où le backup dépasse la fenêtre de temps permise avant le prochain cycle de chargement de données, par exemple), alors vous pouvez prévoir de déplacer des objets de telle sorte que l’espace libre se trouve à la fin de fichiers. Cela permet ensuite de réduire la taille des fichiers: voir par exemple cette note sur la réduction de la taille des tablespaces (en anglais).
Par contre, il faut garder à l’esprit qu’il peut y avoir des effets indésirables lors de cette réorganisation. Il y avait cette question sur le forum OTN il y a quelques années où un DBA s’est aperçu que déplacer des tables les a rendu plus volumineuses. j’ai écrit une note (en anglais) à propose de cela, en reprenant la question et la réponse (réponse que j’avais publiée dans ‘Practical Oracle 8i’).

Les difficultés liées à cette fragmentation ‘gruyère’ on été en grande partie un effet secondaire du paramètre PCTINCREASE d’Oracle qu’on pouvait spécifier pour les segments de données, amplifié par l’idée reçue qu’il vaut mieux réduire les objets à un seul extent. Mais depuis l’introduction des tablespaces dont l’espace libre est géré localement (LMT – Locally Managed Tablespaces), qui simplifient les options de dimensionnement des extents (surtout pour la taille d’extent UNIFORM), la seule question est quand l’espace libéré va être réutilisé et non comment est gérée cette réutilisation.

Pour en lire un peu plus là dessus: une histoire ancienne que j’ai publié bien avant qu’Oracle n’introduise les Locally Managed Tablespaces avec une taille d’extent uniforme, republié il y a 2 ans.

La suite: Fragmentation – Table