Discussion :

[phil4444]

Rappel de la procédure (L'ordre est crucial) :
BKP Les DATAFILES [SCN n à n+t]
BKP Un exemplaire des CONTROL FILES via le BACKUP TO TRACE [scn n+t+x]
On fait le SWITCH LOGFILE ou ARCHIVE LOG CURRENT (Qui va provoquer un SWITCH)
BKP Les REDO LOGS
BKP Les ARCHIVE LOGS (Qui contiennent tous les changements de n à n+t+x)


Ben voilà, je suis paumé là.
la sauvegarde respecte l'ordre, à la différence, je ne fais pas de BACKUP TO TRACE mais alter database backup controlfile to '&folder/control01.ctl'
et l'archivelog ce" fait de manière automatique je ne le provoque pas , je vais le provoquer dans le script en plus alors.

Si je comprends bien il faut que je repére le redo-log qui est inactive et le sauvegarder.

et il faudrait que je provoque un autre ARCHIVE LOGS

[phil4444]

c'est vrai que je bloque sur la restauration suite à la sauvegarde, il faut dire que script une automatisation de la restauration, je sais RMAN fait très bien cela, mais je ne veux pas l'utiliser.

Mais c'est une bonne manière aussi pour moi du fait de la complexité de la tâche d'apprendre par immertion dans la problèmatique d'oracle.

C'est un vrai défit si j'arrive au bout, le but c'est quand même de rendre la restauration facile et abordable pour des gens novices et qui n'auront pas de DBA en poste pour les tâches d'administration courant.

[philcero]

Attention, il faut tout de même sauvegarder TOUS les REDO LOGS juste avant les ARCHIVE LOGS comme indiqué car si ils ne font pas partie intégrante de la base, ils sont nécessaires au moteur.

Si tu respecte la procédure, tes REDO LOGS n'ont pas d'information nécessaires à la remise en état de la base mais ils seront nécessaires à l'ouverture de celle-ci. On les sauvegarde donc à la fin de manière à ne pas avoir à les re-créer (Quand on restore, moins il y en a à faire, moins on risque de se prendre le mur)...

Petite précisions quant au SCN : Celui-ci évolue pendant la sauvegarde tout simplement parce-que Oracle continu à faire de I/O sur ses fichiers pendant que celle-ci à lieu. Le fait de mettre les tablespaces en mode BEGIN BACKUP vont en fait geler la mise à jour du SCN dans l'en-tête des fichiers de données (Il reste à SCN1) pour le temps de la sauvegarde. Ainsi lors de la restoration, même si le fichier est physiquement cassé (Car Oracle à écrit dedans pendant qu'on le sauvegardait) toutes ces m.a.j de blocs disques effectuées entre SCN1 et SCNx sont consignés à l'arrivée dans les ARCHIVELOGS et on obligatoirement un SCN supérieur à celui que présente le fichier. D'où ré-application des blocs modifiés et on arrive mathématiquement à un fichier cohérent.

Bon je sais, c'est de la théorie et cela va plus loin que ce qui est demandé, mais je voulais battre le record de la longueur du POST et puis cela aide un petit peu mieux à comprendre le pourquoi du comment...

[philcero]

le but c'est quand même de rendre la restauration facile et abordable pour des gens novices et qui n'auront pas de DBA en poste pour les tâches d'administration courantes

Je sais qu'il s'agit là de petits moyens, mais baser sa production, aussi petite soit-elle, sur du Oracle sans avoir un DBA (Même junior, même un jour par semaine) qui surveille, c'est tout de même très risqué et pas sérieux...

[Milo59000]

mouais philcero... je suis pas sur que tu ais battu le record

Mais bon, ca avance pas trop tout de même... va t'on réussir à résoudre le problème ?

[phil4444]

je suis dans une petite structure SSII, et la base n'est là que pour poser des docs de développement et rien de plus, disons que je veux aussi aller plus loin que la demande initiale.

j'espère que ça avance

sinon pour l'archive logs courant, ne vaut il pas mieux faire un ALTER SYSTEM CHECKPOINT;

[Milo59000]

Au fait, tu as réussi à récupérer ta base ?

[phil4444]

euh non, dutout puisque j'ai plus mes REDO-LOGS mis à part les ARCHIVED REDO LOGS

pour les ARCHIVE LOGS CURRENT je fais un ALTER SYSTEM CHECKPOINT;
et pour le BACKUP des ARCHIVELOGS

[Milo59000]

Je ne comprends pas pourquoi, vu que tu n'as plus tes REDO LOG, tu ne fais pas une récupération jusqu'au dernier ARCHIVED REDO LOG ?

[philcero]

Y a un truc que je saisis plus, il s'agissait bien d'un test au début du POST ?

Si oui, tu as bien un backup complet de ta base à froid de disponible pour recommencer tes tests ?

[Milo59000]

ce n'est pas bête du tout philcero ^^

Au moins ca évitera de se prendre la tête sur ce problème et tout recommencer depuis le début !

En tout cas, moi je vais manger

[phil4444]

