KEEP backups from rman are used to provide long-term and archival retention. They are used to bypass the default policy retention and are used to sustain some regulations/compliances (like HIPAA, or others) that require archival retention. But with ZDLRA they are treated in a different way. Here I will show how the KEEP backups can impact your backup strategy for ZDLRA.
Below, the database ORCL19C was recently added and there is no backup for this database registered inside of ZDLRA.
[oracle@orcloel7 ~]$ rman target=/ catalog=vpcbronze/vpcbronze@zdlras1-scan:1521/zdlras1 Recovery Manager: Release 19.0.0.0.0 - Production on Sat Oct 24 20:55:46 2020 Version 19.3.0.0.0 Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved. connected to target database: ORCL19C (DBID=1487680695) connected to recovery catalog database RMAN> list backup of datafile 1 device type sbt_tape; specification does not match any backup in the repository RMAN>
And inside of ZDLRA, you can see that there are no backups:
SQL> select DB_KEY from ra_database where DB_UNIQUE_NAME = 'ORCL19C';
DB_KEY
----------
14577
SQL> select DBINC_KEY from rc_database where db_key = 14577;
DBINC_KEY
----------
14578
SQL> select count(*) from vbdf where DB_KEY = 14577;
COUNT(*)
----------
0
SQL> select count(*) from plans where DB_KEY = 14577;
COUNT(*)
----------
0
SQL> select DB_KEY, SPACE_USAGE, KEEP_SPACE from ra_database where DB_UNIQUE_NAME = 'ORCL19C';
DB_KEY SPACE_USAGE KEEP_SPACE
---------- ----------- ----------
14577 0 0
SQL>
And as you can see above, at table RA_DATABASE there is column KEEP_SPACE to report the space used by keep backups.
So, we can do the first keep backup (I made just for the datafile 1):
RMAN> BACKUP INCREMENTAL LEVEL 0 DEVICE TYPE SBT FILESPERSET 1 DATAFILE 1 TAG 'KEEPDF1' KEEP FOREVER;
Starting backup at 24/10/2020 22:38:54
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=71 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: RA Library (ZDLRAS1) SID=B271AF93A734380EE053010310AC1736
backup will never be obsolete
archived logs required to recover from this backup will be backed up
channel ORA_SBT_TAPE_1: starting incremental level 0 datafile backup set
channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/ORCL19C/system01.dbf
channel ORA_SBT_TAPE_1: starting piece 1 at 24/10/2020 22:38:57
channel ORA_SBT_TAPE_1: finished piece 1 at 24/10/2020 22:40:52
piece handle=ORCL19C_c3vdq8s1_1_1 tag=KEEPDF1 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:01:55
current log archived
using channel ORA_SBT_TAPE_1
backup will never be obsolete
archived logs required to recover from this backup will be backed up
channel ORA_SBT_TAPE_1: starting archived log backup set
channel ORA_SBT_TAPE_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=96 RECID=155 STAMP=1054680052
channel ORA_SBT_TAPE_1: starting piece 1 at 24/10/2020 22:40:54
channel ORA_SBT_TAPE_1: finished piece 1 at 24/10/2020 22:41:01
piece handle=ORCL19C_c4vdq8vm_1_1 tag=KEEPDF1 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:07
using channel ORA_SBT_TAPE_1
backup will never be obsolete
archived logs required to recover from this backup will be backed up
channel ORA_SBT_TAPE_1: starting full datafile backup set
channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set
including current SPFILE in backup set
channel ORA_SBT_TAPE_1: starting piece 1 at 24/10/2020 22:41:02
channel ORA_SBT_TAPE_1: finished piece 1 at 24/10/2020 22:41:03
piece handle=ORCL19C_c5vdq8vu_1_1 tag=KEEPDF1 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:01
using channel ORA_SBT_TAPE_1
backup will never be obsolete
archived logs required to recover from this backup will be backed up
channel ORA_SBT_TAPE_1: starting full datafile backup set
channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_SBT_TAPE_1: starting piece 1 at 24/10/2020 22:41:05
channel ORA_SBT_TAPE_1: finished piece 1 at 24/10/2020 22:41:08
piece handle=ORCL19C_c6vdq900_1_1 tag=KEEPDF1 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:03
Finished backup at 24/10/2020 22:41:08
RMAN> list backup of datafile 1 device type sbt_tape;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
15685 Incr 0 783.25M SBT_TAPE 00:01:44 24/10/2020 22:40:41
BP Key: 15686 Status: AVAILABLE Compressed: NO Tag: KEEPDF1
Handle: ORCL19C_c3vdq8s1_1_1 Media: Recovery Appliance (ZDLRAS1)
Keep: BACKUP_LOGS Until: FOREVER
List of Datafiles in backup set 15685
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 0 Incr 2676322 24/10/2020 22:38:57 NO /u01/app/oracle/oradata/ORCL19C/system01.dbf
RMAN>
Above, you can see that “Handle” does not report “VB$_” as normal virtual backups managed by ZDLRA. And if we look at internals tables of ZDLRA the backup was not used to generate ant virtual full backup:
SQL> select DB_KEY, SPACE_USAGE, KEEP_SPACE from ra_database where DB_UNIQUE_NAME = 'ORCL19C';
DB_KEY SPACE_USAGE KEEP_SPACE
---------- ----------- ----------
14577 .79296875 .79296875
SQL>
SQL> select count(*) from plans where DB_KEY = 14577;
COUNT(*)
----------
0
SQL> select count(*) from vbdf where DB_KEY = 14577;
COUNT(*)
----------
0
SQL>
SQL> select DBINC_KEY from rc_database where db_key = 14577;
DBINC_KEY
----------
14578
SQL>
SQL> select DF_KEY from df where DBINC_KEY = 14578 and file# = 1;
DF_KEY
----------
14590
SQL>
SQL> select count(*) from blocks where DF_KEY = 14590;
COUNT(*)
----------
0
SQL>
To be clear, this is was expected since the KEEP backups, even in traditional, rman scenarios (with the third-party backup appliance) are not considered as part of the backup workflow. This means that if I do one incremental backup, the keep is not considered a valid parent backup.
The same is valid at ZDLRA, as you can see below I made a subsequent level 1 backup for the datafile 1 and no parent backups were found:
RMAN> BACKUP INCREMENTAL LEVEL 1 DEVICE TYPE SBT FILESPERSET 1 DATAFILE 1 TAG 'DF1'; Starting backup at 24/10/2020 22:54:28 allocated channel: ORA_SBT_TAPE_1 channel ORA_SBT_TAPE_1: SID=34 device type=SBT_TAPE channel ORA_SBT_TAPE_1: RA Library (ZDLRAS1) SID=B271E73EF4373B90E053010310AC6873 no parent backup or copy of datafile 1 found channel ORA_SBT_TAPE_1: starting incremental level 0 datafile backup set channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set input datafile file number=00001 name=/u01/app/oracle/oradata/ORCL19C/system01.dbf channel ORA_SBT_TAPE_1: starting piece 1 at 24/10/2020 22:54:30 channel ORA_SBT_TAPE_1: finished piece 1 at 24/10/2020 22:56:35 piece handle=ORCL19C_c7vdq9p6_1_1 tag=DF1 comment=API Version 2.0,MMS Version 12.2.0.2 channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:02:05 Finished backup at 24/10/2020 22:56:35 Starting Control File and SPFILE Autobackup at 24/10/2020 22:56:35 piece handle=c-1487680695-20201024-06 comment=API Version 2.0,MMS Version 12.2.0.2 Finished Control File and SPFILE Autobackup at 24/10/2020 22:56:44 RMAN>
And internally at ZDLRA, you can see that this backup without a keep, was used to generate virtual backups:
SQL> select count(*) from vbdf where DB_KEY = 14577;
COUNT(*)
----------
1
SQL> select count(*) from blocks where DF_KEY = 14590;
COUNT(*)
----------
100251
SQL> select DB_KEY, SPACE_USAGE, KEEP_SPACE from ra_database where DB_UNIQUE_NAME = 'ORCL19C';
DB_KEY SPACE_USAGE KEEP_SPACE
---------- ----------- ----------
14577 1.27265625 .79296875
SQL>
So, at this moment we have keep and virtual backup:
RMAN> list backup of datafile 1 device type sbt_tape;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
15685 Incr 0 783.25M SBT_TAPE 00:01:44 24/10/2020 22:40:41
BP Key: 15686 Status: AVAILABLE Compressed: NO Tag: KEEPDF1
Handle: ORCL19C_c3vdq8s1_1_1 Media: Recovery Appliance (ZDLRAS1)
Keep: BACKUP_LOGS Until: FOREVER
List of Datafiles in backup set 15685
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 0 Incr 2676322 24/10/2020 22:38:57 NO /u01/app/oracle/oradata/ORCL19C/system01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
15776 Incr 0 325.05M SBT_TAPE 00:01:59 24/10/2020 22:56:29
BP Key: 15777 Status: AVAILABLE Compressed: YES Tag: DF1
Handle: VB$_1918343643_15775I Media:
List of Datafiles in backup set 15776
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 0 Incr 2678532 24/10/2020 22:54:30 NO /u01/app/oracle/oradata/ORCL19C/system01.dbf
RMAN>
But during the normal database life (after several backups are done) is possible/needed to do some keep backup. Fortunately, since the keep backup does not affect the incremental forever strategy, we can have it without collateral effect. Even doing a level 0 backup, the virtual full backups continue to work:
RMAN> BACKUP INCREMENTAL LEVEL 0 DEVICE TYPE SBT FILESPERSET 1 DATAFILE 1 TAG 'KEEPDF1' KEEP FOREVER;
Starting backup at 24/10/2020 23:01:29
using channel ORA_SBT_TAPE_1
backup will never be obsolete
archived logs required to recover from this backup will be backed up
channel ORA_SBT_TAPE_1: starting incremental level 0 datafile backup set
channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/ORCL19C/system01.dbf
channel ORA_SBT_TAPE_1: starting piece 1 at 24/10/2020 23:01:29
channel ORA_SBT_TAPE_1: finished piece 1 at 24/10/2020 23:03:24
piece handle=ORCL19C_c9vdqa69_1_1 tag=KEEPDF1 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:01:55
current log archived
using channel ORA_SBT_TAPE_1
backup will never be obsolete
archived logs required to recover from this backup will be backed up
channel ORA_SBT_TAPE_1: starting archived log backup set
channel ORA_SBT_TAPE_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=97 RECID=156 STAMP=1054681404
channel ORA_SBT_TAPE_1: starting piece 1 at 24/10/2020 23:03:27
channel ORA_SBT_TAPE_1: finished piece 1 at 24/10/2020 23:03:34
piece handle=ORCL19C_cavdqa9v_1_1 tag=KEEPDF1 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:07
using channel ORA_SBT_TAPE_1
backup will never be obsolete
archived logs required to recover from this backup will be backed up
channel ORA_SBT_TAPE_1: starting full datafile backup set
channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set
including current SPFILE in backup set
channel ORA_SBT_TAPE_1: starting piece 1 at 24/10/2020 23:03:35
channel ORA_SBT_TAPE_1: finished piece 1 at 24/10/2020 23:03:42
piece handle=ORCL19C_cbvdqaa7_1_1 tag=KEEPDF1 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:07
using channel ORA_SBT_TAPE_1
backup will never be obsolete
archived logs required to recover from this backup will be backed up
channel ORA_SBT_TAPE_1: starting full datafile backup set
channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_SBT_TAPE_1: starting piece 1 at 24/10/2020 23:03:44
channel ORA_SBT_TAPE_1: finished piece 1 at 24/10/2020 23:03:47
piece handle=ORCL19C_ccvdqaaf_1_1 tag=KEEPDF1 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:03
Finished backup at 24/10/2020 23:03:47
RMAN> BACKUP INCREMENTAL LEVEL 0 DEVICE TYPE SBT FILESPERSET 1 DATAFILE 1 TAG 'DF1';
Starting backup at 24/10/2020 23:05:16
using channel ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: starting incremental level 1 datafile backup set
channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/ORCL19C/system01.dbf
channel ORA_SBT_TAPE_1: starting piece 1 at 24/10/2020 23:06:44
channel ORA_SBT_TAPE_1: finished piece 1 at 24/10/2020 23:06:45
piece handle=ORCL19C_cevdqag4_1_1 tag=DF1 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:01
Finished backup at 24/10/2020 23:06:45
Starting Control File and SPFILE Autobackup at 24/10/2020 23:06:45
piece handle=c-1487680695-20201024-07 comment=API Version 2.0,MMS Version 12.2.0.2
Finished Control File and SPFILE Autobackup at 24/10/2020 23:06:49
RMAN> list backup of datafile 1 device type sbt_tape;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
15685 Incr 0 783.25M SBT_TAPE 00:01:44 24/10/2020 22:40:41
BP Key: 15686 Status: AVAILABLE Compressed: NO Tag: KEEPDF1
Handle: ORCL19C_c3vdq8s1_1_1 Media: Recovery Appliance (ZDLRAS1)
Keep: BACKUP_LOGS Until: FOREVER
List of Datafiles in backup set 15685
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 0 Incr 2676322 24/10/2020 22:38:57 NO /u01/app/oracle/oradata/ORCL19C/system01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
15776 Incr 0 325.05M SBT_TAPE 00:01:59 24/10/2020 22:56:29
BP Key: 15777 Status: AVAILABLE Compressed: YES Tag: DF1
Handle: VB$_1918343643_15775I Media:
List of Datafiles in backup set 15776
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 0 Incr 2678532 24/10/2020 22:54:30 NO /u01/app/oracle/oradata/ORCL19C/system01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
15781 Incr 0 783.25M SBT_TAPE 00:01:45 24/10/2020 23:03:14
BP Key: 15782 Status: AVAILABLE Compressed: NO Tag: KEEPDF1
Handle: ORCL19C_c9vdqa69_1_1 Media: Recovery Appliance (ZDLRAS1)
Keep: BACKUP_LOGS Until: FOREVER
List of Datafiles in backup set 15781
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 0 Incr 2679717 24/10/2020 23:01:29 NO /u01/app/oracle/oradata/ORCL19C/system01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
15895 Incr 1 48.00K SBT_TAPE 00:00:04 24/10/2020 23:06:48
BP Key: 15896 Status: AVAILABLE Compressed: YES Tag: DF1
Handle: VB$_1918343643_15894I Media:
List of Datafiles in backup set 15895
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 1 Incr 2680540 24/10/2020 23:06:44 NO /u01/app/oracle/oradata/ORCL19C/system01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
15899 Incr 0 323.93M SBT_TAPE 00:00:04 24/10/2020 23:06:48
BP Key: 15900 Status: AVAILABLE Compressed: YES Tag: DF1
Handle: VB$_1918343643_15894_1 Media:
List of Datafiles in backup set 15899
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 0 Incr 2680540 24/10/2020 23:06:44 NO /u01/app/oracle/oradata/ORCL19C/system01.dbf
RMAN>
Above you can notice that I made one keep backup level 0 for datafile 1 and after that, I made a new level 1 backup. But the virtual full backup was generated correctly meaning that the “keep level 0” not affect the normal ZDLRA behavior.
So, the KEEP backup not affect the incremental forever strategy even when taken when you already stored backups at ZDLRA. They are stored at the ZDLRA delta store, consume space, but are treated as a separate thread.
Disclaimer: “The postings on this site are my own and don’t necessarily represent my actual employer positions, strategies or opinions. The information here was edited to be useful for general purpose, specific data and identifications were removed to allow reach the generic audience and to be useful for the community. Post protected by copyright.”
Great post on keep backups!
I found a few ways to leverage the fact that keep backups do not virtualize or affect the incremental forever strategy.
1) if you need to create a one-off backup to create a clone from. For example, I want to create a disk backup and sFTP it to another server, keep is the way to go. Creating a keep backup to disk won’t affect you ZDLRA backups.
2) You can compress the keep backup if using TDE. If you compress a backup that contains TDE data it will not virtualize. But for an archival backup, it is a big plus. It will take up less room on the ZDLRA , and get written to tape or cloud compressed.
Pingback: MOVE_BACKUP and ZDLRA | Fernando Simon