Estou tentando entender alguns metadados de cache de plano de execução em um sistema SQL Server 2016 SP3 e não consigo conciliar o que estou vendo com os documentos.

Os documentos parasys.dm_exec_cached_plans dizer que contém:

uma linha para cada plano de consulta armazenado em cache pelo SQL Server para uma execução de consulta mais rápida.

No sistema que estou observando, esta visão tem 41.283 linhas agora. A grande maioria destes (37.594 linhas) são cacheobjtype = "Compiled Plan" e objtype = "Adhoc".

Os documentos parasys.dm_exec_query_stats dizer que contém:

uma linha por instrução de consulta dentro do plano armazenado em cache e o tempo de vida das linhas está vinculado ao próprio plano. Quando um plano é removido do cache, as linhas correspondentes são eliminadas dessa visualização.

Eu esperaria que houvesse pelo menos 37.594 linhas nessa exibição (uma por plano em cache, potencialmente mais se alguns dos planos em cache tiverem várias instruções). No entanto, essa exibição tem um total de 6.867 linhas.

Essa discrepância é tão grande que devo assumir que estou entendendo mal o que deveria estar nessas visões.

Alguém pode me ajudar a entender por que existem tão poucas linhas em sys.dm_exec_query_statscomparação com sys.dm_exec_cached_plans?

Eu tentei unir as tabelas internamente em plan_handle, e as únicas correspondências foram 1:1 - em outras palavras, existem dezenas de milhares de planos em cache sem linhas de "estatísticas de consulta".

Eu também pensei que a diferença poderia ser explicada por muitas linhas estarem em sys.dm_exec_procedure_statsou sys.dm_exec_trigger_stats, mas esse não era o caso (93 e 2 linhas, respectivamente).

Para quem estiver curioso sobre o "porquê" desta pergunta, estou tentando ver a idade dos vários planos no cache e não tenho certeza de uma maneira de fazer isso além de ingressar sys.dm_exec_query_statse verificar creation_time.

Aqui estão as consultas que usei para obter os números referenciados acima:

-- total cached plans
SELECT COUNT_BIG(*) AS total_cached_plans
FROM sys.dm_exec_cached_plans decp

-- totals by type
SELECT decp.cacheobjtype, decp.objtype, COUNT_BIG(*) AS plan_count
FROM sys.dm_exec_cached_plans decp
GROUP BY decp.cacheobjtype, decp.objtype
ORDER BY decp.cacheobjtype, decp.objtype;

-- total query stats
SELECT COUNT_BIG(*) AS total_query_stats
FROM sys.dm_exec_query_stats;

A grande maioria dessas consultas são consultas de usuário não parametrizadas, não consultas do sistema. Eu verifiquei isso classificando pelo texto SQL (extraído de sys.dm_exec_sql_text). Alguns exemplos:

• 5.000 instruções "INSERT INTO" diferentes na mesma tabela com diferentes valores literais
• 15.000 consultas "SELECT COUNT(*)" diferentes com cláusulas WHERE diferentes
• 15.000 instruções "UPDATE" diferentes em algumas tabelas com valores literais diferentes

Essas são todas as consultas legítimas enviadas pelos aplicativos que se conectam a esse servidor.

Configurar

Estou tendo problemas para entender uma estimativa de cardinalidade. Aqui está minha configuração de teste:

• a versão 2010 do banco de dados Stack Overflow
• SQL Server 2017 CU15+GDR (KB4505225) - 14.0.3192.2
• o novo CE (nível de compatibilidade 140)

Eu tenho este proc:

USE StackOverflow2010;
GO

CREATE OR ALTER PROCEDURE #sp_PostsByCommentCount
    @CommentCount int
AS
BEGIN
    SELECT * 
    FROM dbo.Posts p
    WHERE 
        p.CommentCount = @CommentCount
    OPTION (RECOMPILE); 
END;
GO

Não há índices ou estatísticas não clusterizadas na dbo.Poststabela (há um índice clusterizado em Id).

Ao solicitar um plano estimado para isso, as "linhas estimadas" que saem dbo.Postssão 1.934,99:

EXEC #sp_PostsByCommentCount @CommentCount = 51;

