SQL Serverがこれらの統計情報の更新をフルスキャン以外で拒否するのはなぜですか？

Question

毎日実行されるデータウェアハウスビルドで、比較的長時間（20分以上）の自動更新統計操作に気づきました。関連するテーブルは

CREATE TABLE [dbo].[factWebAnalytics]( [WebAnalyticsId] [bigint] IDENTITY(1,1) NOT NULL, [MarketKey] [int] NOT NULL CONSTRAINT [DF_factWebAnalytics_MarketKey] DEFAULT ((-1)), /*Other columns removed*/ CONSTRAINT [PK_factWebAnalytics] PRIMARY KEY CLUSTERED ( [MarketKey] ASC, [WebAnalyticsId] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [MarketKeyPS]([MarketKey]) ) ON [MarketKeyPS]([MarketKey])

これはMicrosoft SQL Server 2012（SP1）-11.0.3513.0（X64）で実行されているため、書き込み可能な列ストアインデックスは使用できません。

テーブルには、2つの異なる市場キーのデータが含まれています。ビルドは、特定のMarketKeyのパーティションをステージングテーブルに切り替え、列ストアインデックスを無効にし、必要な書き込みを実行し、列ストアを再構築してから、元に戻します。

Update statisticsの実行プランは、テーブルからすべての行を引き出し、それらをソートし、推定行数をひどく間違って取得し、スピルレベル2でtempdbにスピルすることを示しています。

ランニング

SELECT [s].[name] AS "Statistic", [sp].* FROM [sys].[stats] AS [s] OUTER APPLY sys.dm_db_stats_properties ([s].[object_id], [s].[stats_id]) AS [sp] WHERE [s].[object_id] = OBJECT_ID(N'[dbo].[factWebAnalytics]');

ショー

そのインデックスの統計のサンプルサイズを明示的に試して、他の人が使用するものに減らすと

UPDATE STATISTICS [dbo].[factWebAnalytics] [PK_factWebAnalytics] WITH SAMPLE 897667 ROWS

クエリは再び20分以上実行され、実行計画は、要求された897,667サンプルではなく、すべての行を処理していることを示しています。

このすべての最後に生成された統計はあまり興味深いものではなく、完全スキャンに費やされた時間を保証するものではないようです。

Statistics for INDEX 'PK_factWebAnalytics'. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Name Updated Rows Rows Sampled Steps Density Average Key Length String Index -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- PK_factWebAnalytics Jan 22 2016 11:31AM 420072086 420072086 2 0 12 NO 420072086 All Density Average Length Columns -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 0.5 4 MarketKey 2.380544E-09 12 MarketKey, WebAnalyticsId Histogram Steps RANGE_HI_KEY RANGE_ROWS EQ_ROWS DISTINCT_RANGE_ROWS AVG_RANGE_ROWS -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 1 0 3.441652E+08 0 1 2 0 7.590685E+07 0 1

この動作が発生する理由と、NORECOMPUTEを使用する以外に実行できる手順はありますか？

再現スクリプトここにあります。クラスター化されたPKと列ストアインデックスを含むテーブルを作成し、低いサンプルサイズでPK統計を更新しようとします。これはパーティショニングを使用しません-パーティショニングの側面が不要であることを示します。ただし、上記のパーティション分割を使用すると、パーティションを切り替えてから再度切り替えると（他の変更を加えなくても）、パーティション内の行数の2倍のmodification_counterが増加するため、状況はさらに悪化し、統計が実際に保証されます。古いと見なされ、自動更新されます。

KB2986627に示されているように、非クラスター化インデックスをテーブルに追加しようとしました（両方とも行なしでフィルターにかけられ、それが失敗すると、フィルターなしのNCIも影響なし）。

再現はビルド11.0.6020.0で問題のある動作を示さず、SP3にアップグレードした後、問題は修正されました。

Paul White 9 · Accepted Answer

まず、SQL ServerインスタンスをSP1 CU16から現在のQFEでSP3 CU1（現在の2012ビルド）に更新してから、動作が同じかどうかを再テストします。

例えば：

FIX：UPDATE STATISTICSは、SQL Serverの列ストアインデックスを持つテーブルに対して誤ったサンプリングと処理を実行します

... SP2 CU2で最初にリリースされたものが関連している可能性があります。

とは言っても、サンプリングされた統計に必要な2012 columnstoreがtablesampleをサポートしているかどうかはわかりません。質問で再現が利用可能になったら、この回答を更新します。