One of the most knows features of ZDLRA is the virtual full backup, basically incremental forever strategy. But what this means in real life? In this post, I will show some details about that and how interesting they are, check what it is Virtual Full Backup and Incremental Forever strategy for ZDLRA.
This post is based on my previous one where I showed all the steps to configure the VPC and enroll database at ZDLRA.
Virtual Full Backup
A virtual full backup appears as an incremental level 0 backup in the recovery catalog. From the user’s perspective, a virtual full backup is indistinguishable from a non-virtual full backup. Using virtual backups, Recovery Appliance provides the protection of frequent level 0 backups with only the cost of frequent level 1 backups.
This definition (and image) are in the Zero Data Loss Recovery Appliance Administrator’s Guide and I think that represents the essence of the virtual full backup. ZDLRA receive the incremental level 1 backup, index it, and generate a level 0 to you that it is indistinguishable from a normal backup level 0.
As you can see, virtual full are deeply linked with incremental forever strategy (that it is just executing incremental backups). And based in these incremental backups you receive a full backup available for usage.
To start, I open RMAN and connect in the rman catalog (ZDLRA database, using the VPC configured) and execute a level 0 backup:
RMAN> RUN {
2> BACKUP INCREMENTAL LEVEL 0 DEVICE TYPE SBT FILESPERSET 1 DATABASE TAG 'BKP-DB-INC0';
3> SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
4> BACKUP DEVICE TYPE SBT FILESPERSET 100 FORMAT '%U' ARCHIVELOG ALL NOT BACKED UP TAG 'BKP-ARCH';
5> }
Starting backup at 15-08-2019_00:44:36
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=100 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: RA Library (ZDLRA) SID=901C8083732A1691E053010310AC46B7
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/ORCL18/system01.dbf
channel ORA_SBT_TAPE_1: starting piece 1 at 15-08-2019_00:44:38
channel ORA_SBT_TAPE_1: finished piece 1 at 15-08-2019_00:47:23
piece handle=ORCL18_0tu97pnm_1_1 tag=BKP-DB-INC0 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:02:45
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=00003 name=/u01/app/oracle/oradata/ORCL18/sysaux01.dbf
channel ORA_SBT_TAPE_1: starting piece 1 at 15-08-2019_00:47:24
channel ORA_SBT_TAPE_1: finished piece 1 at 15-08-2019_00:48:59
piece handle=ORCL18_0uu97pss_1_1 tag=BKP-DB-INC0 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:01:35
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=00004 name=/u01/app/oracle/oradata/ORCL18/undotbs01.dbf
channel ORA_SBT_TAPE_1: starting piece 1 at 15-08-2019_00:48:59
channel ORA_SBT_TAPE_1: finished piece 1 at 15-08-2019_00:49:02
piece handle=ORCL18_0vu97pvr_1_1 tag=BKP-DB-INC0 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:03
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=00007 name=/u01/app/oracle/oradata/ORCL18/users01.dbf
channel ORA_SBT_TAPE_1: starting piece 1 at 15-08-2019_00:49:02
channel ORA_SBT_TAPE_1: finished piece 1 at 15-08-2019_00:49:05
piece handle=ORCL18_10u97pvu_1_1 tag=BKP-DB-INC0 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 15-08-2019_00:49:05
Starting Control File and SPFILE Autobackup at 15-08-2019_00:49:05
piece handle=c-3914023082-20190815-02 comment=API Version 2.0,MMS Version 12.2.0.2
Finished Control File and SPFILE Autobackup at 15-08-2019_00:49:22
sql statement: ALTER SYSTEM ARCHIVE LOG CURRENT
Starting backup at 15-08-2019_00:49:28
current log archived
using channel ORA_SBT_TAPE_1
skipping archived logs of thread 1 from sequence 4 to 9; already 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=10 RECID=7 STAMP=1016326166
input archived log thread=1 sequence=11 RECID=8 STAMP=1016326170
channel ORA_SBT_TAPE_1: starting piece 1 at 15-08-2019_00:49:32
channel ORA_SBT_TAPE_1: finished piece 1 at 15-08-2019_00:49:35
piece handle=12u97q0s_1_1 tag=BKP-ARCH 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 15-08-2019_00:49:35
Starting Control File and SPFILE Autobackup at 15-08-2019_00:49:35
piece handle=c-3914023082-20190815-03 comment=API Version 2.0,MMS Version 12.2.0.2
Finished Control File and SPFILE Autobackup at 15-08-2019_00:49:51
RMAN> list backup of datafile 1;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
2222 Incr 0 748.50M SBT_TAPE 00:02:32 15-08-2019_00:47:10
BP Key: 2223 Status: AVAILABLE Compressed: NO Tag: BKP-DB-INC0
Handle: ORCL18_0tu97pnm_1_1 Media: Recovery Appliance (ZDLRA)
List of Datafiles in backup set 2222
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 0 Incr 1614233 15-08-2019_00:44:39 NO /u01/app/oracle/oradata/ORCL18/system01.dbf
RMAN>
As you can see a simple incremental level 0 backup, archive log generation, and backup. ZDLRA after receive this backup start to index it to generate the base level 0. If you go to ZDLRA database you can see:
SQL> select TASK_ID, TASK_TYPE, STATE, WAITING_ON, DB_KEY, DB_UNIQUE_NAME, CREATION_TIME, ERROR_COUNT, DF_KEY, BS_KEY, BP_KEY, VB_KEY from rasys.ra_task where archived = 'N';
TASK_ID TASK_TYPE STATE WAITING_ON DB_KEY DB_UNIQUE_NAME CREATION_TIME ERROR_COUNT DF_KEY BS_KEY BP_KEY VB_KEY
---------- -------------------- --------------- ---------- ---------- ------------------------------ ----------------------------------- ----------- ---------- ---------- ---------- ----------
9626 INDEX_BACKUP RUNNING 1527 ORCL18 15-AUG-19 12.47.12.479004 AM +02:00 0 2223
9627 INDEX_BACKUP EXECUTABLE 1527 ORCL18 15-AUG-19 12.48.56.229219 AM +02:00 0 2228
9628 INDEX_BACKUP EXECUTABLE 1527 ORCL18 15-AUG-19 12.49.02.200951 AM +02:00 0 2232
9629 INDEX_BACKUP EXECUTABLE 1527 ORCL18 15-AUG-19 12.49.04.895727 AM +02:00 0 2236
4 rows selected.
SQL>
Above look the task INDEX_BACKUP running BS_KEY 2223, and check that it is the same backupset for datafile 1 that I showed before (I executed the list backup for datafile 1 just after the backup finish). And while the INDEX_BACKUP task still running you can see check again the list backupset for datafile 1 at rman:
RMAN> list backup of datafile 1;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
2222 Incr 0 748.50M SBT_TAPE 00:02:32 15-08-2019_00:47:10
BP Key: 2223 Status: AVAILABLE Compressed: NO Tag: BKP-DB-INC0
Handle: ORCL18_0tu97pnm_1_1 Media: Recovery Appliance (ZDLRA)
List of Datafiles in backup set 2222
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 0 Incr 1614233 15-08-2019_00:44:39 NO /u01/app/oracle/oradata/ORCL18/system01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
2336 Incr 0 329.21M SBT_TAPE 00:02:34 15-08-2019_00:47:12
BP Key: 2337 Status: AVAILABLE Compressed: YES Tag: BKP-DB-INC0
Handle: VB$_4142545763_2226I Media:
List of Datafiles in backup set 2336
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 0 Incr 1614233 15-08-2019_00:44:39 NO /u01/app/oracle/oradata/ORCL18/system01.dbf
RMAN>
Look how interesting it is. Now you have a new backupset (BS key 2336) that it is a clone for the original. Have same SCN, same TAG, same completion time, and size. The only difference is the handle that has the ZDLRA pattern VB$_*. And after some tasks inside ZDLRA finish (like RM_INC_FILES and RUN_PURGE_DF) you have just one backup of datafile 1:
RMAN> list backup of datafile 1;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
2336 Incr 0 329.21M SBT_TAPE 00:02:34 15-08-2019_00:47:12
BP Key: 2337 Status: AVAILABLE Compressed: YES Tag: BKP-DB-INC0
Handle: VB$_4142545763_2226I Media:
List of Datafiles in backup set 2336
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 0 Incr 1614233 15-08-2019_00:44:39 NO /u01/app/oracle/oradata/ORCL18/system01.dbf
RMAN>
As I told in my previous post, ZDLRA has the ability to open your backupset and index every block for your datafile, and more important: validated every block for each datafile.
Incremental Forever
Above was just for the initial level 0 backup, and it is not “incremental forever”. But if you do an incremental level 1 backup (I cropped the output to reduce the post size but it was just: BACKUP INCREMENTAL LEVEL 1 DEVICE TYPE SBT FILESPERSET 1 DATABASE TAG ‘BKP-DB-INC1’;. Check the list backup after that:
RMAN> list backup of datafile 1;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
2336 Incr 0 329.21M SBT_TAPE 00:02:34 15-08-2019_00:47:12
BP Key: 2337 Status: AVAILABLE Compressed: YES Tag: BKP-DB-INC0
Handle: VB$_4142545763_2226I Media:
List of Datafiles in backup set 2336
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 0 Incr 1614233 15-08-2019_00:44:39 NO /u01/app/oracle/oradata/ORCL18/system01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
2589 Incr 1 48.00K SBT_TAPE 00:00:02 15-08-2019_00:58:00
BP Key: 2590 Status: AVAILABLE Compressed: YES Tag: BKP-DB-INC1
Handle: VB$_4142545763_2588I Media:
List of Datafiles in backup set 2589
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 1 Incr 1614888 15-08-2019_00:57:59 NO /u01/app/oracle/oradata/ORCL18/system01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
2644 Incr 0 328.08M SBT_TAPE 00:00:02 15-08-2019_00:58:00
BP Key: 2645 Status: AVAILABLE Compressed: YES Tag: BKP-DB-INC1
Handle: VB$_4142545763_2588_1 Media:
List of Datafiles in backup set 2644
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 0 Incr 1614888 15-08-2019_00:57:59 NO /u01/app/oracle/oradata/ORCL18/system01.dbf
RMAN>
Look the details above. Inside of rman catalog at ZDLRA was made available to you a new level 0 backup that it is the virtual full backup. This level 0 have the same SCN than the incremental level 1.
So, basically, ZDLRA opened the backup incremental level 1 that you sent, read all the blocks, index it and based in the previous backup level 0 that was available (virtual or not – this is important) merged the block and present to you a new level 0. And if you do this every day, after an incremental level 1 you receive a complete virtual full backup.
In real life, it is simple like that. Again, check how interesting it is, you have now one backup level 0 available after the incremental that have a new backupset (BS key 2644) that it is a merge from the incremental level 1 (backupset 2589) with the previous level 0 (backupset 2636). And have the same SCN, same TAG, same completion time that the incremental level 1.
Some details that you need to take care of this. If you use rman encryption virtual full backups will not work. For TDE, you can use it, not a problem. But you can’t use TDE with rman compression enabled. Check here. The recommendation too is using FILESPERSET 1 while doing the backup. This is good because reduce some overhead inside of ZDLRA (to open every backup and split it), and reduce pollution inside rman catalog list backup (if you sent a backup without fileperset, ZDLRA does not remove it from the list).
If I do a backup without filersperset the ZDLRA will open the bakupset and generate a virtual full for each datafile that it is inside of the original backupset. Check below that SCN is the same than incremental level 1:
RMAN> list backup of database completed after "sysdate - 5/1440";
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
2905 Incr 1 1.26M SBT_TAPE 00:00:08 15-08-2019_01:04:28
BP Key: 2906 Status: AVAILABLE Compressed: YES Tag: BKP-DB-INC1
Handle: VB$_4142545763_2827I Media:
List of Datafiles in backup set 2905
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 1 Incr 1615589 15-08-2019_01:04:20 NO /u01/app/oracle/oradata/ORCL18/system01.dbf
3 1 Incr 1615589 15-08-2019_01:04:20 NO /u01/app/oracle/oradata/ORCL18/sysaux01.dbf
4 1 Incr 1615589 15-08-2019_01:04:20 NO /u01/app/oracle/oradata/ORCL18/undotbs01.dbf
7 1 Incr 1615589 15-08-2019_01:04:20 NO /u01/app/oracle/oradata/ORCL18/users01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
2992 Incr 0 328.09M SBT_TAPE 00:00:08 15-08-2019_01:04:28
BP Key: 2993 Status: AVAILABLE Compressed: YES Tag: BKP-DB-INC1
Handle: VB$_4142545763_2827_1 Media:
List of Datafiles in backup set 2992
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
1 0 Incr 1615589 15-08-2019_01:04:20 NO /u01/app/oracle/oradata/ORCL18/system01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
2996 Incr 0 40.00K SBT_TAPE 00:00:08 15-08-2019_01:04:28
BP Key: 2997 Status: AVAILABLE Compressed: YES Tag: BKP-DB-INC1
Handle: VB$_4142545763_2827_7 Media:
List of Datafiles in backup set 2996
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
7 0 Incr 1615589 15-08-2019_01:04:20 NO /u01/app/oracle/oradata/ORCL18/users01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
3000 Incr 0 480.00K SBT_TAPE 00:00:08 15-08-2019_01:04:28
BP Key: 3001 Status: AVAILABLE Compressed: YES Tag: BKP-DB-INC1
Handle: VB$_4142545763_2827_4 Media:
List of Datafiles in backup set 3000
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
4 0 Incr 1615589 15-08-2019_01:04:20 NO /u01/app/oracle/oradata/ORCL18/undotbs01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
3004 Incr 0 135.47M SBT_TAPE 00:00:08 15-08-2019_01:04:28
BP Key: 3005 Status: AVAILABLE Compressed: YES Tag: BKP-DB-INC1
Handle: VB$_4142545763_2827_3 Media:
List of Datafiles in backup set 3004
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
3 0 Incr 1615589 15-08-2019_01:04:20 NO /u01/app/oracle/oradata/ORCL18/sysaux01.dbf
RMAN>
The virtual backup continue to work if you use the SECTION SIZE (it is recommended by the way, especially for huge databases). Look the example:
[oracle@orcloel7 ~]$ sqlplus / as sysdba
SQL*Plus: Release 18.0.0.0.0 - Production on Thu Aug 15 01:11:58 2019
Version 18.6.0.0.0
Copyright (c) 1982, 2018, Oracle. All rights reserved.
Connected to:
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.6.0.0.0
SQL> create tablespace simon datafile '/u01/app/oracle/oradata/ORCL18/simon.dbf' size 1G;
Tablespace created.
SQL> exit
Disconnected from Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.6.0.0.0
[oracle@orcloel7 ~]$ rman target=/ catalog=cat_zdlra/s3nhazdlra@zdlra
Recovery Manager: Release 18.0.0.0.0 - Production on Thu Aug 15 01:15:24 2019
Version 18.6.0.0.0
Copyright (c) 1982, 2018, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORCL18 (DBID=3914023082)
connected to recovery catalog database
PL/SQL package CAT_ZDLRA.DBMS_RCVCAT version 18.03.00.00. in RCVCAT database is not current
PL/SQL package CAT_ZDLRA.DBMS_RCVMAN version 18.03.00.00 in RCVCAT database is not current
RMAN> report schema;
starting full resync of recovery catalog
full resync complete
Report of database schema for database with db_unique_name ORCL18
List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1 870 SYSTEM YES /u01/app/oracle/oradata/ORCL18/system01.dbf
3 510 SYSAUX NO /u01/app/oracle/oradata/ORCL18/sysaux01.dbf
4 320 UNDOTBS1 YES /u01/app/oracle/oradata/ORCL18/undotbs01.dbf
5 1024 SIMON NO /u01/app/oracle/oradata/ORCL18/simon.dbf
7 5 USERS NO /u01/app/oracle/oradata/ORCL18/users01.dbf
List of Temporary Files
=======================
File Size(MB) Tablespace Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1 49 TEMP 32767 /u01/app/oracle/oradata/ORCL18/temp01.dbf
RMAN> BACKUP INCREMENTAL LEVEL 0 SECTION SIZE 250M DEVICE TYPE SBT DATAFILE 5 TAG 'BKP-DBF5-INC0';
Starting backup at 15-08-2019_01:16:35
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=68 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: RA Library (ZDLRA) SID=901CF26E504F1E35E053010310AC27EC
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=00005 name=/u01/app/oracle/oradata/ORCL18/simon.dbf
backing up blocks 1 through 32000
channel ORA_SBT_TAPE_1: starting piece 1 at 15-08-2019_01:16:37
channel ORA_SBT_TAPE_1: finished piece 1 at 15-08-2019_01:16:38
piece handle=ORCL18_1fu97rjl_1_1 tag=BKP-DBF5-INC0 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:01
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=00005 name=/u01/app/oracle/oradata/ORCL18/simon.dbf
backing up blocks 32001 through 64000
channel ORA_SBT_TAPE_1: starting piece 2 at 15-08-2019_01:16:38
channel ORA_SBT_TAPE_1: finished piece 2 at 15-08-2019_01:16:39
piece handle=ORCL18_1fu97rjl_2_1 tag=BKP-DBF5-INC0 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:01
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=00005 name=/u01/app/oracle/oradata/ORCL18/simon.dbf
backing up blocks 64001 through 96000
channel ORA_SBT_TAPE_1: starting piece 3 at 15-08-2019_01:16:39
channel ORA_SBT_TAPE_1: finished piece 3 at 15-08-2019_01:16:42
piece handle=ORCL18_1fu97rjl_3_1 tag=BKP-DBF5-INC0 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:03
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=00005 name=/u01/app/oracle/oradata/ORCL18/simon.dbf
backing up blocks 96001 through 128000
channel ORA_SBT_TAPE_1: starting piece 4 at 15-08-2019_01:16:42
channel ORA_SBT_TAPE_1: finished piece 4 at 15-08-2019_01:16:43
piece handle=ORCL18_1fu97rjl_4_1 tag=BKP-DBF5-INC0 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:01
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=00005 name=/u01/app/oracle/oradata/ORCL18/simon.dbf
backing up blocks 128001 through 131072
channel ORA_SBT_TAPE_1: starting piece 5 at 15-08-2019_01:16:43
channel ORA_SBT_TAPE_1: finished piece 5 at 15-08-2019_01:16:44
piece handle=ORCL18_1fu97rjl_5_1 tag=BKP-DBF5-INC0 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 15-08-2019_01:16:44
Starting Control File and SPFILE Autobackup at 15-08-2019_01:16:44
piece handle=c-3914023082-20190815-08 comment=API Version 2.0,MMS Version 12.2.0.2
Finished Control File and SPFILE Autobackup at 15-08-2019_01:16:52
RMAN> list backup of datafile 5;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
3244 Incr 0 208.00K SBT_TAPE 00:00:08 15-08-2019_01:16:45
List of Datafiles in backup set 3244
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
5 0 Incr 1616756 15-08-2019_01:16:37 NO /u01/app/oracle/oradata/ORCL18/simon.dbf
Backup Set Copy #1 of backup set 3244
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ ------------------- ---------- ---
SBT_TAPE 00:00:08 15-08-2019_01:16:45 YES BKP-DBF5-INC0
List of Backup Pieces for backup set 3244 Copy #1
BP Key Pc# Status Media Piece Name
------- --- ----------- ----------------------- ----------
3245 1 AVAILABLE VB$_4142545763_3227I
3250 2 AVAILABLE VB$_4142545763_3248I
3255 3 AVAILABLE VB$_4142545763_3253I
3260 4 AVAILABLE VB$_4142545763_3258I
3272 5 AVAILABLE VB$_4142545763_3270I
RMAN> BACKUP INCREMENTAL LEVEL 1 SECTION SIZE 250M DEVICE TYPE SBT DATAFILE 5 TAG 'BKP-DBF5-INC1';
Starting backup at 15-08-2019_01:20:01
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=00005 name=/u01/app/oracle/oradata/ORCL18/simon.dbf
backing up blocks 1 through 32000
channel ORA_SBT_TAPE_1: starting piece 1 at 15-08-2019_01:20:02
channel ORA_SBT_TAPE_1: finished piece 1 at 15-08-2019_01:20:03
piece handle=ORCL18_1lu97rq2_1_1 tag=BKP-DBF5-INC1 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:01
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=00005 name=/u01/app/oracle/oradata/ORCL18/simon.dbf
backing up blocks 32001 through 64000
channel ORA_SBT_TAPE_1: starting piece 2 at 15-08-2019_01:20:03
channel ORA_SBT_TAPE_1: finished piece 2 at 15-08-2019_01:20:10
piece handle=ORCL18_1lu97rq2_2_1 tag=BKP-DBF5-INC1 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:07
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=00005 name=/u01/app/oracle/oradata/ORCL18/simon.dbf
backing up blocks 64001 through 96000
channel ORA_SBT_TAPE_1: starting piece 3 at 15-08-2019_01:20:10
channel ORA_SBT_TAPE_1: finished piece 3 at 15-08-2019_01:20:11
piece handle=ORCL18_1lu97rq2_3_1 tag=BKP-DBF5-INC1 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:01
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=00005 name=/u01/app/oracle/oradata/ORCL18/simon.dbf
backing up blocks 96001 through 128000
channel ORA_SBT_TAPE_1: starting piece 4 at 15-08-2019_01:20:11
channel ORA_SBT_TAPE_1: finished piece 4 at 15-08-2019_01:20:12
piece handle=ORCL18_1lu97rq2_4_1 tag=BKP-DBF5-INC1 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:01
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=00005 name=/u01/app/oracle/oradata/ORCL18/simon.dbf
backing up blocks 128001 through 131072
channel ORA_SBT_TAPE_1: starting piece 5 at 15-08-2019_01:20:12
channel ORA_SBT_TAPE_1: finished piece 5 at 15-08-2019_01:20:13
piece handle=ORCL18_1lu97rq2_5_1 tag=BKP-DBF5-INC1 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 15-08-2019_01:20:13
Starting Control File and SPFILE Autobackup at 15-08-2019_01:20:13
piece handle=c-3914023082-20190815-09 comment=API Version 2.0,MMS Version 12.2.0.2
Finished Control File and SPFILE Autobackup at 15-08-2019_01:20:21
RMAN> list backup of datafile 5;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
3244 Incr 0 208.00K SBT_TAPE 00:00:08 15-08-2019_01:16:45
List of Datafiles in backup set 3244
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
5 0 Incr 1616756 15-08-2019_01:16:37 NO /u01/app/oracle/oradata/ORCL18/simon.dbf
Backup Set Copy #1 of backup set 3244
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ ------------------- ---------- ---
SBT_TAPE 00:00:08 15-08-2019_01:16:45 YES BKP-DBF5-INC0
List of Backup Pieces for backup set 3244 Copy #1
BP Key Pc# Status Media Piece Name
------- --- ----------- ----------------------- ----------
3245 1 AVAILABLE VB$_4142545763_3227I
3250 2 AVAILABLE VB$_4142545763_3248I
3255 3 AVAILABLE VB$_4142545763_3253I
3260 4 AVAILABLE VB$_4142545763_3258I
3272 5 AVAILABLE VB$_4142545763_3270I
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
3355 Incr 1 200.00K SBT_TAPE 00:00:12 15-08-2019_01:20:14
List of Datafiles in backup set 3355
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
5 1 Incr 1616986 15-08-2019_01:20:02 NO /u01/app/oracle/oradata/ORCL18/simon.dbf
Backup Set Copy #1 of backup set 3355
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ ------------------- ---------- ---
SBT_TAPE 00:00:12 15-08-2019_01:20:14 YES BKP-DBF5-INC1
List of Backup Pieces for backup set 3355 Copy #1
BP Key Pc# Status Media Piece Name
------- --- ----------- ----------------------- ----------
3356 1 AVAILABLE VB$_4142545763_3354I
3406 2 AVAILABLE VB$_4142545763_3404I
3415 3 AVAILABLE VB$_4142545763_3413I
3424 4 AVAILABLE VB$_4142545763_3422I
3433 5 AVAILABLE VB$_4142545763_3431I
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
3359 Incr 0 132.50K SBT_TAPE 00:00:12 15-08-2019_01:20:14
List of Datafiles in backup set 3359
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
5 0 Incr 1616986 15-08-2019_01:20:02 NO /u01/app/oracle/oradata/ORCL18/simon.dbf
Backup Set Copy #1 of backup set 3359
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ ------------------- ---------- ---
SBT_TAPE 00:00:12 15-08-2019_01:20:14 YES BKP-DBF5-INC1
List of Backup Pieces for backup set 3359 Copy #1
BP Key Pc# Status Media Piece Name
------- --- ----------- ----------------------- ----------
3360 1 AVAILABLE VB$_4142545763_3354_5
3410 2 AVAILABLE VB$_4142545763_3404_5
3419 3 AVAILABLE VB$_4142545763_3413_5
3428 4 AVAILABLE VB$_4142545763_3422_5
3437 5 AVAILABLE VB$_4142545763_3431_5
RMAN>
As you can see, I created a tablespace and made backup level 0 (and 1) with section size. And after the index was created a virtual full backup, based on the incremental, for each size. This speed up the restore phase because you can parallelize it (instead if you use a single backupset). ZDLRA will “fix” if you made an incremental level 1 without section size:
RMAN> BACKUP INCREMENTAL LEVEL 1 DEVICE TYPE SBT DATAFILE 5 TAG 'BKP-DBF5-INC1';
Starting backup at 15-08-2019_01:23:17
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=00005 name=/u01/app/oracle/oradata/ORCL18/simon.dbf
channel ORA_SBT_TAPE_1: starting piece 1 at 15-08-2019_01:23:17
channel ORA_SBT_TAPE_1: finished piece 1 at 15-08-2019_01:23:18
piece handle=ORCL18_1ru97s05_1_1 tag=BKP-DBF5-INC1 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 15-08-2019_01:23:18
Starting Control File and SPFILE Autobackup at 15-08-2019_01:23:19
piece handle=c-3914023082-20190815-0a comment=API Version 2.0,MMS Version 12.2.0.2
Finished Control File and SPFILE Autobackup at 15-08-2019_01:23:26
RMAN> list backup of datafile 5 completed after "sysdate - 3/1440";
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
3572 Incr 1 40.00K SBT_TAPE 00:00:02 15-08-2019_01:23:19
BP Key: 3573 Status: AVAILABLE Compressed: YES Tag: BKP-DBF5-INC1
Handle: VB$_4142545763_3571I Media:
List of Datafiles in backup set 3572
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
5 1 Incr 1617208 15-08-2019_01:23:18 NO /u01/app/oracle/oradata/ORCL18/simon.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
3581 Incr 0 132.50K SBT_TAPE 00:00:02 15-08-2019_01:23:19
List of Datafiles in backup set 3581
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
5 0 Incr 1617208 15-08-2019_01:23:18 NO /u01/app/oracle/oradata/ORCL18/simon.dbf
Backup Set Copy #1 of backup set 3581
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ ------------------- ---------- ---
SBT_TAPE 00:00:02 15-08-2019_01:23:19 YES BKP-DBF5-INC1
List of Backup Pieces for backup set 3581 Copy #1
BP Key Pc# Status Media Piece Name
------- --- ----------- ----------------------- ----------
3582 1 AVAILABLE VB$_4142545763_3576_5
3586 2 AVAILABLE VB$_4142545763_3577_5
3590 3 AVAILABLE VB$_4142545763_3578_5
3594 4 AVAILABLE VB$_4142545763_3579_5
3598 5 AVAILABLE VB$_4142545763_3580_5
RMAN>
Look that ZDLRA opened the incremental level that was sent (without section size) index it and after that generated a level 0 (that originally was done with section size) and created a virtual full backup correctly
You can see here (Output-Full-Execution-Backup-Level-0-and-Backup-Level-1) a full execution for backup level 0, subsequent levels 1, to verify the generation of virtual full backups and the incremental forever strategy. Check the SCN, creation times for backups 0 that appear in the list after I create a backup level 1.
Virtual Full backup, Incremental forever, and Backup Strategy
Virtual full backups change completely the backup strategy for your database. The incremental forever strategy starts it the key point so save you for a lot of problems.
If you start to check your backup strategy, there are a lot of details to verify. So, what it is your backup strategy? Full every weekend plus incremental every day? What it is the load for your backup appliance? And how many times do you pass doing the backup? If you have a huge database, maybe a full every weekend it is impossible, and you need to sparse in the month (1 time per month is feasible).
But the most important, the time to recover and validate the backup? You need to restore the full (form last week as an example), and all the incremental + plus archives since that. This can be really time-consuming.
But if you can do everything with a single incremental level 1 every day? You receive a full backup, that was validated by ZDLRA, and per datafile data you have. If ZDLRA detects corrupted blocks it advises you about that. The incremental forever strategy help in other places too. The overhead over the network decrease a lot (just pass incremental). The time consumption for CPU inside of database too.
Now think the restore of the database. If you need to do one restore in the middle of the week you need to use the nearest level 0 that cover your request (probably done during the weekend) and apply some days incremental and archivelogs. For ZDLRA, you have one level 0 one day before available and just need to recover just a few archives.
The base idea here is that ZDLRA it is the only appliance that delivers to you a backup full (virtual full backup, as they call) after every incremental backup that you do. This approach is called incremental forever. And even besides that, ZDLRA it is the only one that open correctly what rman sent to you (filesperset or no, section size, compressed or no) and verifies every block of datafile inside, index it, and deliver to you a validated backupset. And as you saw, in the examples before, everything related with catalog it is done automatically by ZDLRA (backup deletion and others).
In the next post, I will show you more details about what’s happens inside of ZDLRA when it receives the incremental backup. The internal tasks and where it’s store the information about the virtual backups.
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.”
Pingback: ZDLRA Internals, INDEX_BACKUP task in details | Blog Fernando Simon
Pingback: ZDLRA, ORDERING_WAIT task state | Fernando Simon
Pingback: ZDLRA, Replication | Fernando Simon
Pingback: ZDLRA, Real-Time Redo | Fernando Simon
Pingback: ZDLRA Internals, Virtual Full Backup | Fernando Simon
Pingback: ZDLRA, Protecting Databases with Replication | Fernando Simon
Hi,
found in “RMAN best practice recommendations for backing up to the Recovery Appliance (Doc ID 2176686.1)”
that “The best practice RMAN command to implement an Incremental Strategy is
backup device type sbt cumulative incremental level 1 filesperset 1 section size 64g database plus archivelog filesperset 32 not backed up;
”
hence with the CUMULATIVE keyword. I guess that CUMULATIVE refers to VB level 0 in this case.
so is there a big difference between:
a) (daily) incr level 1 [your policy]
and
b) (daily) cumulative incr level 1 over VB [M.O.S policy]
?
regards
Noel
Hi,
Not so much, because you will heave “virtual full backup” after every incremental backup.
So, in this case (incremental level 1 or cumulative), will have the same effect because all will collect all changed blocks from the last backup. And since the last backup in the catalog is a full backup (is virtual and is always there after you sent the incremental), they are (more or less) the same, or do the same.
Best regards.
Fernando Simon
Pingback: Oracle Engineered Systems since 2010 - Fernando Simon
Hi,
thank you for all these information. I have a question regarding “ZDLRA will “fix” if you made an incremental level 1 without section size”
One of my database is quite small now, uses bigfiles for tbs, and we plan to load a quite big amount of data in it.
Let’s says I make an initial level 0 backup to ZDLRA, with a 64 GB section size (datafiles are less than 30GB today), so I expect section size will not be used for that: good.
Then I run a daily incremental level 1 backup without any section size : in that case, if files are still less than 30GB, not section size at all being used: well.
After that, I will load my database with a big amount of data (so big file tbs will grow behind 30GB), and still run incremental level 1 daily without section size: I suppose that, again, no section size will used at R.A side, right ?
So now what to do with my big database ?
1) make a new backup level 0 with a 64 GB section size ?
2) add a SECTION SIZE 64G in the incremental level 1 daily backup ?
what is the best option: 1) and/or 2) ?
thank you for any advices,
regards
Noel