O seguinte objeto de estatísticas foi criado automaticamente quando solicitei o plano estimado:

DBCC SHOW_STATISTICS('dbo.Posts', [_WA_Sys_00000006_0519C6AF]);

Os destaques disso são:

• As estatísticas têm uma taxa de amostragem bastante baixa de 1,81% (67.796 / 3.744.192)
• Apenas 31 passos do histograma foram usados
• O valor "Toda densidade" é 0.03030303(33 valores distintos foram amostrados)
• O último RANGE_HI_KEYno histograma é 50, com EQ_ROWSde 1

Pergunta

A passagem de qualquer valor superior a 50 (até e incluindo 2.147.483.647) resulta na estimativa de 1.934,99 linhas. Que cálculo ou valor é usado para produzir essa estimativa? O estimador de cardinalidade legado produz uma estimativa de 1 linha, a propósito.

O que eu tentei

Aqui estão algumas teorias que tive, coisas que tentei ou informações adicionais que consegui desenterrar enquanto investigava isso.

Vetor de densidade

Inicialmente pensei que seria o vetor de densidade, o mesmo que se eu tivesse usado OPTION (OPTIMIZE FOR UNKNOWN). Mas o vetor de densidade para este objeto de estatísticas é 3.744.192 * 0,03030303 = 113.460, então não é isso.

Eventos estendidos

Eu tentei executar uma sessão de Evento Estendido que coletou o query_optimizer_estimate_cardinalityevento (que eu aprendi na postagem do blog de Paul White Cardinality Estimation: Combining Density Statistics ), e obtive esses tipos de informações interessantes:

<CalculatorList>
  <FilterCalculator CalculatorName="CSelCalcColumnInInterval" Selectivity="-1.000" 
                    CalculatorFailed="true" TableName="[p]" ColumnName="CommentCount" />

  <FilterCalculator CalculatorName="CSelCalcAscendingKeyFilter" Selectivity="0.001" 
                    TableName="[p]" ColumnName="CommentCount" UseAverageFrequency="true" 
                    StatId="4" />
</CalculatorList>

Então parece que a CSelCalcAscendingKeyFiltercalculadora foi usada (a outra diz que falhou, o que quer que isso signifique). Esta coluna não é uma chave, ou única, ou necessariamente ascendente, mas tanto faz.

Fazer uma pesquisa no Google sobre esse termo me levou a alguns posts no blog:

• Joe Sack - A calculadora CSelCalcAscendingKeyFilter ,
• Itzik Ben-Gan - Procure e você deve escanear Parte II: Chaves Ascendentes

Essas postagens indicam que o novo CE baseia essas estimativas fora do histograma em uma combinação do vetor de densidade e do contador de modificação da estatística. Infelizmente, já descartei o vetor de densidade (acho?!), e o contador de modificação é zero (de sys.dm_db_stats_propertiesqualquer maneira).

Sinalizadores de rastreamento

Forrest sugeriu que eu ativasse o TF 2363 para obter mais informações sobre o processo de estimativa. Eu acho que a coisa mais relevante dessa saída é esta:

Plan for computation:

  CSelCalcAscendingKeyFilter(avg. freq., QCOL: [p].CommentCount)

Selectivity: 0.000516798

Este é um avanço (obrigado, Forrest!): esse 0.000516798número (que parece ter sido arredondado de forma inútil no Selectivity="0.001"atributo XE acima) multiplicado pelo número de linhas na tabela é a estimativa que eu estava procurando (1.934,99).

Provavelmente estou perdendo algo óbvio, mas não consegui fazer engenharia reversa de como esse valor de seletividade é produzido dentro da CSelCalcAscendingKeyFiltercalculadora.

Confira esta consulta. É bem simples (veja o final do post para definições de tabela e índice e um script de reprodução):

SELECT MAX(Revision)
FROM dbo.TheOneders
WHERE Id = 1 AND 1 = (SELECT 1);

Nota: o "AND 1 = (SELECT 1) é apenas para evitar que essa consulta seja parametrizada automaticamente, o que eu senti que estava confundindo o problema - na verdade, ele obtém o mesmo plano com ou sem essa cláusula

