Rman Fichier obsolete non supprimé [Résolu]

[McM]

Bonjour,

Je sauvegarde une base de données 9i par Rman tous les soirs :
Le Dimanche : Incrémentale Level 0
Lundi au Samedi : Incrémentale Level 1
Il n'y a pas de catalogue.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
Dimanche
RMAN> run
 {
	crosscheck backup ;
 	crosscheck archivelog ALL ;
 	backup incremental level 0 DATABASE plus archivelog NOT backed up 1 times;
	CHANGE archivelog until time 'sysdate-2' DELETE;
 	DELETE force noprompt obsolete ;
 }
 
Lundi au Samedi 
RMAN> run
 {
 	crosscheck backup ;
 	crosscheck archivelog ALL ;
 	backup incremental level 1 DATABASE plus archivelog NOT backed up 1 times;
 	CHANGE archivelog until time 'sysdate-2' DELETE;
  DELETE force noprompt obsolete ;
 }

Le problème c'est que le fichier des dbf de la sauvegarde level 0 n'est pas supprimé par le delete obsolete, et qu'il n'apparait plus dans le crosscheck 15 jours après.

J'ai tracé tous les logs de l'archivage.

Création des fichiers le Dimanche 15/05 (Level 0)

canal ORA_DISK_1: démarrage de l'ensemble de sauvegarde du journal d'archivage
descripteur d'élément=/mnt/rmanbackup/FASPP_20110515_3nmcdqin_1_1 commentaire=NONE

Démarrage de backup dans 15/05/11
canal ORA_DISK_1 : démarrage de l'ensemble de sauvegarde du fichier de données incremental level 0
descripteur d'élément=/mnt/rmanbackup/FASPP_20110515_3omcdqji_1_1 commentaire=NONE

journal d'archivage en entrée thread=1 séquence=27488 recid=54696 horodatage=751234865
descripteur d'élément=/mnt/rmanbackup/FASPP_20110515_3pmcdrpi_1_1 commentaire=NONE

Démarrage de Control File and SPFILE Autobackup dans 15/05/11
descripteur d'élément=/mnt/rmanbackup/c-1144496385-20110515-00 commentaire=NONE
Fin de Control File and SPFILE Autobackup dans 15/05/11

Dimanche suivant, les fichiers sont toujours en cours pour la fenêtre de récup

Dimanche 22/05 Level 0
élément de sauvegarde vérifié : repéré comme étant 'AVAILABLE'
descripteur d'élément de sauvegarde=/mnt/rmanbackup/FASPP_20110515_3nmcdqin_1_1 recid=2165 horodatage=751233624
descripteur d'élément de sauvegarde=/mnt/rmanbackup/FASPP_20110515_3omcdqji_1_1 recid=2166 horodatage=751233650
descripteur d'élément de sauvegarde=/mnt/rmanbackup/FASPP_20110515_3pmcdrpi_1_1 recid=2167 horodatage=751234867
descripteur d'élément de sauvegarde=/mnt/rmanbackup/c-1144496385-20110515-00 recid=2168 horodatage=751234868

élément de sauvegarde supprimé
descripteur d'élément de sauvegarde=/mnt/rmanbackup/FASPP_20110515_3nmcdqin_1_1 recid=2165 horodatage=751233624

Le samedi 28 (Level 1), le fichier est toujours AVAILABLE

28/05 Sam Lev 1
élément de sauvegarde vérifié : repéré comme étant 'AVAILABLE'
/mnt/rmanbackup/FASPP_20110515_3omcdqji_1_1 recid=2166 horodatage=751233650
/mnt/rmanbackup/FASPP_20110515_3pmcdrpi_1_1 recid=2167 horodatage=751234867

Pas d'élément de sauvegarde supprimé

Et le dimanche 29 (Level 0) le fichier 3omcdqji n'est plus vérifié et n'est pas supprimé.

élément de sauvegarde vérifié : repéré comme étant 'AVAILABLE'
/mnt/rmanbackup/FASPP_20110515_3pmcdrpi_1_1 recid=2167 horodatage=751234867

