[Oracle11g]Stratégie de backup

Version imprimable

Bonjour,

Pour le moment, j ai un script de backup rman qui s'exécute tout les jours.
Il fait un backup full database.

Voici mes scripts:
Code:

1 2 3 4 5 6 7 @@Init.rman list backup summary; delete noprompt obsolete; list backup summary; @@Full_step.rman list backup summary; exit
Init.rman:
Code:

1 2 3 4 5 6 startup mount; configure controlfile autobackup format for device type disk to '/mnt/bck_oracle/OracleBackup/Data/%F.bck'; configure controlfile autobackup on; configure retention policy to redundancy 1; configure channel 1 device type disk format '/mnt/bck_oracle/OracleBackup/Data/df_%d_%s_%p.bus' MAXPIECESIZE 20G; configure maxsetsize clear;
Full_step.rman:
Code:

1 2 3 4 5 run { backup database force tag='DBF'; backup current controlfile tag='CTL'; backup archivelog all delete all input tag='ARC'; }
Je ne voit pas trop l'intérêt de faire un full database tous les jours de la semaines alors je pensais juste lancer ce script le samedi.

Les autres jours de la semaine je pensais faire de l'incrémental mais je ne sais pas trop comment modifier mes scripts pour réaliser cela.

Quelqu'un peux-t-il m'aider?

Merci d'avance.

Michaël

Bonjour,

Tout d'abord pour l'incrémental ta base doit etre en archivelog .

Ensuite, il faut que tu modifie ton script tenant compte de la nouvelle stratégie a savoir :

le samedi : Backup Level 0 (équivalent d'un full mais base ouverte)

attention : bien sur rman ne sauvegarde ni les temps ni les redos, a ne pas oublier

Les autres jours de la semaine : Backup level 1, avec utilisation de block change tracking pour faire en sorte d'éviter à rman d'avoir a parcourir tous les blocs de la base pour voir quels sont ceux qui ont été modifiés.

Donc en résumé :

Premierement : activation block change tracking :
Code:

1 2 alter database enable block change tracking using file '/MYREP/fichier.trc' ;
Deuxiemement : sauvegarde level 0 (je passe la configuration du format de tes backup et de leur destination qui reste inchangé , sauf dans le cas ou tu souhaite différencier les backup en fonction de leur level, ce que je te conseil ;)
Code:

1 2 3 4 backup incremental level 0 tag 'MYTAG' format 'mysavelevel0_on%_%t%U.bkp' as compressed backupset database plus archivelog; -- on sauve le ctl à part: backup format 'mysaveCTL_t%t_s%s_p%p' (current controlfile);
Troisièmement : la meme chose, mais avec le level 1
Code:

1 2 3 4 backup incremental level 1 tag 'MYTAG' format 'mysavelevel1_on%_%t%U.bkp' as compressed backupset database plus archivelog; -- on sauve le ctl à part: backup format 'mysaveCTL_t%t_s%s_p%p' (current controlfile);
Après tu peu jouer avec CONFIGURE pour t'éviter les scripts à rallonge. Perso je prefere mettre tout dans le bloc run , mais ca dépend de chacun.

En espérant avoir répondu au mieux,

Mickael.

28/01/2011, 15h35
mika0102

Merci pour ta réponse, je testerai cela lundi mais pour le 1er point, le chemin et le nom de fichier, il s'agit d'une nouveau fichier qui se crée quand j'active l'option ?
28/01/2011, 16h07
Mikl-Dba

Tout à fait, tu lui indique l'emplacement cible, et il se créee automatiquement.

il est très utile ce petit fichier, mais attention néanmoins à sa taille qui varie, bien sur, en fonction de la database et de l'activité de cette dernière.
a titre d'infos, 3Mo de mon coté pour une base de 1To, qui "vit" moyennement (activité plus que raisonnable).
28/01/2011, 16h15
mika0102

Parfait, donc si je comprend bien tu me suggère de faire 2 scripts, 1 en level 0 qui sera lancé le samedi et l autre en level 1 pour la semaine. Tout cela se fait-il à froid ?
28/01/2011, 16h35
Mikl-Dba
oui deux scripts distinct, ou bien un seul en ksh ou bat avec des variables (c'est ce que j'utilise, je n'ai qu'a mettre des arguments et le script créee un fichier de command rman en fonction ...)

Les sauvegardes incrémentales RMAN necessitent obligatoirement d'avoir une base en archivelog , car elles se font Online, donc base open.

La gestion de ces archivelogs (purge) dépend du script rman dans lequel tu spécifie un delete d'archivelog..

exemple :
Code:

1 2 3 crosscheck archivelog all; delete noprompt archivelog until time 'sysdate -2' ;

pour les archivelog je le ferai à part pour pouvoir les supprimer une fois le backup effectué.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
run{
allocate channel d1 type disk;
backup incremental level 0 skip inaccessible tag sunday_level_0 database;
copy current controlfile to '/MYPATH/sunday.ctl';
sql 'alter system archive log current';
backup
archivelog all delete input;
release channel d1;
report obsolete;
delete obsolete ;
}

16/02/2011, 14h51
Pomalaix

Ce sujet est intitulé "stratégie", mais étrangement ne parle que de technique !

Les étapes logiques devraient être :
1) déterminer les objectifs et les contraintes
2) identifier les solutions adaptées, et faire un choix parmi elles
3) mettre en oeuvre la solution retenue

