Discussion :

[ariesnojf]

Bonjour,

Me voici encore devant un problème.

Une base de données sur serveur 1 en archivelog==> Sauvegarde à froid et transfert des fichiers sur serveur 2. (Architecture des 2 serveurs identiques OS / Oracle)
Modif de la base sur serveur 1. Force un switch logfile. Obtention d'un fichier archive sur serveur 1 et 2.
Je simule un arrêt total sur serveur 1 et celui-ci est indisponible.
Activation du serveur 2. Je monte la base et essai de faire un recover du fichier archive obtenu précédemment. Or, le systeme me dit qu'il n'y a aucune récupération possible...

Code :

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

1
2
3
 
startup mount pfile=...;
alter database recover database;

Lorsque j'ouvre la base sur serveur 2, j'ai aucun problème sauf (bien evidemment) que les données sont au point de la sauvegarde.

Comment puis-je rejouer les archives obtenus aprés la sauvegarde à froid ??

J'ai bien pris note des solutions qui m'ont étés mentionnés dans mes précédents sujets, mais j'essaie de trouver la meilleure solution à adapter pour nos besoins, et je me trouve à chaque fois devant un soucis. Merci à ceux qui me répondent et de leur patience.

Merci d'avance

[Jaouad]

essaye plutôt :

Code :

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

1
2
3
 
SQL> STARTUP MOUNT;
SQL> RECOVER DATABASE AUTOMATIC UNTIL CANCEL USING BACKUP CONTROL FILE;

Restauration partielle à partir de la sauvegarde à froid

[ariesnojf]

Oups,

le message:

ORA-00264 : Aucune recuperation requise

Et non pas "récuperation possible"

[bouyao]

en faisant

Code :

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

RECOVER DATABASE UNTIL CANCEL

[LeoAnderson]

Normal, puisque tous les fichiers sont au même niveau de synchro !

Pour qu'il soit nécessaire de jouer un archlog, il faut qu'au moins un fichier soit au n° le plus élevé possible, idéalement un fichier de contrôle.

Si vous restaurez toute la sauvegarde à froid, tous les fichiers sont cohérents et aucun recover n'est envisageable.

[Jaouad]

Normal, puisque tous les fichiers sont au même niveau de synchro !

Pour qu'il soit nécessaire de jouer un archlog, il faut qu'au moins un fichier soit au n° le plus élevé possible, idéalement un fichier de contrôle.

Si vous restaurez toute la sauvegarde à froid, tous les fichiers sont cohérents et aucun recover n'est envisageable.

Léo , je suis plus ou moins d'accord avec toi .

Plus parce qu'effectivment la commande employé par notre ami va juste essayer de synchroniser les SCN entre les datafiles et les fichiers de contrôles .

Cependant il est possible d'effectuer une restauration à partir d'une sauvegarde à froid , effectué la veille notamment , lorsque tu as effectué dans la journée un jolie truncate .

Tu repart de la sauvegarde puis tu repasse toutes les archives jusqu'au
SCN voulue
point dans le temps
jusqu'au fichier d'archive voulue

[LeoAnderson]

certes, mais si tous tes fichiers et tes control sont synchros, tu es cuit !

il ne faut pas que tu restaures des CTL et là ensuite, il voudra bien rejouer les arch.
Si ta base est OPEN et cohérente, recover ne peut pas marcher.

[bouyao]

essaye plutôt :

Code :

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

1
2
3
 
SQL> STARTUP MOUNT;
SQL> RECOVER DATABASE AUTOMATIC UNTIL CANCEL USING BACKUP CONTROL FILE;

Restauration partielle à partir de la sauvegarde à froid

Attention USING BACKUP CONTROLE FILE oblige à faire un RESETLOG

[ariesnojf]

Merci à tous dans un premier temps

Jaouad:
J'ai executer la commande et nouvelle erreur:

Code :

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

1
2
 
ORA-00274: option de recuperation AUTOMATIC non valide

LeoAnderson:
Donc en clair, les fichiers archives que j'obtiens sur serveur 2 issus de la base sur serveur 1 sont inutilisables avec la sauvegarde à froid du serveur 1 ???

Il n'y a aucun moyen de forcer l'utilisation des archives ?

[ariesnojf]

Merci à tous de m'aider,

le temps d'écrire ma réponse à Jaouad et à LeoAnderson, vous repondiez déjà aux questions que je me posais.


Donc, si j'ai bien compris, il faudrait que je restaure tous les fichiers sauf les CTL puis tenter un recover ???

Je vais essayer et vous tiens au courant ...

[Jaouad]

Bouyao Tout à fait .
Léo Comment fais tu pour faire une restauration suite à une opération de type truncate ( sauvegarde à froid )
?

[LeoAnderson]

je restaure tous les dbf "anciens" (de la date de la sauvegarde) mais je me garde les CTL "nouveaux" (de la date où je me rends compte de la boulette) et comme je m'arrête avant la fin (ie date des ctl) je fais un CANCEL => RESETLOGS.

[Marc Musette]

quelqu'un peut-il me dire pourquoi vous utilisez une sauvegarde à froid en travaillant en mode ARCHIVELOG ??? pourquoi ne pas faire un open backup , qui impose toujours un recover

notez également que vous pouvez utiliiser LOGMINER pour rejouer des archives sur la db ouverte et cohérente.

la réponse à votre question, c'est LOGMINER ou implémenter une standby pour que tout soit automatisé

[ariesnojf]

Merci,

Mais, implementer une SDB signifie que je ne peux que l'ouvrir en lecture seule, et moi il me faut l'ouvrir en écriture (selon précédent sujet)

