Sobre o controle de alterações (SQL Server)

Aplica-se a:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceBase de dados SQL no Microsoft Fabric

Este artigo descreve o recurso de controle de alterações para o SQL Server, que é uma solução leve que fornece um mecanismo eficiente de controle de alterações para aplicativos.

Para começar, consulte Configurar o controle de alterações.

Visão geral

Anteriormente, para permitir que os aplicativos consultassem alterações em dados em um banco de dados e acessassem informações relacionadas às alterações, os desenvolvedores de aplicativos precisavam implementar mecanismos personalizados de controle de alterações. Esses mecanismos normalmente envolviam muito trabalho, como uma combinação de gatilhos, colunas de carimbo de data/hora , novas tabelas para armazenar informações de monitorização e processos de limpeza personalizados. O recurso de controle de alterações do SQL Server simplifica esse processo, facilitando a identificação de informações relacionadas a alterações sem a necessidade de uma solução personalizada.

Diferentes tipos de aplicativos têm requisitos diferentes para a quantidade de informações de que precisam sobre as alterações. Os aplicativos podem usar o controle de alterações para responder às seguintes perguntas sobre as alterações feitas em uma tabela de usuário:

• Quais linhas foram alteradas para uma tabela de usuário?

  • Apenas o fato de uma linha ter sido alterada é necessário, não quantas vezes a linha foi alterada ou os valores de quaisquer alterações intermediárias.

  • Os dados mais recentes podem ser obtidos diretamente da tabela que está sendo rastreada.

• Alterou-se uma linha?

  • O fato de uma linha ter sido alterada e as informações sobre a alteração devem estar disponíveis e registradas no momento em que a alteração foi feita na mesma transação.

Alterações do SQL Server 2025

O controle de alterações tem um processo de limpeza automatizado que elimina os metadados obsoletos de controle de alterações das tabelas do sistema. No SQL Server 2022 (16.x) e versões anteriores, o processo de limpeza automática usa uma abordagem de limpeza profunda.

Nessa abordagem, a thread de limpeza automática é ativada a cada 30 minutos, busca todos os bancos de dados e tabelas com controle de alterações, encontra um ponto seguro para a limpeza com base no período de retenção configurado e passa por todas as tabelas para eliminar dados das tabelas auxiliares correspondentes.

No SQL Server 2025 (17.x) e versões posteriores, o processo de limpeza automática do rastreio de alterações introduz uma nova abordagem adaptativa de limpeza superficial para grandes tabelas laterais. Esta nova abordagem elimina os dados abaixo de um ponto de limpeza seguro. Este ponto é encontrado com base na profundidade de limpeza configurada e no período de retenção. Essa abordagem é executada em etapas incrementais até que todos os dados elegíveis sejam removidos.

No SQL Server 2025 (17.x), a limpeza superficial adaptativa está ativada por padrão.

Para desativar a limpeza superficial adaptável, habilite o sinalizador de rastreamento 8273 globalmente:

DBCC TRACEON (8273, -1);

Aplicativos de sincronização de One-Way e Two-Way

Os aplicativos que precisam sincronizar dados com uma instância do Mecanismo de Banco de Dados do SQL Server devem ser capazes de consultar alterações. O controle de alterações pode ser usado como base para aplicativos de sincronização unidirecionais e bidirecionais.

Aplicativos de sincronização One-Way

Aplicativos de sincronização unidirecional, como um cliente ou um aplicativo de cache de camada intermediária, podem ser criados usando o controle de alterações. Como mostrado na ilustração a seguir, um aplicativo de cache requer que os dados sejam armazenados no Mecanismo de Banco de Dados e armazenados em cache em outros armazenamentos de dados. O aplicativo deve ser capaz de manter o cache up-toatualizado com quaisquer alterações que tenham sido feitas nas tabelas do banco de dados. Não há alterações para passar de volta para o Mecanismo de Banco de Dados.

Aplicativos de sincronização Two-Way