élément de sauvegarde supprimé
/mnt/rmanbackup/FASPP_20110515_3pmcdrpi_1_1 recid=2167 horodatage=751234867

Avez vous une idée du pourquoi ?

[Kazevil]

Bonjour,

je vais peut-être commencer par une question bête, mais il faut bien commencer à chercher quelque part

Qu'avez vous défini comme RETENTION au niveau RMAN (RECOVERY WINDOW 30 DAYS?)?

Dans vos scripts, je ne vois nulle part cette information. Or les backups database, d'après ce que je vois dans les scripts, ne seront obsolete qu'une fois la rentention atteinte. Si vous avez le paramètre par défaut à RECOVERY WINDOW 30 DAYS, il faut attendre que les 30 jours soient passés avant de voir le backup database devenir obsolète.

Dans votre cas, je pencherai vers une configuration avec REDUNDANCY 1.

A++

Kaz

[McM]

Flûte, j'ai oublié de mettre la config Rman et de dire que c'était 7 jours, j'étais persuadé que c'était dans le run.
La voici

RMAN> SHOW ALL;

utilisation du fichier de contrôle de la base de données cible au lieu du catalogue de récupération
paramètres de configuration RMAN :
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGURE BACKUP OPTIMIZATION OFF;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/mnt/rmanbackup/%F';
CONFIGURE DEVICE TYPE DISK PARALLELISM 1;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/mnt/rmanbackup/%d_%T_%U';
CONFIGURE MAXSETSIZE TO UNLIMITED;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/home/ora92/dbs/snapcf_faspp.f';

RMAN>

[Kazevil]

Bonjour,

honnêtement je suis comme vous......surpris du fonctionnement. Je n'ai jamais trop utilisé les backups incrémentaux, donc je n'ai jamais eu l'occasion de rencontrer un tel cas en pratique. J'ai cependant une petite théorie, à tester , qui pourrait expliquer ce comportement.

Il me semble que pour restaurer un backup incrémental, le backup level 0 correspondant est nécessaire. Après si les level 1 entre sont nécessaire ou pas cela va dépendre si l'on est en cumulatif ou différentiel.
Du coup, comme vous avez une recovery window de 7 jours, je pense qu'Oracle ne pourra mettre le backup level 0 en obsolète qu'une fois que le dernier backup level 1 correspondant sera lui aussi obsolète. Dans le cas contrainte il serait impossible de restaurer le backup level 1.

En espèrant avoir fait avancé le schimililili...

Kaz

[McM]

Oui, je connais le fonctionnement de la fenêtre, j'ai la doc complète de rman (576 pages).
Avec une fenêtre de 7 jours, et un full (niveau 0) tous les samedis, je ne dois avoir que 2 fichiers gardés.

Mon problème est que je ne vois pas pourquoi :
La sauvegarde du vendredi soir, le fichier 3omcdqji (qui date de 13 jours) est en AVAILABLE (normal) et non supprimé.
La sauvegarde du lendemain (samedi level 0), Oracle ne cherche plus ce fichier pour savoir s'il est à supprimer..

Est ce qu'un autre paramètre peut rentrer en compte ?
Est ce qu'une suppression de fichiers log peut avoir cet effet ? (On crée les archives log sur 2 serveurs, et les archives log créés sur le serveur de standby sont supprimés par cron).

[orafrance]

N'y aurait-il pas Dataguard dans l'affaire ?

[McM]

Non, pas de dataguard.

Par contre, je viens de voir ceci :
Je fais un CROSSCHECK BACKUP, les premiers fichiers commencent au 29/05

