Como posso verificar se o isolamento de instantâneo de leitura confirmada está causando problemas de aplicativo que a leitura confirmada não causaria?

escopo

Esta é uma pergunta difícil de responder e de considerar todos os problemas possíveis, porque quase todas as cargas de trabalho possuem características únicas que requerem atenção especial. Alguns podem funcionar perfeitamente usando níveis de isolamento otimistas, e outros requerem intervenção em determinadas áreas.

Na maioria dos casos, um único nível de isolamento não é 100% adequado para qualquer carga de trabalho, mas o descuido do desenvolvedor, a ingenuidade etc. podem resultar no uso de níveis de isolamento incorretos. Se isso causa algum problema ou não, geralmente é uma questão de sorte ou falta de simultaneidade.

Mensagens de erro que posso rastrear?

Para RCSI, os únicos erros que encontrei foram relacionados ao preenchimento/falta de espaço do armazenamento de versão. Você pode ter uma ideia do que procurar pesquisando nas mensagens de erro disponíveis:

SELECT
    m.*
FROM sys.messages AS m
WHERE m.language_id = 1033
AND   m.text LIKE '%[v-V]ersion [s-S]tore%'
ORDER BY
    m.message_id;

Se você estivesse falando sobre Snapshot Isolation, sua maior preocupação seriam os conflitos de atualização:

SELECT
    m.*
FROM sys.messages AS m
WHERE m.language_id = 1033
AND   m.message_id = 3960
ORDER BY
    m.message_id;

Transação de isolamento de instantâneo abortada devido a conflito de atualização. Você não pode usar o isolamento de snapshot para acessar a tabela '%.*ls' direta ou indiretamente no banco de dados '%.*ls' para atualizar, excluir ou inserir a linha que foi modificada ou excluída por outra transação. Tente novamente a transação ou altere o nível de isolamento da instrução de atualização/exclusão.

Mas esse é um cenário totalmente diferente.

Scripts de diagnóstico que posso executar?

Isso depende do que você está tentando diagnosticar. Mais comumente, seria "o que está usando o armazenamento de versão e quanto ele está usando?"

Aqui está um fragmento de código de sp_PressureDetector , ligeiramente reformatado para respeitar o comprimento da resposta:

SELECT
    free_space_gb =
        CONVERT(decimal(38, 2), SUM(d.unallocated_extent_page_count * 8.) / 1024. / 1024.),
    user_objects_gb =
        CONVERT(decimal(38, 2), SUM(d.user_object_reserved_page_count * 8.) / 1024. / 1024.),
    version_store_gb =
        CONVERT(decimal(38, 2), SUM(d.version_store_reserved_page_count * 8.) / 1024. / 1024.),
    internal_objects_gb =
        CONVERT(decimal(38, 2), SUM(d.internal_object_reserved_page_count * 8.) / 1024. / 1024.)
FROM tempdb.sys.dm_db_file_space_usage AS d
WHERE d.database_id = 2;

Se você estiver no SQL Server 2017 ou superior, poderá verificar usando algo assim:

SELECT
    d.name,
    reserved_page_count,
    reserved_space_gb = 
        CONVERT(decimal(38, 2), reserved_space_kb / 1024. / 1024.)
FROM sys.dm_tran_version_store_space_usage AS t
JOIN sys.databases AS d
  ON t.database_id = d.database_id;

Observe que eles monitoram apenas o tamanho do armazenamento de versão em tempdb . Se você estiver no SQL Server 2019+ e usando a Recuperação Acelerada de Banco de Dados, você desejará monitorar o Armazenamento de Versão Persistente.

SELECT
    d.name,
    persistent_version_store_size_gb = 
        CONVERT(decimal(38, 2), persistent_version_store_size_kb / 1024. / 1024.)
FROM sys.dm_tran_persistent_version_store_stats AS t
JOIN sys.databases AS d
  ON t.database_id = d.database_id;

Métricas a serem observadas?

Além do tamanho do armazenamento de versões, você também pode querer observar transações de longa duração usando o Armazenamento de versões. Algo assim pode fornecer detalhes suficientes:

SELECT
    at.transaction_id,
    at.name,
    at.transaction_begin_time,
    at.transaction_type,
    at.transaction_state,
    dt.is_snapshot,
    dt.first_snapshot_sequence_num,
    dt.max_version_chain_traversed,
    dt.average_version_chain_traversed,
    dt.elapsed_time_seconds
FROM sys.dm_tran_active_transactions AS at
OUTER APPLY
(
    SELECT TOP (1)
           dt.*
    FROM sys.dm_tran_active_snapshot_database_transactions AS dt
    WHERE dt.transaction_id = at.transaction_id
    ORDER BY
        dt.elapsed_time_seconds DESC
) AS dt
ORDER BY
    at.transaction_begin_time DESC;

Em geral, você gostaria de procurar transações de longa duração que possam estar impedindo a limpeza do armazenamento de versões.

Registrando os desenvolvedores de aplicativos podem colocar seu próprio código?

Não consigo pensar em nada que possa ser útil.

Reclamações específicas de usuários para as quais devo estar alerta?

Você gostaria de ficar de olho nas reclamações dos usuários sobre resultados incorretos ou entradas duplicadas.

Tentando ser conciso aqui, pode haver áreas do aplicativo que são sensíveis à simultaneidade, onde o bloqueio é necessário para a correção dos resultados que o bloqueio de leitura confirmada fornece.

Eu sugiro ver exemplos nestas postagens de Paul White:

• Modificações de dados sob isolamento de instantâneo confirmado por leitura
• O nível de isolamento SNAPSHOT
• O nível de isolamento de leitura confirmada
• Tabelas de sequência

Em particular, os detalhes de quais garantias de consistência você está obtendo atualmente com o bloqueio de leitura confirmada como o nível de isolamento e como as modificações de dados podem obter resultados estranhos no isolamento de instantâneo confirmado de leitura. Consultas sensíveis a leituras obsoletas podem ter uma dica READCOMMITTEDLOCK aplicada, conforme mostrado no artigo da tabela de sequência.