.
\nBy a strange coincidence, I’ve encountered several cases of long parse time recently. That was the occasion to give a closer look at a CBO trace enhancement that came with April 2016 PSU: Bug 16923858 Diagnostic enhancement to annotate 10053 trace with accumulated parse time
\n
\nI have a query that takes several seconds to parse and here is the new parse time information when you trace SQL_Compiler (the 10053 trace):<\/p>\n
$ grep TIMER db003_ora_22231_orig.trc\nTIMER: costing additional plans cpu: 1.807 sec elapsed: 2.019 sec\nTIMER: costing general plans cpu: 26.131 sec elapsed: 27.747 sec\nTIMER: costing additional plans cpu: 8.995 sec elapsed: 9.329 sec\nTIMER: SU: costing SEL$A2089C65 cpu: 38.313 sec elapsed: 40.506 sec\nTIMER: costing additional plans cpu: 1.523 sec elapsed: 1.850 sec\nTIMER: SU: costing Interleaved CVM SEL$488B5694 cpu: 4.255 sec elapsed: 4.807 sec\nTIMER: SU: Interleaved CVM SEL$A2089C65 cpu: 4.293 sec elapsed: 4.846 sec\nTIMER: i costing additional plans cpu: 1.742 sec elapsed: 1.884 sec\nTIMER: i costing general plans cpu: 21.343 sec elapsed: 21.843 sec\nTIMER: i costing additional plans cpu: 8.072 sec elapsed: 8.375 sec\nTIMER: i JPPD: costing SEL$A2089C65 cpu: 32.798 sec elapsed: 33.838 sec\nTIMER: i JPPD: iteration (#1) SEL$A2089C65 cpu: 32.822 sec elapsed: 33.863 sec\nTIMER: i costing general plans cpu: 22.088 sec elapsed: 22.751 sec\nTIMER: i costing additional plans cpu: 5.484 sec elapsed: 5.745 sec\nTIMER: i JPPD: costing SEL$A2089C65 cpu: 30.181 sec elapsed: 31.113 sec\nTIMER: i JPPD: iteration (#2) SEL$A2089C65 cpu: 30.197 sec elapsed: 31.129 sec\nTIMER: SU: Interleaved JPPD SEL$A2089C65 cpu: 63.026 sec elapsed: 64.999 sec\nTIMER: SU: iteration (#1) SEL$A2089C65 cpu: 105.656 sec elapsed: 110.375 sec\nTIMER: SU: costing SEL$EB7B6E47 cpu: 3.749 sec elapsed: 4.025 sec\nTIMER: SU: iteration (#2) SEL$EB7B6E47 cpu: 3.762 sec elapsed: 4.038 sec\nTIMER: CBQT SU and CVM SEL$1 cpu: 109.512 sec elapsed: 114.507 sec\nTIMER: Cost-Based Transformations (Overall) SEL$62E0E936 cpu: 110.118 sec elapsed: 115.112 sec\nTIMER: costing additional plans cpu: 1.247 sec elapsed: 1.485 sec\nTIMER: Access Path Analysis (Final) SEL$62E0E936 cpu: 2.227 sec elapsed: 2.227 sec\nTIMER: SQL Optimization (Overall) SEL$62E0E936 cpu: 114.674 sec elapsed: 119.906 sec<\/code><\/pre>\nThe default is to have a line when an operation takes more than 1 second. You can change that with the fix control:<\/p>\n
This will trace all times > 10 microseconds:<\/p>\n
alter session set \"_fix_control\"='16923858:1';<\/code><\/pre>\nThis will trace all times > 10 seconds:<\/p>\n
alter session set \"_fix_control\"='16923858:7';<\/code><\/pre>\nYou get it: each level increases the threshold to the next order of magnitude, the default is 6 (1 second)<\/p>\n
I’ve a small awk script to display the time in a better format:<\/p>\n
\n cpu(ms) ela(ms)\n 42138.000 42159.000 costing general plans 12.1.0.2 640468\n 6416.000 6418.000 costing additional plans 12.1.0.2 719893\n 1509.000 1509.000 costing general plans 12.1.0.2 753749\n 2377.000 2377.000 or expansion check 12.1.0.2 763107\n 52698.000 52721.000 SU: costing SEL$5061678E (SUBQUERY UNNEST SEL$93416A64; SEL$10) 12.1.0.2 763120\n 2035.000 2035.000 costing general plans 12.1.0.2 842348\n 2642.000 2642.000 or expansion check 12.1.0.2 849927\n 4920.000 4921.000 SU: costing Interleaved CVM SEL$959A6A10 (VIEW MERGE SEL$5061678E; SEL$CAA3F13B) 12.1.0.2 849940\n 4941.000 4942.000 SU: Interleaved CVM SEL$5061678E (SUBQUERY UNNEST SEL$93416A64; SEL$10) 12.1.0.2 849942\n 42556.000 42568.000 i costing general plans 12.1.0.2 1482291\n 6348.000 6348.000 i costing additional plans 12.1.0.2 1561716\n 1653.000 1653.000 i costing general plans 12.1.0.2 1595574\n 2487.000 2488.000 i or expansion check 12.1.0.2 1604932\n 52924.000 52938.000 i JPPD: costing SEL$5061678E (SUBQUERY UNNEST SEL$93416A64; SEL$10)(COPY SEL$5061678E) 12.1.0.2 1604945\n 52933.000 52947.000 i JPPD: iteration (#1) SEL$5061678E (SUBQUERY UNNEST SEL$93416A64; SEL$10)(COPY SEL$5061678E) 12.1.0.2 1604956\n 1116.000 1116.000 i costing additional plans 12.1.0.2 1630694\n 33570.000 33576.000 i costing general plans 12.1.0.2 2098660\n 10614.000 10622.000 i costing additional plans 12.1.0.2 2211397\n 2092.000 2093.000 i costing general plans 12.1.0.2 2246743\n 1396.000 1397.000 i costing additional plans 12.1.0.2 2264252\n 3778.000 3780.000 i or expansion check 12.1.0.2 2265816\n 50741.000 50759.000 i JPPD: costing SEL$5061678E (SUBQUERY UNNEST SEL$93416A64; SEL$10)(COPY SEL$5061678E) 12.1.0.2 2265829\n 50752.000 50769.000 i JPPD: iteration (#2) SEL$5061678E (SUBQUERY UNNEST SEL$93416A64; SEL$10)(COPY SEL$5061678E) 12.1.0.2 2265839\n103688.000 103719.000 SU: Interleaved JPPD SEL$5061678E (SUBQUERY UNNEST SEL$93416A64; SEL$10)(COPY SEL$5061678E) 12.1.0.2 2265844\n161339.000 161394.000 SU: iteration (#1) SEL$5061678E (SUBQUERY UNNEST SEL$93416A64; SEL$10)(COPY SEL$5061678E) 12.1.0.2 2265846\n 3250.000 3252.000 SU: costing SEL$1 (PARSER)(COPY SEL$1) 12.1.0.2 2307338\n 3262.000 3264.000 SU: iteration (#2) SEL$1 (PARSER)(COPY SEL$1) 12.1.0.2 2307349\n164632.000 164689.000 CBQT SU and CVM SEL$1 (PARSER)(COPY SEL$1) 12.1.0.2 2307498\n164827.000 164884.000 Cost-Based Transformations (Overall) SEL$1 (PARSER)(COPY SEL$1) 12.1.0.2 2307946\n 2577.000 2578.000 costing general plans 12.1.0.2 2387060\n 3204.000 3204.000 or expansion check 12.1.0.2 2393273\n 4597.000 4598.000 Access Path Analysis (Final) SEL$1 (PARSER)(COPY SEL$1) 12.1.0.2 2393703\n170872.000 170931.000 SQL Optimization (Overall) SEL$1 (PARSER)(COPY SEL$1) 12.1.0.2 2393730\n<\/code><\/pre>\nNote that I’m more interested by the CPU time because the elapsed time includes the time to write to the trace.
\nI’m reading a 2 million line 10053 trace file here. The CBO takes time but is doing lot of work here.<\/p>\n
My awk script also records the maximum time spend on each query block and then displays the ‘Query Block Registry’ with those times. This is a good way to understand which CBO transformation is responsible for most of the parse time:<\/p>\n
\n cpu(ms) ela(ms) Query Block Registry:\n 0.000 0.000 SEL$10 0x897e9b8 (PARSER) [FINAL]\n161339.000 161394.000 SEL$5061678E 0x0 (SUBQUERY UNNEST SEL$93416A64; SEL$10)\n 0.000 0.000 SEL$6F0423A9 0x0 (PUSHED PREDICATE SEL$CAA3F13B; SEL$5061678E; \"VW_SQ_3\"@\"SEL$93416A64\" 28)\n 0.000 0.000 SEL$959A6A10 0x0 (VIEW MERGE SEL$5061678E; SEL$CAA3F13B)\n 0.000 0.000 SEL$1DF60DFD 0x0 (QUERY BLOCK TABLES CHANGED SEL$10)\n 0.000 0.000 SEL$CAA3F13B 0x0 (SUBQ INTO VIEW FOR COMPLEX UNNEST SEL$1DF60DFD)\n 0.000 0.000 SEL$6F0423A9 0x0 (PUSHED PREDICATE SEL$CAA3F13B; SEL$5061678E; \"VW_SQ_3\"@\"SEL$93416A64\" 28)\n 0.000 0.000 SEL$959A6A10 0x0 (VIEW MERGE SEL$5061678E; SEL$CAA3F13B)\n 0.000 0.000 SEL$9 0x8987df0 (PARSER) [FINAL]\n 0.000 0.000 SEL$8 0x8988ee8 (PARSER) [FINAL]\n 0.000 0.000 SEL$7 0x898a4f8 (PARSER) [FINAL]\n 0.000 0.000 SEL$6 0x898c028 (PARSER) [FINAL]\n 0.000 0.000 SEL$5 0x898d268 (PARSER) [FINAL]\n 0.000 0.000 SEL$4 0x898eaf8 (PARSER) [FINAL]\n 0.000 0.000 SEL$3 0x89912b8 (PARSER) [FINAL]\n 0.000 0.000 SEL$2 0x89923c0 (PARSER) [FINAL]\n170872.000 170931.000 SEL$1 0x89a3ef0 (PARSER) [FINAL]\n 0.000 0.000 SEL$93416A64 0x0 (VIEW ADDED SEL$1)\n161339.000 161394.000 SEL$5061678E 0x0 (SUBQUERY UNNEST SEL$93416A64; SEL$10)\n 0.000 0.000 ...\n<\/code><\/pre>\nThe interesting point here is that the [FINAL] is the transformation that is chosen by the optimizer, so we know that we have spent time on a query block that has been finally chosen for the best plan.<\/p>\n
Before going further, here is my ugly awk script that gives the above output from a 10053 trace file:<\/p>\n
\nBEGIN{\n print ; print \" cpu(ms) ela(ms)\"\n}\n\/^ *optimizer_features_enable += +\/{\n ofe=$3 ; sub(\/^[8-9][.]\/,\"0&\",ofe)\n delete qb\n}\n\/TIMER\/{\n l=$0 ; sub(\/ cpu: .*$\/,\"\",l) ; sub(\/TIMER: \/,\"\",l)\n sub(\/^.* cpu: \/,\"\") # --> $1 is cpu $4 is ela\n q=gensub(\/^.* \/,\"\",\"g\",l);\n if ( qb[q] == \"\" ) { q=\"\" } else { sub(\/ [^ ]*$\/,\"\",l) }\n if ( q!=\"\" && $1*1e3 > cpu[q] ) cpu[q]=$1*1e3\n if ( q!=\"\" && $4*1e3 > ela[q] ) ela[q]=$4*1e3\n printf \"%10.3f %10.3ft%-40s %20s %-60st%6s %sn\",$1*1e3,$4*1e3,l,q,qb[q],ofe,NR\n if ( q != \"\") versions[l\" \"q]=versions[l\" \"q] ofe\"=\"($1*1e3)\"msn\"\n}\n\/Query Block Registry\/,\/^:\/{\n if ( $0 ~\/Query Block Registry\/ ) { ; print \"\" ; print \" cpu(ms) ela(ms) \"$0 ; print \"\" }\n else { printf \"%10.3f %10.3ft%sn\",cpu[$1],ela[$1],$0 }\n}\n<\/code><\/pre>\nSo, I know that the unnesting of subquery SEL$10 is responsible for my long parse time. The ‘+alias’ format of the explain plan is an easy way to find which subquery it is comes from, :<\/p>\n
Query Block Name \/ Object Alias (identified by operation id):\n-------------------------------------------------------------\n \n 64 - SEL$10\n 65 - SEL$10 \/ TABLE_WITH_DATES@SEL$10\n 66 - SEL$10 \/ TABLE_WITH_DATES@SEL$10<\/code><\/pre>\nHere is the subselect (I redacted the table names).<\/p>\n
AND begin_date =\n (SELECT MAX (begin_date)\n FROM table_with_dates\n WHERE some_id = some_id\n AND begin_date <= ...\n )<\/code><\/pre>\nSo what can I do from now? I can avoid the subquery unnesting by adding the NO_UNNEST hin in the subquery, or add it to the main query as \/*+ NO_UNNEST( @SEL$10) *\/<\/strong><\/p>\nThis really reduces the parse time, but I have to check that the plan is still acceptable. Actually we cannot blame the CBO for the time it takes here, because the goal of subquery unnesting (SU) is exactly that: open the way to lot of new access path, that can be cost based and may give a better execution plan. And an application should not parse too often, so spending a few seconds in parsing is not bad if it helps to execute the query quickly all over the day.<\/p>\n
So don’t forget to have the latest PSU and trace with:<\/p>\n
alter session set events 'trace [SQL_Compiler.*]';\nexplain plan for ...\nalter session set events 'trace [SQL_Compiler.*] off';<\/code><\/pre>\nget timer information with:<\/p>\n
column value new_value tracefile\nselect value from v$diag_info where name='Default Trace File';\ncolumn value new_value clear\nhost grep TIMER &tracefile<\/code><\/pre>\nAnd find which transformation is responsible for most of the parse time.<\/p>\n","protected":false},"excerpt":{"rendered":"
By Franck Pachot . By a strange coincidence, I’ve encountered several cases of long parse time recently. That was the occasion to give a closer look at a CBO trace enhancement that came with April 2016 PSU: Bug 16923858 Diagnostic enhancement to annotate 10053 trace with accumulated parse time<\/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":[736,96],"type_dbi":[],"class_list":["post-9700","post","type-post","status-publish","format-standard","hentry","category-database-administration-monitoring","tag-cbo","tag-oracle"],"acf":[],"yoast_head":"\n
CBO parse time - matching time with transformation - 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\/cbo-parse-time-match-time-with-transformation\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"CBO parse time - matching time with transformation\" \/>\n<meta property=\"og:description\" content=\"By Franck Pachot . By a strange coincidence, I’ve encountered several cases of long parse time recently. That was the occasion to give a closer look at a CBO trace enhancement that came with April 2016 PSU: Bug 16923858 Diagnostic enhancement to annotate 10053 trace with accumulated parse time\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2017-02-04T19:36:16+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\/cbo-parse-time-match-time-with-transformation\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"CBO parse time – matching time with transformation\",\"datePublished\":\"2017-02-04T19:36:16+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/\"},\"wordCount\":481,\"commentCount\":0,\"keywords\":[\"CBO\",\"Oracle\"],\"articleSection\":[\"Database Administration & Monitoring\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/\",\"name\":\"CBO parse time - matching time with transformation - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"datePublished\":\"2017-02-04T19:36:16+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"CBO parse time – matching time with transformation\"}]},{\"@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":"CBO parse time - matching time with transformation - 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\/cbo-parse-time-match-time-with-transformation\/","og_locale":"en_US","og_type":"article","og_title":"CBO parse time - matching time with transformation","og_description":"By Franck Pachot . By a strange coincidence, I’ve encountered several cases of long parse time recently. That was the occasion to give a closer look at a CBO trace enhancement that came with April 2016 PSU: Bug 16923858 Diagnostic enhancement to annotate 10053 trace with accumulated parse time","og_url":"https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/","og_site_name":"dbi Blog","article_published_time":"2017-02-04T19:36:16+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\/cbo-parse-time-match-time-with-transformation\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"CBO parse time – matching time with transformation","datePublished":"2017-02-04T19:36:16+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/"},"wordCount":481,"commentCount":0,"keywords":["CBO","Oracle"],"articleSection":["Database Administration & Monitoring"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/","url":"https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/","name":"CBO parse time - matching time with transformation - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2017-02-04T19:36:16+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/cbo-parse-time-match-time-with-transformation\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"CBO parse time – matching time with transformation"}]},{"@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\/9700","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=9700"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/9700\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=9700"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=9700"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=9700"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=9700"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}