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]

[pat29]

Les caractéristiques sont les mêmes, aussi bien en disque qu'en tablespace et options d'import.
Quant à l'interêt d'une seule partition c'était pour tester si cela changeait quelque chose d'en mettre une seule, quitte à recréer les autres après l'import. Je pensais que cela évitait à Oracle la recherche de la bonne partition, vu qu'il n'y en a qu'une...
Sinon il y a 18 partitions de prévues (une par mois).
Je vais re-tester sans les index pour voir.

[orafrance]

dans ce cas, crées tout de suite les 18 partitions et parallélise l'import (tu peux utiliser QUERY )... là ça peut devenir très intéressant

[pat29]

tu veux dire faire plusieurs exports avec des paramètres query contigüs et ensuite lancer les exports simultanemént sur chaque dump ?

Sinon le test avec l'import sans les index a été concluant. En fait je créais les index locaux avant l'import pour éviter leur création automatique en global lors de celui-ci. Je pensais que lors d'un import les index étaient mis à jour globalement à la fin de du remplissage de la table, ce qui me paraissait normal pour la perfromance. Manifestement ça n'est pas le cas !
Je vais relancer l'import full cette nuit sans les index et avec toutes les partitions mais sans les index locaux. Je les créerai après l'import.

Cdlt.

[orafrance]

non un export mais plusieurs imports, un par partition dans l'idéal

[pat29]

suite ... (envoi involontaire)

cela provenait bien de la construction de l'index pendant l'import. La fonction import ne le construit donc pas d'un seul coup à la fin du chargement de la table mais bel et bien au fur et à mesure, d'où la performance.
Là l'import à pris moins de 4h sans les index puis 6h30 pour la construction de ceux-ci.

Cdlt.