Azure SQL Automatic Tuning successfully identified and reverted a newly created nonclustered index after investigation using the SQL Server Query Store revealed that the massive 108.15% DTU regression was caused by the index\u2019s imposed maintenance overhead on frequent BULK INSERT write operations, rather than inefficient data reads.<\/p>\n\n\n\n
sys.dm_db_tuning_recommendations<\/code> DMV failed to provide the necessary query_id<\/code> or query text linking the index to the negatively impacted operation.<\/li>\n\n\n\n- Using Query Store and filtering by table name and time window, the team discovered that the top resource consumer was a BULK INSERT statement, confirming the index was harming data writes rather than helping SELECT queries.<\/li>\n\n\n\n
- The standard best practice for environments with heavy data loading is to temporarily disable or drop nonclustered indexes before running the bulk load, and then rebuild them afterward, as this is far more efficient than row-by-row maintenance during the load.<\/li>\n<\/ul>\n\n\n\n
This case validates that while automated systems protect the workload by reverting harmful changes, database optimization still requires human skill, diagnostic tools like Query Store, and collaboration across teams to understand the total impact on a mixed read\/write workload.<\/p>\n\n\n\n
Table of contents<\/h2>- SUMMARY:<\/a><\/li>
- The Initial Anomaly: A 108% Performance Regression<\/a><\/li>
- The Investigation Begins: Finding the “Affected Query”<\/a><\/li>
- The Breakthrough: Unmasking the Culprit with Query Store<\/a><\/li>
- The “Aha!” Moment: Understanding the Real Problem<\/a><\/li>
- Key Lessons and Best Practices<\/a>
- Consider the Entire Workload<\/a><\/li>
- The Best Practice for Bulk Loads \ud83d\ude80<\/a><\/li>
- Trust Your Automation (But Know How to Verify It)<\/a><\/li><\/ul><\/li>
- Conclusion<\/a><\/li>
- FAQs<\/a><\/li><\/ul><\/div>\n\n\n\n
The Initial Anomaly: A 108% Performance Regression<\/strong><\/h2>\n\n\n\nOne of the most powerful features within Azure SQL Managed Instance is Automatic Tuning<\/strong>. It monitors your database workload and applies performance-enhancing actions without manual intervention, such as creating a potentially missing index. But what happens when the machine gets it wrong? Or, more accurately, what happens when it gets it so right that it has to immediately undo its own work?<\/p>\n\n\n\nThat\u2019s the scenario we recently faced. On a reporting database<\/strong>, Automatic Tuning suggested and created a new nonclustered index. Shortly after, it automatically reverted the change, providing a validation report with some puzzling metrics:<\/p>\n\n\n\n\n- DTU regression (overall):<\/strong> 3.89%<\/li>\n\n\n\n
- DTU regression (affected queries):<\/strong> 108.15%<\/li>\n<\/ul>\n\n\n\n
For context, a Database Transaction Unit (DTU) is Azure’s blended measure of CPU, memory, and I\/O. The report told us that while the overall database workload got slightly more expensive (by ~4%), the specific query the index was meant to help got more than twice as expensive (a 108% regression).<\/p>\n\n\n\n
Because this was a reporting environment, our initial analysis was laser-focused on read performance. Our first logical hypothesis was that the index was a good idea in principle, but that it needed page compression<\/strong>. In reporting scenarios with large tables, creating an index with page compression can drastically reduce its size on disk, leading to fewer I\/O operations and better query performance. Our theory was that Azure created the standard index, its I\/O cost was still too high, and this caused the regression.<\/p>\n\n\n\nThis hypothesis seemed sound and provided a clear path forward: find the affected query, and manually recreate the index with page compression to fix the issue. This kicked off a deeper investigation that would ultimately prove our initial theory completely wrong.<\/p>\n\n\n\n
\n\n\n\nThe Investigation Begins: Finding the “Affected Query”<\/strong><\/h2>\n\n\n\nOur first step was to identify the query that was so negatively impacted. This should be easy, right? The recommendation details in the Azure Portal should have the query text or at least a query_id<\/mark>.<\/code><\/p>\n\n\n\nUnfortunately, this was our first dead end. The validation report in the portal UI, while showing the regression percentages, had no mention of a query_id<\/mark>.<\/code><\/p>\n\n\n\nNo problem. We can go deeper. The next logical step is to query the underlying Dynamic Management View (DMV) that feeds the portal: sys.dm_db_tuning_recommendations<\/mark><\/code>. This DMV contains a details<\/mark><\/code> column with rich JSON data that should hold the key. We ran a query to parse this JSON, but to our surprise, the queryId<\/mark><\/code> field was NULL<\/mark><\/code>. After inspecting the raw JSON, we confirmed it wasn’t just in the wrong place\u2014it was completely missing from the log for this specific event.<\/p>\n\n\n\nThis was a frustrating but realistic roadblock. We had hit a limitation in the diagnostic data. It was time to pivot. If we couldn’t link the reverted index to the query via an ID, we had to link them by circumstance. We had two critical clues:<\/p>\n\n\n\n
\n- The Object:<\/strong> The index was created on the table
[dbo].[Staging_ReportData]<\/mark><\/code> on the columns ([RecordId], [EventTimestamp])<\/mark>.<\/code><\/li>\n\n\n\n- The Time Window:<\/strong> The JSON details gave us the exact timestamps for when the index was created and when it was reverted.<\/li>\n<\/ol>\n\n\n\n
The mission was now clear: find a resource-intensive query that ran against [dbo].[Staging_ReportData]<\/mark><\/code> within that specific time window.<\/p>\n\n\n\n
\n\n\n\nThe Breakthrough: Unmasking the Culprit with Query Store<\/strong><\/h2>\n\n\n\nWith our new mission defined, we turned to the ultimate tool for historical query analysis: the SQL Server Query Store<\/strong>. To simplify the process, we used the excellent open-source stored procedure sp_QuickieStore<\/mark><\/code>, which provides a user-friendly way to analyze Query Store data.<\/p>\n\n\n\nSince we couldn\u2019t filter by query_id<\/mark><\/code>, we used the time window and the @query_text_search<\/mark><\/code> parameter to find our culprit. The command was simple and precise:<\/p>\n\n\n\nSQL<\/p>\n\n\n
EXEC sp_QuickieStore
@start_date = '2025-07-04 05:50:11',
@end_date = '2025-07-04 16:07:10',
@sort_order = 'cpu',
@query_text_search = 'Staging_ReportData';<\/mark><\/code><\/pre>\n<\/p>\n\n\nWe ran the command, expecting to see a complex reporting query at the top of the list\u2014one with a WHERE<\/mark><\/code> clause that was somehow inefficiently using the new index.<\/p>\n\n\n\nThe result was something else entirely. The top resource-consumer, by a wide margin, was a BULK INSERT<\/mark><\/code> statement targeting our [dbo].[Staging_ReportData]<\/mark><\/code> table. It had run over 700 times during the validation window with a high average CPU cost. At first, this seemed wrong. Why would a data loading operation be the “affected query”?<\/p>\n\n\n\n
\n\n\n\nThe “Aha!” Moment: Understanding the Real Problem<\/strong><\/h2>\n\n\n\nThen, it all clicked into place. The BULK INSERT<\/mark><\/code> wasn’t the query the index was meant to help; it was the victim<\/strong> of the index.<\/p>\n\n\n\nThis revealed a fundamental database tuning principle: Indexes speed up data reads, but they slow down data writes.<\/strong><\/p>\n\n\n\nEvery time you INSERT<\/mark><\/code>, UPDATE<\/mark><\/code>, or DELETE<\/mark><\/code> data, the database engine doesn’t just change the data in the table; it must also update every single nonclustered index to reflect that change. When Automatic Tuning created the new index [IX_AutoTuned_ReportData_EventTimestamp<\/mark>]<\/code>, it inadvertently imposed a “tax” on our data loading process.<\/p>\n\n\n\nFor each of the 712 BULK INSERT<\/mark><\/code> executions, the database now had to perform the extra work of inserting a new entry into our new index. That extra CPU and I\/O overhead, multiplied 712 times, was the source of the massive 108% performance regression. The “affected query” was the one being harmed<\/em> by the index’s existence. This discovery also invalidated our initial theory about page compression. Adding compression to the index would have increased the CPU ‘tax’ on the BULK INSERT<\/mark><\/code>, likely making the 108% regression even worse.<\/p>\n\n\n\n
\n\n\n\nKey Lessons and Best Practices<\/strong><\/h2>\n\n\n\nThis investigation highlighted several crucial takeaways for anyone managing a database with a mixed workload.<\/p>\n\n\n\n
Consider the Entire Workload<\/strong><\/h3>\n\n\n\nDon’t assume an index is only for SELECT<\/mark><\/code> queries. You must always consider the impact on the entire workload, especially data modification patterns. An index that helps a monthly report run faster might be unacceptable if it cripples a data loading process that runs every five minutes.<\/p>\n\n\n\nThe Best Practice for Bulk Loads \ud83d\ude80<\/strong><\/h3>\n\n\n\nOur scenario is precisely why a standard best practice exists for environments with heavy data loading operations. To maximize performance, the recommended pattern is:<\/p>\n\n\n\n
\n- Disable or Drop Indexes:<\/strong> Before the data load begins, disable or drop the nonclustered indexes on the target table.<\/li>\n\n\n\n
- Perform the Data Load:<\/strong> Run the
BULK INSERT<\/mark><\/code> or other loading process. This will now run much faster without the index maintenance overhead.<\/li>\n\n\n\n- Rebuild or Recreate Indexes:<\/strong> After the load is complete, rebuild or recreate the indexes. This single, large operation is far more efficient than maintaining the indexes row-by-row during the load.<\/li>\n<\/ol>\n\n\n\n
Trust Your Automation (But Know How to Verify It)<\/strong><\/h3>\n\n\n\nAzure’s Automatic Tuning worked perfectly. It identified a potential improvement, tested it, and, upon seeing the massive negative impact, protected the workload by reverting the change. This event reinforces the value of automated tuning, but also shows the importance of having the skills and tools like Query Store to investigate why<\/em> a decision was made.<\/p>\n\n\n\nTo emphasize this, consider this scenario as outlined above. You have a database that is autotuning itself by adding indexes for reporting queries, but now notice many of those indexes are being rolled back by the same mechanism that put them in place. This goes directly to the hand-in-glove or it-takes-a-village approach to maintaining database optimization. It is not uncommon for reporting and ETL developers to be separate people\/teams. Recognizing this sooner will save time and resources later.
In short, the Azure Autuning feature is excellent! However, it requires people to work together for maximum optimization!<\/p>\n\n\n\n
\n\n\n\nConclusion<\/strong><\/h2>\n\n\n\nWhat started as a confusing alert about a reverted index turned into a valuable reminder about the fundamentals of database performance. By following the clues and digging deep into the diagnostic data, we were able to solve the mystery and confirm that our automated systems were making the right call, even if the reason wasn’t immediately obvious.<\/p>\n\n\n\n
FAQs<\/strong><\/h1>\n\n\n\nWhat is Azure Automatic Tuning, and what was the initial problem encountered?<\/strong><\/p>\n\n\n\nAzure Automatic Tuning is a powerful feature in Azure SQL Managed Instance that automatically monitors database workloads and applies performance-enhancing actions, such as creating missing indexes, without manual intervention. In the described scenario, Automatic Tuning created a new nonclustered index, but then quickly reverted it. The puzzling part was the validation report: while the overall database workload experienced a minor 3.89% DTU regression, the specific “affected query” showed a massive 108.15% DTU regression, meaning it became more than twice as expensive.<\/p>\n\n\n\n
Why was identifying the “affected query” so challenging?<\/strong><\/p>\n\n\n\nThe process of identifying the negatively impacted query faced several roadblocks. Initially, the Azure Portal’s validation report, while showing regression percentages, did not provide the query_id or query text. Further investigation by querying the sys.dm_db_tuning_recommendations Dynamic Management View (DMV) also revealed that the queryId field was NULL and completely missing from the rich JSON details for this specific event. This diagnostic data limitation meant the team couldn’t directly link the reverted index to a specific query ID.<\/p>\n\n\n\n
How was the “affected query” ultimately identified without a query_id?<\/strong><\/p>\n\n\n\nUnable to link by query_id, the team pivoted to linking by circumstance, using two critical clues: the specific table and columns on which the index was created ([dbo].[Staging_ReportData] on ([RecordId], [EventTimestamp])), and the exact time window provided by the JSON details when the index was created and reverted. They then used the SQL Server Query Store, specifically the sp_QuickieStore stored procedure, to find resource-intensive queries against Staging_ReportData within that time window. This led them to discover that a BULK INSERT statement was the top resource consumer.<\/p>\n\n\n\n
What was the “Aha!” moment regarding the BULK INSERT?<\/strong><\/p>\n\n\n\nThe “Aha!” moment came when it was realized that the BULK INSERT wasn’t the query the index was intended to help; instead, it was the query being significantly harmed by the index’s presence. This highlighted a fundamental database tuning principle: while indexes speed up data reads (SELECT queries), they inherently slow down data writes (INSERT, UPDATE, DELETE operations). Every time data is modified, all associated nonclustered indexes must also be updated. The new index imposed an “extra tax” on each of the 712 BULK INSERT executions, leading to increased CPU and I\/O overhead, which manifested as the 108% performance regression.<\/p>\n\n\n\n
Why did the initial hypothesis about page compression prove wrong?<\/strong><\/p>\n\n\n\nThe initial hypothesis was that the index was conceptually good but needed page compression to reduce I\/O costs, especially in a reporting environment with large tables. However, once the BULK INSERT was identified as the culprit, this hypothesis was invalidated. Adding page compression to the index would have further increased the CPU overhead for the BULK INSERT operation, making the 108% regression even worse, as compression adds more processing during write operations.<\/p>\n\n\n\n