E aqui está o plano ( cole o link do plano) :

Como há um "top 1" lá, fiquei surpreso ao ver o operador de agregação de fluxo. Não me parece necessário, pois é garantido que haverá apenas uma linha.

Para testar essa teoria, experimentei esta consulta logicamente equivalente:

SELECT MAX(Revision)
FROM dbo.TheOneders
WHERE Id = 1
GROUP BY Id;

Aqui está o plano para esse ( cole o link do plano ):

Com certeza, o grupo por plano é capaz de sobreviver sem o operador de agregação de fluxo.

Observe que ambas as consultas lêem "para trás" do final do índice e fazem um "top 1" para obter a revisão máxima.

O que estou perdendo aqui? A agregação de fluxo está realmente funcionando na primeira consulta ou deve ser eliminada (e é apenas uma limitação do otimizador que não é)?

A propósito, percebo que este não é um problema incrivelmente prático (ambas as consultas relatam 0 ms de CPU e tempo decorrido), estou apenas curioso sobre os internos / comportamento exibidos aqui.

Aqui está o código de configuração que executei antes de executar as duas consultas acima:

DROP TABLE IF EXISTS dbo.TheOneders;
GO

CREATE TABLE dbo.TheOneders
(
    Id INT NOT NULL,
    Revision SMALLINT NOT NULL,
    Something NVARCHAR(23),

    CONSTRAINT PK_TheOneders PRIMARY KEY NONCLUSTERED (Id, Revision)
);
GO

INSERT INTO dbo.TheOneders
    (Id, Revision, Something)
SELECT DISTINCT TOP 1000 
    1, m.message_id, 'Do...'
FROM sys.messages m
ORDER BY m.message_id
OPTION (MAXDOP 1);

INSERT INTO dbo.TheOneders
    (Id, Revision, Something)
SELECT DISTINCT TOP 100 
    2, m.message_id, 'Do that thing you do...'
FROM sys.messages m
ORDER BY m.message_id
OPTION (MAXDOP 1);
GO

Estou pensando em criar um índice filtrado em minha cópia do banco de dados Stack Overflow . Algo assim, por exemplo:

CREATE UNIQUE NONCLUSTERED INDEX IX_DisplayName_Filtered
    ON dbo.Users (DisplayName)
    WHERE Reputation > 400000;

Devo sempre adicionar a coluna na expressão de filtragem ( Reputationneste exemplo) à chave ou às inclusões para o índice, ou tê-la na expressão de filtragem é suficiente?

Acabei de executar sp_whona minha instância do SQL Server 2016 que usa MEMORY_OPTIMIZEDtabelas e vejo vários XTP_THREAD_POOLprocessos em execução:

Alguns outros detalhes sobre a saída:

• Existem exatamente 6 XTP_THREAD_POOLlinhas no conjunto de resultados
• Meu sistema tem dois núcleos lógicos
  • Especificamente, é uma VM com 2 soquetes - cada soquete abriga um processador de 1 núcleo
• Todas essas tarefas estão sendo executadas em segundo plano (sa)

O que esses processos estão fazendo? Não estou encontrando muito no Google sobre esse nome de tarefa.

TIA

Considere esta definição de tabela:

CREATE TABLE [dbo].[Post]
(
    [Id] INT IDENTITY(1,1) NOT NULL,
    [PostType] VARCHAR(10) NOT NULL,

    CONSTRAINT [CK_Post_PostType] CHECK ([PostType] IN ('Question', 'Answer', 'Comment'))
)

Se eu executar isso e depois olhar em sys.check_constraints:

select [definition] 
from sys.check_constraints
where [name] = 'CK_Post_PostType';

Esta é a saída:

([PostType]='Comment' OR [PostType]='Answer' OR [PostType]='Question')

Então, mudou minha declaração "in" para uma série de declarações "ou".

O mesmo vale para (pelo menos)

• BETWEEN(é alterado para ORdeclarações) e
• CAST(é alterado para CONVERT).

