Ceci est une traduction d’un post de Jonathan Lewis sur son blog – la première partie d’une série de quatre sur la fragmentation (original en anglais)

Cet article a commencé comme une note brève, jusqu’à ce que je réalise que ça allait être plus important, et que j’en fasse plutôt une série de quatre articles:

• Fragmentation – Introduction
• Fragmentation – Disque et Tablespace
• Fragmentation – Table
• Fragmentation – Index

Introduction

Le mot ‘fragmentation‘ donne l’idée de quelque chose qui est cassé en plusieurs morceaux, mais il a aussi une connotation émotionnelle qui fait penser qu’il y a beaucoup de petits morceaux. Dans le contexte d’une base Oracle, vous devez savoir ce que vous entendez par ‘morceau’, ainsi que la granularité de ces morceaux, et leur impact possible sur les performances.

Vu qu’il est possible de parler de fragmentation au niveau disque (disque logique), ou au niveau fichier, niveau tablespace, niveau segment, niveau extent ou niveau block, il est important de savoir très clairement ce que vous essayez de dire lorsque vous faites un commentaire du genre ‘Mon tablespace est fragmenté’ ou ‘Mon index est fragmenté’

Partons sur un exemple: Je crée un nouveau tablespace et je déplace une table dedans (ALTER TABLE … MOVE).
Lorsque je regarde DBA_EXTENTS, ma table a 100 extents. Il est évident qu’il y a ‘fragmentation’ dans le sens premier de ce mot, puisque j’ai 100 différents morceaux. Mais d’autre part, puisque cette table est la première chose que j’ai créé dans ce tablespace, je vois que ces extents sont adjacents. On pourrait alors dire que la table est ‘logiquement fragmentée‘ mais ‘physiquement contiguë ‘.

Est-ce que ce type de fragmentation a un impact sur les performances du système ?

Vu qu’Oracle fait la plupart des I/O par bloc (nous lisons des blocs vers le buffer cache, nous écrivons des blocs dans les fichiers), et vu qu’il n’y a pas de conséquences au fait qu’un bloc appartienne à extent plutôt qu’un autre, alors la réponse est probablement: non.
Cependant, il y a des fois où on essaie de lire plusieurs blocs contigus en un seul I/O (full table scan et index fast full scan), alors y a-t-il des conséquences au fait que notre table ‘physiquement contiguë’ soit ‘logiquement fragmentée’ en un grand nombre d’extents ?

Que se passe-t-il si les extents font, disons, 64Ko chacun. Est-ce que cela limite la taille d’une lecture multi-bloc (db file multiblock read) ? Ou bien ces lectures peuvent-elles être à cheval sur deux extents ? Et si le tablespace a deux datafiles ou plus, dans ce cas l’allocation des extents se fait généralement en alternant les datafiles (round-robin), est-ce que cela affecte la manière dont les lectures pourront se faire ? Et si on fait des full table scan en parallel query (parallel tablescan), est-ce qu’il y a des restrictions différentes pour les lectures directes (direct-path reads) ?

Si vous faites tourner un datawarehouse qui passe beaucoup de son temps à faire ce type d’opérations, alors ce sont quelques unes des questions auquelles vous devrez savoir répondre. Voir, par exemple, une note que j’ai écrit il y a trois ans à propos d’anomalies dans les tailles d’I/O lorsqu’on est en parallel query, et l’amélioration faite là dessus en 11G qui a été décrite ici par Christian Antognini il y a quelques années.

Vous ne pouvez commencer à comprendre les problèmes posés par la fragmentation, et si elle a un impact - ou non - sur les performances, que lorsque vous aurez commencé à définir de manière claire ce que vous entendez par ‘fragmentation’. Dans la deuxième partie, je vais faire quelques commentaires sur la manière de réfléchir à la fragmentation au niveau disque et au niveau tablespace.

La suite: Fragmentation – Disque et Tablespace