Também podem ser criados aplicativos de sincronização bidirecional que usam o controle de alterações. Nesse cenário, os dados em uma instância do Mecanismo de Banco de Dados são sincronizados com um ou mais armazenamentos de dados. Os dados nesses armazenamentos podem ser atualizados e as alterações devem ser sincronizadas de volta ao Mecanismo de Banco de Dados.

Um bom exemplo de aplicativo de sincronização bidirecional é um aplicativo conectado ocasionalmente. Nesse tipo de aplicativo, um aplicativo cliente consulta e atualiza um repositório local. Quando uma conexão está disponível entre um cliente e um servidor, a aplicação sincroniza com um servidor e os dados alterados fluem em ambas as direções.

Os aplicativos de sincronização bidirecional devem ser capazes de detetar conflitos. Um conflito ocorreria se os mesmos dados fossem alterados em ambos os armazenamentos de dados no tempo entre as sincronizações. Com a capacidade de detetar conflitos, um aplicativo pode garantir que as alterações não sejam perdidas.

Como funciona o controle de alterações

Para configurar o controle de alterações, você pode usar instruções DDL ou o SQL Server Management Studio. Para obter mais informações, consulte Habilitar e desabilitar o controle de alterações. Para controlar as alterações, o controle de alterações deve primeiro ser habilitado para o banco de dados e, em seguida, habilitado para as tabelas que você deseja controlar dentro desse banco de dados. A definição da tabela não precisa ser alterada de forma alguma, e nenhum gatilho é criado.

Depois que o controle de alterações for configurado para uma tabela, qualquer instrução DML que afete as linhas na tabela fará com que as informações de controle de alterações para cada linha modificada sejam registradas. Para consultar as linhas que foram alteradas e obter informações sobre as alterações, você pode usar funções de controle de alterações.

Os valores da coluna de chave primária são as únicas informações da tabela controlada que são registradas com as informações de alteração. Esses valores identificam as linhas que foram alteradas. Para obter os dados mais recentes para essas linhas, um aplicativo pode usar os valores de coluna de chave primária para unir a tabela de origem com a tabela controlada.

Informações sobre a alteração que foi feita em cada linha também podem ser obtidas usando o controle de alterações. Por exemplo, o tipo de operação DML que causou a alteração (inserir, atualizar ou excluir) ou as colunas que foram alteradas como parte de uma operação de atualização.

Todas as operações DML são rastreadas, mesmo que o valor de uma coluna não seja alterado. Por exemplo, se uma instrução update definir uma coluna com o mesmo valor que ela já tem, a coluna ainda será considerada alterada.

Limpeza de Rastreio de Alterações

As informações de controle de alterações de todas as tabelas (habilitadas para o Controle de Alterações) são armazenadas em um armazenamento de linhas na memória. Os dados de rastreamento de alterações associados a cada tabela ativada para o Rastreamento de Alterações são descarregados em cada ponto de verificação do armazenamento de linhas na memória para a tabela interna correspondente no disco. Durante o ponto de verificação, o rowstore em memória também é purgado depois de as linhas serem movidas para as tabelas no disco.

Cada tabela habilitada para o Controle de Alterações tem uma tabela interna no disco que é usada pelas funções de Controle de Alterações para determinar a versão de alteração e as linhas que foram alteradas desde uma versão específica. Sempre que a thread de limpeza automática é ativada, verifica todas as bases de dados de utilizador na instância do SQL Server para identificar as bases de dados habilitadas para rastreamento de alterações. Com base na configuração do período de retenção do banco de dados, cada tabela interna no disco é limpa de seus registros expirados.

Um procedimento armazenado foi adicionado nos Service Packs do SQL Server 2014 (12.x) e do SQL Server 2016 (13.x) para executar a limpeza manual das tabelas internas do Controle de Alterações. Mais informações sobre o procedimento armazenado estão disponíveis em KB173157.

Conteúdo relacionado

• Ativar e desativar o controlo de alterações
• Trabalhar com controlo de alterações
• Gerir o controlo de alterações
• Solucionar problemas de limpeza automática de acompanhamento de alterações
• Controlar alterações de dados
• Procedimentos armazenados de Rastreamento de Alterações
• Tabelas de rastreamento de alterações