Percebo que isso não é um problema funcional no SQL Server, pois as expressões são logicamente equivalentes. Mas isso causa problemas com ferramentas de comparação de esquema como SSDT, porque o código-fonte está fora de sincronia com o código implantado. Eu escrevi no blog com mais detalhes sobre o problema aqui: Problemas de SSDT: implantando a mesma alteração repetidamente

Existe um nome para esse processo/comportamento de conversão? Existe alguma documentação para as diferentes conversões que podem ocorrer, para que possamos planejá-las (ou tentar evitá-las)?

tl; dr : por que CHECKDB está lendo o log de transações para um banco de dados de usuário com tabelas otimizadas para memória?

Parece que CHECKDB está lendo o arquivo de log de transações do banco de dados do usuário quando está verificando um dos meus bancos de dados - em particular, um banco de dados que usa tabelas OLTP na memória.

CHECKDB para este banco de dados ainda termina em um período de tempo razoável, então estou apenas curioso sobre o comportamento; mas é definitivamente a duração mais longa para CHECKDB de todos os bancos de dados nesta instância.

Ao examinar o épico " CHECKDB From Every Angle: Complete description of all CHECKDB stage " de Paul Randal ", vejo que o CHECKDB pré-SQL 2005 costumava ler o log para obter uma visão consistente do banco de dados. Mas como é 2016, ele usa um instantâneo de banco de dados interno.

No entanto, um dos pré- requisitos para instantâneos é que:

O banco de dados de origem não deve conter um grupo de arquivos MEMORY_OPTIMIZED_DATA

Meu banco de dados de usuário tem um desses grupos de arquivos, então parece que os instantâneos estão fora da mesa.

De acordo com os documentos CHECKDB :

Se um instantâneo não puder ser criado ou TABLOCK for especificado, DBCC CHECKDB adquirirá bloqueios para obter a consistência necessária. Nesse caso, um bloqueio de banco de dados exclusivo é necessário para realizar as verificações de alocação e os bloqueios de tabela compartilhada são necessários para realizar as verificações de tabela.

Ok, então estamos fazendo o bloqueio de banco de dados e tabela em vez de instantâneos. Mas isso ainda não explica por que ele precisa ler o log de transações. Então o que dá?

Forneci um script abaixo para reproduzir o cenário. Ele é usado sys.dm_io_virtual_file_statspara identificar as leituras do arquivo de log.

Observe que na maioria das vezes ele lê uma pequena parte do log (480 KB), mas ocasionalmente lê muito mais (48,2 MB). No meu cenário de produção, ele lê a maior parte do arquivo de log (~1,3 GB do arquivo de 2 GB) todas as noites à meia-noite quando executamos CHECKDB.

Aqui está um exemplo das saídas que obtive até agora com o script:

collection_time            num_of_reads     num_of_bytes_read
2018-04-04 15:12:29.203    106              50545664

Ou isto:

collection_time            num_of_reads     num_of_bytes_read
2018-04-04 15:25:14.227    1                491520

Se eu substituir os objetos com otimização de memória por tabelas regulares, a saída será assim:

collection_time            num_of_reads     num_of_bytes_read
2018-04-04 15:21:03.207    0                0

Por que CHECKDB está lendo o arquivo de log? E especialmente, por que ocasionalmente lê uma parte muito maior do arquivo de log?

Aqui está o script real:

-- let's have a fresh DB
USE [master];

IF (DB_ID(N'LogFileRead_Test') IS NOT NULL) 
BEGIN
    ALTER DATABASE [LogFileRead_Test]
    SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
    DROP DATABASE [LogFileRead_Test];
END

GO
CREATE DATABASE [LogFileRead_Test]

GO
ALTER DATABASE [LogFileRead_Test]
MODIFY FILE
(
    NAME = LogFileRead_Test_log,
    SIZE = 128MB
);

-- Hekaton-yeah, I want memory optimized data
GO
ALTER DATABASE [LogFileRead_Test]
ADD FILEGROUP [LatencyTestInMemoryFileGroup] CONTAINS MEMORY_OPTIMIZED_DATA;

GO
ALTER DATABASE [LogFileRead_Test]
ADD FILE 
(
    NAME = [LatencyTestInMemoryFile], 
    FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\LogFileRead_Test_SessionStateInMemoryFile'
) TO FILEGROUP [LatencyTestInMemoryFileGroup];

