Discussion :

[Débéa]

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 :

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

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 :

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

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

L'import tourne 20 heure !

Que puis-je faire pour optimiser le temps ?

[Jaouad]

et en re créant les index à part

est ce que tu observe des évènements d'attente particulier lors de l'insert ?

[Débéa]

tu veux dire faire un imp avec indexes=N puis un imp avec indexes=Y et rows=N ?

[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.

[Débéa]

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)

[Pomalaix]

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 !

[LeoAnderson]

Et des tables qui ne contiennent pas de rowid, c'est quoi donc ??? comment est-ce possible ?

[LeoAnderson]

Et sinon, est-ce que la lenteur ne proviendrait pas des disques très sollicités ?

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