Version imprimable
Bonjour,
J'ai affaire à une base en mode NOARCHIVELOG.
La sauvegarde actuelle consiste à faire un full export de la base ouverte.
Si je restaure via un script de création de la base + utilitaire imp, ma base sera t'elle dans un état incohérent?
Merci d'avance.
Si tu as pris soin d'ajouter l'option CONSISTENT=Y ça devrait aller :)
Ce qui veut dire, que de cette manière on peut faire de la récupération de bases de données en mode NOARCHIVELOG?
Merci d'avance.
Citation:
Envoyé par orafrance
Oui, c'est même le seul moyen de faire un backup base ouverte en NOARCHIVELOG... ce qui, du reste, n'est pas le plus approprié en prod :?
Pour quelles raisons ?
je vois la sollicitation des undo segments, y en a t'il d'autres?
Citation:
Envoyé par orafrance
les archivelogs sont le seul moyen de pouvoir retrouver un état cohérent de la base depuis une sauvegarde.
Bonjour,
Il faut faire attention a tout ca :l'export n'est pas une vraie sauvegarde
meme consistent =y
voir la section consistent =y dans la doc officielle pour les limitations
http://download.oracle.com/docs/cd/B...htm#sthref2160
De doute facons : Noarchivelog est deconseillé
voir le lien ici
http://oracle.developpez.com/guide/s...e/generalites/
Bref export et nonarchivelog , a éviter comme solution si on doit maintenir une base
J'ai lu la doc sur le mode consistent.
Elle dit que dans ce mode les objets exportés sont hermétiques aux modifications exterieures (même commitées) et ce, dès le lancement de l'export.
Donc le dump ne contiendra pas les données issues des transactions commitées qui se terminent après le lancement de l'export.
Celà ne contredit pas le fait que les informations exportées sont cohérentes et donc qu'on peut les récupérer dans cet état.
Mais j'ai bien compris que ceci ne peut constituer un paliatif au mode ARCHIVELOG.
Ma conclusion c'est que les utilitaires export sont utiles en cas de perte de données dans une table par exemple, mais je ne me hasarderai pas à utiliser le mode full
Merci à tous les deux.
Citation:
Envoyé par fatsora
Bonjour,
deux petites précisions:
- ne pas faire l'export en tant que sysdba (car consistent=y est ignoré dans ce cas)
- le but d'un backup, c'est de restaurer une base rapidement et dans un état identique. Donc un vrai backup, c'est une copie des fichiers physiques (+ archived logs). L'export logique ne réponds pas à ces contraintes: un import est très long (et surtout le temps d'import est difficile à estimer) et il va réorganiser complètement les tables et les index => celà peut poser de gros problèmes de perfs (plans d'exécution qui changent).
Cordialement,
Franck.
Merci à tous pour votre contribution
A+