GO
USE [LogFileRead_Test]

GO
CREATE TYPE [dbo].[InMemoryIdTable] AS TABLE (
    [InMemoryId] NVARCHAR (88) COLLATE Latin1_General_100_BIN2 NOT NULL,
    PRIMARY KEY NONCLUSTERED HASH ([InMemoryId]) WITH (BUCKET_COUNT = 240))
    WITH (MEMORY_OPTIMIZED = ON);

GO
CREATE TABLE [dbo].[InMemoryStuff] (
    [InMemoryId]   NVARCHAR (88)    COLLATE Latin1_General_100_BIN2 NOT NULL,
    [Created]     DATETIME2 (7)    NOT NULL,
    CONSTRAINT [PK_InMemoryStuff_InMemoryId] PRIMARY KEY NONCLUSTERED HASH ([InMemoryId]) WITH (BUCKET_COUNT = 240)
)
WITH (MEMORY_OPTIMIZED = ON);

GO
-- RBAR is the new black (we need some logs to read)
declare @j int = 0;
while @j < 100000
begin
    INSERT INTO [dbo].[InMemoryStuff](InMemoryId, Created) VALUES ('Description' + CAST(@j as varchar), GETDATE());
    set @j = @j + 1;
end

-- grab a baseline of virtual file stats to be diff'd later
select f.num_of_reads, f.num_of_bytes_read
into #dm_io_virtual_file_stats
from sys.dm_io_virtual_file_stats(default, default) f
where database_id = db_id('LogFileRead_Test') and file_id = FILE_IDEX('LogFileRead_Test_log');

-- hands off my log file, CHECKDB!
GO
DBCC CHECKDB ([LogFileRead_Test]) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY;

-- grab the latest virtual file stats, and compare with the previous capture
GO
select f.num_of_reads, f.num_of_bytes_read
into #checkdb_stats
from sys.dm_io_virtual_file_stats(default, default) f
where database_id = db_id('LogFileRead_Test') and file_id = FILE_IDEX('LogFileRead_Test_log');

select 
        collection_time = GETDATE() 
        , num_of_reads = - f.num_of_reads + t.num_of_reads
        , num_of_bytes_read = - f.num_of_bytes_read + t.num_of_bytes_read
into #dm_io_virtual_file_stats_diff
from #dm_io_virtual_file_stats f, #checkdb_stats t;

drop table #checkdb_stats;
drop table #dm_io_virtual_file_stats;

-- CHECKDB ignored my comment
select collection_time, num_of_reads, num_of_bytes_read
from #dm_io_virtual_file_stats_diff d
order by d.collection_time;

drop table #dm_io_virtual_file_stats_diff;

-- I was *not* raised in a barn
USE [master];

ALTER DATABASE [LogFileRead_Test]
SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE [LogFileRead_Test];

Como esse repro geralmente gera apenas 1 ou 106 leituras de arquivos de log, pensei em pesquisar o 1 com uma sessão de eventos estendidos file_read e file_read_completed.

name                timestamp                   mode        offset  database_id file_id size    duration
file_read           2018-04-06 10:51:11.1098141 Contiguous  72704   9           2       0       NULL    
file_read_completed 2018-04-06 10:51:11.1113345 Contiguous  72704   9           2       491520  1       

E aqui estão os detalhes do VLF ( DBCC LOGINFO()) para o contexto desses deslocamentos e tal:

RecoveryUnitId  FileId  FileSize    StartOffset FSeqNo  Status  Parity  CreateLSN
0               2       2031616     8192        34      2       64      0
0               2       2031616     2039808     35      2       64      0
0               2       2031616     4071424     36      2       64      0
0               2       2285568     6103040     37      2       64      0
0               2       15728640    8388608     38      2       64      34000000005200001
0               2       15728640    24117248    39      2       64      34000000005200001
0               2       15728640    39845888    40      2       64      34000000005200001
0               2       15728640    55574528    0       0       0       34000000005200001
0               2       15728640    71303168    0       0       0       34000000005200001
0               2       15728640    87031808    0       0       0       34000000005200001
0               2       15728640    102760448   0       0       0       34000000005200001
0               2       15728640    118489088   0       0       0       34000000005200001

