{"id":606,"date":"2019-09-25T08:06:23","date_gmt":"2019-09-25T11:06:23","guid":{"rendered":"http:\/\/www.fernandosimon.com\/blog\/?p=606"},"modified":"2020-07-19T19:16:29","modified_gmt":"2020-07-19T22:16:29","slug":"zdlra-internals-virtual-full-backup","status":"publish","type":"post","link":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/","title":{"rendered":"ZDLRA Internals, Virtual Full Backup"},"content":{"rendered":"

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.<\/p>\n

About the internal tables, you can check my previous post \u201cZDLRA Internals, Tables and Storage<\/a>\u201d where I explained details about that. To understand the INDEX_BACKUP task, check my post \u201cZDLRA Internals, INDEX_BACKUP task in details<\/a>\u201d. But if you know nothing and want to start reading about ZDLRA, you can check my post \u201cUnderstanding ZDLRA<\/a>\u201d and check all the features and details.<\/p>\n

The base for this article is virtual full backup and incremental forever strategy. I explained both at \u201cZDLRA, Virtual Full Backup and Incremental Forever<\/a>\u201d and I included hot it\u2019s 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.<\/p>\n

<\/p>\n

Database Environment<\/h2>\n

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.<\/p>\n

Creating the tablespace, checking the datafile, and creating the table:<\/p>\n

SQL> create tablespace simon datafile '\/u01\/app\/oracle\/oradata\/ORCL19\/simon01.dbf' size 1m autoextend on next 1m maxsize 10m;\r\n\r\nTablespace created.\r\n\r\nSQL>\r\nSQL> select file_id from dba_data_files where tablespace_name = 'SIMON';\r\n\r\n   FILE_ID\r\n----------\r\n         5\r\n\r\nSQL>\r\nSQL> create table test(c1 decimal(1,0), c2 varchar2(128)) tablespace simon;\r\n\r\nTable created.\r\n\r\nSQL> insert into test (c1, c2) values (0, 'SIMON');\r\n\r\n1 row created.\r\n\r\nSQL> commit;\r\n\r\nCommit complete.\r\n\r\nSQL><\/pre>\n
And after that, doing the initial backup level 0 for the datafile:<\/p>\n
RMAN> list backup of datafile 5;\r\n\r\nspecification does not match any backup in the repository\r\n\r\nRMAN> BACKUP INCREMENTAL LEVEL 0 DEVICE TYPE SBT FILESPERSET 1 DATAFILE 5;\r\n\r\nStarting backup at 22-09-2019_17:54:27\r\nallocated channel: ORA_SBT_TAPE_1\r\nchannel ORA_SBT_TAPE_1: SID=75 device type=SBT_TAPE\r\nchannel ORA_SBT_TAPE_1: RA Library (ZDLRAS1) SID=9327516A92A43E0DE053010310ACCB56\r\nchannel ORA_SBT_TAPE_1: starting incremental level 0 datafile backup set\r\nchannel ORA_SBT_TAPE_1: specifying datafile(s) in backup set\r\ninput datafile file number=00005 name=\/u01\/app\/oracle\/oradata\/ORCL19\/simon01.dbf\r\nchannel ORA_SBT_TAPE_1: starting piece 1 at 22-09-2019_17:54:28\r\nchannel ORA_SBT_TAPE_1: finished piece 1 at 22-09-2019_17:54:29\r\npiece handle=ORCL19_2aucdsak_1_1 tag=TAG20190922T175427 comment=API Version 2.0,MMS Version 12.2.0.2\r\nchannel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:01\r\nFinished backup at 22-09-2019_17:54:29\r\n\r\nStarting Control File and SPFILE Autobackup at 22-09-2019_17:54:29\r\npiece handle=c-310627084-20190922-05 comment=API Version 2.0,MMS Version 12.2.0.2\r\nFinished Control File and SPFILE Autobackup at 22-09-2019_17:54:30\r\n\r\nRMAN>\r\n\r\nRMAN> list backup of datafile 5;\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\n2729    Incr 0  40.00K     SBT_TAPE    00:00:02     22-09-2019_17:54:30\r\n        BP Key: 2730   Status: AVAILABLE  Compressed: YES  Tag: TAG20190922T175427\r\n        Handle: VB$_1887643964_2728I   Media:\r\n  List of Datafiles in backup set 2729\r\n  File LV Type Ckp SCN    Ckp Time            Abs Fuz SCN Sparse Name\r\n  ---- -- ---- ---------- ------------------- ----------- ------ ----\r\n  5    0  Incr 2320763    22-09-2019_17:54:28              NO    \/u01\/app\/oracle\/oradata\/ORCL19\/simon01.dbf\r\n\r\nRMAN><\/pre>\n
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.<\/p>\n
Basic information for database<\/h3>\n
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.<\/p>\n
[oracle@zdlras1n1 ~]$ sqlplus rasys\/change^Me2\r\n\r\nSQL*Plus: Release 19.0.0.0.0 - Production on Sun Sep 22 17:53:21 2019\r\nVersion 19.3.0.0.0\r\n\r\nCopyright (c) 1982, 2019, Oracle.  All rights reserved.\r\n\r\nLast Successful login time: Sun Sep 22 2019 17:39:03 +02:00\r\n\r\nConnected to:\r\nOracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production\r\nVersion 19.3.0.0.0\r\n\r\nSQL> set linesize 250\r\nSQL> select db_key, dbinc_key from rc_database where name = 'ORCL19';\r\n\r\n    DB_KEY  DBINC_KEY\r\n---------- ----------\r\n      2202       2203\r\n\r\nSQL>\r\nSQL> select df_key, file#, ts#, create_scn, create_time, block_size, blocks from df where dbinc_key = 2203 and file# = 5;\r\n\r\n    DF_KEY      FILE#        TS# CREATE_SCN CREATE_TI BLOCK_SIZE     BLOCKS\r\n---------- ---------- ---------- ---------- --------- ---------- ----------\r\n      2689          5          6    2319183 22-SEP-19       8192        128\r\n\r\nSQL><\/pre>\n
Virtual Full Backup and PLANS<\/h2>\n
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:<\/p>\n
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;\r\n\r\n    VB_KEY    CKP_SCN   VCBP_KEY  SRCBP_KEY     BLOCKS CHUNKS_USED\r\n---------- ---------- ---------- ---------- ---------- -----------\r\n      2728    2320763       2730       2701        128           1\r\n\r\nSQL>\r\nSQL> select * from plans where db_key = 2202 and df_key = 2689 order by vb_key asc;\r\n\r\n      TYPE     DB_KEY     VB_KEY     DF_KEY    TASK_ID        OLD   BLKSREAD    MAXRANK  NUMCHUNKS   READSIZE  NEEDCHUNK  FREECHUNK\r\n---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------\r\n         8       2202       2728       2689                               19          1          1\r\n\r\nSQL>\r\n<\/pre>\n
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).<\/p>\n
But this not show how ZDLRA see the backup<\/strong>, the virtual full backup store the information at PLAN_DETAILS table. Reading this table we can see the foundation of virtual full backup:<\/p>\n
SQL> select * from plans_details where df_key = 2689 order by vb_key asc, blockno asc;\r\n\r\n    DF_KEY       TYPE     VB_KEY    BLKRANK    BLOCKNO    CHUNKNO    NUMBLKS    COFFSET   NUMBYTES\r\n---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------\r\n      2689          8       2728          1          0          1          1       8192      24576\r\n      2689          8       2728          1          2          1         17      32788       2167\r\n      2689          8       2728          1 4294967295          1          1      34955        294\r\n\r\nSQL><\/pre>\n
Let\u2019s explain what this means: <\/strong><\/p>\n
    \n
  1. The datafile block 0 (column BLOCKNO) until block 1 (BLOCKNO+NUNBLKS) are stored at chunk 1.<\/li>\n
  2. The datafile block 2 (column BLOCKNO) until block 19 (BLOCKNO+NUNBLKS) are stored at chunk 1<\/li>\n
  3. The datafile block 4294967295 (the last block of datafile) is stored at chunks 1.<\/li>\n<\/ol>\n
    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:<\/p>\n
    \"\"<\/a><\/p>\n
    Subsequent backups<\/h3>\n
    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:<\/p>\n
    SQL> BEGIN\r\n  2    FOR i IN 1 .. 300 LOOP\r\n  3      insert into test (c1, c2) values (2, DBMS_RANDOM.STRING('P', 128));\r\n  4\r\n  5      if (MOD(i, 100) = 0) then\r\n  6         commit;\r\n  7      end if;\r\n  8\r\n  9    END LOOP;\r\n 10\r\n 11    commit;\r\n 12  END;\r\n 13  \/\r\n\r\nPL\/SQL procedure successfully completed.\r\n\r\nSQL>\r\n\r\nRMAN> BACKUP INCREMENTAL LEVEL 1 DEVICE TYPE SBT FILESPERSET 1 DATAFILE 5;\r\n\r\nStarting backup at 22-09-2019_18:34:30\r\nusing channel ORA_SBT_TAPE_1\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=00005 name=\/u01\/app\/oracle\/oradata\/ORCL19\/simon01.dbf\r\nchannel ORA_SBT_TAPE_1: starting piece 1 at 22-09-2019_18:34:31\r\nchannel ORA_SBT_TAPE_1: finished piece 1 at 22-09-2019_18:34:32\r\npiece handle=ORCL19_2cucduln_1_1 tag=TAG20190922T183430 comment=API Version 2.0,MMS Version 12.2.0.2\r\nchannel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:01\r\nFinished backup at 22-09-2019_18:34:32\r\n\r\nStarting Control File and SPFILE Autobackup at 22-09-2019_18:34:32\r\npiece handle=c-310627084-20190922-06 comment=API Version 2.0,MMS Version 12.2.0.2\r\nFinished Control File and SPFILE Autobackup at 22-09-2019_18:34:36\r\n\r\nRMAN><\/pre>\n
    And now inside of ZDLRA we have two virtual full backups and two plans (for PLANS look the number of blocks read \u2013 this is normal since I added more data above):<\/p>\n
    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;\r\n\r\n    VB_KEY    CKP_SCN   VCBP_KEY  SRCBP_KEY     BLOCKS CHUNKS_USED\r\n---------- ---------- ---------- ---------- ---------- -----------\r\n      2728    2320763       2730       2701        128           1\r\n      2768    2322525       2770       2735        128           1\r\n\r\nSQL>\r\nSQL> select * from plans where db_key = 2202 and df_key = 2689 order by vb_key asc;\r\n\r\n      TYPE     DB_KEY     VB_KEY     DF_KEY    TASK_ID        OLD   BLKSREAD    MAXRANK  NUMCHUNKS   READSIZE  NEEDCHUNK  FREECHUNK\r\n---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------\r\n         8       2202       2728       2689                               19          1          1\r\n         1       2202       2768       2689                               27          1          2\r\n\r\nSQL>\r\n<\/pre>\n
    The virtual full backups have these PLAN_DETAILS:<\/p>\n
    SQL> select * from plans_details where df_key = 2689 order by vb_key asc, blockno asc;\r\n\r\n    DF_KEY       TYPE     VB_KEY    BLKRANK    BLOCKNO    CHUNKNO    NUMBLKS    COFFSET   NUMBYTES\r\n---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------\r\n      2689          8       2728          1          0          1          1       8192      24576\r\n      2689          8       2728          1          2          1         17      32788       2167\r\n      2689          8       2728          1 4294967295          1          1      34955        294\r\n      2689          1       2768          1          0       1025          1       8192      24576\r\n      2689          1       2768          1          2       1025          2      32788        252\r\n      2689          1       2768          1          4          1          4      33038        408\r\n      2689          1       2768          1          8       1025         16      33040      45339\r\n      2689          1       2768          1         71          1          3      34703        252\r\n      2689          1       2768          1 4294967295       1025          1      78379        293\r\n\r\n9 rows selected.\r\n\r\nSQL>\r\n<\/pre>\n
    Checking in details the last virtual full backup, VB_KEY 2768, we can see interesting things and start to understand how it\u2019s work. So, to \u201cmount\u201d the virtual full backup 2768 we have:<\/p>\n
      \n
    1. The datafile block 0 (column BLOCKNO) until block 1 (BLOCKNO+NUNBLKS) are stored at chunk 1025.<\/li>\n
    2. The datafile block 2 (column BLOCKNO) until block 4 (BLOCKNO+NUNBLKS) are stored at chunk 1025.<\/li>\n
    3. The datafile block 4 (column BLOCKNO) until block 8 (BLOCKNO+NUNBLKS) are stored at chunk 1 (and came from previous virtual full backup<\/strong>).<\/li>\n
    4. The datafile block 8 (column BLOCKNO) until block 24 (BLOCKNO+NUNBLKS) are stored at chunk 1025.<\/li>\n<\/ol>\n
      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:\"\"<\/a><\/p>\n
      Look that ZDLRA started to save space to store the backup, being \u201csmart\u201d and indexing all the blocks to needed to create the virtual full backup. But the important here it is that ZDLRA understood and indexed<\/strong> every datafile block that was inside of backup. And the virtual full backup \u201cdoes not exist\u201d, it is basically the index for each version of the block.<\/p>\n
      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:<\/p>\n
      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;\r\n\r\n    VB_KEY    CKP_SCN   VCBP_KEY  SRCBP_KEY     BLOCKS CHUNKS_USED\r\n---------- ---------- ---------- ---------- ---------- -----------\r\n      2728    2320763       2730       2701        128           1\r\n      2768    2322525       2770       2735        128           1\r\n      2818    2323607       2820       2779        128           1\r\n      2874    2324062       2876       2829        128           1\r\n      2936    2324792       2938       2885        128           1\r\n\r\nSQL> select * from plans where db_key = 2202 and df_key = 2689 order by vb_key asc;\r\n\r\n      TYPE     DB_KEY     VB_KEY     DF_KEY    TASK_ID        OLD   BLKSREAD    MAXRANK  NUMCHUNKS   READSIZE  NEEDCHUNK  FREECHUNK\r\n---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------\r\n         8       2202       2728       2689                               19          1          1\r\n         1       2202       2768       2689                               27          1          2\r\n         1       2202       2818       2689                               27          1          3\r\n         1       2202       2874       2689                               27          1          3\r\n         1       2202       2936       2689                               27          1          4\r\n\r\nSQL> select * from plans_details where df_key = 2689 order by vb_key asc, blockno asc;\r\n\r\n    DF_KEY       TYPE     VB_KEY    BLKRANK    BLOCKNO    CHUNKNO    NUMBLKS    COFFSET   NUMBYTES\r\n---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------\r\n      2689          8       2728          1          0          1          1       8192      24576\r\n      2689          8       2728          1          2          1         17      32788       2167\r\n      2689          8       2728          1 4294967295          1          1      34955        294\r\n      2689          1       2768          1          0       1025          1       8192      24576\r\n      2689          1       2768          1          2       1025          2      32788        252\r\n      2689          1       2768          1          4          1          4      33038        408\r\n      2689          1       2768          1          8       1025         16      33040      45339\r\n      2689          1       2768          1         71          1          3      34703        252\r\n      2689          1       2768          1 4294967295       1025          1      78379        293\r\n      2689          1       2818          1          0       2049          1       8192      24576\r\n      2689          1       2818          1          2       1025          2      32788        252\r\n      2689          1       2818          1          4          1          4      33038        408\r\n      2689          1       2818          1          8       2049          1      32788        257\r\n      2689          1       2818          1          9       1025          7      33293      36549\r\n      2689          1       2818          1         16       2049          3      33045      17304\r\n      2689          1       2818          1         19       1025          1      76821       1026\r\n      2689          1       2818          1         20       2049          4      50349      29052\r\n      2689          1       2818          1         71          1          3      34703        252\r\n      2689          1       2818          1 4294967295       2049          1      79401        301\r\n      2689          1       2874          1          0       3073          1       8192      24576\r\n      2689          1       2874          1          2       1025          2      32788        252\r\n      2689          1       2874          1          4          1          4      33038        408\r\n      2689          1       2874          1          8       3073          1      32788        262\r\n      2689          1       2874          1          9       1025          2      33293        347\r\n      2689          1       2874          1         11       3073         13      33050      94555\r\n      2689          1       2874          1         71          1          3      34703        252\r\n      2689          1       2874          1 4294967295       3073          1     127605        296\r\n      2689          1       2936          1          0       4097          1       8192      24576\r\n      2689          1       2936          1          2       1025          2      32788        252\r\n      2689          1       2936          1          4          1          4      33038        408\r\n      2689          1       2936          1          8       3073          1      32788        262\r\n      2689          1       2936          1          9       1025          2      33293        347\r\n      2689          1       2936          1         11       3073         13      33050      94555\r\n      2689          1       2936          1         71          1          3      34703        252\r\n      2689          1       2936          1 4294967295       4097          1      32788        278\r\n\r\n35 rows selected.\r\n\r\nSQL><\/pre>\n
      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:<\/p>\n
        \n
      1. The datafile block 0 until block 1 are stored at chunk 4097.<\/li>\n
      2. The datafile block 2 until block 4 are stored at chunk 1025.<\/li>\n
      3. The datafile block 4 until block 8 are stored at chunk 1.<\/li>\n
      4. The datafile block 8 are stored at chunk 3073.<\/li>\n
      5. The datafile block 9 until block 10 are stored at chunk 1025.<\/li>\n
      6. The datafile block 11 until block 24 are stored at chunk 3073.<\/li>\n<\/ol>\n
        The image below represents this:<\/p>\n
        \"\"<\/a><\/p>\n
        Automated Delta Pool Space Management<\/h2>\n
        Since ZDLRA contains a \u201cself-managed\u201d  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 \u201cautomated delta pool space management<\/a>\u201d, specifically the “delta pool optimization<\/a>“, to optimize the delta pool.<\/p>\n
        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:<\/p>\n
        SQL> select * from plans_details where df_key = 2689 order by vb_key asc, blockno asc;\r\n\r\n    DF_KEY       TYPE     VB_KEY    BLKRANK    BLOCKNO    CHUNKNO    NUMBLKS    COFFSET   NUMBYTES\r\n---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------\r\n      2689          1       2768          1          0       1025          1       8192      24576\r\n      2689          1       2768          1          2       1025          2      32788        252\r\n      2689          1       2768          1          4          1          4      33038        408\r\n      2689          1       2768          1          8       1025         16      33040      45339\r\n      2689          1       2768          1         71          1          3      34703        252\r\n      2689          1       2768          1 4294967295       1025          1      78379        293\r\n      2689          1       2818          1          0       2049          1       8192      24576\r\n      2689          1       2818          1          2       1025          2      32788        252\r\n      2689          1       2818          1          4          1          4      33038        408\r\n      2689          1       2818          1          8       2049          1      32788        257\r\n      2689          1       2818          1          9       1025          7      33293      36549\r\n      2689          1       2818          1         16       2049          3      33045      17304\r\n      2689          1       2818          1         19       1025          1      76821       1026\r\n      2689          1       2818          1         20       2049          4      50349      29052\r\n      2689          1       2818          1         71          1          3      34703        252\r\n      2689          1       2818          1 4294967295       2049          1      79401        301\r\n      2689          1       2874          1          0       3073          1       8192      24576\r\n      2689          1       2874          1          2       1025          2      32788        252\r\n      2689          1       2874          1          4          1          4      33038        408\r\n      2689          1       2874          1          8       3073          1      32788        262\r\n      2689          1       2874          1          9       1025          2      33293        347\r\n      2689          1       2874          1         11       3073         13      33050      94555\r\n      2689          1       2874          1         71          1          3      34703        252\r\n      2689          1       2874          1 4294967295       3073          1     127605        296\r\n      2689          1       2936          1          0       4097          1       8192      24576\r\n      2689          1       2936          1          2       1025          2      32788        252\r\n      2689          1       2936          1          4          1          4      33038        408\r\n      2689          1       2936          1          8       3073          1      32788        262\r\n      2689          1       2936          1          9       1025          2      33293        347\r\n      2689          1       2936          1         11       3073         13      33050      94555\r\n      2689          1       2936          1         71          1          3      34703        252\r\n      2689          1       2936          1 4294967295       4097          1      32788        278\r\n      2689          1       3002          1          0       5121          1       8192      24576\r\n      2689          1       3002          1          2       5121          2      32788        255\r\n      2689          1       3002          1          4          1          4      33038        408\r\n      2689          1       3002          1          8       3073          1      32788        262\r\n      2689          1       3002          1          9       1025          1      33293        128\r\n      2689          1       3002          1         10       5121          1      33043        215\r\n      2689          1       3002          1         11       3073         13      33050      94555\r\n      2689          1       3002          1         24       5121         28      33258       4986\r\n      2689          1       3002          1         52          1          1      34703         84\r\n      2689          1       3002          1         56       5121          8      38244       1168\r\n      2689          1       3002          1         72          1          1      34787         84\r\n      2689          1       3002          1        128       5121        843      39412     125460\r\n      2689          1       3002          1 4294967295       5121          1     164872        301\r\n\r\n45 rows selected.\r\n\r\nSQL><\/pre>\n
        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:<\/p>\n
        \"\"<\/a><\/p>\n
        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.<\/p>\n
        At the end if I do another backup we can see more evolution for space management:<\/p>\n
        SQL> select * from plans_details where df_key = 2689 order by vb_key asc, blockno asc;\r\n\r\n    DF_KEY       TYPE     VB_KEY    BLKRANK    BLOCKNO    CHUNKNO    NUMBLKS    COFFSET   NUMBYTES\r\n---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------\r\n      2689          1       2818          1          0       2049          1       8192      24576\r\n      2689          1       2818          1          2       1025          2      32788        252\r\n      2689          1       2818          1          4          1          4      33038        408\r\n      2689          1       2818          1          8       2049          1      32788        257\r\n      2689          1       2818          1          9       1025          7      33293      36549\r\n      2689          1       2818          1         16       2049          3      33045      17304\r\n      2689          1       2818          1         19       1025          1      76821       1026\r\n      2689          1       2818          1         20       2049          4      50349      29052\r\n      2689          1       2818          1         71          1          3      34703        252\r\n      2689          1       2818          1 4294967295       2049          1      79401        301\r\n      2689          1       2874          1          0       3073          1       8192      24576\r\n      2689          1       2874          1          2       1025          2      32788        252\r\n      2689          1       2874          1          4          1          4      33038        408\r\n      2689          1       2874          1          8       3073          1      32788        262\r\n      2689          1       2874          1          9       1025          2      33293        347\r\n      2689          1       2874          1         11       3073         13      33050      94555\r\n      2689          1       2874          1         71          1          3      34703        252\r\n      2689          1       2874          1 4294967295       3073          1     127605        296\r\n      2689          1       2936          1          0       4097          1       8192      24576\r\n      2689          1       2936          1          2       1025          2      32788        252\r\n      2689          1       2936          1          4          1          4      33038        408\r\n      2689          1       2936          1          8       3073          1      32788        262\r\n      2689          1       2936          1          9       1025          2      33293        347\r\n      2689          1       2936          1         11       3073         13      33050      94555\r\n      2689          1       2936          1         71          1          3      34703        252\r\n      2689          1       2936          1 4294967295       4097          1      32788        278\r\n      2689          1       3002          1          0       5121          1       8192      24576\r\n      2689          1       3002          1          2       5121          2      32788        255\r\n      2689          1       3002          1          4          1          4      33038        408\r\n      2689          1       3002          1          8       3073          1      32788        262\r\n      2689          1       3002          1          9       1025          1      33293        128\r\n      2689          1       3002          1         10       5121          1      33043        215\r\n      2689          1       3002          1         11       3073         13      33050      94555\r\n      2689          1       3002          1         24       5121         28      33258       4986\r\n      2689          1       3002          1         52          1          1      34703         84\r\n      2689          1       3002          1         56       5121          8      38244       1168\r\n      2689          1       3002          1         72          1          1      34787         84\r\n      2689          1       3002          1        128       5121        843      39412     125460\r\n      2689          1       3002          1 4294967295       5121          1     164872        301\r\n      2689          1       3074          1          0       6145          1       8192      24576\r\n      2689          1       3074          1          2       5121          2      32788        255\r\n      2689          1       3074          1          4          1          4      33038        408\r\n      2689          1       3074          1          8       3073          1      32788        262\r\n      2689          1       3074          1          9       1025          1      33293        128\r\n      2689          1       3074          1         10       5121          1      33043        215\r\n      2689          1       3074          1         11       3073         13      33050      94555\r\n      2689          1       3074          1         24       5121         28      33258       4986\r\n      2689          1       3074          1         52          1          1      34703         84\r\n      2689          1       3074          1         56       5121          8      38244       1168\r\n      2689          1       3074          1         72          1          1      34787         84\r\n      2689          1       3074          1        128       5121        843      39412     125460\r\n      2689          1       3074          1 4294967295       6145          1      32788        281\r\n\r\n52 rows selected.\r\n\r\nSQL><\/pre>\n
        The image that represents the actual story now it is:<\/p>\n
        \"\"<\/a><\/p>\n
        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.<\/p>\n
        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.<\/p>\n
        Virtual Full Backup<\/h2>\n
        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).<\/p>\n
        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.<\/p>\n
         <\/p>\n
        Disclaimer<\/strong>: \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":"
        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 […]<\/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":[29,77,5,106,51],"tags":[66,100,65,104,74],"class_list":["post-606","post","type-post","status-publish","format-standard","hentry","category-database","category-engineeredsystems","category-oracle","category-virtual-full-backup","category-zdlra","tag-database","tag-engineered-systems","tag-oracle","tag-virtual-full-backup","tag-zdlra"],"yoast_head":"\nZDLRA Internals, Virtual Full Backup - Fernando Simon<\/title>\n<meta name=\"description\" content=\"Check how ZDLRA works and manage virtual full backup. How internally integrate INDEX_BACKUP task with PLANS, PLANS_DETAILS and CHUNKS\" \/>\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-virtual-full-backup\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"ZDLRA Internals, Virtual Full Backup - Fernando Simon\" \/>\n<meta property=\"og:description\" content=\"Check how ZDLRA works and manage virtual full backup. How internally integrate INDEX_BACKUP task with PLANS, PLANS_DETAILS and CHUNKS\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/\" \/>\n<meta property=\"og:site_name\" content=\"Fernando Simon\" \/>\n<meta property=\"article:published_time\" content=\"2019-09-25T11:06:23+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2020-07-19T22:16:29+00:00\" \/>\n<meta property=\"og:image\" content=\"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/09\/Plan_VB_KEY_2728.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=\"12 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-virtual-full-backup\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/\"},\"author\":{\"name\":\"Simon\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9\"},\"headline\":\"ZDLRA Internals, Virtual Full Backup\",\"datePublished\":\"2019-09-25T11:06:23+00:00\",\"dateModified\":\"2020-07-19T22:16:29+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/\"},\"wordCount\":1440,\"commentCount\":2,\"image\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/#primaryimage\"},\"thumbnailUrl\":\"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/09\/Plan_VB_KEY_2728.png\",\"keywords\":[\"Database\",\"Engineered Systems\",\"Oracle\",\"Virtual Full Backup\",\"ZDLRA\"],\"articleSection\":[\"Database\",\"Engineered Systems\",\"Oracle\",\"Virtual Full Backup\",\"ZDLRA\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/\",\"url\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/\",\"name\":\"ZDLRA Internals, Virtual Full Backup - Fernando Simon\",\"isPartOf\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/#primaryimage\"},\"thumbnailUrl\":\"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/09\/Plan_VB_KEY_2728.png\",\"datePublished\":\"2019-09-25T11:06:23+00:00\",\"dateModified\":\"2020-07-19T22:16:29+00:00\",\"author\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9\"},\"description\":\"Check how ZDLRA works and manage virtual full backup. How internally integrate INDEX_BACKUP task with PLANS, PLANS_DETAILS and CHUNKS\",\"breadcrumb\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/#primaryimage\",\"url\":\"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/09\/Plan_VB_KEY_2728.png\",\"contentUrl\":\"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/09\/Plan_VB_KEY_2728.png\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.fernandosimon.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"ZDLRA Internals, Virtual Full Backup\"}]},{\"@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, Virtual Full Backup - Fernando Simon","description":"Check how ZDLRA works and manage virtual full backup. How internally integrate INDEX_BACKUP task with PLANS, PLANS_DETAILS and CHUNKS","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-virtual-full-backup\/","og_locale":"en_US","og_type":"article","og_title":"ZDLRA Internals, Virtual Full Backup - Fernando Simon","og_description":"Check how ZDLRA works and manage virtual full backup. How internally integrate INDEX_BACKUP task with PLANS, PLANS_DETAILS and CHUNKS","og_url":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/","og_site_name":"Fernando Simon","article_published_time":"2019-09-25T11:06:23+00:00","article_modified_time":"2020-07-19T22:16:29+00:00","og_image":[{"url":"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/09\/Plan_VB_KEY_2728.png","type":"","width":"","height":""}],"author":"Simon","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Simon","Est. reading time":"12 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/#article","isPartOf":{"@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/"},"author":{"name":"Simon","@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9"},"headline":"ZDLRA Internals, Virtual Full Backup","datePublished":"2019-09-25T11:06:23+00:00","dateModified":"2020-07-19T22:16:29+00:00","mainEntityOfPage":{"@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/"},"wordCount":1440,"commentCount":2,"image":{"@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/#primaryimage"},"thumbnailUrl":"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/09\/Plan_VB_KEY_2728.png","keywords":["Database","Engineered Systems","Oracle","Virtual Full Backup","ZDLRA"],"articleSection":["Database","Engineered Systems","Oracle","Virtual Full Backup","ZDLRA"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/","url":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/","name":"ZDLRA Internals, Virtual Full Backup - Fernando Simon","isPartOf":{"@id":"https:\/\/www.fernandosimon.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/#primaryimage"},"image":{"@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/#primaryimage"},"thumbnailUrl":"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/09\/Plan_VB_KEY_2728.png","datePublished":"2019-09-25T11:06:23+00:00","dateModified":"2020-07-19T22:16:29+00:00","author":{"@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9"},"description":"Check how ZDLRA works and manage virtual full backup. How internally integrate INDEX_BACKUP task with PLANS, PLANS_DETAILS and CHUNKS","breadcrumb":{"@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/#primaryimage","url":"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/09\/Plan_VB_KEY_2728.png","contentUrl":"http:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2019\/09\/Plan_VB_KEY_2728.png"},{"@type":"BreadcrumbList","@id":"https:\/\/www.fernandosimon.com\/blog\/zdlra-internals-virtual-full-backup\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.fernandosimon.com\/blog\/"},{"@type":"ListItem","position":2,"name":"ZDLRA Internals, Virtual Full Backup"}]},{"@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-9M","_links":{"self":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts\/606","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=606"}],"version-history":[{"count":0,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts\/606\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/media?parent=606"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/categories?post=606"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/tags?post=606"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}