Où les statistiques sont-elles physiquement stockées dans SQL Server?

Où les statistiques utilisées par l'Optimiseur de requête sont-elles physiquement stockées dans un fichier de base de données SQL Server et le pool de tampons?

Plus précisément, existe-t-il un moyen de comprendre les pages utilisées par les statistiques à l'aide de DMV et / ou DBCC?

Je possède à la fois des livres sur SQL Server 2008 Internals et SQL Server Internals and Troubleshooting et aucun d'eux ne parle de la structure physique des statistiques; s'ils le font, je ne pourrai pas trouver cette information.

Je les ai trouvés.

1. Créez une table avec un simple objet stats.

   CREATE DATABASE splunge;
   GO
   USE splunge;
   GO
   CREATE TABLE dbo.foo(bar INT, munge INT);
   GO
   CREATE STATISTICS x ON dbo.foo(bar);
   CREATE STATISTICS y ON dbo.foo(munge);
   GO
   INSERT dbo.foo SELECT s1.[object_id], s2.[object_id]
     FROM sys.objects AS s1
     CROSS JOIN sys.objects AS s2;
   GO
   UPDATE STATISTICS dbo.foo;
   GO

2. Connectez-vous à l'aide du DAC ( ADMIN:Server[\instance]).

3. Exécutez les requêtes suivantes:

   DBCC SHOW_STATISTICS('dbo.foo', 'x') WITH STATS_STREAM;
   DBCC SHOW_STATISTICS('dbo.foo', 'y') WITH STATS_STREAM;
   
   SELECT name, imageval 
     FROM sys.stats AS s
     INNER JOIN sys.sysobjvalues AS o
     ON s.object_id = o.objid
     AND s.stats_id = o.subobjid
   WHERE 
     s.object_id = OBJECT_ID('dbo.foo');

Vous remarquerez que imagevalpour chaque objet stats, ce n'est pas la même chose que le blob stats, mais il contient le blob stats - il est juste décalé. Sur mon système, cela a produit ceci pour x (j'ai évidemment tronqué pas mal de bits):

0x0100...bunch of chars...000007000000C4E1BE00EEA0...rest the same
                            0x07000000C4E1BE00EEA0...rest the same

Et cela pour y:

0x0100...bunch of chars...430007000000C7E1BE00EEA0...rest the same
                            0x07000000C7E1BE00EEA0...rest the same

Il en va de même pour les statistiques indexées.

Vous pourriez probablement faire une validation supplémentaire de cela avec une série de requêtes à l'aide de DBCCcommandes. Tout d'abord, recherchez les pages concernées par l'index clusterisé sys.sysobjvalues(remplacez le nom de votre base de données):

DBCC IND('splunge', 'sys.sysobjvalues', 1);

Le résultat listera un tas de pages, celles qui vous intéressent PageType = 1. Avec une nouvelle base de données, vous devriez pouvoir trouver ces informations sur l'une des pages avec les PagePIDvaleurs les plus élevées. Par exemple, sur mon système, c'était la page 281, alors j'ai regardé de plus près cette page:

DBCC TRACEON(3604);

DECLARE @dbid INT = DB_ID();

DBCC PAGE(@dbid, 1, 281, 3);

DBCC TRACEOFF(3604);

Effectivement, j'ai trouvé les données dans l'emplacement 17:

(Sur des bases de données plus grandes, vous devrez peut-être faire beaucoup plus de chasse et de picage, car il n'y a aucune garantie que même un nouvel objet de statistiques se retrouvera sur une nouvelle (er) page.)

Allez-y et essayez ceci à la maison, mais il y a une raison pour laquelle vous devez vous connecter avec le DAC pour cela. Je serais curieux de savoir, bien sûr, ce que vous allez faire de ces informations que vous ne pourriez pas faire avec la DBCC SHOW_STATISTICSsortie.

Notez que cela n'essaie bien sûr pas de décoder le STATS_STREAMpour fournir un histogramme ou d'autres informations, et je n'ai trouvé aucune preuve que la sortie tabulaire de DBCC SHOW_STATISTICS ... WITH HISTOGRAMest stockée n'importe où au format tableau. Joe Chang a des informations sur le décodage si c'est ce que vous recherchez. Je ne pense pas que ce soit quelque chose que vous voudriez faire dans une requête - utilisez simplement DBCC.