Discussion :

[phil4444]

c'est du Windows 2003 server et je passe mes scripts au travers d'un interpréteur Cygwin

[philcero]

T'as pas trouvé plus compliqué ?

[orafrance]

je reviens à ma question ets-il mieux de faire une sauvegarde des control file en utilisant un BACKUP TO TRACE ou par ma méthode

les 2

backup control file permet de recréer le fichier de contrôle ce qui peut être utile mais c'est quand même plus pratique d'avoir le ctl

[orafrance]

c'est du Windows 2003 server et je passe mes scripts au travers d'un interpréteur Cygwin

Dans la série "j'aime pas faire simple"

[phil4444]

oui mais ça va, je suis en route pour la certification SENIOR DBA ORACLE
Je fais surtout avec ce que j'ai comme outil a disposition
j'ai pas de baie SUN 20k ou 25K avec de la haute dispo et un cluster veritas

je roule en LADA

[phil4444]

Euh sauf erreur de ma part en passant par un BACKUP TO TRACE ou un PROMPT alter database backup controlfile to '&folder/control01.ctl' REUSE;;
dans les deux cas c'est une création de controlfile que l'on fait au final.

Je ne cerne pas la valeur ajoutée

[orafrance]

non, backup to trace génère le script qui permet de recréer le control file...

[phil4444]

je ne comprends plus rien avec les sauvegardes des redo, un coup je dois les sauvegardés puisque avec les archivelogs en cas de perte des redos ça ne suffit pas pour la restauration.
et puis si je lis la réponse de Philcero, il dit
Ton REDO LOG il est dans le lot et c'est toi qui le copie vers ta destination. Ne pas perdre du point de vue qu'à partir du moment où tous les fichiers de ta base CTL+DATA ont un SCN inférieur à ton REDO, son contenu on s'en fou car il devient inutile et obsolète et il sera "remis à blanc" avec le OPEN RESETLOGS.

pour mémoire, je suis dans le cas d'une restauration compléte donc pas d'utilisation de RESETLOGS

[phil4444]

oui le PROMPT alter database backup controlfile to '&folder/control01.ctl' REUSE;;
créer aussi un fichier controlfile ?

plus haut dans un post tu parles qu'il est bon de récupérer les controlfiles, hors là on est dans la création

[orafrance]

Pas aussi... c'est le SEUL

backup to trace génère le script qui permet de recréer le control file...

va voir ça : http://orafrance.developpez.com/dbahelp/#L2.1

[phil4444]

Oui j'ai déjà lu la doc mais ça répond en rien à ma question
on peut créer un controlfile via un ALTER DATABASE BACKUP CONTROLFILE to filename;

le propre du DBA c'est de se contre-dire lol
voilà pourquoi je ne comprends rien, tu disais qu'il était bon de récupérer le controlfile et là tu parles de script de création de controlfile.

c'est un peu comme la différence entre une poire et le fromage.
réponse le fromage

ça veut rien dire mais on en sait pas plus.
j'apprends des choses ici quand même ou pas

[phil4444]

Dans mon processus de sauvegarde, j'ai positionné ma base en mode ARCHIVELOG et je voulais savoir si en plus je dois sauvegarder mes fichiers journaux (redo-logs) si oui comment je peux faire ça avec une base ouverte (on-line).
Question que j'avais posé hier et dont je n'ai pas la réponse.
Je ne vois pas de solution sans arrêter la base et c'est ce que je voudrais éviter en même temps.
en plus ARCHIVELOG ==> c'est quand même la sauvegarde des redos et pourtant j'ai fais un test de restauration sans mes fichiers journaux juste avec ceux qui ont été sauvegardés mais ça semble ne pas suffir. Le LGWR écrit dans les redo-logs donc je dirais qu'ils sont necessaire pour une restauration plus fine (c'est à dire avec les dernières transactions avant un crash disque ou un crash de la base)

[Milo59000]

On ne peut pas sauvegarder les fichiers REDO LOG lorsque la base est ouverte. C'est à ca que sert le mode ARCHIVELOG, faire une sauvegarde des fichiers REDO LOGS lorsque ceux-ci sont pleins (ou lors d'une bascule de REDO LOG).

Si ton disque dur crashe et que tu perds l'ensmble de tes fichiers REDO LOG, dans ce cas-là tu pourras faire une récupération de ta base jusqu'au dernier ARCHIVED REDO LOG que tu possèdes en utilisant le UNTIL CANCEL. De ce fait tu récupères ta base dans un état cohérent avant la crash mais tu auras perdu les transactions qui n'avaient pas encore étaient archivées.

