Virtual Full Backup probably is the most know feature of Oracle Zero Data Loss Recovery Appliance (ZDLRA) and you can check here how it works. In this post I will show how virtual full backup works internally and integrate INDEX_BACKUP task with tables like PLANS, PLAN_DETAILS, CHUNKS, and BLOCKS.

About the internal tables, you can check my previous post “ZDLRA Internals, Tables and Storage” where I explained details about that. To understand the INDEX_BACKUP task, check my post “ZDLRA Internals, INDEX_BACKUP task in details”. But if you know nothing and want to start reading about ZDLRA, you can check my post “Understanding ZDLRA” and check all the features and details.

The base for this article is virtual full backup and incremental forever strategy. I explained both at “ZDLRA, Virtual Full Backup and Incremental Forever” and I included hot it’s work integrated with rman backup. Basically, after an initial backup level 0, you execute just level 1 backups and ZDLRA generated a virtual backup level 0. But here, in this post, I will show you how it works in some internal details.

Database Environment

In this post, I used a new datafile with 1MB (block size of 8k) and I create a small table to load some data. After every load, I took backup for the datafile (level 1). The idea is to show how ZDLRA will index the backups, generate, and store internally the virtual full backup. The database here runs over 19c, and the ZDLRA it is running 19c version too. But, this works the same for every database version supported, and for every ZDLRA version.

Creating the tablespace, checking the datafile, and creating the table:

SQL> create tablespace simon datafile '/u01/app/oracle/oradata/ORCL19/simon01.dbf' size 1m autoextend on next 1m maxsize 10m;




Tablespace created.




SQL>

SQL> select file_id from dba_data_files where tablespace_name = 'SIMON';




   FILE_ID

----------

         5




SQL>

SQL> create table test(c1 decimal(1,0), c2 varchar2(128)) tablespace simon;




Table created.




SQL> insert into test (c1, c2) values (0, 'SIMON');




1 row created.




SQL> commit;




Commit complete.




SQL>

And after that, doing the backup level 0 for the datafile:

RMAN> list backup of datafile 5;




specification does not match any backup in the repository




RMAN> BACKUP INCREMENTAL LEVEL 0 DEVICE TYPE SBT FILESPERSET 1 DATAFILE 5;




Starting backup at 22-09-2019_17:54:27

allocated channel: ORA_SBT_TAPE_1

channel ORA_SBT_TAPE_1: SID=75 device type=SBT_TAPE

channel ORA_SBT_TAPE_1: RA Library (ZDLRAS1) SID=9327516A92A43E0DE053010310ACCB56

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/ORCL19/simon01.dbf

channel ORA_SBT_TAPE_1: starting piece 1 at 22-09-2019_17:54:28

channel ORA_SBT_TAPE_1: finished piece 1 at 22-09-2019_17:54:29

piece handle=ORCL19_2aucdsak_1_1 tag=TAG20190922T175427 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 22-09-2019_17:54:29




Starting Control File and SPFILE Autobackup at 22-09-2019_17:54:29

piece handle=c-310627084-20190922-05 comment=API Version 2.0,MMS Version 12.2.0.2

Finished Control File and SPFILE Autobackup at 22-09-2019_17:54:30




RMAN>




RMAN> list backup of datafile 5;







List of Backup Sets

===================







BS Key  Type LV Size       Device Type Elapsed Time Completion Time

------- ---- -- ---------- ----------- ------------ -------------------

2729    Incr 0  40.00K     SBT_TAPE    00:00:02     22-09-2019_17:54:30

        BP Key: 2730   Status: AVAILABLE  Compressed: YES  Tag: TAG20190922T175427

        Handle: VB$_1887643964_2728I   Media:

  List of Datafiles in backup set 2729

  File LV Type Ckp SCN    Ckp Time            Abs Fuz SCN Sparse Name

  ---- -- ---- ---------- ------------------- ----------- ------ ----

  5    0  Incr 2320763    22-09-2019_17:54:28              NO    /u01/app/oracle/oradata/ORCL19/simon01.dbf




