Partager l'article ! Partionnement - Administration - Type de partitionnement: Bonsoir, Me revoila avec mes histoires de partitionnement. Juste un petit post pour rev ...
Pour être informé des derniers articles, pensez à vous inscrire à la newsletter. Par ailleurs, n'hésitez pas à faire part
de vos remarques, suggestions,...
LAO.
proposition@lao-dba.com
LAO.
proposition@lao-dba.com
Jeudi 13 novembre 2008
4
13
/11
/Nov
/2008
20:23
Bonsoir,
Me revoila avec mes histoires de partitionnement. Juste un petit post pour revenir sur les trois types de partiionnement possibles:
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.
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.
Par LAO
-
Publié dans : Administration
-
Communauté : ORACLE
Ecrire un commentaire - Voir les 1 commentaires
Ecrire un commentaire - Voir les 1 commentaires
Commentaires
Archives
- août 2011 (1)
- juin 2010 (1)
- mai 2010 (1)
- février 2010 (1)
- juin 2009 (1)
- mars 2009 (1)
- février 2009 (6)
- janvier 2009 (6)
- décembre 2008 (10)
- novembre 2008 (15)
- octobre 2008 (17)
Catégories
- RMAN (1)
- FLASHBACK (1)
- ORACLE NET (1)
- PERFORMANCE (12)
- Administration (23)
- ORACLE 11 (7)
- SQL DEVELOPER (1)
- Dataguard (4)
- Clonage de base (3)
- RAC (1)
Recherche
Articles récents
- Envie d'aventures...
- Administration - Export et compression à la volée
- RAC - Passer une base en archivelog
- Oracle 11 & Dataguard active
- Administration - Opérations longues
- Historique volumétrie tablespace
- Dataguard - Physical Standby - Mise en place
- Dataguard - Présentation
- Connaitre la version Oracle qui tourne (32 ou 64 bit)
- Dataguard - Version standard - Mise en place d'une base "standby" (2)
Calendrier
| Février 2012 | ||||||||||
| L | M | M | J | V | S | D | ||||
| 1 | 2 | 3 | 4 | 5 | ||||||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 | ||||
| 13 | 14 | 15 | 16 | 17 | 18 | 19 | ||||
| 20 | 21 | 22 | 23 | 24 | 25 | 26 | ||||
| 27 | 28 | 29 | ||||||||
|
||||||||||
Profil
- LAO
-
- Homme
- 06/05/1972
- IDF
- DBA
L'ensemble ? la conclusion ? ou moi !