Je vous laisse ici un petit script qui pourrait s'avérer utile pour déterminer la taille de vos sauvegardes.
Bien sûr si vous passez par RMAN avec un LIST BACKUP vous pouvez l'avoir pour chaque BackupSet mais il va falloir commencer à faire les calculs.
En bref, je me suis créé ce script pour une demande d'inventaire des tailles des sauvegardes que j'avais reçue.
Pour ce faire, je devais aller valider tous les derniers FULL backup de la dernière semaine de chaque bd chez un client.
Ce script peut vous sauver pas mal de temps lorsque un Catalog RMAN est utilisé. Je dois publier d'ici peu la version du script sans catalogue.
Je l'ai testé avec plus de 70 bases de données et le résultat semble correct lorsqu'il est comparé avec les tailles montrés par le LIST BACKUP. Cependant, rien ne vous empêche de refaire vos tests :)
J'espère que cela sera vraiment utile pour vous.
SET LINESIZE 450
SET PAGESIZE 1000
COL BACKUP_TYPE FORMAT A20
COL STATUS FORMAT A5
COL SESSION_RECIDSTAMP FORMAT A20
COL START_TIME FORMAT A18
COL COMPRESSED FORMAT A6 HEAD "Compre"
COL CONTROLFILE_INCLUDED FORMAT A10 HEAD "Inc |Ctrlf"
COL INCREMENTAL_LEVEL FORMAT 99 HEAD "Inc |Level"
COL OUTPUT_MBYTES FORMAT 999,999,999,999.99
COL OUTPUT_GBYTES FORMAT 999,999,999.99
COL MEDIA FORMAT A10
BREAK ON SESSION_RECIDSTAMP SKIP 1
COMPUTE SUM LABEL TOTAL OF OUTPUT_MBYTES OUTPUT_GBYTES ON SESSION_RECIDSTAMP
ACCEPT BD PROMPT 'DatabaseName: '
SELECT TO_CHAR(C.SESSION_RECID)||'-'||TO_CHAR(C.SESSION_STAMP) SESSION_RECIDSTAMP,
A.DB_KEY,
A.NAME,
TO_CHAR(B.START_TIME,'YYYY/MM/DD HH24:MI') START_TIME,
C.BS_KEY,
DECODE(B.BACKUP_TYPE,'D','FULL OR LEVEL_0','I','INCREMENTAL','L','ARCHIVES' ) BACKUP_TYPE,
C.CONTROLFILE_INCLUDED,
B.INCREMENTAL_LEVEL, B.STATUS, B.BLOCK_SIZE, C.COMPRESSED,
ROUND(C.OUTPUT_BYTES/1024/1024,2) OUTPUT_MBYTES,
ROUND(C.OUTPUT_BYTES/1024/1024/1024,2) OUTPUT_GBYTES,
D.MEDIA
FROM RC_DATABASE A, RC_BACKUP_SET B, RC_BACKUP_SET_DETAILS C, RC_BACKUP_PIECE D
WHERE A.NAME = '&BD' AND
A.DB_KEY = B.DB_KEY AND
A.DBID = B.DB_ID AND
B.BACKUP_TYPE IN ('D','I') AND
B.DB_KEY = C.DB_KEY AND
B.INPUT_FILE_SCAN_ONLY = 'NO' AND
B.BS_KEY = C.BS_KEY AND
A.DB_KEY = D.DB_KEY AND
B.BS_KEY = D.BS_KEY
AND B.START_TIME >= SYSDATE - 7
UNION ALL
SELECT TO_CHAR(C.SESSION_RECID)||'-'||TO_CHAR(C.SESSION_STAMP) SESSION_RECIDSTAMP,
A.DB_KEY, A.NAME,
TO_CHAR(B.START_TIME,'YYYY/MM/DD HH24:MI') START_TIME,
B.BS_KEY,
DECODE(B.BACKUP_TYPE,'D','FULL OR LEVEL_0','I','INCREMENTAL','L','ARCHIVES' ) BACKUP_TYPE,
'' CONTROLFILE_INCLUDED,
B.INCREMENTAL_LEVEL, B.STATUS, B.BLOCK_SIZE, '-' COMPRESSED,
ROUND(C.MBYTES,2) OUTPUT_MBYTES,
ROUND(C.GBYTES,2) OUTPUT_GBYTES,
D.MEDIA
FROM RC_DATABASE A, RC_BACKUP_SET B,
(SELECT AA.DB_KEY, AA.SESSION_RECID, AA.SESSION_STAMP, AA.BTYPE_KEY BS_KEY, SUM(AA.FILESIZE)/1024/1024 MBYTES, SUM(AA.FILESIZE)/1024/1024/1024 GBYTES
FROM RC_BACKUP_ARCHIVELOG_DETAILS AA
WHERE AA.DB_NAME = '&BD'
GROUP BY AA.DB_KEY, AA.SESSION_RECID, AA.SESSION_STAMP, AA.BTYPE_KEY
) C, RC_BACKUP_PIECE D
WHERE A.NAME = '&BD' AND
A.DB_KEY = B.DB_KEY AND
A.DBID = B.DB_ID AND
B.BACKUP_TYPE = 'L' AND
B.DB_KEY = C.DB_KEY AND
B.INPUT_FILE_SCAN_ONLY = 'NO' AND
B.BS_KEY = C.BS_KEY AND
A.DB_KEY = D.DB_KEY AND
B.BS_KEY = D.BS_KEY
AND B.START_TIME >= SYSDATE - 7
ORDER BY 4, 5 ;
Voici un exemple du résultat, bien sûr j'ai supprimé les données de deux colonnes par sécurité.
NB :
Avec les catalogues 11g le temps de réponse est bon (moins de 3 sec), pour ceux qui ont toujours une bd 10g, cela c'est plus long (beaucoup plus long, entre 40 et 90 sec.)
Je n'ai pas eu de temps de vérifier la raison de cette différence.
