{"id":10815,"date":"2018-02-12T15:00:29","date_gmt":"2018-02-12T14:00:29","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/"},"modified":"2023-07-17T17:00:43","modified_gmt":"2023-07-17T15:00:43","slug":"index-seek-operator-and-residual-io","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/","title":{"rendered":"Index seek operator and residual IO"},"content":{"rendered":"

This blog post draws on the previous article<\/a> about index seek and gotchas. I encountered another interesting case but it is not so much because of the nature of the problem I decided to write this article but rather the different ways that exist to troubleshoot it.<\/p>\n

Firstly, let\u2019s set the scene:<\/p>\n

A simple update query and its corresponding execution plan that tend to say the plan is efficient\u00a0 in terms of performance<\/p>\n

declare @P0 datetime2\n       ,@P1 int,\n       @P2 nvarchar(4000)\n\nset @P0 = GETDATE()\nset @P1 = 1\nset @P2 = '005245'\n\nUPDATE\n\t[TABLE]\nSET\n\t[_DATE] = @P0\nWHERE\n\t[_ID] = @P1\n    AND\n    [_IDENTIFIER] = @P2\n;<\/pre>\n
\"blog<\/p>\n
An index Seek – with a cardinality of 1 – and then a clustered index update operation. A simple case as you may notice here. But although the customer noticed a warning icon in the execution plan, he was confident enough about this plan to take care about it.<\/p>\n
But if we look closer at the warning icon it concerns a CONVERT_IMPLICT operation (meaning hidden operation done by the optimizer) that may affect the SeekPlan as stated by the pop up:<\/p>\n
\"blog<\/p>\n
In fact, in the context of this customer, this query became an issue when it was executed a thousand times in a very short period leading to trigger lock time out issues and to consume one entire VCPU of the server as well.<\/p>\n
Let\u2019s jump quickly to the root cause and the solution. Obviously the root cause concerned the @P2 parameter type here \u2013 NVARCHAR(4000) \u2013 that forced the optimizer to use an CONVERT_IMPLICT operation which makes the predicate non sargable and an index seek operation inefficient. This is particularly true when the CONVERT_IMPLICIT operation concerns the column in the predicate rather than the leading parameter. Indeed in this case @P2 type is NVARCHAR(4000) whereas the _IDENTIFIER column type is VARCHAR(50) and the optimizer has to convert first the _IDENTIFIER column (with lower precedence type) to match with the @P2 parameter (with the higher precedence type). Let\u2019s say also that the @P1 parameter is not selective enough to prevent a range scan operation in this case.<\/p>\n
Although the actual execution plan is showing index seek with a cardinality of 1, I was able to confirm quickly to my customer that the real number was completely overshadowed by using IO and TIME statistics.<\/p>\n
  CPU time = 0 ms,  elapsed time = 0 ms.\nTable 'TABLE'. Scan count 1, logical reads 17152, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.\n\nSQL Server Execution Times:\n   CPU time = 609 ms,  elapsed time = 621 ms.<\/pre>\n
Well, do you really think that a true index seek may lead to read such number of pages and to consume this amount of CPU per execution? \ud83d\ude42 \u2026\u00a0I let you\u00a0image how intensive this query may be in terms of CPU\u00a0when executed a lot of times in a very\u00a0short period\u00a0…<\/p>\n
Another point that puts us quickly on the right track is that the comparison is done in the predicate section of the index seek operation meaning it will be checked after the seek predicate. Thus, the index seek operator acts as an index scan by starting at the first page and keeps running until satisfying the seek predicate.<\/p>\n
\"blog<\/p>\n
Referring to the IO statistics output above we may notice the operator read 17152 pages and a quick look at the corresponding index physical stats allowed us to assume safely the storage engine read a big part of the index in this case.<\/p>\n
SELECT \n\tindex_id,\n\tpartition_number,\n\tindex_level,\n\tpage_count\nFROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID('TABLE'), NULL, NULL, 'DETAILED')\nWHERE index_id = 10<\/pre>\n
Ultimately, we may also benefit from an undocumented trace flag 9130<\/strong> that highlights in an obvious way how to address this issue by showing a filter operator (predicate section of index seek operator pop up) after the index seek operator itself (reading from the right to the left). From a storage perspective we are far from the first exposed reality.<\/p>\n
\"blog<\/p>\n
SQL Server Execution Times:\n   CPU time = 0 ms,  elapsed time = 0 ms.\nTable 'table'. Scan count 1, logical reads 6, physical reads 1, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.\n\nSQL Server Execution Times:\n   CPU time = 0 ms,  elapsed time = 1 ms.<\/pre>\n
Ok my problem was fixed but let\u2019s jump quickly to another interesting point. Previously I used different tools \/ tricks to identify the \u201cresidual\u201d seek operation. But shall I go through all this stuff to identify this kind of issue? Is there an easier way for that? The good news is yes if you run on SQL Server 2012 SP3+ \/ SQL Server 2014 SP2+ or SQL Server 2016+ because the SQL Server team added runtime information<\/a> to showplan.<\/p>\n
In my context, it may simplify drastically the analysis because runtime statistics are directly exposed per operator. I got interesting information as ActualRowsRead (3104706 rows) and ActualLogicalReads (17149 pages).<\/p>\n
Note that if we refer to the IO statistics from the first query where I got 17152 pages for the table TABLE, the missing 3 pages are in fact on the update index operator.<\/p>\n
<RelOp AvgRowSize=\"36\" \n\t\t\t\t\t\t   EstimateCPU=\"3.28721\" \n\t\t\t\t\t\t   EstimateIO=\"12.1472\" \n\t\t\t\t\t\t   EstimateRebinds=\"0\" \n\t\t\t\t\t\t   EstimateRewinds=\"0\" \n\t\t\t\t\t\t   EstimatedExecutionMode=\"Row\" \n\t\t\t\t\t\t   EstimateRows=\"1\" \n\t\t\t\t\t\t   LogicalOp=\"Index Seek\" \n\t\t\t\t\t\t   NodeId=\"3\" \n\t\t\t\t\t\t   Parallel=\"false\" \n\t\t\t\t\t\t   PhysicalOp=\"Index Seek\" \n\t\t\t\t\t\t   EstimatedTotalSubtreeCost=\"15.4344\" \n\t\t\t\t\t\t   TableCardinality=\"5976470\">\n                      <OutputList>\n                        <ColumnReference \n\t\t\t\t\t\t\tDatabase=\"[DB]\" \n\t\t\t\t\t\t\tSchema=\"[dbo]\" \n\t\t\t\t\t\t\tTable=\"[TABLE]\" \n\t\t\t\t\t\t\tColumn=\"_DELIVERED\" \/>\n                      <\/OutputList>\n                      <RunTimeInformation>\n                        <RunTimeCountersPerThread Thread=\"0\" \n\t\t\t\t\t\t\t\t\t\t\t\t  ActualRows=\"1\" \n\t\t\t\t\t\t\t\t\t\t\t\t  ActualRowsRead=\"3104706\" \n\t\t\t\t\t\t\t\t\t\t\t\t  ActualEndOfScans=\"1\" \n\t\t\t\t\t\t\t\t\t\t\t\t  ActualExecutions=\"1\" \n\t\t\t\t\t\t\t\t\t\t\t\t  ActualElapsedms=\"1209\" \n\t\t\t\t\t\t\t\t\t\t\t\t  ActualCPUms=\"747\" \n\t\t\t\t\t\t\t\t\t\t\t\t  ActualScans=\"1\" \n\t\t\t\t\t\t\t\t\t\t\t\t  ActualLogicalReads=\"17149\" \n\t\t\t\t\t\t\t\t\t\t\t\t  ActualPhysicalReads=\"1\" \n\t\t\t\t\t\t\t\t\t\t\t\t  ActualReadAheads=\"17141\" \n\t\t\t\t\t\t\t\t\t\t\t\t  ActualLobLogicalReads=\"0\" \n\t\t\t\t\t\t\t\t\t\t\t\t  ActualLobPhysicalReads=\"0\" \n\t\t\t\t\t\t\t\t\t\t\t\t  ActualLobReadAheads=\"0\" \/>\n                      <\/RunTimeInformation>\n\n<\/pre>\n
Finally, if you\u2019re an enthusiastic of the famous Plan Explorer<\/a> tool like me in order to troubleshoot execution plans, the addition of runtime statistics was also included to this tool accordingly. The warning icons and corresponding popups alert us very quickly about the residual IO issue as shown below:<\/p>\n
\"blog<\/p>\n
\"blog<\/p>\n
Happy troubleshooting!<\/p>\n
By David Barbarin<\/p>\n","protected":false},"excerpt":{"rendered":"
This blog post draws on the previous article about index seek and gotchas. I encountered another interesting case but it is not so much because of the nature of the problem I decided to write this article but rather the different ways that exist to troubleshoot it. Firstly, let\u2019s set the scene: A simple update […]<\/p>\n","protected":false},"author":26,"featured_media":10816,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[229],"tags":[933,67,1282,51],"type_dbi":[],"class_list":["post-10815","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-database-administration-monitoring","tag-index-seek","tag-performance","tag-residual-io","tag-sql-server"],"acf":[],"yoast_head":"\nIndex seek operator and residual IO<\/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\/index-seek-operator-and-residual-io\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Index seek operator and residual IO\" \/>\n<meta property=\"og:description\" content=\"This blog post draws on the previous article about index seek and gotchas. I encountered another interesting case but it is not so much because of the nature of the problem I decided to write this article but rather the different ways that exist to troubleshoot it. Firstly, let\u2019s set the scene: A simple update […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2018-02-12T14:00:29+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-07-17T15:00:43+00:00\" \/>\n<meta property=\"og:image\" content=\"http:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/blog-129-1-query-plan-before-optimization-e1518444878858.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"800\" \/>\n\t<meta property=\"og:image:height\" content=\"124\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Microsoft 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=\"Microsoft Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"5 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-seek-operator-and-residual-io\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/\"},\"author\":{\"name\":\"Microsoft Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4\"},\"headline\":\"Index seek operator and residual IO\",\"datePublished\":\"2018-02-12T14:00:29+00:00\",\"dateModified\":\"2023-07-17T15:00:43+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/\"},\"wordCount\":764,\"commentCount\":0,\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/blog-129-1-query-plan-before-optimization-e1518444878858.jpg\",\"keywords\":[\"index seek\",\"Performance\",\"Residual IO\",\"SQL Server\"],\"articleSection\":[\"Database Administration & Monitoring\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/\",\"name\":\"Index seek operator and residual IO\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/blog-129-1-query-plan-before-optimization-e1518444878858.jpg\",\"datePublished\":\"2018-02-12T14:00:29+00:00\",\"dateModified\":\"2023-07-17T15:00:43+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/#primaryimage\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/blog-129-1-query-plan-before-optimization-e1518444878858.jpg\",\"contentUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/blog-129-1-query-plan-before-optimization-e1518444878858.jpg\",\"width\":800,\"height\":124},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Index seek operator and residual IO\"}]},{\"@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\/bfab48333280d616e1170e7369df90a4\",\"name\":\"Microsoft Team\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g\",\"caption\":\"Microsoft Team\"},\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/microsoft-team\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Index seek operator and residual IO","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-seek-operator-and-residual-io\/","og_locale":"en_US","og_type":"article","og_title":"Index seek operator and residual IO","og_description":"This blog post draws on the previous article about index seek and gotchas. I encountered another interesting case but it is not so much because of the nature of the problem I decided to write this article but rather the different ways that exist to troubleshoot it. Firstly, let\u2019s set the scene: A simple update […]","og_url":"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/","og_site_name":"dbi Blog","article_published_time":"2018-02-12T14:00:29+00:00","article_modified_time":"2023-07-17T15:00:43+00:00","og_image":[{"width":800,"height":124,"url":"http:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/blog-129-1-query-plan-before-optimization-e1518444878858.jpg","type":"image\/jpeg"}],"author":"Microsoft Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Microsoft Team","Est. reading time":"5 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/"},"author":{"name":"Microsoft Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4"},"headline":"Index seek operator and residual IO","datePublished":"2018-02-12T14:00:29+00:00","dateModified":"2023-07-17T15:00:43+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/"},"wordCount":764,"commentCount":0,"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/blog-129-1-query-plan-before-optimization-e1518444878858.jpg","keywords":["index seek","Performance","Residual IO","SQL Server"],"articleSection":["Database Administration & Monitoring"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/","url":"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/","name":"Index seek operator and residual IO","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/#primaryimage"},"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/blog-129-1-query-plan-before-optimization-e1518444878858.jpg","datePublished":"2018-02-12T14:00:29+00:00","dateModified":"2023-07-17T15:00:43+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/#primaryimage","url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/blog-129-1-query-plan-before-optimization-e1518444878858.jpg","contentUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/blog-129-1-query-plan-before-optimization-e1518444878858.jpg","width":800,"height":124},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/index-seek-operator-and-residual-io\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Index seek operator and residual IO"}]},{"@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\/bfab48333280d616e1170e7369df90a4","name":"Microsoft Team","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g","caption":"Microsoft Team"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/microsoft-team\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/10815","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\/26"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=10815"}],"version-history":[{"count":1,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/10815\/revisions"}],"predecessor-version":[{"id":26787,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/10815\/revisions\/26787"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media\/10816"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=10815"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=10815"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=10815"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=10815"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}