Discussion :

[madmaxou]

Bonjour à tous,

Ma question est relativement simple, mais n'étant pas un expert je ne sais s'il existe une réponse également simple

Au sein de mon entreprise nous effectuons deux types de sauvegardes de nos bases Oracle situées sur un NetApp, toujours basées sur un snapshot puis un snapvault vers un backup.
L'une s'effectue "à chaud" bases encore ouvertes (mais l'application métier cesse de transmettre ses requêtes pour avoir un état aussi "propre" que possible), l'autre s'effectue à froid, bases arrêtées.

Je m'assure en ce moment de la validité de nos processus de sauvegarde, et si je n'ai eu aucune réelle mauvaise surprise jusqu'à présent, il y a tout de même une chose qui me chiffonne.
En effet, à chaque restauration, je dois procéder à un [recovery] sur un tablespace system. Si cela ne m'a pas interpellé lors de la restauration de la sauvegarde à chaud, je me demande pour quelle raison cette manipulation est nécessaire pour une sauvegarde à froid.

Je pensais que du fait que la base est arrêtée au moment de la sauvegarde, aucun recovery n'était nécessaire ?
Pensez-vous qu'il puisse s'agir d'un simple "recalage" sur le jour ou quelque chose comme ça ? (aucune recherche de séquence de redo log n'est effectuée par exemple).

Voilà si vous pouvez donc éclairer un peu ma lanterne, je vous en remercie d'avance
[edit]
Ha oui je précise que nous utilisons Oracle EE 9.2.0.4 sous SunOS, si cela a un intérêt

[fatsora]

Bonjour,



Quelle commande tu lances pour faire la restauration et le recovery dans le cas de sauvegarde base eteinte?

Normalement :

Code :

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

1
2
3
4
5
6
 
 
SQL> STARTUP MOUNT;
SQL> RECOVER DATABASE
media recovery completed 
SQL> ALTER DATABASE OPEN;

tiré d'ici

http://oracle.developpez.com/guide/s...eneralites/#L4

Suffit.

[madmaxou]

Oui c'est tout à fait ça ^-^

Mais ça fonctionne également pour les sauvegarde à chaud, ce que je me demandais, c'est le pourquoi de ce

Code :

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

recover database;

dans le cas d'une sauvegarde à froid.

Comme il est dit dans l'article que tu indiques

Si la sauvegarde à froid s'est bien déroulée alors le démarrage suite à la restauration des fichiers ne doit poser aucun problème.

d'où ma question sur la nécessité du recovery.

Ca ne me traumatise pas, et comme cela fonctionne je peux garantir l'état des sauvegardes, mais pour ma culture je cherchais à comprendre pourquoi

Merci de ta réponse en tout cas

[fatsora]

Effectivement,

Si tu restaure tout en sauvegarde base éteinte, et toute chose égale par ailleurs ....
Normalement, pas besoin de recover ...

Quel message tu obtiens si tu fais un backup complet : controlfile,redolog,arch ,datafiles

et 2.restauration

3.alter database open;

Par contre si tu veux récupérer les redolog archivés qui ne sont pas appliqués

Code sql :

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

recover database until cancel using backup controlfile;

[madmaxou]

En fait le processus de sauvegarde n'est pas réellement complet.

On a un multiplexage des controlfile sur un filesystem local qui n'est pas inclut dans le processus de sauvegarde par snapshot. Ce qui fait que déjà, lorsqu'on restore, on doit commenter dans le pfile, la ligne qui concernerait un éventuel controlfile multiplexé en local.

Il y aussi un log des archives qui se fait en local, et qui n'est pas non plus sauvegardé, mais jusqu'à présent je n'en vois pas l'utilité dans un processus de restauration.

Pour répondre à tes questions :
1) Il s'agit de copie des contenus des volumes NetApp sur lesquels sont réparties les données, et qui sont donc sauvegardées par Snapshot sur un netapp de backup. Grosso-modo il ne s'agit que d'un "copier-coller"

2) Une fois modifié le pfile si un multiplexage des controlfiles est en place, je peux effectuer sans encombre:

Code :

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

1
2
startup nomount ;
alter database mount ;

Ce n'est qu'au moint du

Code :

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

alter database open

que j'ai un message indiquant :

ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/xxx/xxx/system01.dbf'

Quel que soit le type de sauvegarde (à chaud ou à froid) un simple

Code :

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

recover database

suffit à fixer le problème, je peux ensuite procéder à un

Code :

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

alter database open ;

sans retrouver l'erreur précédente, d'ailleurs la base s'arrête et se redémarre sans encombre.

Mon hypothèse et qu'il y a peut-être un problème dans le processus de sauvegarde par snapshot qui fait en sorte que la sauvegarde "à froid" n'apporte pas les avantages qu'elle est censée générer, c'est cela qui m'a poussé à venir vous poser ma question

Pour ce qui est de rejouer les redo logs, nous partons du principe qu'il s'agit d'un crash inopiné, donc que les données du jour sont perdues

[fatsora]

En fait le processus de sauvegarde n'est pas réellement complet.