Pour la première phase :
- quels sont les types d'incidents auxquels les sauvegardes doivent répondre ?
- quelle perte de données peut-on tolérer ?
- quels sont les objectifs et éventuelles contraintes quant à la durée de sauvegarde ?
- quels sont les objectifs et éventuelles contraintes quant à la durée de restauration ?
- quelles sont les contraintes en matière de volume de sauvegardes ?

Pour la seconde phase, il sera notamment important de savoir si vous êtes ou non en édition Entreprise.

Sur le plan technique, les sauvegardes incrémentales n'exigent pas le mode ARCHIVELOG, mais devront alors se faire base fermée (c'est à dire MOUNT dans le contexte RMAN).
D'après la doc :

Citation:

If the database is in NOARCHIVELOG mode, then RMAN can only make incremental backups after a consistent shutdown.

Bien entendu, au bout de 10 secondes de réflexion à la phase 1, on se rendra compte que l'activation de l'archivage est impérative.
16/02/2011, 15h07
Pomalaix

Citation:

Envoyé par Mikl-Dba

il est très utile ce petit fichier, mais attention néanmoins à sa taille qui varie, bien sur, en fonction de la database et de l'activité de cette dernière.
a titre d'infos, 3Mo de mon coté pour une base de 1To, qui "vit" moyennement (activité plus que raisonnable).

Je suis un peu surpris de cette mise en garde sur un élément qui ne pose vraiment pas de souci.

Ce fichier de suivi, d'expérience et d'après la doc, est de taille très modeste : environ 1/30 000 eme de la taille de la base !
Ensuite, il a une taille minimale de 10M, donc il est très étonnant que vous en ayez un de 3M.
Enfin, sa taille ne dépend en aucune façon de la quantité de modifications faites sur les données.
Le gros principe de ce fichier, c'est que chaque bloc des fichiers de données y est représenté par un bit (pas uniquement les blocs modifiés, mais bien tous les blocs). Lorsqu'un bloc est modifié depuis la dernière sauvegarde, alors le bit passe à 1.

Le fichier de suivi est certes un mécanisme indispensable si on veut que les sauvegardes incrémentales soient plus rapides.
Il exige l'édition Entreprise, mais en dehors de cette contrainte, il ne demande aucune gestion, et sa taille n'est absolument jamais un souci.

Plus de détails dans la doc : http://download.oracle.com/docs/cd/E...a.htm#i1032148

Citation:
Envoyé par Mikl-Dba
Bonjour,

Tout d'abord pour l'incrémental ta base doit etre en archivelog .

Ensuite, il faut que tu modifie ton script tenant compte de la nouvelle stratégie a savoir :

le samedi : Backup Level 0 (équivalent d'un full mais base ouverte)

attention : bien sur rman ne sauvegarde ni les temps ni les redos, a ne pas oublier

Les autres jours de la semaine : Backup level 1, avec utilisation de block change tracking pour faire en sorte d'éviter à rman d'avoir a parcourir tous les blocs de la base pour voir quels sont ceux qui ont été modifiés.

Donc en résumé :

Premierement : activation block change tracking :
Code:

1 2 alter database enable block change tracking using file '/MYREP/fichier.trc' ;
Deuxiemement : sauvegarde level 0 (je passe la configuration du format de tes backup et de leur destination qui reste inchangé , sauf dans le cas ou tu souhaite différencier les backup en fonction de leur level, ce que je te conseil ;)
Code:

1 2 3 4 backup incremental level 0 tag 'MYTAG' format 'mysavelevel0_on%_%t%U.bkp' as compressed backupset database plus archivelog; -- on sauve le ctl à part: backup format 'mysaveCTL_t%t_s%s_p%p' (current controlfile);
Troisièmement : la meme chose, mais avec le level 1
Code:

1 2 3 4 backup incremental level 1 tag 'MYTAG' format 'mysavelevel1_on%_%t%U.bkp' as compressed backupset database plus archivelog; -- on sauve le ctl à part: backup format 'mysaveCTL_t%t_s%s_p%p' (current controlfile);
Après tu peu jouer avec CONFIGURE pour t'éviter les scripts à rallonge. Perso je prefere mettre tout dans le bloc run , mais ca dépend de chacun.

En espérant avoir répondu au mieux,

Mickael.
Bonjour,

J'ai une question concernant le block change tracking.
Une fois celui-ci activé dans oracle, est-ce que rman en prend directement compte ou doit-on lui dire quelque part qu'il doit utiliser ce fichier?

Merci

20/02/2011, 12h13
Pomalaix

Citation:

Envoyé par mika0102

J'ai une question concernant le block change tracking.
Une fois celui-ci activé dans oracle, est-ce que rman en prend directement compte

Oui. Pour une fois, il n'y a pas de subtilités supplémentaires.