Discussion :

[pat29]

Bonjour,

suite à un post précédent j'ai fait un test d'import d'une grosse table non partitionnée dans le dump (248 colonnes - 9 M lignes) mais partitionnée avec 1 seule partition dans la base de destination (Oracle 9.2.0.4.0 sur Windows server 2003).

Cette table a donc été créée avant l'import avec l'ordre suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
CREATE TABLE INGRID
(
   COL1 NUMBER,
   COL2 NUMBER,
   ....
)
TABLESPACE TAB_INGRID
PARTITION BY RANGE(COL1,COL2)
(
    PARTITION PART_MAX 
    VALUES LESS THAN (MAXVALUE,MAXVALUE)
) ;

Cet import prend plus de 15 h alors que si la table reste non partitionnée cela prend 1h1/2 !!!
Je ne comprend pas cette augmentation de temps... Si quelqu'un a une idée ?

Merci.

[13thFloor]

10 fois plus de temps ! Les caractéristiques sont les mêmes pour les 2 imports : mode logging/nologging, mêmes index sur les tables, mêmes options d'import, tablespace de la table partitionnée sur le même disque que l'autre table ... ?
Prend quelques snapshots avec statspack pour voir quelles attentes se produisent.
En important dans une table partitionnée il y a un léger temps de recherche destiné à la détermination de la bonne partition mais là il n'y en a qu'une.
Curieux.

[orafrance]

à chaque insert un algorithme recherche la partition dans laquelle mettre les blocs et met en branle toute la gestion de l'espace spécifique au partitionnement... il parait assez logique de voir se genre de comportement

[LeoAnderson]

De plus, je cerne mal l'intérêt d'un tel partitionnement ?

[orafrance]

éviter d'avoir des imports trop rapides peut-être

[LeoAnderson]