On a un multiplexage des controlfile sur un filesystem local qui n'est pas inclut dans le processus de sauvegarde par snapshot. Ce qui fait que déjà, lorsqu'on restore, on doit commenter dans le pfile, la ligne qui concernerait un éventuel controlfile multiplexé en local.

Il y aussi un log des archives qui se fait en local, et qui n'est pas non plus sauvegardé, mais jusqu'à présent je n'en vois pas l'utilité dans un processus de restauration.

Pour répondre à tes questions :
1) Il s'agit de copie des contenus des volumes NetApp sur lesquels sont réparties les données, et qui sont donc sauvegardées par Snapshot sur un netapp de backup. Grosso-modo il ne s'agit que d'un "copier-coller"

2) Une fois modifié le pfile si un multiplexage des controlfiles est en place, je peux effectuer sans encombre:

Code :

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

1
2
startup nomount ;
alter database mount ;

Ce n'est qu'au moint du

Code :

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

alter database open

que j'ai un message indiquant :


Quel que soit le type de sauvegarde (à chaud ou à froid) un simple

Code :

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

recover database

suffit à fixer le problème, je peux ensuite procéder à un

Code :

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

alter database open ;

sans retrouver l'erreur précédente, d'ailleurs la base s'arrête et se redémarre sans encombre.

Mon hypothèse et qu'il y a peut-être un problème dans le processus de sauvegarde par snapshot qui fait en sorte que la sauvegarde "à froid" n'apporte pas les avantages qu'elle est censée générer, c'est cela qui m'a poussé à venir vous poser ma question

Pour ce qui est de rejouer les redo logs, nous partons du principe qu'il s'agit d'un crash inopiné, donc que les données du jour sont perdues

IL faut verifier le snapshot .

Peut tu creer une petite base ou faire une sauvegarde base eteinte en faisant une copie et non par snapshot ?

Par contre le fait de na pas sauvagarder les archivelog n'est pas top du tout...

Tu devrais trouver des bouts de disques pour les sauvagarder !!

Tu perds les avantages de l'archivelog .

En plus le faite de ne rien faire au niveau fonctionnel ,bas de batchs quand vous faites les sauvagardes a chaud ne sert pas a grand chose non plus .


Le mieux est d'apprendre RMAN .

http://oracle.developpez.com/guide/sauvegarde/rman/

[glood1]

Bonjour,

je voudrais faire un point sur la restauration en mode non archivelog
la sauvegarde se fait base arrêtée. dans état cohérent.

je voudrais me souvenir (j' ai pas pratique le nonarchiv log depuis lontemps)
si c 'est possible de faire une Restauration partielle à partir de la sauvegarde à froid et d' une base en nonarchivlog ?

notement sur
-cancel-based (basé sur l'annulation)
-time-based (basé sur le temps)
-change-based (basé sur le numéro de séquence du système SCN)

et l' option open resetlog
j ai une idéé sur la reponse mais je voudrai avoir une confirmation.


ex : restauration d' un datafile supprimer opar erreur et incoherence ctrl

ai je une autre solution de tout restaurer physiquement ?
la restauration est obligatoirement au jour j de la sauvegarde


merci de
votre collaboration.

[fatsora]

Bonjour,

je voudrais faire un point sur la restauration en mode non archivelog
la sauvegarde se fait base arrêtée. dans état cohérent.

je voudrais me souvenir (j' ai pas pratique le nonarchiv log depuis lontemps)
si c 'est possible de faire une Restauration partielle à partir de la sauvegarde à froid et d' une base en nonarchivlog ?

notement sur
-cancel-based (basé sur l'annulation)
-time-based (basé sur le temps)
-change-based (basé sur le numéro de séquence du système SCN)

et l' option open resetlog
j ai une idéé sur la reponse mais je voudrai avoir une confirmation.


ex : restauration d' un datafile supprimer opar erreur et incoherence ctrl

ai je une autre solution de tout restaurer physiquement ?
la restauration est obligatoirement au jour j de la sauvegarde


merci de
votre collaboration.

Dans certains cas NOARCHIVELOG on peut restaurer un ou plusieurs datafiles

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
SQL> STARTUP MOUNT
 
SQL> SELECT FILE#, NAME, STATUS FROM V$DATAFILE;
 
SQL> ALTER DATABASE DATAFILE '<CHEMIN_COMPLET_FICHIER>' ONLINE;
 
     (Si le datafile est au status OFFLINE)
 
SQL> SELECT V1.GROUP#, MEMBER, SEQUENCE#, FIRST_CHANGE# 
 
        FROM V$LOG V1, V$LOGFILE V2 
 
        WHERE V1.GROUP# = V2.GROUP# ; 
 
SQL> SELECT FILE#, CHANGE# FROM V$RECOVER_FILE; 
 
Dans le cas ou CHANGE# est PLUS GRAND que  minimum FIRST_CHANGE# du log alors le datafile peut etre recouvré.
 
 
 
SQL> RECOVER DATAFILE '<CHEMIN_COMPLET_FICHIER>';
 
SQL> ALTER DATABASE OPEN;

Il y a aussi BACKUP INCREMENTAL

https://students.kiv.zcu.cz/doc/orac...cmrecov001.htm

Mais bon , la plus part des cas , il faut faire un restore complet du FULL BACKUP