.
\nYou’ve setup a logical replication, and you trust it. But before the target goes into production, it will be safer to compare source and target. At least count the number of rows.
\nBut tables are continuously changing, so how can you compare? Not so difficult thanks to Dbvisit replicate heartbeat table and Oracle flashback query.
\n
\nHere is the state of the replication, with activity on the source and real-time replication to the target:<\/p>\n
| Dbvisit Replicate 2.7.06.4485(MAX edition) - Evaluation License expires in 29 days \nMINE IS running. Currently at plog 368 and SCN 6119128 (07\/06\/2016 04:15:21). \nAPPLY IS running. Currently at plog 368 and SCN 6119114 (07\/06\/2016 04:15:19). \nProgress of replication dbvrep_XE:MINE->APPLY: total\/this execution \n-------------------------------------------------------------------------------------------------------------------------------------------- \nREPOE.CUSTOMERS: 100% Mine:961\/961 Unrecov:0\/0 Applied:961\/961 Conflicts:0\/0 Last:06\/07\/2016 04:12:12\/OK \nREPOE.ADDRESSES: 100% Mine:961\/961 Unrecov:0\/0 Applied:961\/961 Conflicts:0\/0 Last:06\/07\/2016 04:12:12\/OK \nREPOE.CARD_DETAILS: 100% Mine:894\/894 Unrecov:0\/0 Applied:894\/894 Conflicts:0\/0 Last:06\/07\/2016 04:12:12\/OK \nREPOE.ORDER_ITEMS: 100% Mine:5955\/5955 Unrecov:0\/0 Applied:5955\/5955 Conflicts:0\/0 Last:06\/07\/2016 04:12:12\/OK \nREPOE.ORDERS: 99% Mine:4781\/4781 Unrecov:0\/0 Applied:4780\/4780 Conflicts:0\/0 Last:06\/07\/2016 04:12:12\/OK \nREPOE.INVENTORIES: 100% Mine:5825\/5825 Unrecov:0\/0 Applied:5825\/5825 Conflicts:0\/0 Last:06\/07\/2016 04:12:12\/OK \nREPOE.LOGON: 99% Mine:6175\/6175 Unrecov:0\/0 Applied:6173\/6173 Conflicts:0\/0 Last:06\/07\/2016 04:12:12\/OK \n-------------------------------------------------------------------------------------------------------------------------------------------- \n7 tables listed. <\/code><\/pre>\nIf you wand to compare the rows from source and target, you will always see a difference because modifications on source arrive on target a few seconds later.<\/p>\n
Source and target SCN<\/h3>\n
The first thing to do is to determine a consistent point in time where source and target are the same. This point in time exists because the redo log is sequential by nature, and the commits are done in the same order on target than source. And this order is visible with the SCN. The only problem is that on a logical replication the SCN on source and target are completely different and have their own life.<\/p>\n
The first step is determine an SCN from the target and an SCN on the source that show the same state of transactions.<\/p>\n
But before that, let’s connect to the target and set the environment:<\/p>\n
$ sqlplus \/nolog @ compare.sql\n \nSQL*Plus: Release 11.2.0.2.0 Production on Tue Jul 5 18:15:34 2016\nCopyright (c) 1982, 2014, Oracle. All rights reserved.\nConnected to:\nOracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production\n \nSQL> define table_owner=REPOE\nSQL> define table_name=ORDERS\nSQL>\nSQL> connect system\/manager@\/\/192.168.56.67\/XE\nConnected.\nSQL> alter session set nls_date_format='DD-MON-YYYY HH24:mi:ss';\nSession altered.\nSQL> alter session set nls_timestamp_format='DD-MON-YYYY HH24:mi:ss';\nSession altered.<\/code><\/pre>\nMy example is on the #repattack environment, with Swingbench running on the source, and I’ll compare the ORDER table.<\/p>\n
Heartbeat table<\/h3>\n
Each Dbvisit replicate configuration comes with an heartbeat table created in the Dbvisit schema on the source and replicated to the target. This table is updated every 10 seconds on the source with timestamp and SCN. This is a great way to check how the replication is working. Here it will be the way to get the SCN information from the source.<\/p>\n
Flashback query<\/h3>\n
Oracle flashback query offers a nice way to get the commit SCN for the rows updated in the heartbeat table. From the target database, this is the commit SCN for the replication transaction (the APPLY process) and it can be displayed along with the SCN from the source transaction that is recorded in the heartbeat table and replicated to the target.<\/p>\n
SQL> column versions_startscn new_value scn_target\nSQL> column source_scn new_value scn_source\nSQL> column mine_process_name format a12\nSQL> column versions_starttime format a21\n \nSQL> select mine_process_name,wallclock_date,mine_date,source_scn,mine_scn,versions_startscn,versions_starttime,versions_endscn\n from DBVREP.DBRSCOMMON_HEARTBEAT versions between timestamp(sysdate-1\/24\/60) and sysdate\n order by versions_endscn nulls last ;\n \nMINE_PROCESS WALLCLOCK_DATE MINE_DATE SOURCE_SCN MINE_SCN VERSIONS_STARTSCN VERSIONS_STARTTIME VERSIONS_ENDSCN\n------------ -------------------- -------------------- -------------------- -------------------- -------------------- --------------------- --------------------\nMINE 06-JUL-2016 04:14:27 06-JUL-2016 04:14:22 6118717 6118661 4791342\nMINE 06-JUL-2016 04:14:37 06-JUL-2016 04:14:31 6118786 6118748 4791342 06-JUL-2016 04:11:29 4791376\nMINE 06-JUL-2016 04:14:47 06-JUL-2016 04:14:41 6118855 6118821 4791376 06-JUL-2016 04:11:39 4791410\nMINE 06-JUL-2016 04:14:57 06-JUL-2016 04:14:51 6118925 6118888 4791410 06-JUL-2016 04:11:49 4791443\nMINE 06-JUL-2016 04:15:07 06-JUL-2016 04:15:01 6119011 6118977 4791443 06-JUL-2016 04:11:59 4791479\nMINE 06-JUL-2016 04:15:17 06-JUL-2016 04:15:11 6119091 6119059 4791479 06-JUL-2016 04:12:09 4791515\nMINE 06-JUL-2016 04:15:27 06-JUL-2016 04:15:21 6119162 6119128 4791515 06-JUL-2016 04:12:19\n<\/code><\/pre>\nThis shows that the current version of the heartbeat table on target was commited at SCN 4791515 and we know that this state matches approximately the SCN 6119162 on the source. You can choose any pair you want but the latest will probably be the fastest to query.<\/p>\n
Note that this is approximative because the SCN recorded in the HEARTBEAT table is the SCN of the update and not the commit, which is done just after. You can get the commit SCN by creating your own HEARTBEAT table update a column with userenv(‘commitscn’).<\/p>\n
Counting rows on source<\/h3>\n
I’ll use flashback query to count the rows from the source at SCN 6119162. I’m doing it in parallel query, but be careful when the table has high modification activity there will be lot of undo blocks to read.<\/p>\n
SQL> connect system\/manager@\/\/192.168.56.66\/XE\nConnected.\nSQL> alter session force parallel query parallel 8;\nSession altered.\n \nSQL> select count(*) from \"&table_owner.\".\"&table_name.\" as of scn &scn_source;\nold 1: select count(*) from \"&table_owner.\".\"&table_name.\" as of scn &scn_source\nnew 1: select count(*) from \"REPOE\".\"ORDERS\" as of scn 6119162\n \n COUNT(*)\n--------------------\n 775433<\/code><\/pre>\nCounting rows on target<\/h3>\n
I’m doing the same fron the target, but with the SCN 4791515<\/p>\n
SQL> connect system\/manager@\/\/192.168.56.67\/XE\nConnected.\nSQL> alter session force parallel query parallel 8;\nSession altered.\n \nSQL> select count(*) from \"&table_owner.\".\"&table_name.\" as of scn &scn_target;\nold 1: select count(*) from \"&table_owner.\".\"&table_name.\" as of scn &scn_target\nnew 1: select count(*) from \"REPOE\".\"ORDERS\" as of scn 4791515\n \n COUNT(*)\n--------------------\n 775433<\/code><\/pre>\nGood. Same number of rows. This proves that even with constantly inserted tables we can find a point of comparison, thanks to Dbvisit heartbeat table and thanks to Oracle flashback query. If you are replicating with another logical replication product, you can simulate the heartbeat table with a job that updates the current SCN to a single row table, and replicate it. If your target is not Oracle, then there are good chances that you cannot do that kind of ‘as of’ query which means that you need to lock the table on source for the time you compare.<\/p>\n
ORA_HASH<\/h3>\n
If you think that counting the rows is not sufficient, you can compare a hash value from the columns. Here is an example.
\nI get the list of columns, with ORA_HASH() function on it, and sum() between them:<\/p>\n
SQL> column columns new_value columns\nSQL> select listagg('ORA_HASH('||column_name||')','+') within group (order by column_name) columns\n 2 from dba_tab_columns where owner='&table_owner.' and table_name='&table_name';\nold 2: from dba_tab_columns where owner='&table_owner.' and table_name='&table_name'\nnew 2: from dba_tab_columns where owner='REPOE' and table_name='ORDERS'\n \nCOLUMNS\n--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\nORA_HASH(CARD_ID)+ORA_HASH(COST_OF_DELIVERY)+ORA_HASH(CUSTOMER_CLASS)+ORA_HASH(CUSTOMER_ID)+ORA_HASH(DELIVERY_ADDRESS_ID)+ORA_HASH(DELIVERY_TYPE)+ORA_HASH(INVOICE_ADDRESS_ID)+ORA_HASH(ORDER_DATE)+ORA_\nHASH(ORDER_ID)+ORA_HASH(ORDER_MODE)+ORA_HASH(ORDER_STATUS)+ORA_HASH(ORDER_TOTAL)+ORA_HASH(PROMOTION_ID)+ORA_HASH(SALES_REP_ID)+ORA_HASH(WAIT_TILL_ALL_AVAILABLE)+ORA_HASH(WAREHOUSE_ID)<\/code><\/pre>\nWith this list defined in a substitution variable, I can compare the sum of hash values:<\/p>\n
SQL> select count(*),avg(&columns.) hash from \"&table_owner.\".\"&table_name.\" as of scn &scn_target;\nold 1: select count(*),sum(&columns.) hash from \"&table_owner.\".\"&table_name.\" as of scn &scn_target\nnew 1: select count(*),sum(ORA_HASH(CARD_ID)+ORA_HASH(COST_OF_DELIVERY)+ORA_HASH(CUSTOMER_CLASS)+ORA_HASH(CUSTOMER_ID)+ORA_HASH(DELIVERY_ADDRESS_ID)+ORA_HASH(DELIVERY_TYPE)+ORA_HASH(INVOICE_ADDRESS_ID)+ORA_HASH(ORDER_DATE)+ORA_HASH(ORDER_ID)+ORA_HASH(ORDER_MODE)+ORA_HASH(ORDER_STATUS)+ORA_HASH(ORDER_TOTAL)+ORA_HASH(PROMOTION_ID)+ORA_HASH(SALES_REP_ID)+ORA_HASH(WAIT_TILL_ALL_AVAILABLE)+ORA_HASH(WAREHOUSE_ID)) hash from \"REPOE\".\"ORDERS\" as of scn 4791515\n \n COUNT(*) HASH\n-------------------- --------------------\n 775433 317531150805040439\n \nSQL> connect system\/manager@\/\/192.168.56.66\/XE\nConnected.\nSQL> alter session force parallel query parallel 8;\nSession altered.\n \nSQL> select count(*),avg(&columns.) hash from \"&table_owner.\".\"&table_name.\" as of scn &scn_source;\nold 1: select count(*),sum(&columns.) hash from \"&table_owner.\".\"&table_name.\" as of scn &scn_source\nnew 1: select count(*),sum(ORA_HASH(CARD_ID)+ORA_HASH(COST_OF_DELIVERY)+ORA_HASH(CUSTOMER_CLASS)+ORA_HASH(CUSTOMER_ID)+ORA_HASH(DELIVERY_ADDRESS_ID)+ORA_HASH(DELIVERY_TYPE)+ORA_HASH(INVOICE_ADDRESS_ID)+ORA_HASH(ORDER_DATE)+ORA_HASH(ORDER_ID)+ORA_HASH(ORDER_MODE)+ORA_HASH(ORDER_STATUS)+ORA_HASH(ORDER_TOTAL)+ORA_HASH(PROMOTION_ID)+ORA_HASH(SALES_REP_ID)+ORA_HASH(WAIT_TILL_ALL_AVAILABLE)+ORA_HASH(WAREHOUSE_ID)) hash from \"REPOE\".\"ORDERS\" as of scn 6119162\n \n COUNT(*) HASH\n-------------------- --------------------\n 775433 17531150805040439<\/code><\/pre>\n Note that this is only an example. You must adapt for your needs: precision of the comparison and performance. <\/p>\n
So what?<\/h3>\n
Comparing source and target is not a bad idea. With Dbvisit replicate, if you defined the replication properly and did the initial import with the SCN provided by the setup wizard, you should not miss transactions, even when there is lot of activity on source, and even without locking the source for the initialisation. But it’s always good to compare, especially before the ‘Go’ decision of a migration done with Dbvisit replicate to lower the downtime (and the stress). Thanks to heartbeat table and flashback query, a checksum is not too hard to implement.<\/p>\n","protected":false},"excerpt":{"rendered":"
By Franck Pachot . You’ve setup a logical replication, and you trust it. But before the target goes into production, it will be safer to compare source and target. At least count the number of rows. But tables are continuously changing, so how can you compare? Not so difficult thanks to Dbvisit replicate heartbeat table […]<\/p>\n","protected":false},"author":27,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[229],"tags":[372,96],"type_dbi":[],"class_list":["post-8504","post","type-post","status-publish","format-standard","hentry","category-database-administration-monitoring","tag-dbvisit","tag-oracle"],"acf":[],"yoast_head":"\n
Compare source and target in a Dbvisit replication - dbi Blog<\/title>\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.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Compare source and target in a Dbvisit replication\" \/>\n<meta property=\"og:description\" content=\"By Franck Pachot . You’ve setup a logical replication, and you trust it. But before the target goes into production, it will be safer to compare source and target. At least count the number of rows. But tables are continuously changing, so how can you compare? Not so difficult thanks to Dbvisit replicate heartbeat table […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2016-07-05T16:51:20+00:00\" \/>\n<meta name=\"author\" content=\"Oracle Team\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Oracle Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"8 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"Compare source and target in a Dbvisit replication\",\"datePublished\":\"2016-07-05T16:51:20+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/\"},\"wordCount\":800,\"commentCount\":0,\"keywords\":[\"dbvisit\",\"Oracle\"],\"articleSection\":[\"Database Administration & Monitoring\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/\",\"name\":\"Compare source and target in a Dbvisit replication - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"datePublished\":\"2016-07-05T16:51:20+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Compare source and target in a Dbvisit replication\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\",\"name\":\"Oracle Team\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"caption\":\"Oracle Team\"},\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/oracle-team\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Compare source and target in a Dbvisit replication - dbi Blog","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.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/","og_locale":"en_US","og_type":"article","og_title":"Compare source and target in a Dbvisit replication","og_description":"By Franck Pachot . You’ve setup a logical replication, and you trust it. But before the target goes into production, it will be safer to compare source and target. At least count the number of rows. But tables are continuously changing, so how can you compare? Not so difficult thanks to Dbvisit replicate heartbeat table […]","og_url":"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/","og_site_name":"dbi Blog","article_published_time":"2016-07-05T16:51:20+00:00","author":"Oracle Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Oracle Team","Est. reading time":"8 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"Compare source and target in a Dbvisit replication","datePublished":"2016-07-05T16:51:20+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/"},"wordCount":800,"commentCount":0,"keywords":["dbvisit","Oracle"],"articleSection":["Database Administration & Monitoring"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/","url":"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/","name":"Compare source and target in a Dbvisit replication - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2016-07-05T16:51:20+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/compare-source-and-target-in-a-dbvisit-replication\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Compare source and target in a Dbvisit replication"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee","name":"Oracle Team","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","caption":"Oracle Team"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/oracle-team\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/8504","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/27"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=8504"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/8504\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=8504"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=8504"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=8504"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=8504"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}