Discussion :

[Bonnie38]

Bonjour.
J’ai une base 11.1.0.6.0 sur Linux (Redhat 5).
J’essaye de faire une procédure de sauvegarde à chaud et de reconstruction de ma base en cas de crash avec évidemment récupération des données (utilisée aussi éventuellement pour alimenter une base de test).

Mais lors de la reconstruction de ma base ça ne passe pas. Voici mon mode opératoire :

J’ai passé ma base en mode archivelog (et en force logging).
Mes archives de redo log sont multiplexés sur mon disque de sauvegarde.

Pour la sauvegarde j’ai fait un script qui effectue :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Archive log list;
Alter system switch logfile;

Puis pour chacun des tablespaces de la base:
- passage du tablespace en mode backup (begin backup)
- copie du fichier sur mon disque de sauvegarde
- je repasse le tablespace en mode normal (end backup)

Puis à la fin de mon script :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Alter database backup controlfile to ‘/save/control.ctl’ REUSE ;
Alter system switch logfile;
Archive log list;

Pour reconstruire une base en se servant de la sauvegarde :
- je repasse mes scripts de création de base vide.
- j’arrête ma base (shutdown immediate)
- j’écrase les datafiles (.dat et .dbf) avec ceux de la sauvegarde
- j’écrase les redo log et les archives de redo log avec ceux de la sauvegarde
- j’écrase mes 2 fichiers de contrôle avec le fichier control.ctl de la sauvegarde (là j’ai un gros doute !)
- je me connecte sous sysdba
- je monte ma base
- puis j’exécute la commande suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

recover database using backup controlfile ;

Il me demande alors les archives en me suggérant à chaque fois l’archive avec la bonne séquence (il m’affiche à chaque fois les erreurs ORA-00279, ORA-00289, ORA-00280). Donc je fais juste « Entrer » pour qu’il prenne en compte l’archive.

Ensuite je fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Alter database open resetlogs ;

Et là erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ORA-01113 : le fichier 1 nécessite une récupération après défaillance matérielle
ORA-01110 : fichier de données 1 : ‘/base/ora_system.dbf’

J’avoue être perdue. Comme je ne maitrise pas le détail de ce que font les commandes, je n’arrive pas à trouver mon erreur.
Quelqu’un peut m’aider ?
Merci d'avance

[scheu]

As-tu bien rejoué TOUS les archivelogs (mêmes ceux générés après ton backup des tablespaces) ?

[Bonnie38]

Peut-être pas.
J'ai recopié les archivelog. J'avais de la séquence 60 à la séquence 70.
Et lors du recover il m'a demandé les séquences à partir de 64, mais il ne s'est pas arrêté à 70, il a demandé la 71 que je n'avais pas.
En fait volontairement j'ai fait des modifications de ma base pendant le backup (là normalement les modif sont compris dans les archivelog que j'ai recopié).
Puis j'ai arrêté ma base pour tout figer, et bien mis de coté tous les archivelog et les redo log pour ne pas les écraser par ceux générés lors de ma reconstruction de base vide.
après j'ai écrasé tous les fichiers par ceux mis de coté.
Sinon mon mode opératoire est bon?

[scheu]

Le log 71 était la séquence en cours pendant ton backup ?
Dans ce cas tu en as besoin pour finir la restauration, sinon tes datafiles peuvent être désynchronisés (pas tous au même SCN vu que tu ne les as pas copiés en même temps)

Pour ta procédure, je backuperais d'abord les tablespaces/datafiles, ensuite log du switch et enfin sauvegarde des archivelogs (y compris celui généré par le switch)

[pifor]

Pour dupliquer une base, il est inutile de la recréer avec CREATE DATABASE mais il faut recréer les control files avec CREATE CONTROLFILE. Il ne faut pas en général sauvegarder les online redo logs.

[Alain B.]

il faut penser à sauver les données redo générées pendant la durée de toute l'opération de backup.

Surtout si on procède individuellement par tablespace, il peut/va y avoir un écart entre le premier tablespace ( en générale le datafile 1 = system.dbf) et le dernier.

APRES la backup des tablespaces, il faut forcer un archivage des redo et garder ces archives au chaud avec le le reste du backup.


Je crois qu'il existe maintenant un "database begin/end backup"

PS:
Message subliminal :
!!! RMAN c'est bien !!! RMAN c'est bien !!! RMAN c'est bien !!!

[Bonnie38]

