Pourquoi SQL Server refuse-t-il de mettre à jour ces statistiques avec autre chose que l'analyse complète?

J'ai remarqué une opération de statistiques de mise à jour automatique relativement longue (20 min +) dans une construction de datawarehouse quotidienne. Le tableau concerné est

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

Ceci s'exécute sur Microsoft SQL Server 2012 (SP1) - 11.0.3513.0 (X64), donc les index columnstore inscriptibles ne sont pas disponibles.

Le tableau contient des données pour deux clés de marché distinctes. La génération remplace la partition d'une MarketKey spécifique par une table intermédiaire, désactive l'index columnstore, effectue les écritures nécessaires, reconstruit le columnstore, puis le rétablit.

Le plan d'exécution des statistiques de mise à jour montre qu'il extrait toutes les lignes de la table, les trie, obtient le nombre estimé de lignes très incorrectes et se répand tempdbavec le niveau de déversement 2.

Fonctionnement

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

Spectacles

Si j'essaie explicitement de réduire la taille de l'échantillon des statistiques de cet index à celle utilisée par les autres avec

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

La requête s'exécute à nouveau pendant 20 minutes et le plan d'exécution montre qu'il traite toutes les lignes et non l'échantillon 897 667 demandé.

Les statistiques générées à la fin de tout cela ne sont pas très intéressantes et ne semblent certainement pas justifier le temps passé sur une analyse complète.

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                               

Avez-vous des idées pour lesquelles je rencontre ce comportement et quelles mesures puis-je prendre à part les utiliser NORECOMPUTE?

Un script de repro est ici . Il crée simplement une table avec un PK en cluster et un index columnstore et essaie de mettre à jour les statistiques PK avec une petite taille d'échantillon. Cela n'utilise pas le partitionnement - montrant que l'aspect de partitionnement n'est pas requis. Cependant, l'utilisation du partitionnement décrit ci-dessus ne fait qu'aggraver les choses, car la désactivation de la partition, puis sa reconnexion (même sans autres modifications) augmentera le modification_counter en doublant le nombre de lignes de la partition, garantissant ainsi pratiquement que les statistiques seront considéré comme périmé et mis à jour automatiquement.

J'ai essayé d'ajouter un index non clusterisé à la table comme indiqué dans KB2986627 (tous deux filtrés sans lignes et puis, en cas d'échec, un NCI non filtré également sans effet).

La repro n'a pas montré le comportement problématique sur la version 11.0.6020.0 et après la mise à niveau vers SP3, le problème est maintenant résolu.

La première chose que j'essaierais serait de mettre à jour l'instance SQL Server du SP1 CU16 avec QFE que vous avez en ce moment, vers SP3 CU1 (version 2012 actuelle), puis de retester pour voir si le comportement est le même.

Par exemple:

CORRECTIF: UPDATE STATISTICS effectue un échantillonnage et un traitement incorrects pour une table avec un index columnstore dans SQL Server

... publié pour la première fois dans SP2 CU2 peut être pertinent.

Cela dit, je ne sais pas si 2012 columnstore a pris en charge l'échantillonnage de table, requis pour les statistiques échantillonnées. Je mettrai à jour cette réponse une fois qu'une repro sera disponible dans la question.