.
\nToday I was doing a hard parse storm post-mortem analysis. One hypothesis was rolling invalidation causing invalidation, but figures didn’t match. I often reproduce the hypothesis to check the numbers to be sure I interpret them correctly. Especially the timestamps in V$SQL_SHARED_CURSOR.REASON. And as it may help others (including myself in the future) I share the test case.
\n
\nI create a table with one row (12c online statistics gathering, so num_rows is 1) and then insert one more row.<\/p>\n
\n21:31:26 SQL> create table DEMO as select * from dual;\nTable created.\n21:31:26 SQL> insert into DEMO select * from dual;\n1 row created.\n21:31:26 SQL> commit;\nCommit complete.\n<\/code><\/pre>\nI run a query on the table. I don’t care about the result, so let’s put it something that will be useful later: the UTC time as the number of seconds since Jan 1st, 1970 (aka Epoch)<\/p>\n
\n21:32:52 SQL> select (cast(sys_extract_utc(current_timestamp) as date)-date'1970-01-01')*24*3600 from DEMO;\n \n(CAST(SYS_EXTRACT_UTC(CURRENT_TIMESTAMP)ASDATE)-DATE'1970-01-01')*24*3600\n-------------------------------------------------------------------------\n 1472585572\n 1472585572\n<\/code><\/pre>\nThe execution plan cardinality estimation is 1 row as this is what is in object statistics.<\/p>\n
\n21:32:52 SQL> select * from table(dbms_xplan.display_cursor(null,null));\n \nPLAN_TABLE_OUTPUT\n------------------------------------------------------------------------------------------------------------------------\nSQL_ID 61x2h0y9zv0r6, child number 0\n-------------------------------------\nselect (cast(sys_extract_utc(current_timestamp) as\ndate)-date'1970-01-01')*24*3600 from DEMO\n \nPlan hash value: 4000794843\n \n------------------------------------------------------------------\n| Id | Operation | Name | Rows | Cost (%CPU)| Time |\n------------------------------------------------------------------\n| 0 | SELECT STATEMENT | | | 2 (100)| |\n| 1 | TABLE ACCESS FULL| DEMO | 1 | 2 (0)| 00:00:01 |\n------------------------------------------------------------------\n<\/code><\/pre>\nI gather statistics with all default attributes, so rolling invalidation occurs.<\/p>\n
\n21:32:52 SQL> exec dbms_stats.gather_table_stats(user,'DEMO');\nPL\/SQL procedure successfully completed.\n<\/code><\/pre>\nAt this time, the cursor has been parsed only once:<\/p>\n
\n21:32:52 SQL> select invalidations,loads,parse_calls,executions,first_load_time,last_load_time,last_active_time from v$sql where sql_id='61x2h0y9zv0r6';\n \nINVALIDATIONS LOADS PARSE_CALLS EXECUTIONS FIRST_LOAD_TIME LAST_LOAD_TIME LAST_ACTIVE_TIME\n------------- ---------- ----------- ---------- ------------------- ------------------- ------------------\n 0 1 1 1 2016-08-30\/21:32:51 2016-08-30\/21:32:51 30-AUG-16 21:32:51\n<\/code><\/pre>\nBy default the invalidation window is 5 hours. I don’t want to wait so I set it to something shorter- 15 seconds:<\/p>\n
\n21:32:54 SQL> alter system set \"_optimizer_invalidation_period\"=15;\nSystem altered.\n<\/code><\/pre>\nThere will not be any invalidation until the next execution. To prove it I wait 20 seconds, run the query again and check the execution plan:<\/p>\n
\n21:33:12 SQL> select (sysdate-date'1970-01-01')*24*3600 from DEMO;\n \n(SYSDATE-DATE'1970-01-01')*24*3600\n----------------------------------\n 1472592792\n 1472592792\n \n21:33:12 SQL> select * from table(dbms_xplan.display_cursor('61x2h0y9zv0r6',null));\n \nPLAN_TABLE_OUTPUT\n------------------------------------------------------------------------------------------------------------------------\nSQL_ID 61x2h0y9zv0r6, child number 0\n-------------------------------------\nselect (cast(sys_extract_utc(current_timestamp) as\ndate)-date'1970-01-01')*24*3600 from DEMO\n \nPlan hash value: 4000794843\n \n------------------------------------------------------------------\n| Id | Operation | Name | Rows | Cost (%CPU)| Time |\n------------------------------------------------------------------\n| 0 | SELECT STATEMENT | | | 2 (100)| |\n| 1 | TABLE ACCESS FULL| DEMO | 1 | 2 (0)| 00:00:01 |\n------------------------------------------------------------------\n<\/code><\/pre>\nThis is still the old cursor (child number 0) with old stats (num_rows=1)<\/p>\n
However, from this point rolling invalidation occurs: a random timestamp is generated within the rolling window (15 seconds here – 5 hours in default database).<\/p>\n
I don’t know how to see this timestamp at that point (comments welcome) so I run the query several times within this 15 seconds window to see when it occurs:<\/p>\n
\n21:33:16 SQL> select (cast(sys_extract_utc(current_timestamp) as date)-date'1970-01-01')*24*3600 from DEMO;\n \n(CAST(SYS_EXTRACT_UTC(CURRENT_TIMESTAMP)ASDATE)-DATE'1970-01-01')*24*3600\n-------------------------------------------------------------------------\n 1472585596\n 1472585596\n \n21:33:19 SQL> select (cast(sys_extract_utc(current_timestamp) as date)-date'1970-01-01')*24*3600 from DEMO;\n \n(CAST(SYS_EXTRACT_UTC(CURRENT_TIMESTAMP)ASDATE)-DATE'1970-01-01')*24*3600\n-------------------------------------------------------------------------\n 1472585599\n 1472585599\n \n21:33:22 SQL> select (cast(sys_extract_utc(current_timestamp) as date)-date'1970-01-01')*24*3600 from DEMO;\n \n(CAST(SYS_EXTRACT_UTC(CURRENT_TIMESTAMP)ASDATE)-DATE'1970-01-01')*24*3600\n-------------------------------------------------------------------------\n 1472585602\n 1472585602\n \n21:33:25 SQL> select (cast(sys_extract_utc(current_timestamp) as date)-date'1970-01-01')*24*3600 from DEMO;\n \n(CAST(SYS_EXTRACT_UTC(CURRENT_TIMESTAMP)ASDATE)-DATE'1970-01-01')*24*3600\n-------------------------------------------------------------------------\n 1472585605\n 1472585605\n \n21:33:28 SQL> select (cast(sys_extract_utc(current_timestamp) as date)-date'1970-01-01')*24*3600 from DEMO;\n \n(CAST(SYS_EXTRACT_UTC(CURRENT_TIMESTAMP)ASDATE)-DATE'1970-01-01')*24*3600\n-------------------------------------------------------------------------\n 1472585608\n 1472585608\n \n21:33:31 SQL> select (cast(sys_extract_utc(current_timestamp) as date)-date'1970-01-01')*24*3600 from DEMO;\n \n(CAST(SYS_EXTRACT_UTC(CURRENT_TIMESTAMP)ASDATE)-DATE'1970-01-01')*24*3600\n-------------------------------------------------------------------------\n 1472585611\n 1472585611\n<\/code><\/pre>\nAfter those runs, I check that I have a new execution plan with new estimation from new statistics (num_rows=2):<\/p>\n
\n21:33:31 SQL> select * from table(dbms_xplan.display_cursor('61x2h0y9zv0r6',null));\n \nPLAN_TABLE_OUTPUT\n------------------------------------------------------------------------------------------------------------------------\nSQL_ID 61x2h0y9zv0r6, child number 0\n-------------------------------------\nselect (cast(sys_extract_utc(current_timestamp) as\ndate)-date'1970-01-01')*24*3600 from DEMO\n \nPlan hash value: 4000794843\n \n------------------------------------------------------------------\n| Id | Operation | Name | Rows | Cost (%CPU)| Time |\n------------------------------------------------------------------\n| 0 | SELECT STATEMENT | | | 2 (100)| |\n| 1 | TABLE ACCESS FULL| DEMO | 1 | 2 (0)| 00:00:01 |\n------------------------------------------------------------------\n \nSQL_ID 61x2h0y9zv0r6, child number 1\n-------------------------------------\nselect (cast(sys_extract_utc(current_timestamp) as\ndate)-date'1970-01-01')*24*3600 from DEMO\n \nPlan hash value: 4000794843\n \n------------------------------------------------------------------\n| Id | Operation | Name | Rows | Cost (%CPU)| Time |\n------------------------------------------------------------------\n| 0 | SELECT STATEMENT | | | 2 (100)| |\n| 1 | TABLE ACCESS FULL| DEMO | 2 | 2 (0)| 00:00:01 |\n------------------------------------------------------------------\n<\/code><\/pre>\nYes, I have a new child cursor, child number 1. A new cursor means that I have a reason in V$SQL_SHARED_CURSOR:<\/p>\n
\n21:33:31 SQL> select child_number,reason from v$sql_shared_cursor where sql_id='61x2h0y9zv0r6';\n \nCHILD_NUMBER REASON\n------------ --------------------------------------------------------------------------------\n 0 <ChildNode><ChildNumber>0<\/ChildNumber><ID>33<\/ID><reason>Rolling Invalidate Win\n dow Exceeded(2)<\/reason><size>0x0<\/size><details>already_processed<\/details><\/Ch\n ildNode><ChildNode><ChildNumber>0<\/ChildNumber><ID>33<\/ID><reason>Rolling Invali\n date Window Exceeded(3)<\/reason><size>2x4<\/size><invalidation_window>1472585604<\n \/invalidation_window><ksugctm>1472585607<\/ksugctm><\/ChildNode>\n \n 1\n<\/code><\/pre>\nChild cursor number 0 has not been shared because of rolling invalidation. The invalidation_window number, 1472585604, is the timestamp set by rolling invalidation, set at first parse call (or execution) after stats gathering, and defined within the rolling window that follows. After this one (1472585604 is 21:33:24 in my GMT+2 timezone) the cursor will not be shared and a new hard parse occurs. I think that ksugctm is the timestamp when the new cursor is created. 1472585607 is 21:33:27 here in Switzerland. You see the corresponding timestamps in V$SQL:<\/p>\n
\n21:33:31 SQL> select invalidations,loads,parse_calls,executions,first_load_time,last_load_time,last_active_time from v$sql where sql_id='61x2h0y9zv0r6';\n \nINVALIDATIONS LOADS PARSE_CALLS EXECUTIONS FIRST_LOAD_TIME LAST_LOAD_TIME LAST_ACTIVE_TIME\n------------- ---------- ----------- ---------- ------------------- ------------------- ------------------\n 0 1 5 5 2016-08-30\/21:32:51 2016-08-30\/21:32:51 30-AUG-16 21:33:24\n 0 1 2 2 2016-08-30\/21:32:51 2016-08-30\/21:33:27 30-AUG-16 21:33:30\n<\/code><\/pre>\nOk. Important thing is that the ‘rolling invalidation’ is not an invalidation (as V$SQL.INVALIDATIONS=0) of the cursor, but just non-sharing of the child.<\/p>\n
If we gather statistics with immediate invalidation, it’s different:<\/p>\n
\n21:33:31 SQL> exec dbms_stats.gather_table_stats(user,'DEMO',no_invalidate=>false);\nPL\/SQL procedure successfully completed.\n \n21:33:34 SQL> select (cast(sys_extract_utc(current_timestamp) as date)-date'1970-01-01')*24*3600 from DEMO;\n \n(CAST(SYS_EXTRACT_UTC(CURRENT_TIMESTAMP)ASDATE)-DATE'1970-01-01')*24*3600\n-------------------------------------------------------------------------\n 1472585614\n 1472585614\n21:33:34 SQL> select child_number,reason from v$sql_shared_cursor where sql_id='61x2h0y9zv0r6';\n \nCHILD_NUMBER REASON\n------------ --------------------------------------------------------------------------------\n 0 <ChildNode><ChildNumber>0<\/ChildNumber><ID>33<\/ID><reason>Rolling Invalidate Win\n dow Exceeded(3)<\/reason><size>2x4<\/size><invalidation_window>1472585604<\/invalid\n ation_window><ksugctm>1472585607<\/ksugctm><\/ChildNode><ChildNode><ChildNumber>0<\n \/ChildNumber><ID>33<\/ID><reason>Rolling Invalidate Window Exceeded(2)<\/reason><s\n ize>0x0<\/size><details>already_processed<\/details><\/ChildNode>\n<\/code><\/pre>\nI’ve only one child here, a new one, and I’m not sure the reason has a meaning.<\/p>\n
\n21:33:34 SQL> select invalidations,loads,parse_calls,executions,first_load_time,last_load_time,last_active_time from v$sql where sql_id='61x2h0y9zv0r6';\n \nINVALIDATIONS LOADS PARSE_CALLS EXECUTIONS FIRST_LOAD_TIME LAST_LOAD_TIME LAST_ACTIVE_TIME\n------------- ---------- ----------- ---------- ------------------- ------------------- ------------------\n 1 2 1 1 2016-08-30\/21:32:51 2016-08-30\/21:33:33 30-AUG-16 21:33:33\n<\/code><\/pre>\nThis is an invalidation of the cursor. Old children cursors are removed and the proud parent is marked as invalidated 1 time.<\/p>\n","protected":false},"excerpt":{"rendered":"
By Franck Pachot . Today I was doing a hard parse storm post-mortem analysis. One hypothesis was rolling invalidation causing invalidation, but figures didn’t match. I often reproduce the hypothesis to check the numbers to be sure I interpret them correctly. Especially the timestamps in V$SQL_SHARED_CURSOR.REASON. And as it may help others (including myself in […]<\/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":[96,255],"type_dbi":[],"class_list":["post-8766","post","type-post","status-publish","format-standard","hentry","category-database-administration-monitoring","tag-oracle","tag-statistics"],"acf":[],"yoast_head":"\n
Rolling Invalidate Window Exceeded - 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\/rolling-invalidate-window-exceeded\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Rolling Invalidate Window Exceeded\" \/>\n<meta property=\"og:description\" content=\"By Franck Pachot . Today I was doing a hard parse storm post-mortem analysis. One hypothesis was rolling invalidation causing invalidation, but figures didn’t match. I often reproduce the hypothesis to check the numbers to be sure I interpret them correctly. Especially the timestamps in V$SQL_SHARED_CURSOR.REASON. And as it may help others (including myself in […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/rolling-invalidate-window-exceeded\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2016-08-30T19:05:47+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=\"7 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\\\/rolling-invalidate-window-exceeded\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/rolling-invalidate-window-exceeded\\\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"Rolling Invalidate Window Exceeded\",\"datePublished\":\"2016-08-30T19:05:47+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/rolling-invalidate-window-exceeded\\\/\"},\"wordCount\":480,\"commentCount\":0,\"keywords\":[\"Oracle\",\"Statistics\"],\"articleSection\":[\"Database Administration & Monitoring\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/rolling-invalidate-window-exceeded\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/rolling-invalidate-window-exceeded\\\/\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/rolling-invalidate-window-exceeded\\\/\",\"name\":\"Rolling Invalidate Window Exceeded - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\"},\"datePublished\":\"2016-08-30T19:05:47+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/66ab87129f2d357f09971bc7936a77ee\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/rolling-invalidate-window-exceeded\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/rolling-invalidate-window-exceeded\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/rolling-invalidate-window-exceeded\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Rolling Invalidate Window Exceeded\"}]},{\"@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":"Rolling Invalidate Window Exceeded - 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\/rolling-invalidate-window-exceeded\/","og_locale":"en_US","og_type":"article","og_title":"Rolling Invalidate Window Exceeded","og_description":"By Franck Pachot . Today I was doing a hard parse storm post-mortem analysis. One hypothesis was rolling invalidation causing invalidation, but figures didn’t match. I often reproduce the hypothesis to check the numbers to be sure I interpret them correctly. Especially the timestamps in V$SQL_SHARED_CURSOR.REASON. And as it may help others (including myself in […]","og_url":"https:\/\/www.dbi-services.com\/blog\/rolling-invalidate-window-exceeded\/","og_site_name":"dbi Blog","article_published_time":"2016-08-30T19:05:47+00:00","author":"Oracle Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Oracle Team","Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/rolling-invalidate-window-exceeded\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/rolling-invalidate-window-exceeded\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"Rolling Invalidate Window Exceeded","datePublished":"2016-08-30T19:05:47+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/rolling-invalidate-window-exceeded\/"},"wordCount":480,"commentCount":0,"keywords":["Oracle","Statistics"],"articleSection":["Database Administration & Monitoring"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/rolling-invalidate-window-exceeded\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/rolling-invalidate-window-exceeded\/","url":"https:\/\/www.dbi-services.com\/blog\/rolling-invalidate-window-exceeded\/","name":"Rolling Invalidate Window Exceeded - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2016-08-30T19:05:47+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/rolling-invalidate-window-exceeded\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/rolling-invalidate-window-exceeded\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/rolling-invalidate-window-exceeded\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Rolling Invalidate Window Exceeded"}]},{"@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\/8766","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=8766"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/8766\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=8766"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=8766"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=8766"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=8766"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}