Então, a operação CHECKDB:

• começou a ler 63 KB (64.512 bytes) no primeiro VLF,
• leia 480 KB (491.520 bytes) e
• não leu os últimos 1.441 KB ( 1.475.584 bytes) do VLF

Também capturei as pilhas de chamadas, caso sejam úteis.

pilha de chamadas file_read:

(00007ffd`999a0860)   sqlmin!XeSqlPkg::file_read::Publish+0x1dc   |  (00007ffd`999a0b40)   sqlmin!XeSqlPkg::file_read_enqueued::Publish
(00007ffd`9a825e30)   sqlmin!FireReadEvent+0x118   |  (00007ffd`9a825f60)   sqlmin!FireReadEnqueuedEvent
(00007ffd`9980b500)   sqlmin!FCB::AsyncRead+0x74d   |  (00007ffd`9980b800)   sqlmin!FCB::AsyncReadInternal
(00007ffd`9970e9d0)   sqlmin!SQLServerLogMgr::LogBlockReadAheadAsync+0x6a6   |  (00007ffd`9970ec00)   sqlmin!LBH::Destuff
(00007ffd`9970a6d0)   sqlmin!LogConsumer::GetNextLogBlock+0x1591   |  (00007ffd`9970ab70)   sqlmin!LogPoolPrivateCacheBufferMgr::Lookup
(00007ffd`9a9fcbd0)   sqlmin!SQLServerLogIterForward::GetNext+0x258   |  (00007ffd`9a9fd2d0)   sqlmin!SQLServerLogIterForward::GetNextBlock
(00007ffd`9aa417f0)   sqlmin!SQLServerCOWLogIterForward::GetNext+0x2b   |  (00007ffd`9aa418c0)   sqlmin!SQLServerCOWLogIterForward::StartScan
(00007ffd`9aa64210)   sqlmin!RecoveryMgr::AnalysisPass+0x83b   |  (00007ffd`9aa65100)   sqlmin!RecoveryMgr::AnalyzeLogRecord
(00007ffd`9aa5ed50)   sqlmin!RecoveryMgr::PhysicalRedo+0x233   |  (00007ffd`9aa5f790)   sqlmin!RecoveryMgr::PhysicalCompletion
(00007ffd`9aa7fd90)   sqlmin!RecoveryUnit::PhysicalRecovery+0x358   |  (00007ffd`9aa802c0)   sqlmin!RecoveryUnit::CompletePhysical
(00007ffd`9a538b90)   sqlmin!StartupCoordinator::NotifyPhaseStart+0x3a   |  (00007ffd`9a538bf0)   sqlmin!StartupCoordinator::NotifyPhaseEnd
(00007ffd`9a80c430)   sqlmin!DBTABLE::ReplicaCreateStartup+0x2f4   |  (00007ffd`9a80c820)   sqlmin!DBTABLE::RefreshPostRecovery
(00007ffd`9a7ed0b0)   sqlmin!DBMgr::SyncAndLinkReplicaRecoveryPhase+0x890   |  (00007ffd`9a7edff0)   sqlmin!DBMgr::DetachDB
(00007ffd`9a7f2cd0)   sqlmin!DBMgr::CreatePhasedTransientReplica+0x869   |  (00007ffd`9a7f3630)   sqlmin!DBMgr::StrandTransientReplica
(00007ffd`9a7f2ae0)   sqlmin!DBMgr::CreateTransientReplica+0x118   |  (00007ffd`9a7f2cd0)   sqlmin!DBMgr::CreatePhasedTransientReplica
(00007ffd`99ec6d30)   sqlmin!DBDDLAgent::CreateReplica+0x1b5   |  (00007ffd`99ec6f90)   sqlmin!FSystemDatabase
(00007ffd`9abaaeb0)   sqlmin!UtilDbccCreateReplica+0x82   |  (00007ffd`9abab000)   sqlmin!UtilDbccDestroyReplica
(00007ffd`9ab0d7e0)   sqlmin!UtilDbccCheckDatabase+0x994   |  (00007ffd`9ab0ffd0)   sqlmin!UtilDbccRetainReplica
(00007ffd`9ab0cfc0)   sqlmin!DbccCheckDB+0x22d   |  (00007ffd`9ab0d380)   sqlmin!DbccCheckFilegroup
(00007ffd`777379c0)   sqllang!DbccCommand::Execute+0x193   |  (00007ffd`77737d70)   sqllang!DbccHelp
(00007ffd`777e58d0)   sqllang!CStmtDbcc::XretExecute+0x889   |  (00007ffd`777e6250)   sqllang!UtilDbccSetPermissionFailure
(00007ffd`76b02eb0)   sqllang!CMsqlExecContext::ExecuteStmts<1,1>+0x40d   |  (00007ffd`76b03410)   sqllang!CSQLSource::CleanupCompileXactState
(00007ffd`76b03a60)   sqllang!CMsqlExecContext::FExecute+0xa9e   |  (00007ffd`76b043d0)   sqllang!CCacheObject::Release
(00007ffd`76b03430)   sqllang!CSQLSource::Execute+0x981   |  (00007ffd`76b039b0)   sqllang!CSQLLock::Cleanup

