Table + Index Partionnées

Version imprimable

17/03/2004, 16h59
superfly

Table + Index Partionnées

Voila j'ai une table avec 3.5 million de lignes et je voudrais essaye dans faire une table partionnees avec un index partionnees, histoire de voir si les perfs peuvent etre meilleur?

Je voudrais faire des range partitions (table et index).
Quelqu'un a t-il déja fais ce genre de chose?
Merci :wink:
17/03/2004, 17h21
Pomalaix

Re: Table + Index Partionnées

Citation:

Envoyé par superfly

Voila j'ai une table avec 3.5 million de lignes et je voudrais essaye dans faire une table partionnees avec un index partionnees, histoire de voir si les perfs peuvent etre meilleur?

Je voudrais faire des range partitions (table et index).
Quelqu'un a t-il déja fais ce genre de chose?
Merci :wink:

Merci d'être précis dans votre question !
Quel genre d'infos recherchez-vous ?
17/03/2004, 17h38
superfly

En fait je voulais savoir si quelqu'un avait déjà implémenté cela sur une table existante car le souci c'est que cela modifie la structure de la table. Donc il faut extraire les données puis les remettres...
J'ai extraits les données avec EXP et je les ai importé avec IMP, et biensur j'ai plus rien dans la table comme si il ne pouvait pas importer les données....
17/03/2004, 17h42
superfly

je crois que j'ai trouvé mon problème....

voici un petit bout de code et l'erreur que me génère Oracle, peut-etre que quelqu'un aura une idée car moi je suis un peu sec :cry:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
CREATE TABLE t_Historique 
     (   NUM_ETA    NUMBER(8),
  NUM_ASS    NUMBER(6),
  NUM_CLI    NUMBER(6),
  NUM_AFF    NUMBER(2),
  COD_ACT    VARCHAR2(5),
  COD_BNF    VARCHAR2(5),
  NUM_SIN    NUMBER(8),
  NUM_GAR    NUMBER(3),
  COD_ART    VARCHAR2(5),
  COD_TAB    VARCHAR2(2) not null,
  COD_EVT    VARCHAR2(5) not null,
  COD_USR    VARCHAR2(15) not null,
  COD_COU    VARCHAR2(10),
  DAT_HST    DATE not null,
  LIB_IMGAVT VARCHAR2(60),
  LIB_IMGAPR VARCHAR2(60),
  COD_DOC    VARCHAR2(5) )
   PARTITION BY RANGE ( NUM_CLI)
     ( PARTITION num_cli_q1 VALUES LESS THAN ( 100000)
        TABLESPACE INDEX_3)
     ENABLE ROW MOVEMENT

Code:

1
2
3
4
5
6
7
8
9
10
 
Fichier d'export créé par EXPORT:V08.01.07 via le chemin classique
import effectué dans le jeu de caractères WE8ISO8859P1 et le jeu NCHAR WE8ISO8859P1
. Import d'objets OP dans OP
. . Import de la table                  "T_HISTORIQUE"
IMP-00058: Erreur ORACLE 14400 rencontrée
ORA-14400: la clé de partition insérée dépasse la limite supérieure autorisée
IMP-00028: Import partiel de la table précédente annulée : lignes 190660 annulées
Préparation à l'activation des contraintes...
Fin de l'import réussie avec avertissements.

Merci :wink:

17/03/2004, 18h46
rouardg

Bonjour,

C'est normal que cela plante. Tu as créé une table partitionnée avec une seule partition qui accueille les données inférieures à 100000.

Or tout semble indiquer que ta table d'origine contient des données supérieures à 100000. Et le pb, c'est qu'il n'y a pas une autre partition pour accueillir ce genre de valeurs.

Tu aurais du créer ta table avec 2 partitions, de la manière suivante :

Code:

Citation:

CREATE TABLE t_Historique
( NUM_ETA NUMBER(8),
NUM_ASS NUMBER(6),
NUM_CLI NUMBER(6),
NUM_AFF NUMBER(2),
COD_ACT VARCHAR2(5),
COD_BNF VARCHAR2(5),
NUM_SIN NUMBER(8),
NUM_GAR NUMBER(3),
COD_ART VARCHAR2(5),
COD_TAB VARCHAR2(2) not null,
COD_EVT VARCHAR2(5) not null,
COD_USR VARCHAR2(15) not null,
COD_COU VARCHAR2(10),
DAT_HST DATE not null,
LIB_IMGAVT VARCHAR2(60),
LIB_IMGAPR VARCHAR2(60),
COD_DOC VARCHAR2(5) )
PARTITION BY RANGE ( NUM_CLI)
( PARTITION num_cli_q1 VALUES LESS THAN ( 100000) TABLESPACE INDEX_3,
PARTITION num_autres VALUES LESS THAN (MAXVALUE) TABLESPACE INDEX_3
) ENABLE ROW MOVEMENT

Comme tu le vois, j'ai créé la table avec une autre partition NUM_AUTRES et en spécifiant la clause MAXVALUE.

Sinon, au lieu de détruire ta table et de la recréer avec 2 partitions, tu peux utiliser un ALTER TABLE ... SPLIT PARTITION...

Merci de regarder la doc Oracle pour en savoir plus sur cette syntaxe
17/03/2004, 18h48
superfly

Merci rouardg :wink:
18/03/2004, 09h52
orafrance

Pour répondre à la problématique de performance, je te confirme que les indexes partitionnés peuvent résoudre des problémes de perf sur les gros volume... en revanche je suis beaucoup moins convaincu par le partitionnement de la table ;)