Lob Logical Read et lob read-ahead reads dans NCCI
J'ai une table de test avec la structure suivante.
CREATE TABLE [dbo].[DW_test](
[ID] [bigint] IDENTITY(1,1) NOT NULL,
[CourtCaseID] [int] NOT NULL,
[ActionID] [int] NOT NULL,
PRIMARY KEY CLUSTERED([ID] ASC)
Ensuite, j'ai rempli ma table avec environ 470 millions d'enregistrements avec le script suivant.
insert into DW_test
--select count(*)
--from (
select top 1000000 abs(checksum(newid())) % 100000 + 1 a, abs(checksum(newid())) % 10 + 1 b
from sys.all_objects
cross join sys.all_objects a
cross join sys.all_objects b
cross join sys.all_objects c
cross join sys.all_objects d
cross join sys.all_objects e
cross join sys.all_objects f
cross join sys.all_objects g
--) t
GO
Le script a été exécuté environ 470 fois pour générer 470 millions d'enregistrements dans la table et a créé NCCI sur cette table.
CREATE NONCLUSTERED COLUMNSTORE INDEX [IX_test1] ON [dbo].[DW_test]
(
[CourtCaseID],
[ActionID]
)
Ensuite, je teste une requête simple pour compter les enregistrements dans le tableau.
DBCC DROPCLEANBUFFERS
GO
select COUNT_BIG(*)
from DW_test
Si je tourne SET STATISTICS IO ON J'obtiens les résultats suivants
Avec cache froid
Tableau 'DW_test'. Nombre de balayages 25, lectures logiques 3, lectures physiques 0, lectures anticipées 0, lob lectures logiques 469697, lob lectures physiques 1, lob lectures anticipées 1877324.
Tableau 'DW_test'. Le segment lit 453, le segment a sauté 0.
Tableau "Table de travail". Nombre de balayages 0, lectures logiques 0, lectures physiques 0, lectures anticipées 0, lectures logiques 0, lob lectures physiques 0, lob lectures anticipées 0.
Avec cache chaud
Tableau 'DW_test'. Nombre de scans 25, lectures logiques 3, lectures physiques 0, lectures anticipées 0, lob lectures logiques 229248, lob lectures physiques 0, lob lectures anticipées 0.
Tableau 'DW_test'. Le segment lit 453, le segment a sauté 0.
Tableau "Table de travail". Nombre de balayages 0, lectures logiques 0, lectures physiques 0, lectures anticipées 0, lectures logiques 0, lob lectures physiques 0, lob lectures anticipées 0. "
Je sais qu'une lecture logique est une seule page de données lue dans le pool de tampons pendant l'exécution de la requête et une lecture physique est une seule page de données lue sur le disque. RedGate nous dit que la lecture anticipée est:
Ce nombre nous indique combien de lectures physiques ont été satisfaites par le mécanisme de lecture anticipée des serveurs SQL. Ceci est directement lié aux lectures physiques, donc s'il n'y a pas de lectures physiques, vous aurez 0 pour les lectures anticipées.
Dans mon cas, j'ai affaire à des lectures logiques, physiques et de lecture anticipée. Je veux comprendre ce que ce nombre signifie dans mon cas particulier.
Comment est-il possible d'avoir seulement 1 lob de lecture physique avec cache froid si la table a environ 470 millions d'enregistrements?
Comment est-il possible que le nombre total de pages lob soit passé d'environ 2,3 millions en cache froid à environ 220k en cache chaud?
Comment est-il possible d'avoir seulement 1 lob de lecture physique avec cache froid si la table a environ 470 millions d'enregistrements?
Il existe une lecture physique LOB et 1 877 324 lectures anticipées. La lecture anticipée est toujours une lecture physique, juste effectuée à l'avance (prélecture). Le devis de Redgate est incorrect.
Comment est-il possible que le nombre total de pages lob soit passé d'environ 2,3 millions en cache froid à environ 220k en cache chaud?
Les lectures logiques comptent le nombre de fois où une page en mémoire a été touchée. La réduction est de 469 697 (cache froid) à 229 248 (chaud). Je n'ai pas d'explication complète à cela, mais cela peut être en partie parce que les données du magasin de colonnes sont mises en cache de manière contiguë dans un pool d'objets de magasin de colonnes séparé, plutôt que dans le pool de tampons général de la taille d'une page.
La lecture anticipée lit les pages des niveaux supérieurs d'un arbre b pour identifier les pages à lire avant la numérisation, ce qui peut également entraîner un nombre variable de lectures logiques `` supplémentaires '', en fonction du moment et des caractéristiques du système de stockage . Les index Columnstore ont une structure b-tree sur le stockage persistant.
Un autre facteur est le parallélisme (il semble que votre test ait été exécuté au DOP 24), car les demandes qui se chevauchent de différents threads peuvent entraîner des lectures logiques supplémentaires. Vous pouvez constater que les lectures logiques en excès diminuent quelque peu si vous exécutez avec OPTION (MAXDOP 1).
Les détails de stockage interne pour columnstore ne sont pas bien documentés, ni entièrement pris en charge par les DMV habituels. À ce stade, je dirais que la meilleure explication de la réduction des lectures entre les cas de cache froid et chaud est la différence entre le stockage sur disque et en mémoire (mis en cache).
Les données de colonnes (dictionnaires et segments) sont stockées sur des LOB sur disque, mais ne sont pas conservées en mémoire dans le même format, pour des raisons de performances. Parce que ce sont des choses différentes, vous ne pouvez pas simplement ajouter des lectures logiques aux lectures physiques pour obtenir un résultat significatif.
"Comment est-il possible d'avoir seulement 1 lob de lecture physique avec cache froid si la table a environ 470 millions d'enregistrements?"
Parce que les autres lectures physiques ont été servies par lecture anticipée (le type LOB). Peut-être que cet article RedGate vous a dérouté, mais si vous servez (par exemple) d'une lecture anticipée (RA), alors vous ne verrez aucune lecture physique. Le thread qui recueille les statistiques de lectures physiques a trouvé ces pages dans le cache, donc elles n'ont pas été accumulées dans le compteur de lectures physiques.
Une autre situation lorsque nous rencontrons ce problème est le compteur perfmon de taux de succès du cache de tampon classique. RA indique que pas contribue à cette valeur, vous pouvez donc avoir des charges et des charges d'E/S physiques mais toujours proches de 100 dans BCHR.
"Comment est-il possible que le nombre total de pages lob soit passé d'environ 2,3 millions en cache froid à environ 220k en cache chaud?"
Je suppose que le premier a lancé une statistique de création automatique.