RMAN> CROSSCHECK BACKUP
utilisation du fichier de contrôle de la base de données cible au lieu du catalogue de récupération
canal affecté : ORA_DISK_1
canal ORA_DISK_1 : sid=41 typedev=DISK
élément de sauvegarde vérifié : repéré comme étant 'AVAILABLE'
descripteur d'élément de sauvegarde=/mnt/rmanbackup/FASPP_20110529_5gmdinri_1_1 recid=2222 horodatage=752443250
élément de sauvegarde vérifié : repéré comme étant 'AVAILABLE'
descripteur d'élément de sauvegarde=/mnt/rmanbackup/FASPP_20110529_5hmdip2g_1_1 recid=2223 horodatage=752444497
...

Par contre si je fais une vérif en base des backup_piece : Ils commencent au 15/04/2011 et un fichier le dimanche (17/04) est noté comme non supprimé et en Statut A (Available) !

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
SELECT recid, handle, tag, STATUS, completion_time, deleted
FROM V$BACKUP_PIECE
ORDER BY recid
 
RECID	HANDLE	TAG	STATUS	COMPLETION_TIME	DELETED
2048	/mnt/rmanbackup/c-1144496385-20110415-00		D	15/04/2011 20:06	YES
2049	/mnt/rmanbackup_20110416_03m9unas_1_1	TAG20110416T200027	D	16/04/2011 20:00	YES
2050	/mnt/rmanbackup_20110416_04m9unc0_1_1	TAG20110416T200104	D	16/04/2011 20:05	YES
2051	/mnt/rmanbackup_20110416_05m9unl8_1_1	TAG20110416T200600	D	16/04/2011 20:06	YES
2052	/mnt/rmanbackup/c-1144496385-20110416-00		D	16/04/2011 20:06	YES
2053	/mnt/rmanbackup_20110417_07ma1bml_1_1	TAG20110417T200021	D	17/04/2011 20:00	YES
2054	/mnt/rmanbackup_20110417_08ma1bng_1_1	TAG20110417T200048	A	17/04/2011 20:21	NO
2055	/mnt/rmanbackup_20110417_09ma1ctq_1_1	TAG20110417T202114	D	17/04/2011 20:21	YES
2056	/mnt/rmanbackup/c-1144496385-20110417-00		D	17/04/2011 20:21	YES

Puis tous les fichiers de la semaine (du lundi au samedi suivant, tout est en D), et le dimanche suivant encore un fichier Available, ainsi de suite.

Voici la liste des fichiers qui sont en dehors de la fenêtre de 7 jours de récup, et noté en tant qu'Available.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
SELECT recid, handle, STATUS, completion_time, deleted
FROM V$BACKUP_PIECE
WHERE STATUS = 'A'
AND completion_time < TO_DATE('29.05.2011', 'DD.MM.RRRR')
ORDER BY recid
 
RECID	HANDLE	STATUS	COMPLETION_TIME	DELETED
2054	/mnt/rmanbackup/FASPP_20110417_08ma1bng_1_1	A	17/04/2011 20:21:04	NO
2082	/mnt/rmanbackup/FASPP_20110424_14majqbh_1_1	A	24/04/2011 20:20:42	NO
2110	/mnt/rmanbackup/FASPP_20110501_20mb8tbe_1_1	A	01/05/2011 20:21:37	NO
2138	/mnt/rmanbackup/FASPP_20110508_2smbrbvg_1_1	A	08/05/2011 20:22:01	NO
2166	/mnt/rmanbackup/FASPP_20110515_3omcdqji_1_1	A	15/05/2011 20:21:02	NO
2194	/mnt/rmanbackup/FASPP_20110522_4kmd097g_1_1	A	22/05/2011 20:20:35	NO

Je m'y perds un peu..

[McM]

J'ai modifié le param CONTROL_FILE_RECORD_KEEP_TIME qui était à 7 (valeur par défaut).

Code :

ALTER SYSTEM SET CONTROL_FILE_RECORD_KEEP_TIME=14 SCOPE=BOTH

Visiblement ça aurait permis le 12 Juin la suppression du fichier du 29 Mai.
Je vais modifier mes 3 autres bases qui sont dans le même cas et je verrai la semaine prochaine si tout s'est bien passé.

[McM]

C'était bien ça !
Problème résolu.