ZDLRA Internals, Virtual Full Backup

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 initial 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:

Subsequent backups

If we continue to modify data in this tablespace/datafile and execute new incremental backup level 1 we can see more details. So, first, add more data and do a backup:

SQL> BEGIN
  2    FOR i IN 1 .. 300 LOOP
  3      insert into test (c1, c2) values (2, DBMS_RANDOM.STRING('P', 128));
  4
  5      if (MOD(i, 100) = 0) then
  6         commit;
  7      end if;
  8
  9    END LOOP;
 10
 11    commit;
 12  END;
 13  /

PL/SQL procedure successfully completed.

SQL>

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

Starting backup at 22-09-2019_18:34:30
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/ORCL19/simon01.dbf
channel ORA_SBT_TAPE_1: starting piece 1 at 22-09-2019_18:34:31
channel ORA_SBT_TAPE_1: finished piece 1 at 22-09-2019_18:34:32
piece handle=ORCL19_2cucduln_1_1 tag=TAG20190922T183430 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_18:34:32

Starting Control File and SPFILE Autobackup at 22-09-2019_18:34:32
piece handle=c-310627084-20190922-06 comment=API Version 2.0,MMS Version 12.2.0.2
Finished Control File and SPFILE Autobackup at 22-09-2019_18:34:36

RMAN>

And now inside of ZDLRA we have two virtual full backups and two plans (for PLANS look the number of blocks read – this is normal since I added more data above):

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
      2768    2322525       2770       2735        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
         1       2202       2768       2689                               27          1          2

SQL>

The virtual full backups have these PLAN_DETAILS:

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
      2689          1       2768          1          0       1025          1       8192      24576
      2689          1       2768          1          2       1025          2      32788        252
      2689          1       2768          1          4          1          4      33038        408
      2689          1       2768          1          8       1025         16      33040      45339
      2689          1       2768          1         71          1          3      34703        252
      2689          1       2768          1 4294967295       1025          1      78379        293

9 rows selected.

SQL>

Checking in details the last virtual full backup, VB_KEY 2768, we can see interesting things and start to understand how it’s work. So, to “mount” the virtual full backup 2768 we have:

  1. The datafile block 0 (column BLOCKNO) until block 1 (BLOCKNO+NUNBLKS) are stored at chunk 1025.
  2. The datafile block 2 (column BLOCKNO) until block 4 (BLOCKNO+NUNBLKS) are stored at chunk 1025.
  3. The datafile block 4 (column BLOCKNO) until block 8 (BLOCKNO+NUNBLKS) are stored at chunk 1 (and came from previous virtual full backup).
  4. The datafile block 8 (column BLOCKNO) until block 24 (BLOCKNO+NUNBLKS) are stored at chunk 1025.

So, the virtual full backup with VB_KEY 2768 for DF_KEY can be reconstructed following the PLANS_DETAILS. It is the image below represents the Delta Store and actual virtual full backups:

Look that ZDLRA started to save space to store the backup, being “smart” and indexing all the blocks to needed to create the virtual full backup. But the important here it is that ZDLRA understood and indexed every datafile block that was inside of backup. And the virtual full backup “does not exist”, it is basically the index for each version of the block.

If I continue to insert/delete/update some of the lines from this table I will possibly change blocks (and same blocks already created) and if I do some subsequent backups I have these plans:

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
      2768    2322525       2770       2735        128           1
      2818    2323607       2820       2779        128           1
      2874    2324062       2876       2829        128           1
      2936    2324792       2938       2885        128           1

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
         1       2202       2768       2689                               27          1          2
         1       2202       2818       2689                               27          1          3
         1       2202       2874       2689                               27          1          3
         1       2202       2936       2689                               27          1          4

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
      2689          1       2768          1          0       1025          1       8192      24576
      2689          1       2768          1          2       1025          2      32788        252
      2689          1       2768          1          4          1          4      33038        408
      2689          1       2768          1          8       1025         16      33040      45339
      2689          1       2768          1         71          1          3      34703        252
      2689          1       2768          1 4294967295       1025          1      78379        293
      2689          1       2818          1          0       2049          1       8192      24576
      2689          1       2818          1          2       1025          2      32788        252
      2689          1       2818          1          4          1          4      33038        408
      2689          1       2818          1          8       2049          1      32788        257
      2689          1       2818          1          9       1025          7      33293      36549
      2689          1       2818          1         16       2049          3      33045      17304
      2689          1       2818          1         19       1025          1      76821       1026
      2689          1       2818          1         20       2049          4      50349      29052
      2689          1       2818          1         71          1          3      34703        252
      2689          1       2818          1 4294967295       2049          1      79401        301
      2689          1       2874          1          0       3073          1       8192      24576
      2689          1       2874          1          2       1025          2      32788        252
      2689          1       2874          1          4          1          4      33038        408
      2689          1       2874          1          8       3073          1      32788        262
      2689          1       2874          1          9       1025          2      33293        347
      2689          1       2874          1         11       3073         13      33050      94555
      2689          1       2874          1         71          1          3      34703        252
      2689          1       2874          1 4294967295       3073          1     127605        296
      2689          1       2936          1          0       4097          1       8192      24576
      2689          1       2936          1          2       1025          2      32788        252
      2689          1       2936          1          4          1          4      33038        408
      2689          1       2936          1          8       3073          1      32788        262
      2689          1       2936          1          9       1025          2      33293        347
      2689          1       2936          1         11       3073         13      33050      94555
      2689          1       2936          1         71          1          3      34703        252
      2689          1       2936          1 4294967295       4097          1      32788        278