RMAN>

So, as you can see, the tablespace SIMON was created (datafile #5). After that, the table TEST was created and some data loaded. At the end, the first backup of datafile was done and this was indexed by ZDLRA.

Basic information for database

For this database (database name ORCL19), inside internal tables of ZDLRA, we can see that have the DB_KEY as 2202 and DB_INCKEY as 2203. The DF_KEY for the datafile is 2689. This info is important to identify correctly the backups.

[oracle@zdlras1n1 ~]$ sqlplus rasys/change^Me2




SQL*Plus: Release 19.0.0.0.0 - Production on Sun Sep 22 17:53:21 2019

Version 19.3.0.0.0




Copyright (c) 1982, 2019, Oracle.  All rights reserved.




Last Successful login time: Sun Sep 22 2019 17:39:03 +02:00




Connected to:

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

Version 19.3.0.0.0




SQL> set linesize 250

SQL> select db_key, dbinc_key from rc_database where name = 'ORCL19';




    DB_KEY  DBINC_KEY

---------- ----------

      2202       2203




SQL>

SQL> select df_key, file#, ts#, create_scn, create_time, block_size, blocks from df where dbinc_key = 2203 and file# = 5;




    DF_KEY      FILE#        TS# CREATE_SCN CREATE_TI BLOCK_SIZE     BLOCKS

---------- ---------- ---------- ---------- --------- ---------- ----------

      2689          5          6    2319183 22-SEP-19       8192        128




SQL>

Virtual Full Backup and PLANS

After the backup ingests, and the task INDEX_BACKUP finished at ZDLRA, we have one virtual full backup linked with the datafile. This information came from VBDF and PLANS tables:

SQL> select vb_key, ckp_scn, vcbp_key, srcbp_key, blocks, chunks_used from vbdf where db_key = 2202 and df_key = 2689 order by vb_key asc;




    VB_KEY    CKP_SCN   VCBP_KEY  SRCBP_KEY     BLOCKS CHUNKS_USED

---------- ---------- ---------- ---------- ---------- -----------

      2728    2320763       2730       2701        128           1




SQL>

SQL> select * from plans where db_key = 2202 and df_key = 2689 order by vb_key asc;




      TYPE     DB_KEY     VB_KEY     DF_KEY    TASK_ID        OLD   BLKSREAD    MAXRANK  NUMCHUNKS   READSIZE  NEEDCHUNK  FREECHUNK

---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------

         8       2202       2728       2689                               19          1          1




SQL>

Above we can see that this virtual full backup with VB_KEY have 128 blocks (128 * 8K = 1M) and have one plan for this backup. This virtual full backup/plan has just 19 blocks (BLKSREAD) and used 1 chunk to store it (NUMCHUNKS).

But this not show how ZDLRA see the backup, the virtual full backup store the information at PLAN_DETAILS table. Reading this table we can see the foundation of virtual full backup:

SQL> select * from plans_details where df_key = 2689 order by vb_key asc, blockno asc;




    DF_KEY       TYPE     VB_KEY    BLKRANK    BLOCKNO    CHUNKNO    NUMBLKS    COFFSET   NUMBYTES

---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------

      2689          8       2728          1          0          1          1       8192      24576

      2689          8       2728          1          2          1         17      32788       2167

      2689          8       2728          1 4294967295          1          1      34955        294




SQL>

Let’s explain what this means:

1. The datafile block 0 (column BLOCKNO) until block 1 (BLOCKNO+NUNBLKS) are stored at chunk 1.

2. The datafile block 2 (column BLOCKNO) until block 19 (BLOCKNO+NUNBLKS) are stored at chunk 1

3. The datafile block 4294967295 (the last block of datafile) is stored at chunks 1.

To show this I created the schema below. This represents the first 13 blocks of the virtual full backup and will help to visualize the virtual full backup next. So, the virtual full backup with VB_KEY 2728 can be reconstructed following the PLANS_DETAILS as: