Estou usando o Microsoft SQL Server 2016 (SP2-GDR) (KB4505220) - 13.0.5101.9 (X64) 15 de junho de 2019 23:15:58 Copyright (c) Microsoft Corporation Standard Edition (64 bits) no Windows Server 2012 R2 Standard 6.3 (Build 9600: )
Tenho vários bancos de dados com CHANGE_TRACKING habilitado em tabelas de alta inserção/atualização. Meu período de retenção é de 2 DIAS, com a limpeza automática habilitada. A compatibilidade do banco de dados está definida como 130 (SQL 2016)
Algumas das tabelas rastreadas são enormes e podem ter milhares de inserções/atualizações todos os dias. Este é o conteúdo das tabelas change_tracking.
Aqui está um exemplo de consulta que fazemos para obter as alterações.
SELECT Columns
FROM CHANGETABLE(CHANGES MyTable, @TrackingKey) AS CT
INNER JOIN MyTable b ON b.Key=CT.Key
WHERE b.Status = 1
Tenho visto de tempos em tempos que as consultas para obter as últimas alterações em algumas das tabelas levam muito tempo para serem concluídas e geram muita CPU. Para ajudar com isso, configurei uma estatística de atualização diária nas tabelas de controle de alterações que são executadas todas as noites. E isso ajuda muito, mas às vezes, em dias de alta atividade do usuário, tenho que executar essa atualização de estatísticas mesmo durante o dia. Quando executo as estatísticas de atualização nessa tabela, a situação volta ao normal e as consultas para obter as alterações mais recentes funcionam bem por algum tempo.
Usamos o controle de alterações para algumas partes vitais de nossos aplicativos, por isso tem que funcionar.
Existe alguma opção, sinalizador de rastreamento que eu possa ativar para ajudar nas estatísticas de rastreamento de alterações? Alguém tem experiência com rastreamento de alterações em bancos de dados de alta atividade pode me dar alguns conselhos?
Então, finalmente decidi fazer um trabalho para verificar se a tabela de controle de alterações mudou mais de 20 mil linhas desde a última atualização de estatística, então o trabalho atualizará as estatísticas na tabela de controle de alterações.
Vou colocar a consulta aqui se puder ajudar alguém. Essa consulta fornece todas as estatísticas para tabelas de controle de alterações em que a tabela foi alterada mais de 20 mil vezes desde a última atualização das estatísticas. Ele fornece uma "Atualização de Estatísticas" com o object_name para atualizar. Você só precisa executar os resultados da consulta em seu banco de dados. Vou ajustá-lo para minha carga de trabalho e ver se 20k é o melhor número.
SELECT
-- st.object_id AS [Table ID]
--, OBJECT_NAME(st.object_id) AS [Table Name]
--, st.name AS [Index Name]
--, STATS_DATE(st.object_id, st.stats_id) AS [LastUpdated]
--, modification_counter AS [Rows Modified]
'UPDATE STATISTICS sys.[' + OBJECT_NAME(st.object_id) + ']' as QueryToRun
FROM sys.stats st
CROSS APPLY sys.dm_db_stats_properties(st.object_id, st.stats_id) AS sp
WHERE OBJECT_NAME(st.object_id) like 'change_t%'
AND OBJECT_NAME(st.object_id) in (SELECT 'change_tracking_' + convert(nvarchar(50),st.object_id) FROM sys.change_tracking_tables ctt inner join sys.tables st ON st.object_id = ctt.object_id inner join sys.schemas ss ON ss.schema_id = st.schema_id)
AND modification_counter > 20000
Como você está no SQL Server 2016 com modo de compatibilidade de banco de dados, o comportamento do TF 2371 é o comportamento padrão .
Você deve habilitar
auto update async
a opção de banco de dados para que quando o sql server atualizar as estatísticas, isso não afete sua carga de trabalho. Alterar esta opção db é uma operação online.O que você pode fazer é aproveitar
sys.dm_db_stats_properties
- o novo DMV para decidir se você deve atualizar manualmente as estatísticas de uma tabela. Você pode ter um trabalho de agente sql configurado para verificar e atualizar estatísticas a cada x min ou hora para determinadas tabelas de chaves.Você pode olhar para isso . Kendra fez um bom artigo sobre o desempenho do rastreamento de alterações, e isso também nos ajudou.