35 rows selected.

SQL>

As you can see above now I have 5 virtual full backups (2728, 2768,2818,2874, and 2936) stored in 5 chunks (1, 1025, 2049,3073,4097). In this case, if I want need to read the virtual full backup 2936 I read the PLAN_DETAILS and check that:

  1. The datafile block 0 until block 1 are stored at chunk 4097.
  2. The datafile block 2 until block 4 are stored at chunk 1025.
  3. The datafile block 4 until block 8 are stored at chunk 1.
  4. The datafile block 8 are stored at chunk 3073.
  5. The datafile block 9 until block 10 are stored at chunk 1025.
  6. The datafile block 11 until block 24 are stored at chunk 3073.

The image below represents this:

Automated Delta Pool Space Management

Since ZDLRA contains a “self-managed”  rman catalog, the backups need are managed automatically. This means that unnecessary data are deleted from time to time to avoid redundancy and to be more space-efficient. For ZDLRA this is called “automated delta pool space management”, specifically the “delta pool optimization“, to optimize the delta pool.

Internally this means that ZDLRA constantly checks the ingest backup and try to optimize the Delta Store. If I continue to change data and to do more backups we can see this in action:

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          1       2768          1          0       1025          1       8192      24576
      2689          1       2768          1          2       1025          2      32788        252
      2689          1       2768          1          4          1          4      33038        408
      2689          1       2768          1          8       1025         16      33040      45339
      2689          1       2768          1         71          1          3      34703        252
      2689          1       2768          1 4294967295       1025          1      78379        293
      2689          1       2818          1          0       2049          1       8192      24576
      2689          1       2818          1          2       1025          2      32788        252
      2689          1       2818          1          4          1          4      33038        408
      2689          1       2818          1          8       2049          1      32788        257
      2689          1       2818          1          9       1025          7      33293      36549
      2689          1       2818          1         16       2049          3      33045      17304
      2689          1       2818          1         19       1025          1      76821       1026
      2689          1       2818          1         20       2049          4      50349      29052
      2689          1       2818          1         71          1          3      34703        252
      2689          1       2818          1 4294967295       2049          1      79401        301
      2689          1       2874          1          0       3073          1       8192      24576
      2689          1       2874          1          2       1025          2      32788        252
      2689          1       2874          1          4          1          4      33038        408
      2689          1       2874          1          8       3073          1      32788        262
      2689          1       2874          1          9       1025          2      33293        347
      2689          1       2874          1         11       3073         13      33050      94555
      2689          1       2874          1         71          1          3      34703        252
      2689          1       2874          1 4294967295       3073          1     127605        296
      2689          1       2936          1          0       4097          1       8192      24576
      2689          1       2936          1          2       1025          2      32788        252
      2689          1       2936          1          4          1          4      33038        408
      2689          1       2936          1          8       3073          1      32788        262
      2689          1       2936          1          9       1025          2      33293        347
      2689          1       2936          1         11       3073         13      33050      94555
      2689          1       2936          1         71          1          3      34703        252
      2689          1       2936          1 4294967295       4097          1      32788        278
      2689          1       3002          1          0       5121          1       8192      24576
      2689          1       3002          1          2       5121          2      32788        255
      2689          1       3002          1          4          1          4      33038        408
      2689          1       3002          1          8       3073          1      32788        262
      2689          1       3002          1          9       1025          1      33293        128
      2689          1       3002          1         10       5121          1      33043        215
      2689          1       3002          1         11       3073         13      33050      94555
      2689          1       3002          1         24       5121         28      33258       4986
      2689          1       3002          1         52          1          1      34703         84
      2689          1       3002          1         56       5121          8      38244       1168
      2689          1       3002          1         72          1          1      34787         84
      2689          1       3002          1        128       5121        843      39412     125460
      2689          1       3002          1 4294967295       5121          1     164872        301

45 rows selected.

SQL>

Here, look the plan for virtual full backup 2768 (that was one of the first and already consolidated) changed. Look that for block 0 the chunk that store changed from 1 to 1025. And this occurred for other blocks (blocks 8-13 as an example), look the plans right now:

