Partilhar via

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

  • Artigo

Aplica-se a: SQL Server Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure

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

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

Visão geral

Antes, para permitir que os aplicativos consultassem as alterações nos dados de um banco de dados e acessassem as informações relacionadas às alterações, os desenvolvedores de aplicativos precisavam implementar mecanismos personalizados de controle de alterações. Esses mecanismos geralmente envolviam muito trabalho, como uma combinação de gatilhos, colunas de carimbo de data/hora, novas tabelas para armazenar informações de acompanhamento 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 necessidade de uma solução personalizada.

Tipos distintos de aplicativos têm requisitos diferentes quanto à quantidade de informações 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 na tabela de um usuário:

  • Que linhas da tabela de um usuário foram alteradas?

    • Só é necessário o fato de que uma linha foi alterada, e não quantas vezes ela foi alterada ou os valores das alterações intermediárias.

    • Os últimos dados podem ser obtidos diretamente da tabela que está sendo controlada.

  • Uma linha foi alterada?

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

Observação

Se um aplicativo precisar de informações sobre todas as alterações feitas e os valores intermediários dos dados alterados, talvez seja adequado usar o Change Data Capture, em vez do controle de alterações. Para obter mais informações, consulte Sobre a captura de dados de alterações (SQL Server).

Aplicativos de sincronização unidirecional e bidirecional

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

Aplicativos de sincronização unidirecional

É possível criar aplicativos de sincronização unidirecional, como um aplicativo cliente ou de cache de camada intermediária, que usem o controle de alterações. Como mostra a ilustração a seguir, um aplicativo em cache exige 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 atualizado com as alterações feitas nas tabelas do banco de dados. Não há nenhuma alteração para devolver ao Mecanismo de Banco de Dados.

Diagrama mostrando aplicativos de sincronização unidirecional.

Aplicativos de sincronização bidirecional

Também é possível criar aplicativos de sincronização bidirecional que usem o controle de alterações. Neste cenário, os dados em uma instância do Mecanismo de Banco de Dados são sincronizados com um ou mais repositórios de dados. Os dados nesses repositórios podem ser atualizados, e as alterações devem ser sincronizadas novamente com o Mecanismo de Banco de Dados.

Diagrama mostrando aplicativos de sincronização bidirecional.

Um bom exemplo de aplicativo de sincronização bidirecional é um aplicativo ocasionalmente conectado. Nesse tipo de aplicativo, um aplicativo cliente consulta e atualiza um repositório local. Quando houver uma conexão disponível entre um cliente e um servidor, o aplicativo será sincronizado com um servidor, e os fluxos de dados alterados ocorrerão nas duas direções.

Os aplicativos de sincronização bidirecional devem ser capazes de detectar conflitos. Ocorrerá um conflito se os mesmos dados forem alterados em ambos os repositórios de dados em algum momento entre sincronizações. Com a capacidade de detectar conflitos, um aplicativo pode certificar-se de que as alterações não sejam perdidas.

Como o controle de alterações funciona

Para configurar o controle de alterações, você pode usar instruções DDL ou o SQL Server Management Studio. Para obter mais informações, veja Habilitar e desabilitar o controle de alterações. Para controlar alterações, o controle de alterações deve ser habilitado no banco de dados e, então, nas tabelas que você deseja controlar no banco de dados. A definição da tabela não precisa sofrer nenhuma alteração, e nenhum gatilho é criado.

Após a configuração do controle de alterações para uma tabela, qualquer instrução DML que afete as linhas da tabela fará com que as informações do controle de alterações de cada linha modificada sejam registradas. Para consultar as linhas que foram alteradas e obter informações sobre as alterações, você pode usar as funções de controle de alterações.

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

As informações sobre a alteração 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 (inserção, atualização ou exclusão) 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 mude. Por exemplo, se uma declaração de atualização definir uma coluna com o mesmo valor que ela já tem, a coluna ainda será considerada alterada.

Limpeza do controle de alterações

Informações de controle de alterações para todas as tabelas (habilitado para Controle de Alterações) são armazenadas em um rowstore na memória. Dados de controle de alterações associados a cada tabela habilitados para Controle de Alterações são liberados em cada ponto de verificação do rowstore em memória para a respectiva tabela interna no disco. Durante o ponto de verificação, o rowstore em memória também é limpo após as linhas serem movidas para as tabelas em disco.

Cada tabela habilitada para Controle de Alterações tem uma tabela interna em disco que é usada por funções de Controle de Alterações para determinar a versão da alteração e as linhas que foram alteradas desde uma versão específica. Sempre que o thread limpeza automática é habilitado, ele examina todos os banco de dados na instância do SQL Server para identificar os bancos de dados habilitados para controle de alterações. Com base na configuração de período de retenção do banco de dados, é feita a limpeza dos registros expirados de cada tabela em disco interna.

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

Conteúdo relacionado