Respostas:
STATISTICS IO
não inclui leituras do repositório de versões, pelo menos para o repositório de versões no tempdb.
Aqui está uma demonstração para a prova:
--setup script
USE master
GO
CREATE DATABASE TestDB
GO
ALTER DATABASE TestDB
SET ALLOW_SNAPSHOT_ISOLATION ON
GO
USE TestDB
GO
DROP TABLE IF EXISTS dbo.Test
GO
CREATE TABLE dbo.Test (ID int identity PRIMARY KEY, junk int)
INSERT dbo.Test
SELECT TOP (100000) 1
FROM master.dbo.spt_values a
CROSS JOIN master.dbo.spt_values b
Inicie um loop de atualização dos anos 30 em uma guia SSMS
--UPDATE loop
SET NOCOUNT ON
DECLARE @stop datetime = DATEADD(SECOND, 30, GETDATE())
WHILE GETDATE() < @stop
BEGIN
BEGIN TRAN
UPDATE dbo.Test
SET junk += 1
COMMIT
END
UPDATE dbo.Test
SET junk = 1
E enquanto o loop estiver em execução, execute duas consultas idênticas SNAPSHOT
com STATISTICS IO ON
, separadas por 15s para permitir que as versões se acumulem.
USE TestDB
SET STATISTICS IO ON
GO
SET TRANSACTION ISOLATION LEVEL SNAPSHOT
BEGIN TRAN
SELECT MAX(junk)
FROM dbo.Test
WAITFOR DELAY '00:00:15'
SELECT MAX(junk)
FROM dbo.Test
COMMIT
As estatísticas de IO mostram leituras idênticas:
Mas o plano de execução real mostra a varredura da segunda consulta que leva muito mais tempo, devido à leitura do armazenamento de versão.
Para provar a si mesmo que essa consulta resultou em leituras tempdb, você pode usar esta sessão de Eventos Estendidos (que obviamente é melhor que o Profiler), filtrada para a sessão em que as consultas de leitura estão em execução:
CREATE EVENT SESSION [file_reads] ON SERVER
ADD EVENT sqlserver.file_read_completed(
ACTION(sqlserver.session_id,sqlserver.sql_text)
WHERE ([sqlserver].[session_id]=(52)))
ADD TARGET package0.event_file(SET filename=N'file_reads')
GO
Ao visualizar os "dados ativos" para a sessão XE durante a demonstração, você pode ver as leituras no ID do banco de dados 2 (tempdb) e ele captura o texto da consulta também:
Agradecimentos especiais a Paul White por trazer esta questão ao STATISTICS IO.