Oui ce sont des tests et j'ai fais une boulette et avec cette boulette, c'est un bon jeu de test justement, j'ai viré tous mes fichiers de ma base "rm" et je suis parti de ma sauvegarde à chaud, qui ne contient pas les redo logs mais juste les ARCHIVED REDO LOGS.
Ce genre de bourbe, va me permettre de compléter mon script en ajoutant un ALTER SYSTEM CHECKPOINT ou un SWITCH LOGFILE, mais pour pas trop complexifier l'algorythme du script, je pense que faire un ALTER SYSTEM CHECKPOINT sera peut être mieux.

Pour te répondre Milo mes ARCHIVED REDO LOG seuls ne suffisent pas

[philcero]

Donc si je résume tu as voulu faire un test avec une base que nous pouvons appeler production sans savoir si ta sauvegarde était viable.

Pour la méthode, je pense qu'il va falloir revoir...



En ce qui concerne ta base, je re-positionne nos informations :

• Tu as au moins 1 exemplaire de tes CONTROL FILES
• Tu as les fichiers de ta base
• Tu as les ARCHIVE LOGS
• Tu n'as pas les fichiers REDO LOGS

Tu es donc dans le cadre d'une restauration SANS REDO LOGS.

La méthode donnée par Oracle est la suivante :

1. Tu remets en place TOUS les fichiers de ta sauvegarde.
2. Tu dupliques ton CONTROL FILE sauvegardé en tes 3 CONTROL FILES originels.
3. Tu lances SQLPLUS AS SYSDBA.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
STARTUP MOUNT
...
RECOVER DATABASE UNTIL CANCEL
...
CANCEL
...
ALTER DATABASE RENAME FILE ".../redo01.log" TO ".../redo01new.log";
...
ALTER DATABASE OPEN RESETLOGS;
...
SHUTDOWN IMMEDIATE

[phil4444]

disons que l'incident n'était pas voulu mais quand tu crash un disque ou tu as une panne secteur et que dans la société tu n'as pas d'onduleur, ça revient du pareil au même.
Et qui plus est tu es entrain d'optimiser un script pour valider la pire catastrophe au niveau base de données.

je me demandait dans ta méthodologie de sauvegarde tu parlais dans un post plus haut de faire un BACKUP TO TRACE, si je suis la doc faut retravailler le script généré, donc par le faite je peux pas l'inclure dans mon script de sauvegarde automatisé

[philcero]

tu parlais dans un post plus haut de faire un BACKUP TO TRACE

En fait il y a deux méthodes :

• Faire un ALTER DATABASE BACKUP CONTROLFILE TO TRACE" qui va te créer en fait un script de re-création des CONTROL FILES.
• Faire un ALTER DATABASE BACKUP CONTROLFILE TO '..../moncontrole.ctl' REUSE ;qui va te créer un vrai fichier de contrôle réutilisable.

A toi de voir tes préférences. La deuxième soluce est en fait la plus simple mais ce sera un vrai fichier de contrôle donc non éditable. Ce que tu peux faire c'est faire les deux (Script & fichier de contrôle), après tout rien ne t'en empêche, et utiliser le fichier de contrôle lors de la restauration...

Autre point, vu qu'il ne va pas y avoir de DBA sur cette base, n'hésite pas à mettre ceinture + bretelles. Autrement dit d'avoir en plus de ta sauvegarde ONLINE, un EXP FULL à la suite que tu peux copier en automatique sur un drive réseau (En cas de gros pépins physiques, ça peut sauver la vie)...

[orafrance]

disons que l'incident n'était pas voulu mais quand tu crash un disque ou tu as une panne secteur et que dans la société tu n'as pas d'onduleur, ça revient du pareil au même.

oui sauf que t'es sensé avoir un backup fonctionnel ce qui n'est visiblement pas ton cas

[phil4444]

Comme je disais il n'y a pas de DBA donc facilitons la tâche.
La restauration de la base de données est faite par l'intermédiraire d'un script que je développe, donc l'utilisation d'un script qui génére un script c'est pas utilisable en temps que tel, surtout pour un script qui propose une restauration sans manip préable de personnes qui ne sont pas DBA

[phil4444]

c'est pas évident d'être fonctionnel sur une phase de développement, je peux pas mettre la charrue avant les beaufs.
J'espère ne pas être trop désagréable

[Milo59000]

Pour te répondre Milo mes ARCHIVED REDO LOG seuls ne suffisent pas

ah bon ??? C'est nouveau ca ^^ d'ailleurs dans le post qui suit philcero te met carrément les manipulations à faire pour récupérer ta base sans les REDO LOGS... donc c'est ce que je dis depuis le début, tu peux faire une récupération en utilisant que les ARCHIVED REDO LOG

[orafrance]

donc l'utilisation d'un script qui génére un script c'est pas utilisable en temps que tel

regarde comment est fait le script, c'est pas compliqué de faire un BACKUP CONTROLFILE TO TRACE à la main, un coup de dba_tempfiles, dba_datafiles, dba_logfiles, etc... et c'est bon