Ensuite tu dis que le ALTER DATABASE BACKUP CONTROLFILE TO TRACE et la sauvegarde du fichier CTL c'est pareil (avec une jolie métaphore...) et bien non, la première commande te génère un script pour le recréer alors que la sauvegarde est une copie du fichier.

[phil4444]

Oui je suis d'accord, mais dans les posts nos amis surtout un voulait semer la confusion.

comme je te disais, j'ai écraser tout mes fichiers de la base avec une perte des redo-logs courant et j'ai pas pu restaurer ma base.

Pourquoi je ne sais pas, en tous les cas il y a un décalage de séquence et il va chercher une séquence qui n'existe pas dans la sauvegarde des redo-logs (ARCHIVELOG)

pour ce faire j'avais fait une restauration de ma sauvegarde (un simple cp des fichiers DBF, CTL, sans les Redos ).
1)connexion à la base
2)STARTUP MOUNT
3)RECOVER DATABASE (déjà à ce niveau, il demande un RECOVER DATABASE UNTIL CANCEL USING BACKUP¨CONTROLFILE
en précisant le fichier redo archivé, mais toujours un problème.
4) après j'aurais fait un ALTER DATABASE OPEN;

[Milo59000]

hmmmm... je ne vois vraiment pas de quel ami tu parles et je ne pense qu'il veuille semer la confusion.

Donc si je comprends bien, tu remet à partir d'une sauvegarde les fichiers CTL et DATA et seulement cela. Ensuite tu fais un STARTUP MOUNT pour ensuite faire un RECOVER DATABASE et là il te dis de faire un RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL. Ca me parait normal.

En fait, ce que tu dois faire, à mon avis, ce n'est pas indiquer une archive lorsque ca plante mais un fichier REDO LOG en ligne. J'ai déjà eu ce problème. En essayant avec chaque fichier REDO LOG en ligne au bout du deuxième ou troisième fichier indiqué, il m'a trouvé ma séquence et j'ai eu droit à RECOVERY COMPLETE et ensuite j'ai pu faire mon ALTER DATABASE OPEN RESETLOGS afin de créer une nouvelle incarnation de ma base. La dernière étape étant de refaire une sauvegarde à froid de ta base !

Voilà... en tout cas essaie comme cela en indiquant non pas un e archive mais un REDO LOG en ligne.

Dis nous ce qu'il en est car je suis un peu pommé dans cette discussion qui part dans tous les sens ^^

[phil4444]

Voici le genre d'erreur suite au RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE

après je choisis AUTO


SQL> RECOVER AUTOMATIC DATABASE USING BACKUP CONTROLFILE;
ORA-00279: changement 1277726 gÚnÚrÚ Ó 05/15/2008 10:01:29 requis pour thread 1
ORA-00289: suggestion : D:\ORAINET\ARCHIVELOG\ARC00004_0654697185.001
ORA-00280: le changement 1277726 pour le thread 1 se trouve au no de sÚquence 4
ORA-00278: le fichier journal 'D:\ORAINET\ARCHIVELOG\ARC00004_0654697185.001'
n'est plus nÚcessaire pour cette rÚcupÚration
ORA-00308: impossible d'ouvrir le journal d'archivage
'D:\ORAINET\ARCHIVELOG\ARC00004_0654697185.001'
ORA-27041: ouverture du fichier impossible
OSD-04002: ouverture impossible du fichier
O/S-Error: (OS 2) Le fichier spÚcifiÚ est introuvable.


Indiquer le journal : {<RET>=suggÚrÚ | nomfichier | AUTO | CANCEL}
AUTO
ORA-00308: impossible d'ouvrir le journal d'archivage
'D:\ORAINET\ARCHIVELOG\ARC00004_0654697185.001'
ORA-27041: ouverture du fichier impossible
OSD-04002: ouverture impossible du fichier
O/S-Error: (OS 2) Le fichier spÚcifiÚ est introuvable.


ORA-00308: impossible d'ouvrir le journal d'archivage
'D:\ORAINET\ARCHIVELOG\ARC00004_0654697185.001'
ORA-27041: ouverture du fichier impossible
OSD-04002: ouverture impossible du fichier
O/S-Error: (OS 2) Le fichier spÚcifiÚ est introuvable.

[Milo59000]

Indiquer le journal : {<RET>=suggÚrÚ | nomfichier | AUTO | CANCEL}
AUTO
ORA-00308: impossible d'ouvrir le journal d'archivage
'D:\ORAINET\ARCHIVELOG\ARC00004_0654697185.001'
ORA-27041: ouverture du fichier impossible
OSD-04002: ouverture impossible du fichier
O/S-Error: (OS 2) Le fichier spÚcifiÚ est introuvable.

