{"id":1553,"date":"2014-01-30T09:00:00","date_gmt":"2014-01-30T17:00:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/dataplatforminsider\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/"},"modified":"2024-01-22T22:49:03","modified_gmt":"2024-01-23T06:49:03","slug":"in-memory-oltp-index-troubleshooting-part-ii","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/","title":{"rendered":"In-Memory OLTP Index Troubleshooting, Part II"},"content":{"rendered":"<p>With the In-Memory OLTP feature in SQL Server 2014 we introduce two new types of indexes for memory-optimized tables: the memory-optimized NONCLUSTERED indexes, and the memory-optimized HASH indexes.<\/p>\n<p>Memory-optimized NONCLUSTERED indexes behave similar to traditional NONCLUSTERED indexes from an application point-of-view. The main difference being that memory-optimized indexes are always covering (i.e. all columns are virtually included), while with traditional disk-based NONCLUSTERED indexes you need to specify which column you want to include alongside the index key columns.<a><\/a><\/p>\n<p>Memory-optimized HASH indexes behave different from NONCLUSTERED indexes. They are optimized for point-lookup operations, and do not support ordered scans or inequality seek operations. In addition, you need to specify a BUCKET_COUNT when creating the index, and you need to pick the right value in order for the index to perform optimally. In earlier posts we covered the following three index troubleshooting aspects:<\/p>\n<ul>\n<li>\n<a href=\"http:\/\/blogs.technet.com\/b\/dataplatforminsider\/archive\/2013\/10\/09\/troubleshooting-common-performance-problems-with-memory-optimized-hash-indexes.aspx\">Bucket_count<\/a> troubleshooting for HASH indexes: how to find out whether a bucket_count is too low, and how to determine what should be the correct bucket_count. You can also find more information about determining the right bucket_count in <a href=\"http:\/\/msdn.microsoft.com\/en-us\/library\/dn494956(v=sql.120).aspx\">Books Online<\/a>.<\/li>\n<li>\n<a href=\"http:\/\/blogs.technet.com\/b\/dataplatforminsider\/archive\/2013\/10\/09\/troubleshooting-common-performance-problems-with-memory-optimized-hash-indexes.aspx\">Searching on a subset of the index key<\/a>: HASH indexes do not support searching on the leading columns of an index key.<\/li>\n<li>\n<a href=\"http:\/\/blogs.technet.com\/b\/dataplatforminsider\/archive\/2013\/11\/12\/sql-server-2014-in-memory-oltp-nonclustered-indexes-for-memory-optimized-tables.aspx\">Searching on inequality predicates and ordered scans<\/a>: both operations are not supported with HASH indexes, but they are supported with NONCLUSTERED indexes.\u00a0But note that NONCLUSTERED indexes support ordered scans only in the direction indicated with the index key: for example, if the index key is (c1 DESC), the index supports retrieving the values for c1 in descending order, but not in ascending order.<\/li>\n<\/ul>\n<p>All that said, it seems that HASH indexes have quite a few limitations, compared with NONCLUSTERED indexes. For that reason, it is usually a safer bet to start with NONCLUSTERED indexes, both for new applications and when migrating existing disk-based tables to memory-optimized. You can then\u00a0use HASH indexes to further optimize the workload. Indeed, HASH indexes are the most efficient index for equality search (point lookup) and full table scan operations.<\/p>\n<p>In the remainder of this post we:<\/p>\n<ul>\n<li>Describe a way to troubleshoot seek vs. scans on memory-optimized indexes using the new DMV sys.dm_db_xtp_index_stats: if there are more full index scans than expected, one of the above-mentioned issues may be the case: trying to search on a subset of a HASH index key or trying to search on inequality predicates with a HASH index.<\/li>\n<li>Troubleshoot duplicates: you may run into problems if the index keys of a memory-optimized index contain a lot of duplicate values, particularly when using a HASH index. We describe how to detect this situation and how to work around.<\/li>\n<\/ul>\n<h2>Troubleshooting seek vs. scan using XTP index DMVs<\/h2>\n<p>The DMV sys.dm_db_xtp_index_stats shows statistics for index operations performed by the in-memory storage engine. The index contains stats about the usage of the index since its creation in memory \u2013 note that memory-optimized indexes are always recreated on database restart. You can use the following query to retrieve key statistics about the usage of indexes on your table:<\/p>\n<p><span style=\"font-family:'courier new', courier;\"><span style=\"background-color:#ffffff;color:#0000ff;\">SELECT<\/span> ix.index_id, ix.name, scans_started, rows_returned<\/span><\/p>\n<p><span style=\"font-family:'courier new', courier;\"><span style=\"color:#0000ff;\">FROM<\/span> <span style=\"color:#339966;\">sys<\/span>.dm_db_xtp_index_stats ixs JOIN <span style=\"color:#339966;\">sys.indexes<\/span> ix <span style=\"color:#0000ff;\">ON<\/span> <\/span><\/p>\n<p><span style=\"font-family:'courier new', courier;\">ix.<span style=\"color:#ff00ff;\">object_id<\/span>=ixs.<span style=\"color:#ff00ff;\">object_id<\/span> AND ix.index_id=ixs.index_id<\/span><\/p>\n<p><span style=\"font-family:'courier new', courier;\"><span style=\"color:#0000ff;\">WHERE<\/span> ix.<span style=\"color:#ff00ff;\">object_id<\/span>=<span style=\"color:#ff00ff;\">object_id<\/span>(<span style=\"color:#ff0000;\">&#8216;<i>&lt;table name&gt;<\/i>&#8216;<\/span>)<\/span><\/p>\n<p>For troubleshooting indexes, the columns \u2018scans_started\u2019 and \u2018rows_returned\u2019 contain key information:<\/p>\n<ul>\n<li>scans_started \u2013 this is the number of scan operations the in-memory storage engine has started. Note that from the storage engine point-of-view, all operations to locate a row or the location to insert a new row are scans: for example, a full index scan, a point lookup and, a row insert all require a single scan operation.<\/li>\n<li>rows_returned \u2013 the cumulative number of rows returned by all scan operations in the storage engine. Note that this number reflects the rows returned by the storage engine, not the number of rows returned to the client. For example, the query plan may call for a filter condition or aggregation that reduces the number of rows before it is returned to the client.\n<ul>\n<li>Insert operations do not result in rows being returned. Update and delete operations consist of a scan, to locate the row to be updated, followed by the actual row update\/delete.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>If the number of rows_returned is significantly larger than the scans_started, this is an indication that, on average, index operations scan a large part of the index. If all index operations are expected to be point lookups, this could be an indication of one of the earlier-mentioned problems where the query\u00a0calls for an operation to be supported by the index, thus causing a revert to full index scan, such as: <i>search requires a subset of hash index key columns<\/i> or <i>search on inequality predicates with a hash index<\/i>.<\/p>\n<p>The scans_started being larger than rows_returned is an indication that the workload is insert-heavy, or that a lot of point lookups failed to locate a row.<a><\/a><\/p>\n<h2>Index keys with many duplicate values<\/h2>\n<p><b>Issue: <\/b>Index keys with many duplicate values can cause performance problems. If each index key has 5 duplicates this is usually not a problem, but if the discrepancy between the number of unique index keys and the number of rows in the tables becomes very large \u2013 more than 10X \u2013 this can become problematic.<\/p>\n<p>All rows with the same index key end up in the same duplicate chain. For hash indexes this can create a lot of overhead in case of hash collisions: if multiple index keys end up in the same bucket due to a hash collision, index scanners always need to scan the full duplicate chain for the first value before they can locate the first row corresponding to the second value. For nonclustered indexes this causes additional overhead for garbage collection.<\/p>\n<p><b>Symptom: <\/b>For hash indexes the performance of DML operations degrades and CPU utilization increases. In addition, there is an increase in CPU utilization during database startup, and a potential increase in recovery time. This becomes especially clear when inserting a large number of rows.<\/p>\n<p>For nonclustered indexes garbage collection will start to consume more resources, resulting in an overall increased CPU utilization in the system. The problem does not affect DML operations directly,<a>[1]<\/a> but it does put more overall pressure on system resources.<\/p>\n<p><b>How to troubleshoot<\/b>: The average number of duplicate rows for a given index key can be obtained using T-SQL queries. First determine the row count of the table, then determine the number of unique index key values. Divide the row count by the number of unique index keys to obtain the average number of duplicates.<\/p>\n<p>To determine the row count for the table use the following query:<\/p>\n<p><span style=\"font-family:'courier new', courier;\"><span style=\"color:#0000ff;\">select<\/span> <span style=\"color:#ff00ff;\">count<\/span>(*) <span style=\"color:#0000ff;\">as<\/span> <span style=\"color:#ff0000;\">&#8216;Row count&#8217;<\/span> <span style=\"color:#0000ff;\">from<\/span> <i>&lt;tableName&gt;<\/i><\/span><\/p>\n<p>To determine the number of unique index key values use the following query:<\/p>\n<p><span style=\"font-family:'courier new', courier;\"><span style=\"color:#0000ff;\">select<\/span> <span style=\"color:#ff00ff;\">count<\/span>(*) <span style=\"color:#0000ff;\">as<\/span> <span style=\"color:#ff0000;\">&#8216;Distinct index key values&#8217;<\/span> <span style=\"color:#0000ff;\">from<\/span> (<span style=\"color:#0000ff;\">select distinct<\/span> <i>&lt;indexKeyColumns&gt;<\/i> <span style=\"color:#0000ff;\">from<\/span> <i>&lt;tableName&gt;<\/i>) a<\/span><\/p>\n<p>For hash indexes specifically, you can also troubleshoot using the hash index stats DMV. Use the following query:<\/p>\n<p><span style=\"font-family:'courier new', courier;\"><span style=\"color:#0000ff;\">SELECT<\/span> hs.<span style=\"color:#ff00ff;\">object_id<\/span>, <span style=\"color:#ff00ff;\">object_name<\/span>(hs.<span style=\"color:#ff00ff;\">object_id<\/span>) <span style=\"color:#0000ff;\">AS<\/span> <span style=\"color:#ff0000;\">&#8216;object name&#8217;<\/span>, i.name <span style=\"color:#0000ff;\">as<\/span> <span style=\"color:#ff0000;\">&#8216;index name&#8217;<\/span>, hs.*<\/span><\/p>\n<p><span style=\"font-family:'courier new', courier;\"><span style=\"color:#0000ff;\">FROM<\/span> <span style=\"color:#339966;\">sys<\/span>.dm_db_xtp_hash_index_stats <span style=\"color:#0000ff;\">AS<\/span> hs<\/span><\/p>\n<p><span style=\"font-family:'courier new', courier;\">JOIN <span style=\"color:#339966;\">sys<\/span>.<span style=\"color:#339966;\">indexes<\/span> <span style=\"color:#0000ff;\">AS<\/span> i <span style=\"color:#0000ff;\">ON<\/span> hs.<span style=\"color:#ff00ff;\">object_id<\/span>=i.<span style=\"color:#ff00ff;\">object_id<\/span> AND hs.index_id=i.index_id;<\/span><\/p>\n<p>If the average chain length is high and the number of empty buckets is high, it is likely that there are many rows with duplicate index key values or there is a skew in the key values.<\/p>\n<p><b>Workaround: <\/b>First, evaluate if the index is truly needed. The index may have been added in the past to support queries that are no longer part of the workload.<\/p>\n<p>For HASH indexes there are two ways to work around the issue of many duplicates:<\/p>\n<ul>\n<li>In most cases you will want to use a NONCLUSTERED index instead, as NONCLUSTERED indexes generally perform better in case of duplicates. If you go for this option, consider uniquifying the index key, as indicated below.<\/li>\n<li>Alternatively, you can over-size the index by using a very high bucket count; for example, 20 \u2013 100 times the number of unique index key values. This will make hash collisions unlikely.<\/li>\n<\/ul>\n<p>For NONCLUSTERED indexes with a lot of duplicates, consider adding additional columns to the index key. For example, you can add the primary key columns to the index key to make it unique, in other words to <i>uniquify<\/i> the index.<\/p>\n<p>Adding columns to the index key does come with a performance penalty for DML operations. Therefore, it is important to test the new uniquified index under production load, and compare the performance with the old index. Consider the overall throughput of the system, query performance, and also the overall resource utilization, especially CPU.<\/p>\n<div>\n<br clear=\"all\"><\/p>\n<hr align=\"left\">\n<div>\n<p><a>[1]<\/a> In SQL 2014 CTP2 user transactions could be affected, due to garbage collection performed at commit time. This issue will be resolved in SQL 2014 RTM: garbage collection no longer directly affects user transactions.<\/p>\n<\/p><\/div>\n<\/p><\/div>\n","protected":false},"excerpt":{"rendered":"<p>With the In-Memory OLTP feature in SQL Server 2014 we introduce two new types of indexes for memory-optimized tables: the memory-optimized NONCLUSTERED indexes, and the memory-optimized HASH indexes. Memory-optimized NONCLUSTERED indexes behave similar to traditional NONCLUSTERED indexes from an application point-of-view. The main difference being that memory-optimized indexes are always covering (i.e.<\/p>\n","protected":false},"author":1457,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ep_exclude_from_search":false,"_classifai_error":"","_classifai_text_to_speech_error":"","footnotes":""},"post_tag":[],"product":[],"content-type":[2424],"topic":[],"coauthors":[2487],"class_list":["post-1553","post","type-post","status-publish","format-standard","hentry","content-type-best-practices"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.2 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>In-Memory OLTP Index Troubleshooting, Part II - Microsoft SQL Server 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.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"In-Memory OLTP Index Troubleshooting, Part II - Microsoft SQL Server Blog\" \/>\n<meta property=\"og:description\" content=\"With the In-Memory OLTP feature in SQL Server 2014 we introduce two new types of indexes for memory-optimized tables: the memory-optimized NONCLUSTERED indexes, and the memory-optimized HASH indexes. Memory-optimized NONCLUSTERED indexes behave similar to traditional NONCLUSTERED indexes from an application point-of-view. The main difference being that memory-optimized indexes are always covering (i.e.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/\" \/>\n<meta property=\"og:site_name\" content=\"Microsoft SQL Server Blog\" \/>\n<meta property=\"article:publisher\" content=\"http:\/\/www.facebook.com\/sqlserver\" \/>\n<meta property=\"article:published_time\" content=\"2014-01-30T17:00:00+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2024-01-23T06:49:03+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-content\/uploads\/2018\/08\/cropped-microsoft_logo_element.png\" \/>\n\t<meta property=\"og:image:width\" content=\"512\" \/>\n\t<meta property=\"og:image:height\" content=\"512\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"SQL Server Team\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@SQLServer\" \/>\n<meta name=\"twitter:site\" content=\"@SQLServer\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"SQL Server Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"6 min read\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/\"},\"author\":[{\"@id\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/author\/sql-server-team\/\",\"@type\":\"Person\",\"@name\":\"SQL Server Team\"}],\"headline\":\"In-Memory OLTP Index Troubleshooting, Part II\",\"datePublished\":\"2014-01-30T17:00:00+00:00\",\"dateModified\":\"2024-01-23T06:49:03+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/\"},\"wordCount\":1519,\"commentCount\":4,\"publisher\":{\"@id\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/#organization\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/\",\"url\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/\",\"name\":\"In-Memory OLTP Index Troubleshooting, Part II - Microsoft SQL Server Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/#website\"},\"datePublished\":\"2014-01-30T17:00:00+00:00\",\"dateModified\":\"2024-01-23T06:49:03+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"In-Memory OLTP Index Troubleshooting, Part II\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/#website\",\"url\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/\",\"name\":\"Microsoft SQL Server Blog\",\"description\":\"Official News from Microsoft\u2019s Information Platform\",\"publisher\":{\"@id\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/#organization\",\"name\":\"Microsoft SQL Server Blog\",\"url\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-content\/uploads\/2019\/08\/Microsoft-Logo.png\",\"contentUrl\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-content\/uploads\/2019\/08\/Microsoft-Logo.png\",\"width\":259,\"height\":194,\"caption\":\"Microsoft SQL Server Blog\"},\"image\":{\"@id\":\"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"http:\/\/www.facebook.com\/sqlserver\",\"https:\/\/x.com\/SQLServer\",\"https:\/\/www.youtube.com\/user\/MSCloudOS\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"In-Memory OLTP Index Troubleshooting, Part II - Microsoft SQL Server 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.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/","og_locale":"en_US","og_type":"article","og_title":"In-Memory OLTP Index Troubleshooting, Part II - Microsoft SQL Server Blog","og_description":"With the In-Memory OLTP feature in SQL Server 2014 we introduce two new types of indexes for memory-optimized tables: the memory-optimized NONCLUSTERED indexes, and the memory-optimized HASH indexes. Memory-optimized NONCLUSTERED indexes behave similar to traditional NONCLUSTERED indexes from an application point-of-view. The main difference being that memory-optimized indexes are always covering (i.e.","og_url":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/","og_site_name":"Microsoft SQL Server Blog","article_publisher":"http:\/\/www.facebook.com\/sqlserver","article_published_time":"2014-01-30T17:00:00+00:00","article_modified_time":"2024-01-23T06:49:03+00:00","og_image":[{"width":512,"height":512,"url":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-content\/uploads\/2018\/08\/cropped-microsoft_logo_element.png","type":"image\/png"}],"author":"SQL Server Team","twitter_card":"summary_large_image","twitter_creator":"@SQLServer","twitter_site":"@SQLServer","twitter_misc":{"Written by":"SQL Server Team","Est. reading time":"6 min read"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/#article","isPartOf":{"@id":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/"},"author":[{"@id":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/author\/sql-server-team\/","@type":"Person","@name":"SQL Server Team"}],"headline":"In-Memory OLTP Index Troubleshooting, Part II","datePublished":"2014-01-30T17:00:00+00:00","dateModified":"2024-01-23T06:49:03+00:00","mainEntityOfPage":{"@id":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/"},"wordCount":1519,"commentCount":4,"publisher":{"@id":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/#organization"},"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/","url":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/","name":"In-Memory OLTP Index Troubleshooting, Part II - Microsoft SQL Server Blog","isPartOf":{"@id":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/#website"},"datePublished":"2014-01-30T17:00:00+00:00","dateModified":"2024-01-23T06:49:03+00:00","breadcrumb":{"@id":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2014\/01\/30\/in-memory-oltp-index-troubleshooting-part-ii\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/"},{"@type":"ListItem","position":2,"name":"In-Memory OLTP Index Troubleshooting, Part II"}]},{"@type":"WebSite","@id":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/#website","url":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/","name":"Microsoft SQL Server Blog","description":"Official News from Microsoft\u2019s Information Platform","publisher":{"@id":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/#organization","name":"Microsoft SQL Server Blog","url":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-content\/uploads\/2019\/08\/Microsoft-Logo.png","contentUrl":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-content\/uploads\/2019\/08\/Microsoft-Logo.png","width":259,"height":194,"caption":"Microsoft SQL Server Blog"},"image":{"@id":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/#\/schema\/logo\/image\/"},"sameAs":["http:\/\/www.facebook.com\/sqlserver","https:\/\/x.com\/SQLServer","https:\/\/www.youtube.com\/user\/MSCloudOS"]}]}},"msxcm_display_generated_audio":false,"msxcm_animated_featured_image":null,"_links":{"self":[{"href":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-json\/wp\/v2\/posts\/1553","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-json\/wp\/v2\/users\/1457"}],"replies":[{"embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-json\/wp\/v2\/comments?post=1553"}],"version-history":[{"count":0,"href":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-json\/wp\/v2\/posts\/1553\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-json\/wp\/v2\/media?parent=1553"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-json\/wp\/v2\/post_tag?post=1553"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-json\/wp\/v2\/product?post=1553"},{"taxonomy":"content-type","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-json\/wp\/v2\/content-type?post=1553"},{"taxonomy":"topic","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-json\/wp\/v2\/topic?post=1553"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/wp-json\/wp\/v2\/coauthors?post=1553"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}