Perché SQL Server rifiuta di aggiornare queste statistiche con tutt'altro che fullscan?

Ho notato un'operazione di statistiche di aggiornamento automatico relativamente lunga (20 min +) in una build quotidiana di datawarehouse. Il tavolo in questione è

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

Questo è in esecuzione su Microsoft SQL Server 2012 (SP1) - 11.0.3513.0 (X64), quindi gli indici columnstore scrivibili non sono disponibili.

La tabella contiene dati per due chiavi di mercato distinte. La build trasforma la partizione per un MarketKey specifico in una tabella di gestione temporanea, disabilita l'indice columnstore, esegue le scritture necessarie, ricostruisce il columnstore, quindi lo reinserisce.

Il piano di esecuzione per le statistiche di aggiornamento mostra che estrae tutte le righe dalla tabella, le ordina, ottiene il numero stimato di righe gravemente errato e si riversa al tempdblivello di versamento 2.

In esecuzione

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

Spettacoli

Se provo esplicitamente a ridurre la dimensione del campione delle statistiche di quell'indice a quella utilizzata dagli altri con

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

La query viene eseguita di nuovo per 20 minuti + e il piano di esecuzione mostra che sta elaborando tutte le righe non l'esempio 897.667 richiesto.

Le statistiche generate alla fine di tutto ciò non sono molto interessanti e sicuramente non sembrano giustificare il tempo impiegato per una scansione completa.

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                               

Qualche idea sul perché sto riscontrando questo comportamento e quali passi posso fare oltre NORECOMPUTEa usarli?

Uno script di riproduzione è qui . Crea semplicemente una tabella con un PK cluster e un indice columnstore e tenta di aggiornare le statistiche PK con una dimensione del campione bassa. Questo non usa il partizionamento, dimostrando che l'aspetto del partizionamento non è richiesto. Tuttavia l'uso del partizionamento sopra descritto non fa che peggiorare le cose in quanto il cambio della partizione e il suo successivo ripristino (anche senza altre modifiche) aumenterà il counter_modifica raddoppiando il numero di righe nella partizione garantendo praticamente che le statistiche saranno considerato obsoleto e aggiornato automaticamente.

Ho provato ad aggiungere un indice non cluster alla tabella come indicato in KB2986627 (entrambi filtrati senza righe e quindi, in caso di errore, un NCI non filtrato anche senza effetto).

La riproduzione non ha mostrato il comportamento problematico sulla build 11.0.6020.0 e dopo l'aggiornamento a SP3 il problema è stato risolto.

La prima cosa che vorrei provare è aggiornare l'istanza di SQL Server da SP1 CU16 con QFE che hai in questo momento, a SP3 CU1 (build corrente del 2012), quindi ripetere il test per vedere se il comportamento è lo stesso.

Per esempio:

FIX: UPDATE STATISTICS esegue il campionamento e l'elaborazione errati per una tabella con indice columnstore in SQL Server

... rilasciato per la prima volta in SP2 CU2 può essere rilevante.

Detto questo, non sono sicuro che il columnstore 2012 abbia supportato tableample, necessario per le statistiche campionate. Aggiornerò questa risposta quando sarà disponibile una replica nella domanda.