11 novembre 2008
2
11
/11
/novembre
/2008
19:51
Bonsoir
Regardons d'un peu plus près ces histoires de partitions.
Pour cela prenons un exemple simple et insignifiant.
CREATE TABLE t_part (i number,j number)
PARTITION BY RANGE (i) SUBPARTITION BY HASH (j) SUBPARTITIONS 4
(
PARTITION P1 VALUES LESS THAN (2),
PARTITION P2 VALUES LESS THAN (3),
PARTITION P3 VALUES LESS THAN (4)
);
Cas 1:
Nous voila donc avec une table disposant de partitions et sous-partition.
Inserons donc quelques lignes...
INSERT INTO t_part VALUES (1,2);
INSERT INTO t_part VALUES (3,9);
INSERT INTO t_part VALUES (8,2);
Pour les deux premières insertions, aucun soucis, en revanche pour la troisième, ...
ORA-14400 : la clé de partition insérée ne correspond à aucune partition
Voila qui est dit ! j'ai une table et je ne peux pas inserer ce que je veux dedans. En tant qu'administrateur, je dois prévoir la création des partitions au départ. Bien évidemment peut ajouter des partitions par la suite.
On aurait pu palier à ce problème en créeant la table d'une autre façon:
DROP TABLE t_part;
CREATE TABLE t_part (i number,j number)
PARTITION BY RANGE (i) SUBPARTITION BY HASH (j) SUBPARTITIONS 4
(
PARTITION P1 VALUES LESS THAN (2),
PARTITION P2 VALUES LESS THAN (3),
PARTITION P3 VALUES LESS THAN (4),
PARTITION P_others VALUES LESS THAN (maxvalue)
);
La valeur maxvalue implique qu'il n'y a plus de valeur maximum et que toutes les lignes n'etant pas déstinées à etre dasn P1, P2 ou P3 seront accueillies par P_others.
Si vous rejouez la sequence d'insertion, il n'y aura plus de soucis.
En revanche vous risquez d'avoir des données dans une partition f"ourre tout", qu'il faudra un jour déplacer.
Il n'y a pas de solution magique, c'est le role du DBA de prévoir et créer les partitions nécessaires lorsque cela est utile. Je pense notemment aux tables partitionnées sur des champs date.
Si votre table est partitionnée par mois, vous allez créer les partitions pour l'année 2008 et courrant décembre 2008 vous ajouterez les partitions pour 2009.
Cas 2:
Encore envie de jouer, alors un petit update sur la clé de partition.
UPDATE t_part SET i=1 WHERE i=8;
ORA-14402 : LAa mise à jour de la colonne de clé de partition modifierait la partition.
Décidement, c'est qu'il faudrait presque réfléchir !
Faire un update sur la clé de partition revient à faire un delete puis un insert.
Pour autoriser les update sur la clé de partition, il faut au préalable effectuer la commande suivante.
ALTER TABLE t_part ENABLE ROW MOVEMENT;
Et maintenant vous pouvez faire tous les update que vous voulez. En même temps si vous en faites beaucoup sur la clé de partition c'est peut être que vous avez mal choisi votre clé de partition.
Cas 3 :
Comme vous le savez pour qu'ORACLE puisse choisir le meilleur plan d'execution possible, il faut que les stast soient à jour.
Allons y !
exec DBMS_STATS.GATHER_TABLE_STATS(user,'t_part',CASCADE=>TRUE);
SELECT Table_Name,Last_Analyzed FROM User_Tables WHERE Table_Name='T_PART';
SELECT Partition_Name,Last_Analyzed FROM User_Tab_Partitions WHERE Table_Name='T_PART';
SELECT Subpartition_Name,Last_Analyzed FROM User_Tab_Subpartitions WHERE Table_Name='T_PART';
Magique ! dans les deux premiers cas on constate que la colonne Last_Analysed est bien renseignée alors que pour les sous partitions que dalle ! Ce qui en clair signifie qu'il n'y a pas de statistiques sur mes sous partitions, ce qui à un moment donnée peut poser problème.
Bug oracle ou mauvaise utilisation du package DBMS_STATS
Pas de suspens inutile
Il existe un paramètre GRANULARITY pour le package DBMS_STATS qui a pour valeur par défaut AUTO. Ce qui entraine que les statistiques ne sont pas collectées au niveau sous-partitions.
Il faut passer la valeur ALL dans l'appel de le procédure.
exec DBMS_STATS.GATHER_TABLE_STATS(user,'t_part',CASCADE=>TRUE,GRANULARITY=>'ALL');
Vous pouvez maintenant interrogé à nouveau la vue User_Tab_Subpartitions et vous constaterez que les statistiques sont bien collectées.
La petite moralité de toute ca : Beaucoup pensent qu'un DBA ne sert à rien ( Spéciale dédicace aux éditeurs de logiciels !)
Les mécanismes internes d'une base de données sont rarement simple et se priver d'une compétence impliquant la partie qui engendre la majorité des problèmes de performance relève pour petite partie d'ignorance et pour grande partie d'incompétence !
LAO,
Regardons d'un peu plus près ces histoires de partitions.
Pour cela prenons un exemple simple et insignifiant.
CREATE TABLE t_part (i number,j number)
PARTITION BY RANGE (i) SUBPARTITION BY HASH (j) SUBPARTITIONS 4
(
PARTITION P1 VALUES LESS THAN (2),
PARTITION P2 VALUES LESS THAN (3),
PARTITION P3 VALUES LESS THAN (4)
);
Cas 1:
Nous voila donc avec une table disposant de partitions et sous-partition.
Inserons donc quelques lignes...
INSERT INTO t_part VALUES (1,2);
INSERT INTO t_part VALUES (3,9);
INSERT INTO t_part VALUES (8,2);
Pour les deux premières insertions, aucun soucis, en revanche pour la troisième, ...
ORA-14400 : la clé de partition insérée ne correspond à aucune partition
Voila qui est dit ! j'ai une table et je ne peux pas inserer ce que je veux dedans. En tant qu'administrateur, je dois prévoir la création des partitions au départ. Bien évidemment peut ajouter des partitions par la suite.
On aurait pu palier à ce problème en créeant la table d'une autre façon:
DROP TABLE t_part;
CREATE TABLE t_part (i number,j number)
PARTITION BY RANGE (i) SUBPARTITION BY HASH (j) SUBPARTITIONS 4
(
PARTITION P1 VALUES LESS THAN (2),
PARTITION P2 VALUES LESS THAN (3),
PARTITION P3 VALUES LESS THAN (4),
PARTITION P_others VALUES LESS THAN (maxvalue)
);
La valeur maxvalue implique qu'il n'y a plus de valeur maximum et que toutes les lignes n'etant pas déstinées à etre dasn P1, P2 ou P3 seront accueillies par P_others.
Si vous rejouez la sequence d'insertion, il n'y aura plus de soucis.
En revanche vous risquez d'avoir des données dans une partition f"ourre tout", qu'il faudra un jour déplacer.
Il n'y a pas de solution magique, c'est le role du DBA de prévoir et créer les partitions nécessaires lorsque cela est utile. Je pense notemment aux tables partitionnées sur des champs date.
Si votre table est partitionnée par mois, vous allez créer les partitions pour l'année 2008 et courrant décembre 2008 vous ajouterez les partitions pour 2009.
Cas 2:
Encore envie de jouer, alors un petit update sur la clé de partition.
UPDATE t_part SET i=1 WHERE i=8;
ORA-14402 : LAa mise à jour de la colonne de clé de partition modifierait la partition.
Décidement, c'est qu'il faudrait presque réfléchir !
Faire un update sur la clé de partition revient à faire un delete puis un insert.
Pour autoriser les update sur la clé de partition, il faut au préalable effectuer la commande suivante.
ALTER TABLE t_part ENABLE ROW MOVEMENT;
Et maintenant vous pouvez faire tous les update que vous voulez. En même temps si vous en faites beaucoup sur la clé de partition c'est peut être que vous avez mal choisi votre clé de partition.
Cas 3 :
Comme vous le savez pour qu'ORACLE puisse choisir le meilleur plan d'execution possible, il faut que les stast soient à jour.
Allons y !
exec DBMS_STATS.GATHER_TABLE_STATS(user,'t_part',CASCADE=>TRUE);
SELECT Table_Name,Last_Analyzed FROM User_Tables WHERE Table_Name='T_PART';
SELECT Partition_Name,Last_Analyzed FROM User_Tab_Partitions WHERE Table_Name='T_PART';
SELECT Subpartition_Name,Last_Analyzed FROM User_Tab_Subpartitions WHERE Table_Name='T_PART';
Magique ! dans les deux premiers cas on constate que la colonne Last_Analysed est bien renseignée alors que pour les sous partitions que dalle ! Ce qui en clair signifie qu'il n'y a pas de statistiques sur mes sous partitions, ce qui à un moment donnée peut poser problème.
Bug oracle ou mauvaise utilisation du package DBMS_STATS
Pas de suspens inutile
Il existe un paramètre GRANULARITY pour le package DBMS_STATS qui a pour valeur par défaut AUTO. Ce qui entraine que les statistiques ne sont pas collectées au niveau sous-partitions.
Il faut passer la valeur ALL dans l'appel de le procédure.
exec DBMS_STATS.GATHER_TABLE_STATS(user,'t_part',CASCADE=>TRUE,GRANULARITY=>'ALL');
Vous pouvez maintenant interrogé à nouveau la vue User_Tab_Subpartitions et vous constaterez que les statistiques sont bien collectées.
La petite moralité de toute ca : Beaucoup pensent qu'un DBA ne sert à rien ( Spéciale dédicace aux éditeurs de logiciels !)
Les mécanismes internes d'une base de données sont rarement simple et se priver d'une compétence impliquant la partie qui engendre la majorité des problèmes de performance relève pour petite partie d'ignorance et pour grande partie d'incompétence !
LAO,
Partager cet article
