{"id":4415,"date":"2015-03-15T19:16:20","date_gmt":"2015-03-15T18:16:20","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/index-on-truncdate-do-you-still-need-old-index\/"},"modified":"2015-03-15T19:16:20","modified_gmt":"2015-03-15T18:16:20","slug":"index-on-truncdate-do-you-still-need-old-index","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/index-on-truncdate-do-you-still-need-old-index\/","title":{"rendered":"Index on trunc(date) – do you still need old index?"},"content":{"rendered":"

By Franck Pachot<\/h2>\n

.
\nSometimes we have to index on ( trunc(date) ) because a SQL statement uses predicate on it instead of giving a range from midnight to midnight. When you do that you probably keep the index on the column. That’s two indexes to maintain for DML. Do we need it?<\/p>\n

I’ll show a feature that appeared in 11.2.0.2 (info from oracle-l<\/a>) so let’s set the optimizer to behave as before that feature.<\/p>\n

SQL> alter session set optimizer_features_enable='11.2.0.1';\nSession altered.\n<\/code><\/pre>\n
I create the following table with a date column;<\/p>\n
SQL> create table DEMO as select prod_id,prod_name,prod_eff_from +rownum\/0.3 prod_date from sh.products,(select * from dual connect by 1000\u02c2=level);\nTable created.\n<\/code><\/pre>\n
and I have an index on the date column:<\/p>\n
SQL> create index PROD_NAME on DEMO(prod_name);\nIndex created.\n\nSQL> create index PROD_DATE on DEMO(prod_date);\nIndex created.\n<\/code><\/pre>\n
The index on the name is for another blog post…<\/p>\n
\u00a0trunc(date)=…<\/h3>\n
It’s quite common to encounter a query that TRUNC the column in order to search for a date – whatever the time component is. We all know that it is better to use a BETWEEN because applying a function an indexed column prevents the index access:<\/p>\n
SQL> set autotrace trace explain\nSQL> select * from DEMO where trunc(prod_date)=date'2015-01-01';\n\nExecution Plan\n----------------------------------------------------------\nPlan hash value: 4000794843\n\n---------------------------------------------------------------\n| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)|\n---------------------------------------------------------------\n|   0 | SELECT STATEMENT  |      |     1 |    49 |     2   (0)|\n|*  1 |  TABLE ACCESS FULL| DEMO |     1 |    49 |     2   (0)|\n---------------------------------------------------------------\n\nPredicate Information (identified by operation id):\n---------------------------------------------------\n\n   1 - filter(TRUNC(INTERNAL_FUNCTION(\"PROD_DATE\"))=TO_DATE('\n              2015-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))\n<\/code><\/pre>\n
 <\/p>\n
But sometimes we can’t change the query and just have to find a workaround. And function based indexes are a gread help for that:<\/p>\n
SQL> create index PROD_DATE_TRUNC on DEMO( trunc(prod_date) );\nIndex created.\n<\/code><\/pre>\n
and that index can be used for the query above:<\/p>\n
SQL> select * from DEMO where trunc(prod_date)=date'2015-01-01';\n\nExecution Plan\n----------------------------------------------------------\nPlan hash value: 1760965557\n\n------------------------------------------------------------------------------------\n| Id  | Operation                   | Name            | Rows  | Bytes | Cost (%CPU)|\n------------------------------------------------------------------------------------\n|   0 | SELECT STATEMENT            |                 |     1 |    58 |     1   (0)|\n|   1 |  TABLE ACCESS BY INDEX ROWID| DEMO            |     1 |    58 |     1   (0)|\n|*  2 |   INDEX RANGE SCAN          | PROD_DATE_TRUNC |     1 |       |     1   (0)|\n------------------------------------------------------------------------------------\n\nPredicate Information (identified by operation id):\n---------------------------------------------------\n\n   2 - access(TRUNC(INTERNAL_FUNCTION(\"PROD_DATE\"))=TO_DATE(' 2015-01-01 00:00:00',\n              'syyyy-mm-dd hh24:mi:ss'))\n<\/code><\/pre>\n
The TRUNC(INTERNAL_FUNCTION(“PROD_DATE”)) is still there but now it’s an access predicate instead of a filter predicate. Our new index has been used.<\/p>\n
\u00a0date > … and date < …<\/h3>\n
Ok. But now i’ve two indexes instead of one. It’s an overhead when inserting, deleting, and updating that date column. If I’m sure that we query only with the trunc function I can drop it.<\/p>\n
SQL> drop index PROD_DATE;\nIndex dropped.\n<\/code><\/pre>\n
But what happens if a query was well written, using a range instead of trunc:<\/p>\n
SQL> select * from DEMO where prod_date >= date'2015-01-01' and prod_date \u02c2 date'2015-01-02';\n\nExecution Plan\n----------------------------------------------------------\nPlan hash value: 4000794843\n\n--------------------------------------------------------------------------\n| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |\n--------------------------------------------------------------------------\n|   0 | SELECT STATEMENT  |      |     1 |    49 |     2   (0)| 00:00:01 |\n|*  1 |  TABLE ACCESS FULL| DEMO |     1 |    49 |     2   (0)| 00:00:01 |\n--------------------------------------------------------------------------\n\nPredicate Information (identified by operation id):\n---------------------------------------------------\n\n   1 - filter(\"PROD_DATE\">=TO_DATE(' 2015-01-01 00:00:00', 'syyyy-mm-dd\n              hh24:mi:ss') AND \"PROD_DATE\"\u02c2TO_DATE(' 2015-01-02 00:00:00',\n              'syyyy-mm-dd hh24:mi:ss'))\n<\/code><\/pre>\n
A full table scan. Does that mean that I have to maintain two indexes? That was in 11.2.0.2 but let’s see the behaviour after the next patchset:<\/p>\n
SQL> alter session set optimizer_features_enable='11.2.0.2';\nSession altered.\n\nSQL> select * from DEMO where prod_date >= date'2015-01-01' and prod_date \u02c2 date'2015-01-02';\n\nExecution Plan\n----------------------------------------------------------\nPlan hash value: 1760965557\n\n-----------------------------------------------------------------------------------------------\n| Id  | Operation                   | Name            | Rows  | Bytes | Cost (%CPU)| Time     |\n-----------------------------------------------------------------------------------------------\n|   0 | SELECT STATEMENT            |                 |     1 |    58 |     1   (0)| 00:00:01 |\n|*  1 |  TABLE ACCESS BY INDEX ROWID| DEMO            |     1 |    58 |     1   (0)| 00:00:01 |\n|*  2 |   INDEX RANGE SCAN          | PROD_DATE_TRUNC |     1 |       |     1   (0)| 00:00:01 |\n-----------------------------------------------------------------------------------------------\n\nPredicate Information (identified by operation id):\n---------------------------------------------------\n\n   1 - filter(\"PROD_DATE\">=TO_DATE(' 2015-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')\n              AND \"PROD_DATE\"\u02c2TO_DATE(' 2015-01-02 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))\n   2 - access(TRUNC(INTERNAL_FUNCTION(\"PROD_DATE\"))>=TRUNC(TO_DATE(' 2015-01-01\n              00:00:00', 'syyyy-mm-dd hh24:mi:ss')) AND TRUNC(INTERNAL_FUNCTION(\"PROD_DATE\"))\u02c2=TRUNC(\n              TO_DATE(' 2015-01-02 00:00:00', 'syyyy-mm-dd hh24:mi:ss')))\n<\/code><\/pre>\n
Since 11.2.0.2 we don’t need to keep the old index. The one with the trunc() can be used.<\/p>\n
use the time part<\/h3>\n
However, something is missing now. If we want to select or filter the full date with time, we have to go to the table because the time part is not in our new index:<\/p>\n
SQL> select prod_date from DEMO where prod_date >= date'2015-01-01' and prod_date \u02c2 date'2015-01-02';\n\nExecution Plan\n----------------------------------------------------------\nPlan hash value: 1760965557\n\n-----------------------------------------------------------------------------------------------\n| Id  | Operation                   | Name            | Rows  | Bytes | Cost (%CPU)| Time     |\n-----------------------------------------------------------------------------------------------\n|   0 | SELECT STATEMENT            |                 |     1 |    18 |     1   (0)| 00:00:01 |\n|*  1 |  TABLE ACCESS BY INDEX ROWID| DEMO            |     1 |    18 |     1   (0)| 00:00:01 |\n|*  2 |   INDEX RANGE SCAN          | PROD_DATE_TRUNC |     1 |       |     1   (0)| 00:00:01 |\n-----------------------------------------------------------------------------------------------\n\nPredicate Information (identified by operation id):\n---------------------------------------------------\n\n   1 - filter(\"PROD_DATE\">=TO_DATE(' 2015-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')\n              AND \"PROD_DATE\"\u02c2TO_DATE(' 2015-01-02 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))\n   2 - access(TRUNC(INTERNAL_FUNCTION(\"PROD_DATE\"))>=TRUNC(TO_DATE(' 2015-01-01\n              00:00:00', 'syyyy-mm-dd hh24:mi:ss')) AND TRUNC(INTERNAL_FUNCTION(\"PROD_DATE\"))\u02c2=TRUNC(\n              TO_DATE(' 2015-01-02 00:00:00', 'syyyy-mm-dd hh24:mi:ss')))\n<\/code><\/pre>\n
That TABLE ACCESS BY INDEX ROWID is usually what is expensive in an index access. In that case, do we need to keep the old index?<\/p>\n
No, a better solution is to add the date – without a trunc – in our new index:<\/p>\n
SQL> drop index PROD_DATE_TRUNC;\nIndex dropped.\n\nSQL> create index PROD_DATE_TRUNC on DEMO( trunc(prod_date) , prod_date );\nIndex created.\n<\/code><\/pre>\n
and now we don’t need to go to the table:<\/p>\n
SQL> select prod_date from DEMO where prod_date >= date'2015-01-01' and prod_date \u02c2 date'2015-01-02';\n\nExecution Plan\n----------------------------------------------------------\nPlan hash value: 547246927\n\n------------------------------------------------------------------------------------\n| Id  | Operation        | Name            | Rows  | Bytes | Cost (%CPU)| Time     |\n------------------------------------------------------------------------------------\n|   0 | SELECT STATEMENT |                 |     1 |    18 |     1   (0)| 00:00:01 |\n|*  1 |  INDEX RANGE SCAN| PROD_DATE_TRUNC |     1 |    18 |     1   (0)| 00:00:01 |\n------------------------------------------------------------------------------------\n\nPredicate Information (identified by operation id):\n---------------------------------------------------\n\n   1 - access(TRUNC(INTERNAL_FUNCTION(\"PROD_DATE\"))>=TRUNC(TO_DATE('\n              2015-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) AND \"PROD_DATE\">=TO_DATE('\n              2015-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND\n              TRUNC(INTERNAL_FUNCTION(\"PROD_DATE\"))\u02c2=TRUNC(TO_DATE(' 2015-01-02\n              00:00:00', 'syyyy-mm-dd hh24:mi:ss')) AND \"PROD_DATE\"\u02c2TO_DATE(' 2015-01-02\n              00:00:00', 'syyyy-mm-dd hh24:mi:ss'))\n       filter(\"PROD_DATE\">=TO_DATE(' 2015-01-01 00:00:00', 'syyyy-mm-dd\n              hh24:mi:ss') AND \"PROD_DATE\"\u02c2TO_DATE(' 2015-01-02 00:00:00', 'syyyy-mm-dd\n              hh24:mi:ss'))\n<\/code><\/pre>\n
And there is one index only to maintain.<\/p>\n
Conclusion<\/h3>\n
From 11.2.0.2 an index on trunc(date) is sufficient for access through predicates on the date without time part – even if we don’t use the trunc() in the predicate. If we need to get the time part without having the overhead of reading the table, then we can add the column without function in the function based index. No need to maintain bot indexes.<\/p>\n","protected":false},"excerpt":{"rendered":"
By Franck Pachot . Sometimes we have to index on ( trunc(date) ) because a SQL statement uses predicate on it instead of giving a range from midnight to midnight. When you do that you probably keep the index on the column. That’s two indexes to maintain for DML. Do we need it? I’ll show […]<\/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":[198,59],"tags":[17],"type_dbi":[],"class_list":["post-4415","post","type-post","status-publish","format-standard","hentry","category-database-management","category-oracle","tag-oracle-11g"],"acf":[],"yoast_head":"\nIndex on trunc(date) - do you still need old index? - dbi Blog<\/title>\n<meta name=\"description\" content=\"indexing on date when using time part or not\" \/>\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\/index-on-truncdate-do-you-still-need-old-index\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Index on trunc(date) - do you still need old index?\" \/>\n<meta property=\"og:description\" content=\"indexing on date when using time part or not\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/index-on-truncdate-do-you-still-need-old-index\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2015-03-15T18:16: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=\"6 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\\\/index-on-truncdate-do-you-still-need-old-index\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/index-on-truncdate-do-you-still-need-old-index\\\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"Index on trunc(date) – do you still need old index?\",\"datePublished\":\"2015-03-15T18:16:20+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/index-on-truncdate-do-you-still-need-old-index\\\/\"},\"wordCount\":496,\"commentCount\":0,\"keywords\":[\"Oracle 11g\"],\"articleSection\":[\"Database management\",\"Oracle\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/index-on-truncdate-do-you-still-need-old-index\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/index-on-truncdate-do-you-still-need-old-index\\\/\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/index-on-truncdate-do-you-still-need-old-index\\\/\",\"name\":\"Index on trunc(date) - do you still need old index? - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\"},\"datePublished\":\"2015-03-15T18:16:20+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/66ab87129f2d357f09971bc7936a77ee\"},\"description\":\"indexing on date when using time part or not\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/index-on-truncdate-do-you-still-need-old-index\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/index-on-truncdate-do-you-still-need-old-index\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/index-on-truncdate-do-you-still-need-old-index\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Index on trunc(date) – do you still need old index?\"}]},{\"@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":"Index on trunc(date) - do you still need old index? - dbi Blog","description":"indexing on date when using time part or not","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\/index-on-truncdate-do-you-still-need-old-index\/","og_locale":"en_US","og_type":"article","og_title":"Index on trunc(date) - do you still need old index?","og_description":"indexing on date when using time part or not","og_url":"https:\/\/www.dbi-services.com\/blog\/index-on-truncdate-do-you-still-need-old-index\/","og_site_name":"dbi Blog","article_published_time":"2015-03-15T18:16:20+00:00","author":"Oracle Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Oracle Team","Est. reading time":"6 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/index-on-truncdate-do-you-still-need-old-index\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/index-on-truncdate-do-you-still-need-old-index\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"Index on trunc(date) – do you still need old index?","datePublished":"2015-03-15T18:16:20+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/index-on-truncdate-do-you-still-need-old-index\/"},"wordCount":496,"commentCount":0,"keywords":["Oracle 11g"],"articleSection":["Database management","Oracle"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/index-on-truncdate-do-you-still-need-old-index\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/index-on-truncdate-do-you-still-need-old-index\/","url":"https:\/\/www.dbi-services.com\/blog\/index-on-truncdate-do-you-still-need-old-index\/","name":"Index on trunc(date) - do you still need old index? - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2015-03-15T18:16:20+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"description":"indexing on date when using time part or not","breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/index-on-truncdate-do-you-still-need-old-index\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/index-on-truncdate-do-you-still-need-old-index\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/index-on-truncdate-do-you-still-need-old-index\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Index on trunc(date) – do you still need old index?"}]},{"@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\/4415","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=4415"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/4415\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=4415"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=4415"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=4415"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=4415"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}