pilha de chamadas file_read_completed:

(00007ffd`99995cc0)   sqlmin!XeSqlPkg::file_read_completed::Publish+0x1fc   |  (00007ffd`99995fe0)   sqlmin!XeSqlPkg::file_write_completed::Publish
(00007ffd`9a826630)   sqlmin!FireIoCompletionEventLong+0x227   |  (00007ffd`9a8269c0)   sqlmin!IoRequestDispenser::Dump
(00007ffd`9969bee0)   sqlmin!FCB::IoCompletion+0x8e   |  (00007ffd`9969c180)   sqlmin!IoRequestDispenser::Put
(00007ffd`beaa11e0)   sqldk!IOQueue::CheckForIOCompletion+0x426   |  (00007ffd`beaa1240)   sqldk!SystemThread::GetCurrentId
(00007ffd`beaa15b0)   sqldk!SOS_Scheduler::SwitchContext+0x173   |  (00007ffd`beaa18a0)   sqldk!SOS_Scheduler::Switch
(00007ffd`beaa1d00)   sqldk!SOS_Scheduler::SuspendNonPreemptive+0xd3   |  (00007ffd`beaa1db0)   sqldk!SOS_Scheduler::ResumeNoCuzz
(00007ffd`99641720)   sqlmin!EventInternal<SuspendQueueSLock>::Wait+0x1e7   |  (00007ffd`99641ae0)   sqlmin!SOS_DispatcherPool<DispatcherWorkItem,DispatcherWorkItem,SOS_DispatcherQueue<DispatcherWorkItem,0,DispatcherWorkItem>,DispatcherPoolConfig,void * __ptr64>::GetDispatchers
(00007ffd`9aa437c0)   sqlmin!SQLServerLogMgr::CheckLogBlockReadComplete+0x1e6   |  (00007ffd`9aa44670)   sqlmin!SQLServerLogMgr::ValidateBlock
(00007ffd`9970a6d0)   sqlmin!LogConsumer::GetNextLogBlock+0x1b37   |  (00007ffd`9970ab70)   sqlmin!LogPoolPrivateCacheBufferMgr::Lookup
(00007ffd`9a9fcbd0)   sqlmin!SQLServerLogIterForward::GetNext+0x258   |  (00007ffd`9a9fd2d0)   sqlmin!SQLServerLogIterForward::GetNextBlock
(00007ffd`9aa417f0)   sqlmin!SQLServerCOWLogIterForward::GetNext+0x2b   |  (00007ffd`9aa418c0)   sqlmin!SQLServerCOWLogIterForward::StartScan
(00007ffd`9aa64210)   sqlmin!RecoveryMgr::AnalysisPass+0x83b   |  (00007ffd`9aa65100)   sqlmin!RecoveryMgr::AnalyzeLogRecord
(00007ffd`9aa5ed50)   sqlmin!RecoveryMgr::PhysicalRedo+0x233   |  (00007ffd`9aa5f790)   sqlmin!RecoveryMgr::PhysicalCompletion
(00007ffd`9aa7fd90)   sqlmin!RecoveryUnit::PhysicalRecovery+0x358   |  (00007ffd`9aa802c0)   sqlmin!RecoveryUnit::CompletePhysical
(00007ffd`9a538b90)   sqlmin!StartupCoordinator::NotifyPhaseStart+0x3a   |  (00007ffd`9a538bf0)   sqlmin!StartupCoordinator::NotifyPhaseEnd
(00007ffd`9a80c430)   sqlmin!DBTABLE::ReplicaCreateStartup+0x2f4   |  (00007ffd`9a80c820)   sqlmin!DBTABLE::RefreshPostRecovery
(00007ffd`9a7ed0b0)   sqlmin!DBMgr::SyncAndLinkReplicaRecoveryPhase+0x890   |  (00007ffd`9a7edff0)   sqlmin!DBMgr::DetachDB
(00007ffd`9a7f2cd0)   sqlmin!DBMgr::CreatePhasedTransientReplica+0x869   |  (00007ffd`9a7f3630)   sqlmin!DBMgr::StrandTransientReplica
(00007ffd`9a7f2ae0)   sqlmin!DBMgr::CreateTransientReplica+0x118   |  (00007ffd`9a7f2cd0)   sqlmin!DBMgr::CreatePhasedTransientReplica
(00007ffd`99ec6d30)   sqlmin!DBDDLAgent::CreateReplica+0x1b5   |  (00007ffd`99ec6f90)   sqlmin!FSystemDatabase
(00007ffd`9abaaeb0)   sqlmin!UtilDbccCreateReplica+0x82   |  (00007ffd`9abab000)   sqlmin!UtilDbccDestroyReplica
(00007ffd`9ab0d7e0)   sqlmin!UtilDbccCheckDatabase+0x994   |  (00007ffd`9ab0ffd0)   sqlmin!UtilDbccRetainReplica
(00007ffd`9ab0cfc0)   sqlmin!DbccCheckDB+0x22d   |  (00007ffd`9ab0d380)   sqlmin!DbccCheckFilegroup
(00007ffd`777379c0)   sqllang!DbccCommand::Execute+0x193   |  (00007ffd`77737d70)   sqllang!DbccHelp

