Discussion :

[D_Latch]

Bonjour à tous !!!


Je suis nouveau sur le forum, ... et sur oracle aussi. (1 an et demi)

Voici mon problème :

J'ai fait une sauvegarde à froid. (sur une base de test) ==> OK
J'ai voulu restaurer.
Donc j'ai fait :
Copier de tous les .dbf data sur le filesystem data
Copier de tous les .dbf redo sur les filesystem redo
Copier le .dbf system sur le filesystem system
...


Sauf !!!!!

Que j'ai oublié de sauvegarder les .dbf undo

Donc quand je restaure tout... y compris le control file.
Il me dit que l'undo est plus récent que le control file.
(Se qui est normal... le SCN de l'undo doit être plus récent car les .dbf n'ont pas été restaurés [Quelqu'un peut confirmer que c'est bien le SCN qui pose problème ?])

Sinon la vrai question :

Comment faire pour pouvoir remonter ma base... (si c'est encore possible )


Voici le contexte :

System : AIX
version Oracle : 9.2.0.8
Je ne suis pas en mode Archive log
Je n'ai pas RMAN


Un énorme merci a tout ceux qui pourrons m'aider ou m'orienter !!!

[pifor]

En mode NOARCHIVELOG, il n'est en général pas possible de restaurer une base s'il manque un datafile d'un tablespace permanent ou du tablespace undo. Le support Oracle peut éventuellement proposer certaines solutions dans certains cas.

[billharry]

Bonjour à tous !!!


Sinon la vrai question :

Comment faire pour pouvoir remonter ma base... (si c'est encore possible )


Voici le contexte :

System : AIX
version Oracle : 9.2.0.8
Je ne suis pas en mode Archive log
Je n'ai pas RMAN

Salut,

essaie de créer un nouveau tablespace undo, que tu utilises par défaut pour emplacer l'actuel et mets le tablespace undo defectueux offline.

[D_Latch]

Bonjour et merci pour vos réponses !


Alors voila ce que je fait :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
SQL> alter database open
  2  ;
alter database open
*
ERREUR à la ligne 1 :
ORA-01122: Echec de controle de verification pour fichier BdD 2
ORA-01110: fichier de donnees 2 :
'/usr/oracle/oradata/commun/undo/<MA_BASE>/undo01.dbf'
ORA-01207: fichier plus recent que le fichier de controle - ancien fichier de
controle

Bon jusque la OK...

Code :

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

1
2
3
4
5
6
7
8
 
SQL> ALTER DATABASE DATAFILE '/usr/oracle/oradata/commun/undo/<MA_BASE>/undo01.dbf' OFFLINE
  2  ;
ALTER DATABASE DATAFILE '/usr/oracle/oradata/commun/undo/<MA_BASE>/undo01.dbf' OFFLINE
*
ERREUR à la ligne 1 :
ORA-01145: OFFLINE IMMEDIATE rejete sauf si recuperation apres defaillance
materielle validee

Bon ca, à priori ca ne marche qu'en archive log...

Code :

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

1
2
3
4
5
6
 
SQL> CREATE UNDO TABLESPACE undo2 DATAFILE '/usr/oracle/oradata/commun/undo/<MA_BASE>/undo2.dbf' SIZE 10M ;
CREATE UNDO TABLESPACE undo2 DATAFILE '/usr/oracle/oradata/commun/undo/<MA_BASE>/undo2.dbf' SIZE 10M
*
ERREUR à la ligne 1 :
ORA-01109: base de donnees non ouverte

...


Est il possible de récupérer le numéro de synchro des .dbf (c'est bien le SCN ???) afin de mettre le même partout à la main ?


Merci à tous pour votre aide !

[billharry]

Essaie de recréer les control files

Voici la procédure

1. Démarre la base en état mount

Code :

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

SQL>Startup mount

2. Créer une trace du control file

Code :

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

SQL> Alter database backup controlfile to trace;

3. Créer un script de création du control file en te servant de la trace générée dans le répertoire user_dump_dest.

Mettre l'option noresetlogs

Reference: Note 1012929.6 How to Recreate the Controlfile

4. Arrêter la base et démarrer en nomount

Code :

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

1
2
SQL>shutdown abort
SQL>startup NoMount

5. Recréer le control file en exécutant le script de l'étape 3

6. Lance un recover

Code :

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

SQL>recover database ;

7.Démarre la base

Code :

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

SQL>Alter database open ;

Comme le dbf manquant est un undo, tu as peut-être une chance de tout récupérer

Et après surtout, SAUVEGARDE TOUT
Un conseil, utilise RMAN, au moins tu es sûr de ne rien oublier

[LeoAnderson]

non. ça ne sert à rien de recréer les control file

les fichiers ne sont pas cohérents. Point. il manque des données, on est pas en archive log, ça part très mal

comme le disait pifor, des procédures non documentées peuvent parfois être utilisées par le support. (ou une recherche ici vous donnera une solution proposée par Pomalaix me semble-t-il)

[pifor]

Si l'instance a été arrêtée proprement (pas de shutdown abort ou de crash) avant la sauvegarde, il y a peut-être une procédure qui peut fonctionner comme le montre ici Tom Kyte.

Mais comme déjà dit, s'il s'agit d'une base de tests, oubliez la et utilisez RMAN pour sauvegarder toute la base ou sauvegardez tous les datafiles et les control files manuellement.

[D_Latch]

Merci ENORMEMENT pifor !!!!


En effet, la procédure de Tom Kyte fonctionne !!!


Par contre, je n'avais pas sauvegarder non plus le .dbf temp... (je pensais qu'on avais pas besoin de le sauvegarder... )

Mais la base était ouverte, j'ai donc réinitialisé le TBS temp comme je l'ai déja fait plusieurs fois. (ex : http://www.drazzib.com/docs:bdd:oracle:temp_tablespace )

Enfin bref, ma base est maintenant OPEN et je ne vois pas de souci apparent...

Je me lance tout de suite dans une sauvegarde à froid INTEGRALE ce coup ci.

control file
data
system
redo
undo
temp

Je n'ai rien oublié... j'espers... (si quelqu'un pouvait confirmer ca serai génial)

En tous cas merci encore pour votre aide.

[billharry]

Je me lance tout de suite dans une sauvegarde à froid INTEGRALE ce coup ci.

control file
data
system
redo
undo
temp

Je n'ai rien oublié... j'espers... (si quelqu'un pouvait confirmer ca serai génial)

Et si, tu as oublié le fichier de démarrage init.ora ou spfile.ora. Si tu ne l'as pas sauvegardé, tu vas galérer pour tout reparamétrer.

Pense à passer en archive log et à sauvegarder par RMAN

[D_Latch]

arf... c'est vrai...


Mais je les avais déja sauvegardés ;-)

Donc a part ca... tout va bien ! ==> MERCI


Pour info, je ne passe pas en mode archive log car c'est une base de test... et je n'ai pas trop d'espace disque. (enfin si mais pas sur le bon VG)

Pour RMAN, pareil, je ne compte pas l'installer.

En fait cette base est faite pour me monter en compétence.
Donc je créer des erreurs (celle de l'undo n'était pas fait exprès ) puis j'essai de les résoudres en regardant les messages d'erreur Oracle et en naviguant sur developpez.com

[billharry]

arf... c'est vrai...
Pour RMAN, pareil, je ne compte pas l'installer.

Déjà, pas besoin d'installer RMAN, c'est dans toute installation database.

En fait cette base est faite pour me monter en compétence.
Donc je créer des erreurs (celle de l'undo n'était pas fait exprès ) puis j'essai de les résoudres en regardant les messages d'erreur Oracle et en naviguant sur developpez.com

Justement, c'est le moment de monter en compétence. RMAN te permet de résoudre pas mal de problème. Par ex:
Restaurer à moment précis (si tu es en archivelog)
Réparer des blocs corrompus
Compresser tes sauvegardes
...

[Alain B.]

Pour info, je ne passe pas en mode archive log car c'est une base de test... et je n'ai pas trop d'espace disque. (enfin si mais pas sur le bon VG)

Si c'est une base de "crash test", il ne doit pas y avoir beaucoup de mouvements données ? donc très peu d'archivelog générés.
(Et la gestion des archivelog c'est aussi une competence à monter)

Et même si résoudre ce genre de problème peut beaucoup apprendre, l'étape suivante c'est comprendre Rman.

Au début je ne m'y sentais pas à l'aise, je ne voyais plus mes fichiers, perdus au fin fond des "backupset". J'avais vraiment l'impression de perdre le contrôle.

Puis à la longue, avec un peu de pratique, on découvre les commandes "qui vont bien" et on s'aperçoit qu'on y gagne beaucoup tant sur le plan fiabilité que sur le plan pratique.
Ne serait ce que la gestion des archivelogs, qui devient quasi transparente.