Por que o SQL Server se recusa a atualizar essas estatísticas com outra coisa senão a fullscan?

Percebi uma operação de estatísticas de atualização automática de execução relativamente longa (20 min +) em uma compilação diária de datawarehouse. A tabela envolvida é

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

Isso está sendo executado no Microsoft SQL Server 2012 (SP1) - 11.0.3513.0 (X64) para que os índices columnstore graváveis ​​não estejam disponíveis.

A tabela contém dados para duas chaves distintas do mercado. A compilação alterna a partição de um MarketKey específico para uma tabela intermediária, desativa o índice columnstore, executa gravações necessárias, reconstrói o columnstore e, em seguida, o inverte.

O plano de execução para as estatísticas de atualização mostra que ele retira todas as linhas da tabela, classifica-as, engana o número estimado de linhas e chega ao tempdbnível 2 do derramamento.

Corrida

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

Shows

Se eu tentar explicitamente reduzir o tamanho da amostra das estatísticas desse índice para o usado pelos outros com

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

A consulta é executada por mais de 20 minutos e o plano de execução mostra que está processando todas as linhas, e não a amostra 897.667 solicitada.

As estatísticas geradas no final de tudo isso não são muito interessantes e definitivamente não parecem justificar o tempo gasto em uma verificação 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                               

Alguma idéia de por que estou enfrentando esse comportamento e que medidas posso tomar além de usá NORECOMPUTE-las?

Um script de reprodução está aqui . Ele simplesmente cria uma tabela com uma PK em cluster e um índice columnstore e tenta atualizar as estatísticas da PK com um tamanho de amostra baixo. Isso não usa particionamento - mostrando que o aspecto de particionamento não é necessário. No entanto, o uso do particionamento descrito acima piora a situação, pois a alternância da partição e sua troca (mesmo sem outras alterações) aumentam o modification_counter dobrando o número de linhas na partição, garantindo praticamente que as estatísticas sejam considerado obsoleto e atualizado automaticamente.

Tentei adicionar um índice não clusterizado à tabela, conforme indicado no KB2986627 (ambos filtrados sem linhas e, quando isso falhou, um NCI não filtrado também sem efeito).

A reprodução não mostrou o comportamento problemático na compilação 11.0.6020.0 e, após a atualização para o SP3, o problema foi corrigido.

A primeira coisa que eu tentaria é atualizar a instância do SQL Server do SP1 CU16 com QFE que você possui agora, para o SP3 CU1 (versão atual de 2012) e depois testar novamente para ver se o comportamento é o mesmo.

Por exemplo:

CORRECÇÃO: UPDATE STATISTICS executa amostragem e processamento incorretos para uma tabela com índice columnstore no SQL Server

... lançado pela primeira vez no SP2 CU2 pode ser relevante.

Dito isso, não tenho certeza se o columnstore de 2012 suportou o exemplo de tabela, necessário para estatísticas amostradas. Atualizarei esta resposta assim que um repro estiver disponível na pergunta.