Esses rastreamentos de pilha se correlacionam com a resposta de Max, indicando que CHECKDB está usando um instantâneo interno, apesar da presença das tabelas Hekaton.

Eu li que os instantâneos executam a recuperação para desfazer transações não confirmadas :

As transações não confirmadas são revertidas em um instantâneo de banco de dados recém-criado porque o Mecanismo de Banco de Dados executa a recuperação após a criação do instantâneo (as transações no banco de dados não são afetadas).

Mas isso ainda não explica por que uma grande parte do arquivo de log é frequentemente lida no meu cenário de produção (e ocasionalmente na reprodução fornecida aqui). Acho que não tenho tantas transações em voo em um determinado momento no meu aplicativo, e certamente não há nenhuma na reprodução aqui.

Eu tenho uma tabela de Producerse uma tabela de Products, ambas no formato:

• Id- int, chave primária
• Name- nvarchar

Um Produtor pode carregar vários Produtos, então eu ia criar uma tabela chamada ProducerDetailsque teria:

• ProducerId- int, chave estrangeira paraProducers.Id
• ProductId- int, chave estrangeira paraProducts.Id

Então comecei a me questionar, então pensei em perguntar aos especialistas. Seria melhor o design do banco de dados ter uma Idcoluna adicional (int, chave primária) na minha ProducerDetailstabela? Ou isso é desnecessário?

Estou usando o SQL-Server 2008 R2, se isso faz alguma diferença.

EDIT - A relação entre essas tabelas seria de muitos para muitos, acredito, desculpe não ter deixado isso claro. Um produtor pode transportar vários tipos de produtos e o mesmo produto pode ser produzido por vários produtores diferentes.

_{Peço desculpas se esta pergunta for excessivamente simples, integridade referencial / design de banco de dados não é meu ponto forte (embora eu esteja tentando melhorar isso).}