export avec erreurs EXP-00056 et ORA-01555 [Résolu]

[moi26]

Bonjour,

J'essaye de faire un export de ma base de production. cette base en 9.2.0.7 fait 240Go.
l'export bloque sur une table qui fait 135go a elle seule.
J'ai augmenté le undo_retention à 90000 et les UNDOTBS sont à 16,5Go.
Mais le probleme persiste.

comment puis je analysé plus précisement ce probleme?
j'ai regardé du coté de v$undostat mais je ne vois pas de valeur qui aurait "explosé" d'un coup.
dans les logs, j'ai SELECT /*+NESTED_TABLE_GET_REFS+*/ avec une "Query Duration=124248 sec"
cette valeur correspond elle à l'undo_retention total nécéssaire pour cette table ou la valeur au moment du plantage?

Je ne sais pas non plus si l'option "consistent" peut améliorer ou non mon export: la table est mise à jour en permanence et je ne veux pas bloquer les mise à jour.

Merci pour vos réponses.

[orafrance]

le plus simple pour comprendre le problème c'est encore de scruter v$session_wait et v$system_event pendant l'export. Pour le UNDO, t'as pas à t'en soucier pendant l'export qui ne fait que du SELECT.

Est-ce que pendant cet export, des utilisateurs modifies les données ? C'est pas possible de cloner ta base ou transporter les tablespaces avec RMAN par exemple ?

[moi26]

grosse base de prod, pas possible de l'arreter pour en faire une copie.
pour RMAN, je ne le maitrise pas du tout.
Sinon, j'avais pensé par rapport à la sauvegarde.
Est ce que je peux faire quelque chose avec une sauvegarde à chaud?

[moi26]

sinon oui, cette tables est modifié en permanence.
J'ai essayé de faire l'export quand la tables est le moins sollicité mais idem.
ça met plus de 40h en tout!

[pifor]

Envoyé par moi26

Est ce que je peux faire quelque chose avec une sauvegarde à chaud?

Oui, vous pouvez utiliser la technique classique de clonage (sauvegarde base source, création des fichiers de contrôle de la nouvelle base) à partir d'une sauvegarde à chaud de façon similiaire au clonage à partir d'une sauvegarde à froid. La principale différence c'est la nécessité d'exécuter une récupération de la base cible (commande RECOVER) pour réappliquer les archive logs générés pendant la sauvegarde à chaud de la base source.

[orafrance]

Envoyé par moi26

grosse base de prod, pas possible de l'arreter pour en faire une copie.

bah si c'est une grosse base de prod, j'ose espérer que tu as un backup non ? C'est une bonne occasion de le tester

Envoyé par moi26

sinon oui, cette tables est modifié en permanence.
J'ai essayé de faire l'export quand la tables est le moins sollicité mais idem.
ça met plus de 40h en tout!

comment peut-tu espérer avoir des données consistantes sans perturber les utilisateurs dans ce cas

[moi26]

...des backups j'en ai à priori. le hic, c'est que je n'ai pas de serveur ayant assez de place pour tester ces backups...

En fait, avoir des données consistantes n'est pas important. L'idée est de remonter la base ailleurs (chez un prestataire) pour pouvoir la faire évoluer. Ce ne sont pas les données qui sont importantes en soit mais la taille et la structure de la base.

J'ai donc continuer mon export avec un undo_retention=150000

[pifor]

Envoyé par moi26

Ce ne sont pas les données qui sont importantes en soit mais la taille et la structure de la base.

Pour exporter uniquement la structure de la base (tablespaces et schémas sans les données), il suffit d'utiliser l'option d'export:

Code :

ROWS=N

[moi26]

oui mais le responsable dev veut un export complet

[orafrance]

Envoyé par moi26

...des backups j'en ai à priori. le hic, c'est que je n'ai pas de serveur ayant assez de place pour tester ces backups...

bah l'export tu le mets où si t'as pas assez de place ?

[moi26]

je me suis mal exprimé:
j'ai un serveur de stockage (qui sert pour tout le monde) sur lequel je copie mon dmp de 200Go.
Mais je n'ai pas de serveur ayant oracle pour remonter une base.

[orafrance]

et tu peux pas envoyer les fichiers sauvés plutôt qu'un bête dump ? En plus pour le prestataire ce sera problablement plus simple.

[moi26]

non, je dois respecter la demande, c'est à dire un dump de la base compressé au format bzip2

[orafrance]

bah faudra leur dire d'être patient alors

[Pomalaix]

Envoyé par orafrance

Pour le UNDO, t'as pas à t'en soucier pendant l'export qui ne fait que du SELECT.

Pas d'accord !
L'export ne génère pas de données UNDO vu qu'il ne fait effectivement que des SELECT, en revanche il est très susceptible d'aller lire les données à exporter dans les segments UNDO, vu qu'il y a une activité transactionnelle simultanée.
Cela veut dire que si l'export de la grosse table commence à 2H et dure 10H, il faut maintenir dans les UNDO pendant 10H les valeurs initiales (telles qu'elles étaient juste avant 2H) de toutes les données modifiées pendant l'export, afin de respecter le principe de lecture cohérente.

[orafrance]

ha oui, j'avais pas pensé au satané snapshot too old

[moi26]

enfin!
l'export est réussi au bout de 38 heures:
l'undo_retention était à 150000 (120000 ne passait pas) et l'undotbs à 16,5Go.

la table posant probleme comportait 325 millions de lignes.

Merci pour vos aides respectives, elles m'ont bien aidées.
M

[Pomalaix]

Envoyé par moi26

enfin!
l'export est réussi au bout de 38 heures:

On est content pour vous !
Vous êtes conscient que l'import va durer au moins 3 ou 4 fois plus longtemps ?
Ils ont intérêt à utiliser les paramètres RESUMABLE vos collègues, sinon dans 15 jours ils y seront encore...

[moi26]

c'est même pire que ça, on m'a demandé de faire un bzip2 de mon dump!
j'en ai déjà pour 55h de compression sur un serveur bi-proc!

ils vont mettre plus d'un MOIS avant de voir les premieres données!

[orafrance]

y'a certain prestataire qui devrait penser à se mettre à la maçonnerie ou l'électricité parce que visiblement l'info c'est pas leur fort

un prestataire qui demande un export pareil, vraiment c'est n'importe quoi Sauf si c'est de la régie... ils ont trouvé un bon moyen de faire trainer les choses