Je croyais que l'export était consistent depuis la v8 (d'ailleurs il y avait une option pour cela)
Je ne l'ai jamais vu utilisé et ne l'ai jamais utilisé moi même (n'utilisant qu'au minimum exp/imp), mais sur une grosse base ou une base fortement sollicitée : l'export est trop impactant et l'import quasi impossible.
imp/exp ne fonctionnait pas sur une base spatiale (sans d'affreuses bidouilles) et peut être avec d'autre bases ayant des options particulières.
Quels problèmes as tu rencontré avec les exports / imports ? le renommage des TBS ? le volume des données ? ou autre ?
cela m’intéressent beaucoup
Les exports/imports sont extrêmement lents, les tables sont réalimentés, les indexes recréés (ou pas), les contraintes validées (ou pas) et j'en oublie...
Tout ça fait que l'import peut durée des jours et tu risques ensuite de passer des jours à rendre la base 100% opérationnelles (création d'index, activation contraintes & co).
Vers 2004 sur un AIX4/Oracle 9i (certes l'OS était obsolète) reconstruire un index en // de 60 ou 70Gb prenait 48h (et il y en avait bcp). La restauration full de la base via rman ~7h.
Sur les grosses bases imp/exp pas possible. Datapump est beaucoup plus performant, mais lors de la restauration tu n'auras pas physiquement la même base (donc des requêtes plus performantes ou d'autre moins performantes en gros c'est une loterie)
Par contre pour nous c'est un élément de la sauvegarde, car dans certains cas tordus nos devs préfèrent que l'on >remonte une table d'un export (même de la veille) pour qu'ils puissent refaire la (ou les) table(s) endommagée(s)
J'ai déjà vu ça et je n'aime pas trop cette solution, depuis là 11g tu peux garantir la rétention du flashback, restaurer une tables via la requête ci-dessus me semble mieux et l'espace supplémentaire sera certainement inférieur à l'espace des exports (la compression datapump est payante).
De plus tu n'es capable de 'restaurer' qu'à la date de ton export (pas de recovery), comment valider les dumps (corruption & co), combien de dumps garder, ... ?
Je connais peu d'applications qui peuvent se permette de perdre 1 ou plusieurs journées en particulier un ERP.
Datapump peut servir à bcp de choses (extraction d'un subset de la base, transfert de données, migrations ...) mais ce n'est pas un outil de restauration.
[^] # Re: De la nécessité d'inclure les sauvegardes dans un processus plus grand
Posté par Kangs . En réponse au journal De l'importance (des tests réguliers) des sauvegardes. Évalué à 1.
Je ne l'ai jamais vu utilisé et ne l'ai jamais utilisé moi même (n'utilisant qu'au minimum exp/imp), mais sur une grosse base ou une base fortement sollicitée : l'export est trop impactant et l'import quasi impossible.
imp/exp ne fonctionnait pas sur une base spatiale (sans d'affreuses bidouilles) et peut être avec d'autre bases ayant des options particulières.
Les exports/imports sont extrêmement lents, les tables sont réalimentés, les indexes recréés (ou pas), les contraintes validées (ou pas) et j'en oublie...
Tout ça fait que l'import peut durée des jours et tu risques ensuite de passer des jours à rendre la base 100% opérationnelles (création d'index, activation contraintes & co).
Vers 2004 sur un AIX4/Oracle 9i (certes l'OS était obsolète) reconstruire un index en // de 60 ou 70Gb prenait 48h (et il y en avait bcp). La restauration full de la base via rman ~7h.
Sur les grosses bases imp/exp pas possible. Datapump est beaucoup plus performant, mais lors de la restauration tu n'auras pas physiquement la même base (donc des requêtes plus performantes ou d'autre moins performantes en gros c'est une loterie)
J'ai déjà vu ça et je n'aime pas trop cette solution, depuis là 11g tu peux garantir la rétention du flashback, restaurer une tables via la requête ci-dessus me semble mieux et l'espace supplémentaire sera certainement inférieur à l'espace des exports (la compression datapump est payante).
De plus tu n'es capable de 'restaurer' qu'à la date de ton export (pas de recovery), comment valider les dumps (corruption & co), combien de dumps garder, ... ?
Je connais peu d'applications qui peuvent se permette de perdre 1 ou plusieurs journées en particulier un ERP.
Datapump peut servir à bcp de choses (extraction d'un subset de la base, transfert de données, migrations ...) mais ce n'est pas un outil de restauration.