pourquoi ne pas faire un open backup , qui impose toujours un recover

Concernant l'open backup, il s'agit d'une sauvegarde à chaud ??
Si ce n'est pas le cas, qu'est ce que c'est (Je vais jeter un coup d'oeil pour en savoir plus ...)

[Jaouad]

Parce que touts les systémes n'imposent pas d'avoir une disponibilité accrue. Avoir une sauvegarde à froid impose d'arrêtter la base mais permet d'avoir une sauvegarde cohérente ( toutes les bases en production ne doivent pas tourner H 24 ) .
Une base en mode archivelog permet de restaurer jusqu'a un certain point lors d'un crash ou d'une erreur. Et la encore toutes les bases de production n'ont pas besoin d'une standby et donc d'un systéme haute dispo .
Le LogMiner permet de fouiller dans les REDO mais ne peut rien contre la destruction des fichiers.

En somme chaque systéme, doit avoir sa propre réponse de sauvegarde et de restauration.

[Marc Musette]

une sauvegarde à chaud (open backup) permet d'avoir une sauvegarde cohérente via les archivelogs ! il n'y a aucun avantage à faire un backup avec db fermé si la db est en archivelog mode (par exemple quand est est-il de cache hit ratio à chaque redémarrage ... ) c'est n'importe quoi

LOGMINER te permet d'appliquer tes redo transfèrés sur une autre machine, c'est quand même bien cela que tu veux faire non ?

comment voulez-vous synchroniser deux db si elles sont toutes deux ouvertes en écriture ??? je ne comprends pas bien ce que vous désirez faire in fine ... une standby suit la primary database et lorsque nécessaire , peut être ouverte (on peut même faire des switch entre primary et standby) ... renseignez-vous plus avant sur ces points avant de crier NON

[Jaouad]

une sauvegarde à chaud (open backup) permet d'avoir une sauvegarde cohérente via les archivelogs ! il n'y a aucun avantage à faire un backup avec db fermé si la db est en archivelog mode (par exemple quand est est-il de cache hit ratio à chaque redémarrage ... ) c'est n'importe quoi

Il existe des procédures de chauffe permettant de récupèrer un bon cache hit ratio ( en mettant le objet en cache ) et même d'eviter les phases de hard parse en pingant les explain plan.

[ariesnojf]

Ce que je veux faire est très simple.

Une base sur serveur n°1 qui ne peut pas être arrêtée pour des raisons de fonctionnement interne.

En cas de crash du serveur physique (non pas crash de données) donc serveur inutilisable, pouvoir basculer "en appuyant sur on" pour démarrer la DB (en ayant les données du serveur 1 juste avant le crash) sur le serveur de secours.

Ce serveur est copie conforme (sauf son nom) au niveau OS /Oracle.

Sur des précedents sujets à laquelle j'ai demandé de l'aide à mainte reprise, il m'a été confirmé qu'une SDB ne pouvait être ouverte qu'en lecture seule. Or, il me faut un accés en écriture sur cette base de secours.

Or jusqu'à maintenant, toujours dans des précédents sujets, personne n'a su me répondre à la question de pouvoir basculer cette SDB en "base standard", voir même certain qui en doutait (Je n'envoi aucun coup de bâton sur personne car moi-même je n'ai pas cette réponse. Et sans ces personnes je n'aurai pas pu exploiter (du moins essayer) toutes les solutions qui m'ont étés suggérés).

Et bien non, je ne crie pas NON aussi sec, au contraire j'étudie toutes ces solutions, et me je base sur ceux qui ont plus de connaissances que moi.

Je suis débutant Oracle et ne demande qu'a apprendre. (renseignement auprés des cours de Jaouad (merci Jaouad), auprés de site comme Tafora... sans oublier Developpez.com)

La solution du switch m'interrese fortement mais ne sait pas comment s'y prendre.

Quand au logminer, j'y regarde d'un peu plus prés cette solution.

J'en profite également, j'ai implémenté une SDB et en tapant dans SVRMGRL

Code :

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

1
2
 
alter database recover managed standby database timeout 30;

Voici ce que j'obtiens:

Code :

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

1
2
3
4
5
 
ORA-01547 : operation RECOVER reussie, mais OPEN RESETLOGS generera l'erreur ci-dessous
ORA-01194 : le fichier 1 nécessite plus de récupération pour être cohérent
ORA-01110 : fichier de données 1 : "....system01.dbf"
ORA-16016 : journal archive non disponible

Cela veut dire que le fichier 1 est HS et qu'il faudra un recover de celui-ci ???

Merci pour vos réponses

[Jaouad]

Sur des précedents sujets à laquelle j'ai demandé de l'aide à mainte reprise, il m'a été confirmé qu'une SDB ne pouvait être ouverte qu'en lecture seule. Or, il me faut un accés en écriture sur cette base de secours.

on peut ouvrir une base en mode écriture
Activer une standby database

[ariesnojf]

J'ai essayé et c'est le cas :

Code :

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

1
2
3
4
5
 
ORA-01547 : operation RECOVER reussie, mais OPEN RESETLOGS generera l'erreur ci-dessous
ORA-01194 : le fichier 1 nécessite plus de récupération pour être cohérent
ORA-01110 : fichier de données 1 : "....system01.dbf"
ORA-16016 : journal archive non disponible

Cela veut dire que le fichier 1 est HS et qu'il faudra un recover de celui-ci ???

Est-ce que j'ai mal fait une configuration pour obtenir cela ? (Je pense que cela va être difficile à répondre)