[8i] Performance import

Version imprimable

16/12/2005, 16h38
Débéa

[8i] Performance import

Bonjour,

Dans le cadre du rafraichissement d'une base de données d'étude, nous exportons la base de prod. pour la reimporter en base de développement.

La base de production fait 100 Go mais contient beaucoup de vide puisque l'export fait 7 Go.

Pour ne pas reimporter le vide en base de developpement (serveur d'étude un peu plus petit !), nous avons recréé les tables et indexes en les dimensionnants à la juste taille. Au final, la base fait 14 Go.

le script de rafraichissement fait :
-disable fk
-disable trigger
-truncate table
-drop procedure function et package
-drop sequence
-drop vue
- import
-enable_fk
-enable_trg

La ligne de commande de l'import est :

Code:

imp userid=xxx buffer=51200000 fromuser=yyy touser=zzz grants=N show=N ignore=Y commit=Y indexes=Y full=N file=ttt.dmp

La ligne de commande de l'export est :

Code:

exp userid=xxx buffer=3072000 compress=Y grants=Y indexes=Y rows=Y FULL=Y file=ttt.dmp

L'import tourne 20 heure ! 8O

Que puis-je faire pour optimiser le temps ?
16/12/2005, 17h07
Jaouad

et en re créant les index à part

est ce que tu observe des évènements d'attente particulier lors de l'insert ?
16/12/2005, 17h13
Débéa

tu veux dire faire un imp avec indexes=N puis un imp avec indexes=Y et rows=N ?
16/12/2005, 17h13
Pomalaix

A noter que COMMIT=YES signifie : faire un commit après l'insertion de chaque ligne !!!
Ce n'est pas très économique.

A moins que vos tables soient énormes, il est préférable de choisir COMMIT=NO. Dans ce cas, la validation aura lieu à la fin du chargement de chaque table. Il faut donc prévoir des segments d'annulation suffisamment bien taillés pour supporter la table la plus grosse.
16/12/2005, 17h18
Débéa

Citation:

Envoyé par Pomalaix

A noter que COMMIT=YES signifie : faire un commit après l'insertion de chaque ligne !!!
Ce n'est pas très économique.

A moins que vos tables soient énormes, il est préférable de choisir COMMIT=NO. Dans ce cas, la validation aura lieu à la fin du chargement de chaque table. Il faut donc prévoir des segments d'annulation suffisamment bien taillés pour supporter la table la plus grosse.

Non il fait un commit après chaque insertion de buffer (paramètre buffer).

J'ai des très grandes tables (8 à 9 millions d'enregistrements, 2 Go)
16/12/2005, 17h56
Pomalaix

Citation:

Envoyé par PhPeltier

Non il fait un commit après chaque insertion de buffer (paramètre buffer).

Bien vu, pan sur le bec !

Cependant néanmoins, en me replongeant à l'instant dans la doc, je lis :
A la rubrique ARRAY : For tables containing LONG, LOB, BFILE, REF, ROWID, UROWID, or DATE columns, rows are inserted individually
A la rubrique COMMIT : For tables containing LONG, LOB, BFILE, REF, ROWID, UROWID, or DATE columns, array inserts are not done. If COMMIT=y, Import commits these tables after each row.

Des tables qui contiennent des dates, c'est fréquent, et celles-ci seront donc validées ligne par ligne... Affolant cette affaire !
16/12/2005, 18h28
LeoAnderson

Et des tables qui ne contiennent pas de rowid, c'est quoi donc ??? comment est-ce possible ? 8O
17/12/2005, 12h12
LeoAnderson
Et sinon, est-ce que la lenteur ne proviendrait pas des disques très sollicités ? :wink:

Je ferais le test suivant :
- Base en no logging
- Pas d'import des indexes
- répartition de la charge disque sur plusieurs disques (ne pas avoir le fichier dmp lu en import sur le même disque que le fichier de data, typiquement)
- Ajout de DBWriters si wait d'écritures
- Si attentes de types free buffer wait, augmentation du buffer