Oracle 10g - Imp très lent

Bonjour,

Depuis quelques semaines, les imports de dumps sur notre base Oracle 10g sont de plus en plus lents (plusieurs heures pour un dump de 2 Mo). Et ce, que je lance l'import à distance ou directement sur le serveur.

La commande passée est :

Code:

---

imp system/<PWD>@mabase file=dump.dmp fromuser=TOTO touser=TITI log=Imp_TOTO_TITI.log

---

La base est mode noarchivelog

J'ai testé la commande

Code:

---

SELECT * FROM v$session_wait WHERE sid=147

---

Mais je ne sais pas ce que je dois en tirer !!!

Voici le retour de la commande précédente

Citation:

---

SID : 147
SEQ# : 1 343
EVENT : Data file init write
P1TEXT : count
P1 : 4 294 967 295
P2TEXT : intr
P2 : 32
P3TEXT : timeout
P3 : 2 147 483 647
WAIT_CLASS_ID : 1 740 759 767
WAIT_CLASS# : 8
WAIT_CLASS : User I/O
WAIT_TIME : -1
SECONDS_IN_WAIT : 346
STATE : WAITED SHORT TIME

---

Je ne trouve pas d'où peut venir ce ralentissement. Je continue de chercher et me tourne vers vos lumières pour éclairer ma lanterne.

Merci d'avance pour votre aide

Cordialement

Bonjour,

as-tu essayé avec datapump?

Bonjour Z3phur et merci pour ta réponse,

Non je n'ai pas essayé. Je ne maîtrise pas trop cette commande et nos clients nous envoient des dumps exportés par la commande exp.

De plus, la base que je suis en train de remonter (celle de 2Mo, lancée à 10h et toujours en cours) a été exportée d'un Oracle 9i pour être remontée sur un 10g. Le datapump, si je ne me trompe pas, ne fonctionne pas sous 9i.

Je vais toutefois essayer en local de faire un export/import par datapump et voir si l'import est plus rapide.

Bonjour,

sinon as-tu essayé de faire l'import dans une autre base pour voir si cela est plus rapide?

Quels sont les paramètres mis lors de l'export.

Oui, j'ai un Oracle 10 XE sur mon poste et l'import s'effectue à vitesse normale (en fonction de la taille du dump)
idem en 9i et en 11g

la commande d'export est la suivante :

Code:

---

exp system/<pwd>@mabase file=dump.dmp owner=<SCHEMA> log=fichier.log

---

Je vais essayer un vidage du cache (http://oracle.developpez.com/faq/?page=4-9#emptycache)

Bonjour,
génère un cliché awr avant puis après/pendant l'import afin de déterminer ou se produisent les attentes.
Cela te permettra de savoir s'il y a des attentes, vérifier les temps d'accès aux fichiers, les éventuels locks etc.
2 Mo en plusieurs heures, c'est franchement trop long.
Voici ce que je vois qui pourrait ralentir considérablement :
- présence de vues matérialisées
- réplication
- énormément d'index par table
- verrouillage d'une table par une autre session
- redolog ridiculement petit

Est-ce que l'import évolue (essaie avec l'option feedback=100, cela affichera un point pour 100 lignes inséreés) ?

Bonjour

J'ai fait un flush du cache, mais le problème reste le même : mon dump de 2 Mo a été relancé à 18h00 hier soir et n'est toujours pas terminé!!!

13thFloor, merci pour ta réponse

Citation:

---

Envoyé par 13thFloor

Bonjour,
génère un cliché awr avant puis après/pendant l'import afin de déterminer ou se produisent les attentes.
Cela te permettra de savoir s'il y a des attentes, vérifier les temps d'accès aux fichiers, les éventuels locks etc.

---

Je vais voir ça (il faut que je cherche comment on fait un cliché awr ... :oops:)

Citation:

---

Envoyé par 13thFloor

Voici ce que je vois qui pourrait ralentir considérablement :
- présence de vues matérialisées
- réplication
- énormément d'index par table
- verrouillage d'une table par une autre session
- redolog ridiculement petit

---

Je suis en train de regarder tout ça (n'étant pas DBA et découvrant les fonctionnalités d'Oracle à chaque résolution de pb, il me faut un peu de temps)
- présence de vues matérialisées :
la requête

Code:

---

select * from user_mviews;

---

ne rapporte aucune ligne

- réplication : je cherche
- énormément d'index par table : à priori non. La structure des base n'a pas changé ces derniers temps et il y a encore 3 semaine, tout allait bien. En revanche, sur ce serveur, nous avons une instance qui regroupe beaucoup de schémas.
- verrouillage d'une table par une autre session : je cherche
- redolog ridiculement petit : paramètres par défaut lors de la création de l'instance (51200). Le mode log est sur NOARCHIVELOG (si je comprends bien, le redolog ne donc pas modifié ?)

Citation:

---

Envoyé par 13thFloor

Est-ce que l'import évolue (essaie avec l'option feedback=100, cela affichera un point pour 100 lignes inséreés) ?

---

Je relance l'import avec cette option.

Merci encore

--edit --
A chaque fois que je relance l'import, les premières tables se remontent plus vite, puis il bloque un peu plus loin.

Plutôt que chercher des pistes éventuelles, il sera plus efficace de déterminer ce qui se passe pendant l'import.
Concernant awr :
juste avant l'import, lance, sous sqlplus en tant que sysdba :

Code:

---

exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT

---

après 30' ou 1h d'import, rebelote :
exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT
Sous sql+ : @?/rdbms/admin/awrrpt.sql
Le script va te demander :
- le type de rapport que tu veux (texte ou html)
- le nombre de jours des derniers clichés => tape 1, tu auras ceux des dernières 24h
- l'id du cliché de début : celui généré juste avant l'import, en principe l'avant-dernier
- l'id du cliché de fin : en principe le dernier dans ton cas
- le nom du rapport

Il en reste plus qu'à analyser le contenu du fichier généré, notamment les parties :
- Top 5 Timed Events
- SQL ordered by Elapsed Time
- SQL ordered by Reads
- Tablespace IO Stats (temps d'accès)
- Segments by Row Lock Waits

En mode text tu peux envoyer le rapport sur http://www.statspackanalyzer.com/analyze090630.asp pour une première analyse.

il faut ajouter à la commande commit=Y

imp system/<PWD>@mabase file=dump.dmp fromuser=TOTO touser=TITI log=Imp_TOTO_TITI.log commit=Y