L'exemple de mise à jour des statistiques de SQL Server manque le RANGE_HI_KEY le plus élevé sur la colonne de clé ascendante

J'essaie de comprendre comment l'échantillonnage des statistiques fonctionne et si le comportement escompté ci-dessous est attendu sur les mises à jour des statistiques échantillonnées.

Nous avons une grande table partitionnée par date avec quelques milliards de lignes. La date de partition est la date commerciale antérieure et est donc une clé ascendante. Nous chargeons uniquement les données de ce tableau pour la veille.

Le chargement des données s'exécute pendant la nuit, donc le vendredi 8 avril, nous avons chargé les données pour le 7.

Après chaque exécution, nous mettons à jour les statistiques, bien que nous prenions un échantillon plutôt qu'un FULLSCAN.

Peut-être que je suis naïf, mais je m'attendais à ce que SQL Server identifie la clé la plus élevée et la clé la plus basse de la plage pour garantir l'obtention d'un échantillon de plage précis. Selon cet article :

Pour le premier compartiment, la limite inférieure est la plus petite valeur de la colonne sur laquelle l'histogramme est généré.

Cependant, il ne mentionne pas le dernier compartiment / la plus grande valeur.

Avec la mise à jour des statistiques échantillonnées le matin du 8, l'échantillon a raté la valeur la plus élevée du tableau (le 7).

Comme nous effectuons beaucoup de requêtes sur les données de la veille, cela a entraîné une estimation de cardinalité inexacte et un certain nombre de requêtes expirant.

SQL Server ne doit-il pas identifier la valeur la plus élevée pour cette clé et l'utiliser comme maximum RANGE_HI_KEY? Ou est-ce juste une des limites de la mise à jour sans utilisation FULLSCAN?

Version SQL Server 2012 SP2-CU7. Nous ne pouvons pas actuellement mettre à niveau en raison d'un changement de OPENQUERYcomportement dans SP3 qui arrondissait les nombres dans une requête de serveur lié entre SQL Server et Oracle.

SQL Server ne doit-il pas identifier la valeur la plus élevée pour cette clé et l'utiliser comme maximum RANGE_HI_KEY? Ou est-ce juste une des limites de la mise à jour sans utilisation FULLSCAN?

C'est une limitation de l'implémentation actuelle des statistiques échantillonnées. En l'état, la collection de statistiques échantillonnées utilise TABLESAMPLE SYSTEM, qui utilise une analyse d'ordre d'allocation et choisit les pages de l'analyse à échantillonner. Seules les pages choisies contribuent à l'histogramme.

Étant donné que l'analyse est ordonnée par allocation (plutôt que par index), il n'y a aucun moyen de donner la préférence aux première et dernière pages dans l'ordre des clés.

Pour plus d'informations, consultez cette question connexe:

Comment fonctionne l'échantillonnage lors de la mise à jour des statistiques?

et mon article, Scans d'ordre d'allocation

Pour des solutions de contournement, voir Statistiques sur les colonnes ascendantes par Fabiano Amorim

Devinette rapide: activez l'indicateur de trace 4139.

Vous utilisez déjà SP2-CU1 , cela devrait donc fonctionner

Notez également les directives concernant TF 2389 et 2390 et consultez également http://sql-sasquatch.blogspot.com.mt/2013/06/mssql-plan-guides-to-address-ascending.html

(Remarque, je n'ai pas vraiment rencontré ce problème et je n'ai pas plongé aussi profondément)