J'ai refait ma manip: sauvegarde à chaud (après avoir recréer une base correcte bien sur), modif de ma base pendant la sauvegarde, modif de ma base après la sauvegarde (tout ça pour tester que je retrouvais mes données après restauration).
Avant de recréer ma base à vide, j'ai bien tout sauvegardé dans un coin. J'ai vérifié mes archivelog, j'avais les séquences 60 et 61.
Et pendant ma restauration, rebelote, il m'a demande la séquence 61 (OK), puis après la 62 qui n'a jamais existé.
Donc restauration toujours KO et je ne sais plus quelle commande tester.

J'aurais voulu une confirmation:
Dans ma procédure de restauration, j'écrase mes fichiers de control (control1 et control2) par le fichier généré lors de ma sauvegarde par la commande "alter database backup control file...".
C'est bien ça qu'il faut faire ou non?
Pifor dit qu'il faut recréer les controlfiles. Mais alors ça sert à quoi cette commande de backup du control file alors?

Pour répondre à pifor: je recréé ma base à vide car la commande que je lance pour la création faire tout un tas de chose, style création de répertoire, génération de script, etc... Donc c'est plus facile pour moi de lancer la commande et être sure que tout est fait plutôt que faire une nouvelle commande avec tout le reste sauf le "CREATE DATABASE".

Pour répondre à Alain:
- malgré ce que j'ai mis dans mon 1er post, je mets tous les tablespaces en backup, puis copies des fichiers, puis rebasculement des tablespaces en mode normal.
- j'ai bien sauvegardé mes redo log après le backup (en fait juste avant de recréer ma base à vide).
- Je force bien un archivage de mes redo à la fin de mon backup. Par contre je ne le fais pas juste avant de casser ma base, vu que je "simule" un crash disque.
- RMAN, j'ai essayé, enfin j'ai essayé de faire ma sauvegarde en construisant une standby database, mais pour être franche, j'ai pas tout compris (loin de là), et je ne suis jamais arrivée à le faire jusqu'au bout.

En tout cas merci pour toutes vos réponses.

[Alain B.]

il m'a demande la séquence 61 (OK), puis après la 62 qui n'a jamais existé.
Donc restauration toujours KO

Pas obligatoirement, Oracle espère que le 62 soit dans les redo logs multiplexés qui ont peut être échappé au crash.
Que donne l'open en resetlog ?

J'aurais voulu une confirmation:
Dans ma procédure de restauration, j'écrase mes fichiers de control (control1 et control2) par le fichier généré lors de ma sauvegarde par la commande "alter database backup control file...".
C'est bien ça qu'il faut faire ou non?

Le problème est aussi lié au script qui recrée inutilement la base !
Dans le cas que tu essaie de reproduire, crash complet, il n'y a PLUS de controlefile et encore moins de redo.
La théorie dans la mesure du possible il faut essayer de garder les ctl file et redo de la production au moment du crash (d'ou l'importance du multiplexage), ce qui permet un recover complet et un open normal.
Dans ton cas, les fichiers créés par le script de recréation arrivent comme un cheveu sur la soupe!

Si le controlefile n'est plus disponible il faut reprendre celui du backup.
Si les redos ont disparus NE PAS PRENDRE CEUX DU BACKUP, d'ailleurs normalement ils ne devraient pas être backupés, et laisser l'open en resetlog les recréer.

j’écrase les redo log [...] avec ceux de la sauvegarde

C'EST MAL!


Tu as appris au moins DEUX choses:
-prendre le temps de faire un script qui respecte les techniques normales de sauvegardes/restoration: scripts bancal, fait à la va vite pour gagner du temps => gros pépins à l'arrivée.
-Tester ses scripts de backup ET de restoration permet de s'éviter de tres mauvaises surprises.


Je te conseille vraiment d'approfondir RMAN.
J'étais un peu dépaysé au début, ne pas avoir un accès direct à mes fichiers backupés m'a traumatisé un bout de temps.
Mais on se familiarise assez vite, surtout si on commence PAR DU SIMPLE, une standby c'est un peu la charue avant les boeufs

[Bonnie38]

Je viens juste de finir la lecture d'un post datant de mai (18 pages très instructives!!).
Donc avec les infos du post et de ta réponse, je suppose que la séquence 62 se trouve dans le redo log courant.
Si j'ai bien tout compris, lors du recover, il faut donner les archivelog, et quand il demande une séquence qu'on n'a pas, il faut donner le redo log courant.

j'ai aussi appris (mieux vaut tard que jamais...) que le control file sauvegardé était inutilisable si depuis la sauvegarde de nouveaux tablespaces sont créés. Les archivelog et redo log seuls ne suffisent pas à la création des nouveaux tablespaces. Comme dans mon appli on créé plein de nouveaux tablespaces, c'est utile de le savoir!
=> Donc je vais de ce pas multiplexer mes control files sur mon disque de sauvegarde, et retenter une sauvegarde et une restauration, et bien sur je vous tiens au courant!