Voilà, ici au lieu de mettre AUTO, met le chemin vers ton fichier REDO LOG, par exemple : /u01/toto/redo/redo1.log

Si ca marche pas essaie avec le redo2.log puis le redo3.log, etc...

En espérant que ca fonctionne...

Voici le genre d'erreur suite au RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE

après je choisis AUTO


SQL> RECOVER AUTOMATIC DATABASE USING BACKUP CONTROLFILE;

Fais attention tu dis que tu fais un UNTIL CANCEL et en dessous dans la commande tu le met pas ^^

[phil4444]

Alors voila en réponse à ton post

Comme je te disais, c'est peut être pas clair mais dans la logique d'une sauvegarde à chaud, ma sauvegarde ne tient pas compte des redo logs courant donc difficile pour moi de charger les redo01.log etc...

Le soucis c'est qu'Oracle ne permet pas vraiment une récupération compléte lors d'un crash disque, car dans cette hypothèse je n'ai plus les redo-logs courant, je reste cohérent avec ma sauvegarde à chaud.

et je ne veux pas me lancer dans une sauvegarde à froid.

Tu me proposes d'écrire une nouvelle incarnation en faisant un RESETLOGS, c'est ça qui séme le doute dans mes POSTs, parce que les collégues ici sont pas tous en accord avec leur logique, il est bien dit plus haut que l'utilisation d'un RESETLOGS ets souhaitable dans le cas d'une restauration imcompléte

[philcero]

...ma sauvegarde ne tient pas compte des redo logs courant...

C'est pour cela que je t'ai spécifié qu'il fallait faire un SWITCH LOGFILE entre le moment où tu as fini la sauvegarde de ta base et celle des archive logs car ainsi le ou les SCN manquants seront obligatoirement dans le dernier fichier ARCHIVE, d'où l'inutilité d'avoir un contenu cohérent dans les REDO LOGS sauvegardés (Rappel : Ils ne font pas vraiment partie de la base donc le ou les SCN qu'ils pourraient fournir ne sont pas pris en compte lors de la recherche du SCN de référence)...

Rappel de la procédure (L'ordre est crucial) :

1. BKP Les DATAFILES [SCN n à n+t]
2. BKP Un exemplaire des CONTROL FILES via le BACKUP TO TRACE [scn n+t+x]
3. On fait le SWITCH LOGFILE ou ARCHIVE LOG CURRENT (Qui va provoquer un SWITCH)
4. BKP Les REDO LOGS
5. BKP Les ARCHIVE LOGS (Qui contiennent tous les changements de n à n+t+x)

[Milo59000]

Soit... Mais normalement, tes fichiers redo logs d'avant ton crash existe encore (est-ce que je me trompe ? Aurais-je passser cette information ?)

Pour ce qui est du RESETLOGS, après une récupération complète ou incomplète, il faut IMPERATIVEMENT réaliser une sauvegarde à froid (CTL, DATAFILE, REDO LOG, PFILE/SPFILE) de ce fait les archived log précédent ne te sont plus d'aucune utilité. Pour moi le RESETLOGS est donc un moyen de remettre la base de données à "PROPRE" comme si il s'agissait d'une nouvelle base avec tes anciennes données.

Oracle permet très bien une récupération complète lors d'un crash disque mais pour celà il faut avoir multiplexer les fichiers de REDO LOG sur des disques différents. Par contre, il est vrai que si cela n'est pas réalisé, que le disque crash, que tu perds tes REDO LOG alors tu ne pourras pas réaliser un récupération complète mais une récupération incomplète. Tout cela dépend vraiment de la configuration et la stratégie de sécurisation des données.

Maintenant, apparement tu restes "bloqué" (sans rien de méchant ) sur la sauvegarde à chaud. Certes la sauvegarde à chaud est très utile et est largement suffisant si tu as multiplexé tes fichiers REDO LOGS car dans ce cas, tu pourras réaliser une récupération complète. Mais apparement dans ton cas, les fichiers REDO LOG n'étaient pas multiplexés... et comme tu peux remarquer, ta sauvegarde à chaud n'est pas suffisante...

Ou en est-on ? Maintenant, tu dois tout de même pouvoir réaliser une récupération grâce à tes ARCHIVED REDO LOG soit avec un UNTIL CANCEL et dans ce cas lorsqu'il te demande le fichier manquant tu marque CANCEL, soit avec une récupération UNTIL TIME (en indiquant une heure et une date contenue dans ton dernier ficheir ARCHIVED REDO LOG), soit avec une récupération UNTIL SCN (en indiquant le deernier SCN contenu dans ton dernier ficheir ARCHIVED REDO LOG).

Je crois que je viens de battre la longueur du plus long post sans code ^^