Partionnement - Administration - Type de partitionnement

13.11.2008

Bonsoir,

Me revoila avec mes histoires de partitionnement. Juste un petit post pour revenir sur les trois types de partiionnement possibles:

Partition by range
Partition by list
Partition by hash

Partition by range.

Le partitionnement "by range" convient parfaitement pour historiser les données. Cela permet d'organiser les données selon un intervalle dans le temps (jours, mois, trimestre ,année).
Il est fréquent que les grosses tables soient intérrogées par periode. Dans ce cas la Oracle utilisera le critère de partitionnement pour n'accèder qu'à une petite partie des données.

Partition by list.

Le partitionnement par liste s'effectue surtout sur des colonnes à faible cardinalité. C'est à dire dont le nombre de valeur distinctes est peu elevé. Attention, contrairement au "partition by range" et"partition by hash", la clé de partitionnement ne peut concerner qu'une seule colonne.

Partition by hash.

Le partitionnement par hash permet de distribuer les données selon un algorithme qu'Oracle applique en fonction de la colonne partionné. L'idée est qu'Oracle répartie les données de façon égale en les différentes partitions. Pour que le répartion soit homogène il faut bien évidemment choisir une clé de hash qui elle même soit répartie de facon homogéne dans la table.
Par exemple, si j'ai une table de facture et que je partitionne par hash sur l'information client en décidant de créer 64 partitions alors que je n'ai que deux clients distincts avec 90 % de facture pour un client et 10 pour l'autre le choix de partitionnement par hash est à revoir. Il aurait mieux fallu choisir un partitionnement par liste.
En revanche, si j'ai un millier de clients avec environ le même nombre de factures par client, on aurra une répartition homogène. Pour le partitionnement par hash, Oracle recommande fortement que le nombre de partition soit une puissance de 2 !

Remarque : Avec cet article, ca fait deux fois que j'indique qu'ORACLE recommande que pour une partition par hash, le nombre de partitions soit une puissance de deux.

Alors je peux me poser la question de lapertinence de cette recommandation. Elle a le mérite de venir d'Oracle. Mais bon nombres de concepts sont appliqués dans des applications dites sensibles sans que leur origine ou bienfondé soit vérifié.
Alors il n'est certe pas possible de toujours tout vérifier, mais dans de nombreux cas, cela ne prends que quelques minutes. Alors que dans quelques mois (après de grandes aventures...), il sera beaucoup plus compliqué de faire marche arrière, même si on est convaincu que ce qui est en place est "bancal".

Revenons à nos moutons.
Crééons deux tables partitionnées par hash une avec 4 ( 2^2) partitions et une autre avec 5 partitions.

CREATE TABLE t_part_4 (i number)
PARTITION BY HASH(i) PARTITIONS 4;

CREATE TABLE t_part_5 (i number)
PARTITION BY HASH(i) PARTITIONS 5;

Je vais maintenant remplir t_part_4 avec 500000 lignes ayant une valeur comprise entre 1 et 10000.

BEGIN
   FOR z IN 1..500000 LOOP
   INSERT INTO t_part_4 VALUES (ROUND(DBMS_RANDOM.VALUE(1,10000)));
   END LOOP;
END;
COMMIT;
/

Remplissons t_part_5 avec les données de t_part_4 (ne laissons pas de place au hasard).

INSERT INTO t_part_5 SELECT * FROM t_part_4;
COMMIT;

Collectons les statistiques pour mes deux tables

BEGIN
DBMS_STATS.GATHER_TABLE_STATS(user,'t_part_4');
DBMS_STATS.GATHER_TABLE_STATS(user,'t_part_5');
END;

Par rapport à la définition d'une partition de hash (si on omet la recommandation d'ORACLE)
on devrait en théroie avoir 100000 lignes par partitions pour t_part_5 et 125000 lignes par partition pour t_part_4.

Vérifions

SELECT Table_Name,Partition_Name,Num_Rows FROM User_Tab_Partitions
WHERE Table_Name IN ('T_PART_4','T_PART_5')
ORDER BY Table_Name,Partition_Position;

Résultat :
Dans le cas de t_part_4 mes données sont plutôt bien réparties : Respectivement 124669,125539,125028,124395 lignes pour chacunes des partitions.
En revanche pour t_part_5, j'ai 126777,123979,124801 lignes pour les partitions 2,3,4 et 63206 ert 59725 pour les partitions 1 et 5.
Nous venons de montrer facilement que le conseil d'ORACLE n'etait pas annodin.

Attention : Je ne dis pas que toutes les recommandations d'ORACLE sont fondées ou se confirment / infirment facilement. Je veux simplement attirer votre attention sur le fait que sur le web on trouve de tout (y a même des gens comme moi qui écrivent des articles sur ORACLE). Et qu'il convient de faire la part des choses. Bon nombre de personnes aiment à s'appeler expert parcequ'elles ont réussi à faire fonctionner un bout de code trouvé de la toile.
Pour reprendre un des principes de Tomas Kyte (Oh grand tout puissant, maitre incontésté de la technologie Oracle): "Ne croyez pas ce que vous lisez ou entendez, experiementez dans vos environnements et vos problématiques, ce qui est valable dans bien des cas ne le sera peut être pas pour vous.Ne cherchez pas de règles magiques, elles n'existent pas , et chaque règle que vous trouverez aura son exception (comme dans la langue francaise)."

LAO.