{"id":569,"date":"2019-08-29T05:11:26","date_gmt":"2019-08-29T08:11:26","guid":{"rendered":"http:\/\/www.fernandosimon.com\/blog\/?p=569"},"modified":"2020-07-19T19:17:10","modified_gmt":"2020-07-19T22:17:10","slug":"zdlra-internals-index_backup-task-in-details","status":"publish","type":"post","link":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/","title":{"rendered":"ZDLRA Internals, INDEX_BACKUP task in details"},"content":{"rendered":"<p style=\"text-align: justify;\">For ZDLRA, the task type INDEX_BACKUP it is important (if it is not the most) because it is responsible to create the virtual full backup. This task runs for every backup that you ingest at ZDLRA and here, I will show with more details what occurs at ZDLRA: internals steps, phases, and tables involved.<\/p>\n<p style=\"text-align: justify;\">I recommend that you check my previous post about ZDLRA: <a href=\"http:\/\/www.fernandosimon.com\/blog\/zdlra-internals-tables-and-storage\/\" target=\"_blank\" rel=\"noopener noreferrer\">ZDLRA Internals, Tables and Storage<\/a>, <a href=\"http:\/\/www.fernandosimon.com\/blog\/zdlra-virtual-full-backup-and-incremental-forever\/\" target=\"_blank\" rel=\"noopener noreferrer\">ZDLRA, Virtual Full Backup and Incremental Forever<\/a>, and <a href=\"http:\/\/www.fernandosimon.com\/blog\/understanding-zdlra\/\" target=\"_blank\" rel=\"noopener noreferrer\">Understanding ZDLRA<\/a>. They provide a good base to understand some aspects of ZDLRA architecture and features.<\/p>\n<h2 style=\"text-align: justify;\">Backup<\/h2>\n<p style=\"text-align: justify;\">As you saw in my previous post, ZDLRA opens every backup that you sent and read every block of it to generate one new virtual full backup. And this backup is validated block a block (physically and logically) against corruption. It differs from a snapshot because it is content-aware (in this case it is proprietary Oracle datafile blocks inside another proprietary Oracle rman block) and Oracle it is the only that can do this guaranteeing that result is valid.<\/p>\n<p style=\"text-align: justify;\"><!--more Click here to read more...--><\/p>\n<p style=\"text-align: justify;\">This generation is done thought INDEX_BACKUP task and occurs for every backup (level 0 or 1) that enter in the system. For this post, I already have a full backup level 0 inside ZDLRA and I made one new incremental level 1:<\/p>\n<pre class=\"EnlighterJSRAW \" data-enlighter-language=\"no-highlight\">RMAN&gt; run{\r\n2&gt; backup device type sbt cumulative incremental level 1 filesperset 1 datafile 29;\r\n3&gt; }\r\n\r\nStarting backup at 2019-08-16_15-01-11\r\nallocated channel: ORA_SBT_TAPE_1\r\nchannel ORA_SBT_TAPE_1: SID=406 instance=SIMON1 device type=SBT_TAPE\r\nchannel ORA_SBT_TAPE_1: RA Library (ZDLRA) SID=903C95C93085DC14E0531E43B20AB30F\r\nallocated channel: ORA_SBT_TAPE_2\r\nchannel ORA_SBT_TAPE_2: SID=451 instance=SIMON1 device type=SBT_TAPE\r\nchannel ORA_SBT_TAPE_2: RA Library (ZDLRA) SID=903C95D1C201DC19E0531E43B20A4C44\r\nallocated channel: ORA_SBT_TAPE_3\r\nchannel ORA_SBT_TAPE_3: SID=502 instance=SIMON1 device type=SBT_TAPE\r\nchannel ORA_SBT_TAPE_3: RA Library (ZDLRA) SID=903C95E1BFD9DC38E0531E43B20A0038\r\nallocated channel: ORA_SBT_TAPE_4\r\nchannel ORA_SBT_TAPE_4: SID=651 instance=SIMON1 device type=SBT_TAPE\r\nchannel ORA_SBT_TAPE_4: RA Library (ZDLRA) SID=903C95EAC1ACDC48E0531E43B20AC79D\r\nchannel ORA_SBT_TAPE_1: starting incremental level 1 datafile backup set\r\nchannel ORA_SBT_TAPE_1: specifying datafile(s) in backup set\r\ninput datafile file number=00029 name=+DATAC1\/simon_x6s\/datafile\/simontsthistoric1_tbs.399.938192975\r\nchannel ORA_SBT_TAPE_1: starting piece 1 at 2019-08-16_15-01-25\r\nchannel ORA_SBT_TAPE_1: finished piece 1 at 2019-08-16_15-03-10\r\npiece handle=SIMON_s0u9c0a5_1_1 tag=TAG20190816T150116 comment=API Version 2.0,MMS Version 3.17.1.26\r\nchannel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:01:45\r\nFinished backup at 2019-08-16_15-03-10\r\n\r\nStarting Control File and SPFILE Autobackup at 2019-08-16_15-03-11\r\npiece handle=c-4165931009-20190816-06 comment=API Version 2.0,MMS Version 3.17.1.26\r\nFinished Control File and SPFILE Autobackup at 2019-08-16_15-03-18\r\n\r\nRMAN&gt;<\/pre>\n<p style=\"text-align: justify;\">As you can see, it is a normal backup. And the details for this backup:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">RMAN&gt; list backupset 52141830;\r\n\r\n\r\nList of Backup Sets\r\n===================\r\n\r\n\r\nBS Key  Type LV Size       Device Type Elapsed Time Completion Time\r\n------- ---- -- ---------- ----------- ------------ -------------------\r\n52141830 Incr 1  30.75M     SBT_TAPE    00:01:44     2019-08-16_15-03-09\r\n        BP Key: 52141831   Status: AVAILABLE  Compressed: NO  Tag: TAG20190816T150116\r\n        Handle: SIMON_s0u9c0a5_1_1   Media: Recovery Appliance (ZDLRA)\r\n  List of Datafiles in backup set 52141830\r\n  File LV Type Ckp SCN    Ckp Time            Name\r\n  ---- -- ---- ---------- ------------------- ----\r\n  29   1  Incr 4932560891039 2019-08-16_15-01-25 +DATAC1\/simon_x6s\/datafile\/simontsthistoric1_tbs.399.938192975\r\n\r\nRMAN&gt;\r\n\r\nRMAN&gt; list backup tag = 'TAG20190816T150116';\r\n\r\n\r\nList of Backup Sets\r\n===================\r\n\r\n\r\nBS Key  Type LV Size       Device Type Elapsed Time Completion Time\r\n------- ---- -- ---------- ----------- ------------ -------------------\r\n52141830 Incr 1  30.75M     SBT_TAPE    00:01:44     2019-08-16_15-03-09\r\n        BP Key: 52141831   Status: AVAILABLE  Compressed: NO  Tag: TAG20190816T150116\r\n        Handle: SIMON_s0u9c0a5_1_1   Media: Recovery Appliance (ZDLRA)\r\n  List of Datafiles in backup set 52141830\r\n  File LV Type Ckp SCN    Ckp Time            Name\r\n  ---- -- ---- ---------- ------------------- ----\r\n  29   1  Incr 4932560891039 2019-08-16_15-01-25 +DATAC1\/simon_x6s\/datafile\/simontsthistoric1_tbs.399.938192975\r\n\r\nRMAN&gt;<\/pre>\n<p style=\"text-align: justify;\">Here it is important to remember the TAG, backupset(BS)\/backup piece (BP) numbers, and the SCN for the backup made.<\/p>\n<h2 style=\"text-align: justify;\">INDEX_BACKUP<\/h2>\n<p style=\"text-align: justify;\">The INDEX_BACKUP appears as a single task inside ZDLRA, but have two major phases: <em>fixup_unordered<\/em> and <em>q_restore_fast<\/em>. And each one impacts differently inside the rman catalog and in the internal tables.<\/p>\n<p style=\"text-align: justify;\">So, after the backup finish, inside of ZDLRA we can see the index task running:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; l\r\n  1  SELECT s.ba_session_id, s.instance_id, s.sid, s.serial#, s.job_name\r\n  2         , rt.task_id, rt.DB_KEY, rt.db_unique_name, rt.task_type, rt.state, rt.waiting_on\r\n  3         , rt.elapsed_seconds\r\n  4         , gs.module, gs.sql_id, gs.action\r\n  5         , rt.BP_KEY, rt.bs_key, rt.df_key, rt.vb_key\r\n  6  FROM sessions s\r\n  7  JOIN ra_task rt\r\n  8  ON rt.task_id = s.current_task\r\n  9  AND rt.task_type = 'INDEX_BACKUP'\r\n 10  JOIN gv$session gs\r\n 11  ON gs.inst_id = s.instance_id\r\n 12  AND gs.sid = s.sid\r\n 13  AND gs.serial# = s.serial#\r\n 14* ORDER BY rt.LAST_EXECUTE_TIME DESC\r\nSQL&gt; \/\r\n\r\nBA_SESSION_ID INSTANCE_ID    SID    SERIAL# JOB_NAME              TASK_ID     DB_KEY DB_UNIQUE_NAME  TASK_TYPE       STATE    WAITING_ON ELAPSED_SECONDS MODULE           SQL_ID        ACTION            BP_KEY     BS_KEY     DF_KEY     VB_KEY\r\n------------- ----------- ------ ---------- ------------------ ---------- ---------- --------------- --------------- -------- ---------- --------------- ---------------- ------------- ------------- ---------- ---------- ---------- ----------\r\n     56215535           2   4228      30075 RA$_EXEC_56216288    56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING                  345.305895 fixup_unordered  1q0zr86n25pvu scan 6% done    52141831\r\n\r\nSQL&gt;<\/pre>\n<p style=\"text-align: justify;\">With this SQL you can check all the INDEX_BACKUP tasks running at ZDLRA. And the SQL use the tables and report:<\/p>\n<ul style=\"text-align: justify;\">\n<li><strong>RA_TASK<\/strong>: All tasks running inside ZDLRA.<\/li>\n<li><strong>SESSIONS<\/strong>: Sessions running inside ZDLRA, used to get the database session running the task<\/li>\n<li><strong>GV$SESSION<\/strong>: Databases sessions, used to get the sql_id and others info<\/li>\n<li><strong>BP_KEY<\/strong>: Identify the backup piece key that it is indexing. It is the start point to identify everything here.<\/li>\n<\/ul>\n<p style=\"text-align: justify;\">Above you can see that task 56242962 is running, processing the BP_KEY (backup piece key) 52141831, running the module <em>fixup_unordered<\/em>, processed 6% of this step, and running SQL_ID 1q0zr86n25pvu.<\/p>\n<h2 style=\"text-align: justify;\">INDEX_BACKUP, fixup_unordered<\/h2>\n<p style=\"text-align: justify;\">As showed, the index task is running the <em>fixup_unordered <\/em>module, and thus represents the first phase where ZDLRA it is checking all the blocks that are necessary to build the virtual full backup. Based on the report from the query above we can see that BP_KEY processed it is 52141831 and we can get more info from backup piece rman table:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; select bp_key, bs_key, tag, handle, bytes\/1024\/1024\/1024 from bp where bp_key = 52141831;\r\n\r\n    BP_KEY     BS_KEY TAG                              HANDLE               BYTES\/1024\/1024\/1024\r\n---------- ---------- -------------------------------- -------------------- --------------------\r\n  52141831   52141830 TAG20190816T150116               SIMON_s0u9c0a5_1_1             .030029297\r\n\r\nSQL&gt;\r\nSQL&gt; select bs_key, INCREMENTAL_LEVEL, HANDLE from rc_backup_piece where bp_key = 52141831;\r\n\r\n    BS_KEY INCREMENTAL_LEVEL HANDLE\r\n---------- ----------------- --------------------\r\n  52141830                 1 SIMON_s0u9c0a5_1_1\r\n\r\nSQL&gt;\r\n<\/pre>\n<p style=\"text-align: justify;\">This tells us that the task it is processing the backup that we made before (look the result of column BP_KEY from SQL in the first topic). The BP, and rc_backup_piece are the tables from rman catalog that store info about the backup pieces, check the handle and tag to compare from rman list output.<\/p>\n<p style=\"text-align: justify;\">Going further we can check the VBDF (virtual backup data file table \u2013 store the virtual full backups information) table and verify more details:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; SELECT vb_key, ckp_id, df_key, db_key, blocks, vcbp_key, srcbp_key, file#, ckp_scn FROM VBDF WHERE srcbp_key = 52141831;\r\n\r\n    VB_KEY         CKP_ID     DF_KEY     DB_KEY     BLOCKS   VCBP_KEY  SRCBP_KEY      FILE#        CKP_SCN\r\n---------- -------------- ---------- ---------- ---------- ---------- ---------- ---------- --------------\r\n  52141864  4932560891039     752220     752186 1655177216              52141831         29  4932560891039\r\n\r\nSQL&gt;<\/pre>\n<p style=\"text-align: justify;\">At VBDF table we can discover:<\/p>\n<ul style=\"text-align: justify;\">\n<li><strong>VB_KEY<\/strong>: Virtual backup key.<\/li>\n<li><strong>CKP_ID<\/strong>: Checkpoint and SCN for this virtual backup.<\/li>\n<li><strong>BLOCKS<\/strong>: Number of the blocks for this virtual backup.<\/li>\n<li><strong>VCBP_KEY<\/strong>: Is null at <em>fixup_unordered <\/em>because the virtual backup piece (VCBP) was not yet generated (it is doing by <em>fixup_unordered<\/em>). This will change in the future and I will show more details.<\/li>\n<li><strong>SRCBP_KEY<\/strong>: The source\/original backup piece used to create this virtual full backup.<\/li>\n<\/ul>\n<p style=\"text-align: justify;\">So, we can check that the backu is in the middle of the index the process since the VCBP_KEY is not yet available. But besides that, we can validate\/check more details about the backups.<\/p>\n<p style=\"text-align: justify;\">Check that does not exist a backup piece associated with this virtual backup key:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; select bp_key, bs_key, tag, handle, bytes\/1024\/1024\/1024, vb_key from bp where vb_key = 52141864;\r\n\r\nno rows selected\r\n\r\nSQL&gt;<\/pre>\n<p style=\"text-align: justify;\">And that exists just one backup of datafile for this SCN and FILE#:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; SELECT bdf_key, bs_key, file#, ckp_scn, incr_level from bdf where CKP_SCN = 4932560891039 and file# = 29;\r\n\r\n   BDF_KEY     BS_KEY      FILE#        CKP_SCN INCR_LEVEL\r\n---------- ---------- ---------- -------------- ----------\r\n  52141832   52141830         29  4932560891039          1\r\n\r\nSQL&gt;\r\nSQL&gt; SELECT db_key, bdf_key, file#, CHECKPOINT_CHANGE#, incremental_level from rc_backup_datafile where bs_key IN(52141830);\r\n\r\n    DB_KEY    BDF_KEY      FILE# CHECKPOINT_CHANGE# INCREMENTAL_LEVEL\r\n---------- ---------- ---------- ------------------ -----------------\r\n    752186   52141832         29      4932560891039                 1\r\n\r\nSQL&gt; SELECT db_key, bdf_key, file#, CHECKPOINT_CHANGE#, incremental_level from rc_backup_datafile where CHECKPOINT_CHANGE# = 4932560891039;\r\n\r\n    DB_KEY    BDF_KEY      FILE# CHECKPOINT_CHANGE# INCREMENTAL_LEVEL\r\n---------- ---------- ---------- ------------------ -----------------\r\n    752186   52141832         29      4932560891039                 1\r\n\r\nSQL&gt;<\/pre>\n<p style=\"text-align: justify;\">Digging more, we can see that are <strong>zero plans<\/strong> for this virtual backup (will be zero until <em>fixup_unordered<\/em> finish \u2013 more detail further):<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; select count(*) from plans where VB_KEY = 52141864;\r\n\r\n  COUNT(*)\r\n----------\r\n         0\r\n\r\nSQL&gt;<\/pre>\n<p style=\"text-align: justify;\">During this phase of INDEX_BACKUP, the major SQL_ID is <em>1q0zr86n25pvu<\/em>:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; select sql_fulltext from gv$sqlarea where inst_id = 2 and sql_id = '1q0zr86n25pvu';\r\n\r\nSQL_FULLTEXT\r\n----------------------------------------------------------------------------------------------------\r\nSELECT * FROM (SELECT \/*+\r\n                     QB_NAME(c)\r\n                     INDEX_RS_ASC(@c b@c)\r\n                     NO_INDEX_FFS(@c b@c)\r\n                     NO_INDEX_SS(@c b@c)\r\n                     OPT_PARAM('optimizer_dynamic_sampling' 0)\r\n                     OPT_PARAM('_optimizer_adaptive_cursor_sharing' 'false')\r\n                     OPT_PARAM('_optimizer_extended_cursor_sharing_rel' 'none')\r\n                     OPT_PARAM('_optimizer_use_feedback' 'false')\r\n                    *\/ BLOCKNO, SCN, CKP_ID, ENDBLK, CHUNKNO, COFFSET FROM BLOCKS B WHERE DF_KEY = :\r\nB4 AND BLOCKNO BETWEEN :B3 AND :B2 AND SCN &lt; :B1 ORDER BY BLOCKNO, SCN, CKP_ID ) WHERE ROWNUM &lt; :B5\r\n\r\nSQL&gt;<\/pre>\n<p style=\"text-align: justify;\">And the bind variables in this case are:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; l\r\n  1  SELECT s.ba_session_id, s.instance_id\r\n  2  , rt.task_id, rt.DB_KEY, rt.db_unique_name, rt.task_type, rt.state\r\n  3  , gs.module, gs.sql_id, gs.action\r\n  4  , rt.BP_KEY, rt.bs_key, rt.df_key, rt.vb_key\r\n  5  , sbc.name, sbc.value_string\r\n  6  FROM sessions s\r\n  7  JOIN ra_task rt\r\n  8  ON rt.task_id = s.current_task\r\n  9  AND RT.TASK_ID = 56242962\r\n 10  JOIN gv$session gs\r\n 11  ON gs.inst_id = s.instance_id\r\n 12  AND gs.sid = s.sid\r\n 13  AND gs.serial# = s.serial#\r\n 14  join gv$sql_bind_capture sbc\r\n 15  on sbc.inst_id = gs.inst_id\r\n 16  and sbc.sql_id = gs.sql_id\r\n 17* ORDER BY rt.LAST_EXECUTE_TIME DESC\r\nSQL&gt;\r\nSQL&gt; \/\r\n\r\nBA_SESSION_ID INSTANCE_ID    TASK_ID     DB_KEY DB_UNIQUE_NAME       TASK_TYPE       STATE           MODULE           SQL_ID        ACTION              BP_KEY     BS_KEY     DF_KEY     VB_KEY NAME  VALUE_STRING\r\n------------- ----------- ---------- ---------- -------------------- --------------- --------------- ---------------- ------------- --------------- ---------- ---------- ---------- ---------- ----- ---------------\r\n     56215535           2   56242962     752186 SIMON_X6S            INDEX_BACKUP    RUNNING         fixup_unordered  1q0zr86n25pvu scan 21% done     52141831                                  :B4   752220\r\n     56215535           2   56242962     752186 SIMON_X6S            INDEX_BACKUP    RUNNING         fixup_unordered  1q0zr86n25pvu scan 21% done     52141831                                  :B3   302875642\r\n     56215535           2   56242962     752186 SIMON_X6S            INDEX_BACKUP    RUNNING         fixup_unordered  1q0zr86n25pvu scan 21% done     52141831                                  :B2   1655177216\r\n     56215535           2   56242962     752186 SIMON_X6S            INDEX_BACKUP    RUNNING         fixup_unordered  1q0zr86n25pvu scan 21% done     52141831                                  :B1   4932554641877\r\n     56215535           2   56242962     752186 SIMON_X6S            INDEX_BACKUP    RUNNING         fixup_unordered  1q0zr86n25pvu scan 21% done     52141831                                  :B5   1048576\r\n\r\nSQL&gt;\r\n<\/pre>\n<p style=\"text-align: justify;\">Explaining a little. So, based on the SQL text and variables we can see that is retrieving from BLOCKS table all the blocks for the DF_KEY 752220 (you can get it in VBDF), that are between 302875642 (actual block of processing) and 1655177216 (max number of blocks for the ingested backup), and have SCN bellow 4932554641877 (from the ingested backup) and process this in package of 1048576 blocks. One information here it is that the number 302875642 will vary while it is running this phase.<\/p>\n<p style=\"text-align: justify;\">So, the idea here for ZDLRA index task is processing get\/check all the blocks that have SCN below of the SCN from ingested backup. And since the INDEX_BACKUP result creates one virtual full backup, all the blocks for this datafile need to be processed.<\/p>\n<p style=\"text-align: justify;\">If you check this query time to time, you will see the increase of scan % increasing until the :B3 and :B4 are equal (compare with the previous execution):<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; \/\r\n\r\nBA_SESSION_ID INSTANCE_ID    TASK_ID     DB_KEY DB_UNIQUE_NAME       TASK_TYPE       STATE           MODULE           SQL_ID        ACTION             BP_KEY     BS_KEY     DF_KEY     VB_KEY NAME  VALUE_STRING\r\n------------- ----------- ---------- ---------- -------------------- --------------- --------------- ---------------- ------------- -------------- ---------- ---------- ---------- ---------- ----- ---------------\r\n     56215535           2   56242962     752186 SIMON_X6S            INDEX_BACKUP    RUNNING         fixup_unordered  1q0zr86n25pvu scan 99% done    52141831                                  :B4   752220\r\n     56215535           2   56242962     752186 SIMON_X6S            INDEX_BACKUP    RUNNING         fixup_unordered  1q0zr86n25pvu scan 99% done    52141831                                  :B3   1641637658\r\n     56215535           2   56242962     752186 SIMON_X6S            INDEX_BACKUP    RUNNING         fixup_unordered  1q0zr86n25pvu scan 99% done    52141831                                  :B2   1655177216\r\n     56215535           2   56242962     752186 SIMON_X6S            INDEX_BACKUP    RUNNING         fixup_unordered  1q0zr86n25pvu scan 99% done    52141831                                  :B1   4932554641877\r\n     56215535           2   56242962     752186 SIMON_X6S            INDEX_BACKUP    RUNNING         fixup_unordered  1q0zr86n25pvu scan 99% done    52141831                                  :B5   1048576\r\n\r\nSQL&gt; select rt.elapsed_seconds from ra_task rt where task_id = 56242962;\r\n\r\nELAPSED_SECONDS\r\n---------------\r\n     6618.53526\r\n\r\nSQL&gt;<\/pre>\n<p style=\"text-align: justify;\">After this hit 100% the next phase of the INDEX_BAKUP (<em>q_restore_fast<\/em>) will start. The phase <em>fixup_unordered<\/em> depends on the size of your datafile and not from the ingested backup. In this example, the backup has just 30MB, but the datafile has more than 16TB, so, the virtual full will have the same size and this takes a lot of time reading all the blocks. For you ZDLRA the DF_KEY, BS_KEY, and others will be different. Just remember that BP_KEY for the index task it is the start point for the analyses.<\/p>\n<h2 style=\"text-align: justify;\">INDEX_BACKUP, q_restore_fast<\/h2>\n<p style=\"text-align: justify;\">After the <em>fixup_unordered<\/em> reach 100% of the scan, the phase <em>q_restore_fast<\/em> starts and this will create the virtual backup itself. But before let\u2019s see what\u2019s happened at rman catalog after the previous phase finished:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">##########################################################\r\nThis is list took right after the backup finished:\r\nRMAN&gt; list backup tag = 'TAG20190816T150116';\r\n\r\n\r\nList of Backup Sets\r\n===================\r\n\r\n\r\nBS Key  Type LV Size       Device Type Elapsed Time Completion Time\r\n------- ---- -- ---------- ----------- ------------ -------------------\r\n52141830 Incr 1  30.75M     SBT_TAPE    00:01:44     2019-08-16_15-03-09\r\n        BP Key: 52141831   Status: AVAILABLE  Compressed: NO  Tag: TAG20190816T150116\r\n        Handle: SIMON_s0u9c0a5_1_1   Media: Recovery Appliance (ZDLRA)\r\n  List of Datafiles in backup set 52141830\r\n  File LV Type Ckp SCN    Ckp Time            Name\r\n  ---- -- ---- ---------- ------------------- ----\r\n  29   1  Incr 4932560891039 2019-08-16_15-01-25 +DATAC1\/simon_x6s\/datafile\/simontsthistoric1_tbs.399.938192975\r\n\r\nRMAN&gt;\r\n##########################################################\r\nAnd now after the fixup_unordered finish:\r\nRMAN&gt; list backup tag = 'TAG20190816T150116';\r\n\r\n\r\nList of Backup Sets\r\n===================\r\n\r\n\r\nBS Key  Type LV Size       Device Type Elapsed Time Completion Time\r\n------- ---- -- ---------- ----------- ------------ -------------------\r\n52146235 Incr 1  28.00M     SBT_TAPE    00:01:44     2019-08-16_15-03-09\r\n        BP Key: 52146236   Status: AVAILABLE  Compressed: YES  Tag: TAG20190816T150116\r\n        Handle: VB$_90959062_52141864I   Media:\r\n  List of Datafiles in backup set 52146235\r\n  File LV Type Ckp SCN    Ckp Time            Name\r\n  ---- -- ---- ---------- ------------------- ----\r\n  29   1  Incr 4932560891039 2019-08-16_15-01-25 +DATAC1\/simon_x6s\/datafile\/simontsthistoric1_tbs.399.938192975\r\n\r\nRMAN&gt;<\/pre>\n<p style=\"text-align: justify;\">As you can see, the backupset (52141830 before, and 52146235 now) and backup piece changed (the handle changed too). But look that TAG and SCN remains the same. This means that a new backup was created because ZDLRA scanned the original backup. But as you can see, the virtual full was not created yet (there is any level 0 available in the list). If you see this in your ZDLRA, that means that INDEX_BACKUP task is in process.<\/p>\n<p style=\"text-align: justify;\">If we continue to check more details and use the same query than before, we can see that backup changed the BS_KEY and BP_KEY in the internal tables (look that old keys disappears):<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; select bs_key, INCREMENTAL_LEVEL, HANDLE from rc_backup_piece where bp_key = 52141831;\r\n\r\nno rows selected\r\n\r\nSQL&gt; select bp_key, bs_key, tag, handle, bytes\/1024\/1024\/1024, vb_key from bp where bp_key = 52141831;\r\n\r\nno rows selected\r\n\r\nSQL&gt; select bp_key, bs_key, tag, handle, bytes\/1024\/1024\/1024 from bp where tag = 'TAG20190816T150116';\r\n                                         \r\n    BP_KEY     BS_KEY TAG                 HANDLE                  BYTES\/1024\/1024\/1024\r\n---------- ---------- ------------------- ----------------------- --------------------\r\n  52146236   52146235 TAG20190816T150116  VB$_90959062_52141864I             .02734375\r\n                                                                 \r\nSQL&gt;<\/pre>\n<p style=\"text-align: justify;\">And now, checking in the VBDF table we can see that info at VCBP_KEY column appears:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; SELECT vb_key, ckp_id, df_key, db_key, blocks, vcbp_key, srcbp_key, file#, ckp_scn FROM VBDF WHERE srcbp_key = 52141831;\r\n\r\n    VB_KEY         CKP_ID     DF_KEY     DB_KEY     BLOCKS   VCBP_KEY  SRCBP_KEY      FILE#        CKP_SCN\r\n---------- -------------- ---------- ---------- ---------- ---------- ---------- ---------- --------------\r\n  52141864  4932560891039     752220     752186 1655177216   52146236   52141831         29  4932560891039\r\n\r\nSQL&gt;<\/pre>\n<p style=\"text-align: justify;\">And if you search now at backup piece table you can see that exists one listed for this virtual backup key (check in the topic before that this info does not exist):<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; select bp_key, bs_key, tag, handle, bytes\/1024\/1024\/1024, vb_key from bp where vb_key = 52141864;\r\n\r\n    BP_KEY     BS_KEY TAG                 HANDLE                  BYTES\/1024\/1024\/1024     VB_KEY\r\n---------- ---------- ------------------- ----------------------- -------------------- ----------\r\n  52146236   52146235 TAG20190816T150116  VB$_90959062_52141864I             .02734375   52141864\r\n\r\nSQL&gt;<\/pre>\n<p style=\"text-align: justify;\">And check that exists just one backup of this datafile at this SCN:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; SELECT bdf_key, bs_key, file#, ckp_scn, incr_level from bdf where CKP_SCN = 4932560891039 and file# = 29;\r\n\r\n   BDF_KEY     BS_KEY      FILE#        CKP_SCN INCR_LEVEL\r\n---------- ---------- ---------- -------------- ----------\r\n  52146237   52146235         29  4932560891039          1\r\n\r\nSQL&gt;\r\n<\/pre>\n<p style=\"text-align: justify;\">In this phase, you can see that the details for index and virtual full backup starts to appear internally. If you check, now you have plans for this virtual full backup:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; select count(*) from plans where VB_KEY = 52141864;\r\n\r\n  COUNT(*)\r\n----------\r\n         1\r\n\r\nSQL&gt;\r\nSQL&gt; select count(*), to_char(sysdate, 'HH24:MI') as time from plans_details where VB_KEY = 52141864;\r\n\r\n  COUNT(*) TIME\r\n---------- -----\r\n   2294010 18:25\r\n\r\nSQL&gt; select count(*), to_char(sysdate, 'HH24:MI') as time from plans_details where VB_KEY = 52141864;\r\n\r\n  COUNT(*) TIME\r\n---------- -----\r\n   5773720 18:43\r\n\r\nSQL&gt;<\/pre>\n<p style=\"text-align: justify;\">As you can see above, the plans_details for this virtual backup is increasing from time to time. This means that the <em>q_restore_fast<\/em> is running and it is reading blocks to create the virtual full backup\/index (and inserting at plan_details).<\/p>\n<p style=\"text-align: justify;\">We can figure out this, while the INDEX_BACKUP task is running, checking the sql_id for the session. While the task is running, we have three major sql\u2019s (I used the same query than before \u2013 where we checked the bind for the session\/task):<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; \/\r\n\r\nBA_SESSION_ID INSTANCE_ID    TASK_ID     DB_KEY DB_UNIQUE_NAME  TASK_TYPE       STATE    MODULE          SQL_ID        ACTION                   BP_KEY     BS_KEY     DF_KEY     VB_KEY NAME  VALUE_STRING\r\n------------- ----------- ---------- ---------- --------------- --------------- -------- --------------- ------------- -------------------- ---------- ---------- ---------- ---------- ----- ---------------\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  9ma189ab8x9c7 plan 0% done           52141831                                  :B1\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  9ma189ab8x9c7 plan 0% done           52141831                                  :B12\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  9ma189ab8x9c7 plan 0% done           52141831                                  :B2\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  9ma189ab8x9c7 plan 0% done           52141831                                  :B1\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  9ma189ab8x9c7 plan 0% done           52141831                                  :B2\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  9ma189ab8x9c7 plan 0% done           52141831                                  :B3\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  9ma189ab8x9c7 plan 0% done           52141831                                  :B4\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  9ma189ab8x9c7 plan 0% done           52141831                                  :B1   752220\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  9ma189ab8x9c7 plan 0% done           52141831                                  :B3   1\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  9ma189ab8x9c7 plan 0% done           52141831                                  :B4   1051071\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  9ma189ab8x9c7 plan 0% done           52141831                                  :B11  0\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  9ma189ab8x9c7 plan 0% done           52141831                                  :B10  4931849117847\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  9ma189ab8x9c7 plan 0% done           52141831                                  :B9   4931848304742\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  9ma189ab8x9c7 plan 0% done           52141831                                  :B8   4932554641877\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  9ma189ab8x9c7 plan 0% done           52141831                                  :B7   752187\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  9ma189ab8x9c7 plan 0% done           52141831                                  :B6   4932554641877\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  9ma189ab8x9c7 plan 0% done           52141831                                  :B5   4932554641877\r\n                                                                                                        \r\n17 rows selected.                                                                                       \r\n                                                                                                        \r\nSQL&gt;                                                                                                    \r\nSQL&gt; \/                                                                                                  \r\n                                                                                                        \r\nBA_SESSION_ID INSTANCE_ID    TASK_ID     DB_KEY DB_UNIQUE_NAME  TASK_TYPE       STATE    MODULE          SQL_ID        ACTION                   BP_KEY     BS_KEY     DF_KEY     VB_KEY NAME  VALUE_STRING\r\n------------- ----------- ---------- ---------- --------------- --------------- -------- --------------- ------------- -------------------- ---------- ---------- ---------- ---------- ----- ---------------\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  brt6uuhzacdnu plan 54% done          52141831                                  :B1   752220\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  brt6uuhzacdnu plan 54% done          52141831                                  :B3   403380104\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  brt6uuhzacdnu plan 54% done          52141831                                  :B4   404440007\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  brt6uuhzacdnu plan 54% done          52141831                                  :B11  0\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  brt6uuhzacdnu plan 54% done          52141831                                  :B10  4931849117847\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  brt6uuhzacdnu plan 54% done          52141831                                  :B9   4931848304742\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  brt6uuhzacdnu plan 54% done          52141831                                  :B8   4932554641877\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  brt6uuhzacdnu plan 54% done          52141831                                  :B7   752187\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  brt6uuhzacdnu plan 54% done          52141831                                  :B6   4932554641877\r\n     56215535           2   56242962     752186 SIMON_X6S       INDEX_BACKUP    RUNNING  q_restore_fast  brt6uuhzacdnu plan 54% done          52141831                                  :B5   4932554641877\r\n\r\n10 rows selected.\r\n\r\nSQL&gt;\r\nSQL&gt; \/\r\n\r\nBA_SESSION_ID INSTANCE_ID    TASK_ID     DB_KEY DB_UNIQUE_NAME  TASK_TYPE       STATE      MODULE          SQL_ID        ACTION             BP_KEY     BS_KEY     DF_KEY     VB_KEY NAME  VALUE_STRING\r\n------------- ----------- ---------- ---------- --------------- --------------- ---------- --------------- ------------- -------------- ---------- ---------- ---------- ---------- ----- --------------\r\n     56215535           2   56242962     477602 SIMON_X6S       INDEX_BACKUP    RUNNING    q_restore_fast  8t81c0j1w9jqu plan 89% done    41032043                                  :B1\r\n     56215535           2   56242962     477602 SIMON_X6S       INDEX_BACKUP    RUNNING    q_restore_fast  8t81c0j1w9jqu plan 89% done    41032043                                  :B3   752220\r\n     56215535           2   56242962     477602 SIMON_X6S       INDEX_BACKUP    RUNNING    q_restore_fast  8t81c0j1w9jqu plan 89% done    41032043                                  :B2   \u202d4389973931270\r\n     56215535           2   56242962     477602 SIMON_X6S       INDEX_BACKUP    RUNNING    q_restore_fast  8t81c0j1w9jqu plan 89% done    41032043                                  :B1   4932554641877\r\n     56215535           2   56242962     477602 SIMON_X6S       INDEX_BACKUP    RUNNING    q_restore_fast  8t81c0j1w9jqu plan 89% done    41032043                                  :B4   1048576\r\n\r\nSQL&gt;<\/pre>\n<p style=\"text-align: justify;\">And the SQL text for them:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; select sql_fulltext from gv$sqlarea where inst_id = 2 and sql_id = '9ma189ab8x9c7';\r\n\r\nSQL_FULLTEXT\r\n--------------------------------------------------------------------------------------------------------------------------------\r\nINSERT \/*+\r\n             QB_NAME(q_restore_fast)\r\n             OPT_PARAM('optimizer_dynamic_sampling' 0)\r\n             OPT_PARAM('_optimizer_adaptive_cursor_sharing' 'false')\r\n             OPT_PARAM('_optimizer_extended_cursor_sharing_rel' 'none')\r\n             OPT_PARAM('_optimizer_use_feedback' 'false')\r\n           *\/ INTO PLANS_DETAILS (DF_KEY, TYPE, VB_KEY, BLKRANK, BLOCKNO, CHUNKNO, NUMBLKS, COFFSET, NUMBYTES) SELECT :B1 , :B12\r\n, :B2 , 1 BLKRANK, BLOCKNO, CHUNKNO, NUMBLKS, COFFSET, NUMBYTES FROM TABLE( DBMS_RA_POOL.COLLAPSE(:B1 , :B2 , :B3 , :B4 ,\r\n CURSOR( SELECT \/*+\r\n                     QB_NAME(q_rfast_c)\r\n                     INDEX_RS_ASC(@q_rfast_c b@q_rfast_c)\r\n                     NO_INDEX_FFS(@q_rfast_c b@q_rfast_c)\r\n                     NO_INDEX_SS(@q_rfast_c b@q_rfast_c)\r\n                     OPT_PARAM('optimizer_dynamic_sampling' 0)\r\n                     OPT_PARAM('_optimizer_adaptive_cursor_sharing' 'false')\r\n                     OPT_PARAM('_optimizer_extended_cursor_sharing_rel' 'none')\r\n                     OPT_PARAM('_optimizer_use_feedback' 'false')\r\n                   *\/ CKP_ID, BLOCKNO, SCN, CHUNKNO, USED, COFFSET, ENDBLK FROM BLOCKS B WHERE DF_KEY = :B1 AND BLOCKNO BETWEEN \r\n:B3 AND :B4 AND SCN BETWEEN :B11 AND :B10 AND CKP_ID &gt;= :B9 AND (CKP_ID &lt;= :B8 OR DBINC_KEY &lt;&gt; :B7 ) AND (SCN &lt; :B6 OR CKP_ID = \r\n:B5 ) ORDER BY BLOCKNO, SCN, CKP_ID, CHUNKNO ) ) )\r\n\r\nSQL&gt;\r\nSQL&gt; select sql_fulltext from gv$sqlarea where inst_id = 2 and sql_id = 'brt6uuhzacdnu';\r\n\r\nSQL_FULLTEXT\r\n-------------------------------------------------------------------------------------------------------------------------------\r\nSELECT \/*+ QB_NAME (\"Q_RFAST_C\") NO_INDEX_SS (\"B\") NO_INDEX_FFS (\"B\") INDEX_RS_ASC (\"B\") *\/ \"B\".\"CKP_ID\" \"CKP_ID\",\"B\".\"BLOCKNO\" \r\n\"BLOCKNO\",\"B\".\"SCN\" \"SCN\",\"B\".\"CHUNKNO\" \"CHUNKNO\",\"B\".\"USED\" \"USED\",\"B\".\"COFFSET\" \"COFFSET\",\"B\".\"ENDBLK\" \"ENDBLK\" FROM \"BLOCKS\" \r\n\"B\" WHERE \"B\".\"DF_KEY\"=:B1 AND \"B\".\"BLOCKNO\"&gt;=:B3 AND \"B\".\"BLOCKNO\"&lt;=:B4 AND \"B\".\"SCN\"&gt;=:B11 AND \"B\".\"SCN\"&lt;=:B10 AND \"B\".\"CKP_ID\r\n\"&gt;=:B9 AND (\"B\".\"CKP_ID\"&lt;=:B8 OR \"B\".\"DBINC_KEY\"&lt;&gt;:B7) AND (\"B\".\"SCN\"&lt;:B6 OR \"B\".\"CKP_ID\"=:B5) ORDER BY \"B\".\"BLOCKNO\",\"B\".\"SCN\",\r\n\"B\".\"CKP_ID\",\"B\".\"CHUNKNO\"\r\n\r\nSQL&gt;\r\nSQL&gt; select sql_fulltext from gv$sqlarea where inst_id = 2 and sql_id = '8t81c0j1w9jqu';\r\n\r\nSQL_FULLTEXT\r\n--------------------------------------------------------------------------------------------------------------------------------\r\nSELECT NVL(MAX(BLOCKNO), :B1 ), COUNT(*) FROM (SELECT \/*+\r\n                 QB_NAME(nbr)\r\n                 INDEX_RS_ASC(@nbr b@nbr)\r\n                 NO_INDEX_FFS(@nbr b@nbr)\r\n                 NO_INDEX_SS(@nbr b@nbr)\r\n                 OPT_PARAM('optimizer_dynamic_sampling' 0)\r\n                 OPT_PARAM('_optimizer_adaptive_cursor_sharing' 'false')\r\n                 OPT_PARAM('_optimizer_extended_cursor_sharing_rel' 'none')\r\n                 OPT_PARAM('_optimizer_use_feedback' 'false')\r\n               *\/ BLOCKNO FROM BLOCKS B WHERE DF_KEY = :B3 AND BLOCKNO BETWEEN :B2 AND :B1 ORDER BY BLOCKNO) WHERE ROWNUM &lt;= :B4\r\n\r\nSQL&gt;\r\n<\/pre>\n<p style=\"text-align: justify;\">As you can see, the sql_id <em>9ma189ab8x9c7<\/em> is responsible to insert into PLANS_DETAILS the blocks that are needed to create this virtual full backup. This is based in SCN, and means that ZDLRA create the index for all blocks that are below the SCN from the backup that was ingested originally. The sql_id <em>brt6uuhzacdnu<\/em> returns all the blocks that are needed (based on the SCN), and it is the same for sql_id <em>8t81c0j1w9jqu<\/em> that verify if we have a block to index. These sql\u2019s are the base for the <em>q_restore_fast and t<\/em>hey alternate itself until we reach 100%.<\/p>\n<p style=\"text-align: justify;\">The idea for ZDLRA in this phase is to create the index that will be the base for the virtual full backup. And &#8220;create the index&#8221; means all the blocks that are needed to create the plan for this virtual full backup key.<\/p>\n<h2 style=\"text-align: justify;\">INDEX_BACKUP, 100%<\/h2>\n<p style=\"text-align: justify;\">So, after the INDEX_BACKUP finish at ZDLRA, we have this at rman catalog:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">RMAN&gt; list backup of datafile 29 tag = TAG20190816T150116;\r\n\r\n\r\nList of Backup Sets\r\n===================\r\n\r\n\r\nBS Key  Type LV Size       Device Type Elapsed Time Completion Time\r\n------- ---- -- ---------- ----------- ------------ -------------------\r\n52146235 Incr 1  28.00M     SBT_TAPE    00:01:44     2019-08-16_15-03-09\r\n        BP Key: 52146236   Status: AVAILABLE  Compressed: YES  Tag: TAG20190816T150116\r\n        Handle: VB$_90959062_52141864I   Media:\r\n  List of Datafiles in backup set 52146235\r\n  File LV Type Ckp SCN    Ckp Time            Name\r\n  ---- -- ---- ---------- ------------------- ----\r\n  29   1  Incr 4932560891039 2019-08-16_15-01-25 +DATAC1\/simon_x6s\/datafile\/simontsthistoric1_tbs.399.938192975\r\n\r\nBS Key  Type LV Size       Device Type Elapsed Time Completion Time\r\n------- ---- -- ---------- ----------- ------------ -------------------\r\n52152458 Incr 0  12.67T     SBT_TAPE    00:01:44     2019-08-16_15-03-09\r\n        BP Key: 52152459   Status: AVAILABLE  Compressed: YES  Tag: TAG20190816T150116\r\n        Handle: VB$_90959062_52141864_29   Media:\r\n  List of Datafiles in backup set 52152458\r\n  File LV Type Ckp SCN    Ckp Time            Name\r\n  ---- -- ---- ---------- ------------------- ----\r\n  29   0  Incr 4932560891039 2019-08-16_15-01-25 +DATAC1\/simon_x6s\/datafile\/simontsthistoric1_tbs.399.938192975\r\n\r\nRMAN&gt;<\/pre>\n<p style=\"text-align: justify;\">Look that for the same TAG we have now two backups, and one it is the virtual full backup. Check that SCN and TAG for both are the same. And if we check internally, at rman catalog view, about the backup pieces linked to the virtual backup key that was created by the index task we can see:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; select bp_key, bs_key, tag, handle, bytes\/1024\/1024\/1024, vb_key from bp where vb_key = 52141864;\r\n\r\n    BP_KEY     BS_KEY TAG                 HANDLE                    BYTES\/1024\/1024\/1024     VB_KEY\r\n---------- ---------- ------------------- ------------------------- -------------------- ----------\r\n  52152459   52152458 TAG20190816T150116  VB$_90959062_52141864_29            12975.3698   52141864\r\n  52146236   52146235 TAG20190816T150116  VB$_90959062_52141864I               .02734375   52141864\r\n\r\nSQL&gt;<\/pre>\n<p style=\"text-align: justify;\">Look above that now we have two backups linked to the same virtual full backup (compare with the same SQL from the previous phases). The backup set key 52152458 is the virtual full backup and was generated during the phase <em>q_restore_fast<\/em>. The backup set key 52146235 was generated during the phase <em>fixup_unordered<\/em>.<\/p>\n<p style=\"text-align: justify;\">And there is now, two backups for this datafile:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; SELECT bdf_key, bs_key, file#, ckp_scn, incr_level from bdf where CKP_SCN = 4932560891039 and file# = 29;\r\n\r\n   BDF_KEY     BS_KEY      FILE#         CKP_SCN INCR_LEVEL\r\n---------- ---------- ---------- --------------- ----------\r\n  52146237   52146235         29   4932560891039          1\r\n  52152460   52152458         29   4932560891039          0\r\n\r\nSQL&gt;<\/pre>\n<p style=\"text-align: justify;\">Just to show that the task took a lot of time to finish:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL&gt; select rt.elapsed_seconds from ra_task rt where task_id = 56242962;\r\n\r\nELAPSED_SECONDS\r\n---------------\r\n     14563.7986\r\n\r\nSQL&gt;\r\nSQL&gt; select count(*) from plans_details where VB_KEY = 52141864;\r\n\r\n  COUNT(*)\r\n----------\r\n  74505579\r\n\r\nSQL&gt;<\/pre>\n<h2 style=\"text-align: justify;\">INDEX_BACKUP, The internals<\/h2>\n<p style=\"text-align: justify;\">As you can see above, the INDEX_BACKUP task it is responsible to generate the virtual full backup and \u201cfix\u201d the rman catalog views to represent the new backups. This is done in two major phases (<em>fixup_unordered<\/em> and <em>q_restore_fast<\/em>) to read the backup that was ingested at ZDLRA and index all the blocks. The other phases are <em>process_allfiles<\/em> and <em>plan_blocks<\/em>, but they are fast to execute.<\/p>\n<p style=\"text-align: justify;\">About the blocks, it is important to hint that it is completely based in SCN\/CKP number. The index creation will search for all blocks that are bellow of the SCN of ingested backup. If you check the details, the backup file does not exist, by the way, it is just a huge list of the blocks need to this SCN (information stored at plans_details table).<\/p>\n<p style=\"text-align: justify;\"><a href=\"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/08\/Virtual-Full-Backup-INDEX.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-570\" src=\"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/08\/Virtual-Full-Backup-INDEX.png\" alt=\"\" width=\"510\" height=\"321\" srcset=\"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/08\/Virtual-Full-Backup-INDEX.png 510w, https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/08\/Virtual-Full-Backup-INDEX-300x189.png 300w\" sizes=\"auto, (max-width: 510px) 100vw, 510px\" \/><\/a><\/p>\n<p style=\"text-align: justify;\">The procedures, SQL, steps, phases that I showed before will have different values in your case. The DF_KEY, BS_KEY, and others will be different. But I think that you can understand the logic of how ZDLRA index the backup and internally generate the virtual full backup. I know that it is not easy to read all the numbers and link between sql\u2019s and tables, but the logic it is simple: verify all the blocks that belong to datafile and create one plan that points to every block needed by the virtual full backup for one scn.<\/p>\n<p style=\"text-align: justify;\">&nbsp;<\/p>\n<p style=\"text-align: justify;\"><strong>Disclaimer:<\/strong> <em>\u201cThe postings on this site are my own and don\u2019t 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.\u201d<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>For ZDLRA, the task type INDEX_BACKUP it is important (if it is not the most) because it is responsible to create the virtual full backup. This task runs for every backup that you ingest at ZDLRA and here, I will show with more details what occurs at ZDLRA: internals steps, phases, and tables involved. I [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[44,29,77,5,91,106,51],"tags":[66,100,107,65,101,104,74],"class_list":["post-569","post","type-post","status-publish","format-standard","hentry","category-backup","category-database","category-engineeredsystems","category-oracle","category-rman","category-virtual-full-backup","category-zdlra","tag-database","tag-engineered-systems","tag-index_backup","tag-oracle","tag-recovery-appliance","tag-virtual-full-backup","tag-zdlra"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v26.8 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>ZDLRA Internals, INDEX_BACKUP task in details - Fernando Simon<\/title>\n<meta name=\"description\" content=\"Check ZDLRA internals for INDEX_BACKUP task for virtual full backup creation. Read and understand fixup_unordered and q_restore_fast phases.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"ZDLRA Internals, INDEX_BACKUP task in details - Fernando Simon\" \/>\n<meta property=\"og:description\" content=\"Check ZDLRA internals for INDEX_BACKUP task for virtual full backup creation. Read and understand fixup_unordered and q_restore_fast phases.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/\" \/>\n<meta property=\"og:site_name\" content=\"Fernando Simon\" \/>\n<meta property=\"article:published_time\" content=\"2019-08-29T08:11:26+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2020-07-19T22:17:10+00:00\" \/>\n<meta property=\"og:image\" content=\"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/08\/Virtual-Full-Backup-INDEX.png\" \/>\n<meta name=\"author\" content=\"Simon\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Simon\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"26 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/\"},\"author\":{\"name\":\"Simon\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9\"},\"headline\":\"ZDLRA Internals, INDEX_BACKUP task in details\",\"datePublished\":\"2019-08-29T08:11:26+00:00\",\"dateModified\":\"2020-07-19T22:17:10+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/\"},\"wordCount\":1945,\"commentCount\":3,\"image\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/#primaryimage\"},\"thumbnailUrl\":\"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/08\/Virtual-Full-Backup-INDEX.png\",\"keywords\":[\"Database\",\"Engineered Systems\",\"INDEX_BACKUP\",\"Oracle\",\"Recovery Appliance\",\"Virtual Full Backup\",\"ZDLRA\"],\"articleSection\":[\"Backup\",\"Database\",\"Engineered Systems\",\"Oracle\",\"RMAN\",\"Virtual Full Backup\",\"ZDLRA\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/\",\"url\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/\",\"name\":\"ZDLRA Internals, INDEX_BACKUP task in details - Fernando Simon\",\"isPartOf\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/#primaryimage\"},\"thumbnailUrl\":\"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/08\/Virtual-Full-Backup-INDEX.png\",\"datePublished\":\"2019-08-29T08:11:26+00:00\",\"dateModified\":\"2020-07-19T22:17:10+00:00\",\"author\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9\"},\"description\":\"Check ZDLRA internals for INDEX_BACKUP task for virtual full backup creation. Read and understand fixup_unordered and q_restore_fast phases.\",\"breadcrumb\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/#primaryimage\",\"url\":\"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/08\/Virtual-Full-Backup-INDEX.png\",\"contentUrl\":\"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/08\/Virtual-Full-Backup-INDEX.png\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.fernandosimon.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"ZDLRA Internals, INDEX_BACKUP task in details\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#website\",\"url\":\"https:\/\/www.fernandosimon.com\/blog\/\",\"name\":\"Fernando Simon\",\"description\":\"Have you hugged your backup today?\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.fernandosimon.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9\",\"name\":\"Simon\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/a3dbc48de62fffb1829befb4a588d789ec6dc5e05977afabb3407a5f37a16482?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/a3dbc48de62fffb1829befb4a588d789ec6dc5e05977afabb3407a5f37a16482?s=96&d=mm&r=g\",\"caption\":\"Simon\"},\"sameAs\":[\"http:\/\/www.fernandosimon.com\"],\"url\":\"https:\/\/www.fernandosimon.com\/blog\/author\/simon\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"ZDLRA Internals, INDEX_BACKUP task in details - Fernando Simon","description":"Check ZDLRA internals for INDEX_BACKUP task for virtual full backup creation. Read and understand fixup_unordered and q_restore_fast phases.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/","og_locale":"en_US","og_type":"article","og_title":"ZDLRA Internals, INDEX_BACKUP task in details - Fernando Simon","og_description":"Check ZDLRA internals for INDEX_BACKUP task for virtual full backup creation. Read and understand fixup_unordered and q_restore_fast phases.","og_url":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/","og_site_name":"Fernando Simon","article_published_time":"2019-08-29T08:11:26+00:00","article_modified_time":"2020-07-19T22:17:10+00:00","og_image":[{"url":"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/08\/Virtual-Full-Backup-INDEX.png","type":"","width":"","height":""}],"author":"Simon","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Simon","Est. reading time":"26 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/#article","isPartOf":{"@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/"},"author":{"name":"Simon","@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9"},"headline":"ZDLRA Internals, INDEX_BACKUP task in details","datePublished":"2019-08-29T08:11:26+00:00","dateModified":"2020-07-19T22:17:10+00:00","mainEntityOfPage":{"@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/"},"wordCount":1945,"commentCount":3,"image":{"@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/#primaryimage"},"thumbnailUrl":"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/08\/Virtual-Full-Backup-INDEX.png","keywords":["Database","Engineered Systems","INDEX_BACKUP","Oracle","Recovery Appliance","Virtual Full Backup","ZDLRA"],"articleSection":["Backup","Database","Engineered Systems","Oracle","RMAN","Virtual Full Backup","ZDLRA"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/","url":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/","name":"ZDLRA Internals, INDEX_BACKUP task in details - Fernando Simon","isPartOf":{"@id":"https:\/\/www.fernandosimon.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/#primaryimage"},"image":{"@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/#primaryimage"},"thumbnailUrl":"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/08\/Virtual-Full-Backup-INDEX.png","datePublished":"2019-08-29T08:11:26+00:00","dateModified":"2020-07-19T22:17:10+00:00","author":{"@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9"},"description":"Check ZDLRA internals for INDEX_BACKUP task for virtual full backup creation. Read and understand fixup_unordered and q_restore_fast phases.","breadcrumb":{"@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/#primaryimage","url":"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/08\/Virtual-Full-Backup-INDEX.png","contentUrl":"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/08\/Virtual-Full-Backup-INDEX.png"},{"@type":"BreadcrumbList","@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-index_backup-task-in-details\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.fernandosimon.com\/blog\/"},{"@type":"ListItem","position":2,"name":"ZDLRA Internals, INDEX_BACKUP task in details"}]},{"@type":"WebSite","@id":"https:\/\/www.fernandosimon.com\/blog\/#website","url":"https:\/\/www.fernandosimon.com\/blog\/","name":"Fernando Simon","description":"Have you hugged your backup today?","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.fernandosimon.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9","name":"Simon","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/a3dbc48de62fffb1829befb4a588d789ec6dc5e05977afabb3407a5f37a16482?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/a3dbc48de62fffb1829befb4a588d789ec6dc5e05977afabb3407a5f37a16482?s=96&d=mm&r=g","caption":"Simon"},"sameAs":["http:\/\/www.fernandosimon.com"],"url":"https:\/\/www.fernandosimon.com\/blog\/author\/simon\/"}]}},"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p5ofTp-9b","_links":{"self":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts\/569","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/comments?post=569"}],"version-history":[{"count":0,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts\/569\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/media?parent=569"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/categories?post=569"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/tags?post=569"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}