Pour RMAN, oui ça serait bien que je m'y mette! Par contre là je vais essayer de faire avec la méthode manuelle (vu que le temps presse un peu), et quand j'aurais plus de temps j'essaierais de refaire ça avec RMAN).

[Alain B.]

il faut donner le redo log courant.

J'insiste courant ne signifie pas sorti du backup !

j'ai aussi appris (mieux vaut tard que jamais...) que le control file sauvegardé était inutilisable si depuis la sauvegarde de nouveaux tablespaces sont créés. Les archivelog et redo log seuls ne suffisent pas à la création des nouveaux tablespaces.

Tiens je suis surpris...
Vu que je crois me souvenir avoir vu la création de tablespace passer sur une standby. Et une standby ça tire ses infos des archives...
(je vais faire un test un de ces jours pour être sur quand même)

Mais depuis que je suis sous RMAN, ce n'est plus un problème.

Pour RMAN, oui ça serait bien que je m'y mette! Par contre là je vais essayer de faire avec la méthode manuelle (vu que le temps presse un peu), et quand j'aurais plus de temps j'essaierais de refaire ça avec RMAN).

La bonne vielle contrainte de temps, la source de tout les maux.


PS: lien du post de 18 pages ?

[Bonnie38]

Oui je prendrais bien le redo log courant (vu qu'ils sont multiplexés je devrais toujours avoir les derniers).
D'ailleurs vu que j'ai une copie "en live" des redo log, des archivelog et bientôt des control files sur mon disque de sauvegarde, je me demande à quoi ça sert se sauvegarder autres choses que les datafiles lors de la sauvegarde.

Pour ta 2ème remarque, c'est vrai que vu comme ça c'est surprenant. C'est vrai que du coup je sais pas comment ça marche avec la standby. A voir...

Voici le lien du post:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

http://www.developpez.net/forums/d547284/bases-donnees/oracle/import-export/probleme-journaux-darchivelogs/

Bonne lecture!! J'ai appris des choses et j'ai aussi un peu rigolé!

[Alain B.]

je me demande à quoi ça sert se sauvegarder autres choses que les datafiles lors de la sauvegarde.

Au cas ou un problème matériel, mémoire par exemple, ne vienne corrompre TOUS les controlefiles ?

PS :
Se mettre de coté le spfile/pfile ca évite aussi des moments de solitudes

[Alain B.]

Bonne lecture!! J'ai appris des choses

Attention quand même, chaque commande, chaque paramètre, apparaissant dans les forums sont destinés à répondre à UN point, UNE problématique précise.

Il n'y a pas de commande miracle.
On voit de plus en plus de forumeurs demander de l'aide en urgence, parce qu'au lieu de faire appel à un support compétent, ont tenté dans le désordre un peu toutes commandes sans vraiment les comprendre.

[Bonnie38]

C'est pour ça que je trouve le post de phil4444 intéressant, car il y a eu toute une discussion, avec des personnes qui maitrisent et d'autres moins, donc intéressant d'avoir la réflexion de chacun, remettre en question tous les points, etc... Plutôt que de lire une doc qui dit "il faut faire ça".

En tout cas moi ça m'a aidé (avec aussi les réponses que j'ai eu sur mon post bien sur). Et maintenant ma restauration marche.

Dans mon cas j'ai fait ma sauvegarde à chaud comme je l'ai indiqué, et à la restauration, je recopie:
- les datafiles de la sauvegarde
- les control files, redo log et archivelog présents juste avant le "crash" car ils sont multiplexés sur mon disque de sauvegarde.

Puis j'ai tapé la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

recover database until cancel

(je n'avais peut-être pas besoin du "until cancel", faut voir...), en lui laissant prendre les archivelog qu'il suggérait s'ils étaient présents, et en indiquant le redo log courant quand il demandait une séquence que je n'avais pas dans les archivelog.
Remarque: vu que je ne savais pas lequel de mes redo log était le courant, j'ai donné le 1er => Ca n'a pas marche. Du coup j'ai retapé ma commande "recover...", puis donné le 2ème, et là BINGO!!! J'ai eu la belle petite phrase qu'on espère tous avoir : "Récupération après défaillance matérielle terminée".

Après j'ai ouvert ma base avec:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

alter database open noresetlogs

Et j'ai retrouvé mes données, celles d'avant la sauvegarde et celles que j'avais inséré après la sauvegarde.

Donc problème résolu pour moi. Je n'ai pas encore tout compris, mais je suis sur la bonne voie!
Il ne me reste "plus" qu'à faire des tests, en créant de nouveaux tablespaces, en en supprimant d'autres, etc...
Merci tout le monde