Warum weigert sich SQL Server, diese Statistiken mit etwas anderem als Fullscan zu aktualisieren?

Ich habe festgestellt, dass die automatische Aktualisierung von Statistiken in einem täglichen Datawarehouse-Build relativ lange dauert (über 20 Minuten). Der Tisch ist

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])

Dies wird unter Microsoft SQL Server 2012 (SP1) - 11.0.3513.0 (X64) ausgeführt, sodass keine beschreibbaren Columnstore-Indizes verfügbar sind.

Die Tabelle enthält Daten für zwei verschiedene Marktschlüssel. Der Build schaltet die Partition für einen bestimmten MarketKey auf eine Staging-Tabelle um, deaktiviert den Columnstore-Index, führt die erforderlichen Schreibvorgänge durch, erstellt den Columnstore neu und schaltet ihn dann wieder ein.

Aus dem Ausführungsplan für die Aktualisierungsstatistik geht hervor, dass alle Zeilen aus der Tabelle entfernt, sortiert, die geschätzte Anzahl der falsch eingegebenen Zeilen ermittelt und tempdbmit Überlaufstufe 2 erreicht werden.

Laufen

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]'); 

Zeigt an

Wenn ich explizit versuche, die Stichprobengröße dieser Indexstatistik auf die zu reduzieren, die von den anderen mit verwendet wird

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

Die Abfrage wird wieder für mindestens 20 Minuten ausgeführt und der Ausführungsplan zeigt, dass alle Zeilen verarbeitet werden, die nicht dem angeforderten 897.667-Beispiel entsprechen.

Die Statistiken, die am Ende erstellt werden, sind nicht sehr interessant und scheinen die Zeit, die für einen vollständigen Scan aufgewendet wird, definitiv nicht zu rechtfertigen.

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                               

Irgendwelche Ideen, warum ich auf dieses Verhalten stoße und welche Schritte ich unternehmen kann, außer NORECOMPUTEdiese anzuwenden?

Ein Reproskript ist hier . Es wird einfach eine Tabelle mit einer Cluster-PK und einem Columnstore-Index erstellt und versucht, die PK-Statistiken mit einer geringen Stichprobengröße zu aktualisieren. Hierbei wird keine Partitionierung verwendet. Dies zeigt, dass der Partitionierungsaspekt nicht erforderlich ist. Die oben beschriebene Verwendung der Partitionierung macht die Sache jedoch noch schlimmer, da das Ausschalten der Partition und das anschließende Wiedereinschalten (auch ohne weitere Änderungen) den Änderungszähler um die doppelte Anzahl von Zeilen in der Partition erhöht und somit praktisch garantiert, dass die Statistik erstellt wird als veraltet und automatisch aktualisiert.

Ich habe versucht, der Tabelle einen nicht gruppierten Index hinzuzufügen, wie in KB2986627 angegeben (beide ohne Zeilen gefiltert und dann, wenn dies fehlschlug, auch ohne Auswirkung ein nicht gefiltertes NCI).

In der Reproduktion wurde das problematische Verhalten in Build 11.0.6020.0 nicht angezeigt, und nach dem Upgrade auf SP3 ist das Problem behoben.

Das erste, was ich versuchen würde, ist das Aktualisieren der SQL Server-Instanz von der SP1 CU16 mit QFE, über die Sie gerade verfügen, auf SP3 CU1 (aktueller Build 2012) und anschließendes erneutes Testen, um festzustellen, ob das Verhalten dasselbe ist.

Beispielsweise:

UPDATE: UPDATE STATISTICS führt für eine Tabelle mit Columnstore-Index in SQL Server eine falsche Stichprobenerfassung und -verarbeitung durch

... zuerst in SP2 veröffentlicht CU2 kann relevant sein.

Ich bin mir jedoch nicht sicher, ob das 2012 columnstore-unterstützte Tabellenbeispiel für Stichprobenstatistiken erforderlich ist. Ich werde diese Antwort aktualisieren, sobald ein Repro in der Frage verfügbar ist.