The red arrows represent the change that we can see in the PLAN_DETAILS table for VB_KEY 2728. The back arrows represent the blocks needed (from previous backups) if I want to read the virtual full backup 3002.

At the end if I do another backup we can see more evolution for space management:

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          1       2818          1          0       2049          1       8192      24576
      2689          1       2818          1          2       1025          2      32788        252
      2689          1       2818          1          4          1          4      33038        408
      2689          1       2818          1          8       2049          1      32788        257
      2689          1       2818          1          9       1025          7      33293      36549
      2689          1       2818          1         16       2049          3      33045      17304
      2689          1       2818          1         19       1025          1      76821       1026
      2689          1       2818          1         20       2049          4      50349      29052
      2689          1       2818          1         71          1          3      34703        252
      2689          1       2818          1 4294967295       2049          1      79401        301
      2689          1       2874          1          0       3073          1       8192      24576
      2689          1       2874          1          2       1025          2      32788        252
      2689          1       2874          1          4          1          4      33038        408
      2689          1       2874          1          8       3073          1      32788        262
      2689          1       2874          1          9       1025          2      33293        347
      2689          1       2874          1         11       3073         13      33050      94555
      2689          1       2874          1         71          1          3      34703        252
      2689          1       2874          1 4294967295       3073          1     127605        296
      2689          1       2936          1          0       4097          1       8192      24576
      2689          1       2936          1          2       1025          2      32788        252
      2689          1       2936          1          4          1          4      33038        408
      2689          1       2936          1          8       3073          1      32788        262
      2689          1       2936          1          9       1025          2      33293        347
      2689          1       2936          1         11       3073         13      33050      94555
      2689          1       2936          1         71          1          3      34703        252
      2689          1       2936          1 4294967295       4097          1      32788        278
      2689          1       3002          1          0       5121          1       8192      24576
      2689          1       3002          1          2       5121          2      32788        255
      2689          1       3002          1          4          1          4      33038        408
      2689          1       3002          1          8       3073          1      32788        262
      2689          1       3002          1          9       1025          1      33293        128
      2689          1       3002          1         10       5121          1      33043        215
      2689          1       3002          1         11       3073         13      33050      94555
      2689          1       3002          1         24       5121         28      33258       4986
      2689          1       3002          1         52          1          1      34703         84
      2689          1       3002          1         56       5121          8      38244       1168
      2689          1       3002          1         72          1          1      34787         84
      2689          1       3002          1        128       5121        843      39412     125460
      2689          1       3002          1 4294967295       5121          1     164872        301
      2689          1       3074          1          0       6145          1       8192      24576
      2689          1       3074          1          2       5121          2      32788        255
      2689          1       3074          1          4          1          4      33038        408
      2689          1       3074          1          8       3073          1      32788        262
      2689          1       3074          1          9       1025          1      33293        128
      2689          1       3074          1         10       5121          1      33043        215
      2689          1       3074          1         11       3073         13      33050      94555
      2689          1       3074          1         24       5121         28      33258       4986
      2689          1       3074          1         52          1          1      34703         84
      2689          1       3074          1         56       5121          8      38244       1168
      2689          1       3074          1         72          1          1      34787         84
      2689          1       3074          1        128       5121        843      39412     125460
      2689          1       3074          1 4294967295       6145          1      32788        281

52 rows selected.

SQL>

The image that represents the actual story now it is:

If you check the table and the image you can see that ZDLRA check block a block and now the block #8 for VB_KEY 2728 came from chunk 2049 (done by virtual full backup 2818). If you check with the previous report you can see that backup #8 was split from previous chunk and this information was added for VB_KEY 2728.

At the end, this means that ZDLRA optimized the delta store too, maybe, allow that chunk 1 can be deleted in the future. Probably during the INDEX_BACKUP/PLAN_DF tasks the ZDLRA checked that the block 1 it is the same that exists in others chunks and marked the existing version in chunk number 1 as obsolete.

Virtual Full Backup

This is how the virtual full backup works. Every datafile block that enters inside of ZDLRA from rman backup it is indexed and stored to create the virtual full backup. As you saw above, the idea is creating the representation for every virtual full backup of datafile (VBDF table) linking with one plan (PLANS and PLAN_DETAILS tables).

Going further, you can see that does not exist 1 to 1 relation between backup that was ingested and the virtual full backup. It is just a matrix of pointers for blocks inside chunks. This is the reason that ZDLRA it is different from other backup appliances, it can analyze block a block and index it efficiently.

 

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.”

2 thoughts on “ZDLRA Internals, Virtual Full Backup

  1. Pingback: ZDLRA, Configuring Tape Library | Fernando Simon

  2. Pingback: ZDLRA, ORDERING_WAIT task state | Fernando Simon

Leave a Reply

Your email address will not be published. Required fields are marked *