Captura de dados de alterações e outros recursos

  • Artigo

Aplica-se a:SQL ServerInstância Gerenciada de SQL do Azure

Este artigo descreve como os recursos a seguir interagem com a captura de dados de alterações para o SQL Server e a Instância Gerenciada de SQL do Azure. Para o Banco de Dados SQL do Azure, confira CDA com Banco de Dados SQL do Azure.

controle de alterações

A captura de dados de alteração e o controle de alterações podem ser habilitados no mesmo banco de dados. Nenhuma consideração especial é necessária. Para obter mais informações, confira Trabalhar com controle de alterações.

Espelhamento de banco de dados

Um banco de dados que é habilitado para captura de dados de alteração pode ser espelhado. Para assegurar que a captura e a limpeza ocorram automaticamente após um failover, siga estas etapas:

  1. Certifique-se de que o SQL Server Agent esteja em execução na nova instância do servidor principal.

  2. Crie os trabalhos de captura e de limpeza no novo banco de dados principal (o antigo banco de dados espelho). Para criar os trabalhos, use o procedimento armazenado sp_cdc_add_job .

Para exibir a configuração atual de um trabalho de limpeza ou captura, use o procedimento armazenado sys.sp_cdc_help_jobs na nova instância de servidor principal. Para um determinado banco de dados, o trabalho de captura é chamado de cdc.database_name_capture e o trabalho de limpeza é chamado de cdc.database_name_cleanup, em que database_name é o nome do banco de dados.

Para alterar a configuração de um trabalho, use o procedimento armazenado sys.sp_cdc_change_job .

Para obter informações sobre o espelhamento de banco de dados, consulte Espelhamento de banco de dados (SQL Server).

Replicação transacional

A captura de dados de alteração e a replicação transacional podem coexistir no mesmo banco de dados, mas a população das tabelas de alteração ocorre de modo diferente quando os dois recursos estão habilitados. A captura de dados de alteração e a replicação transacional sempre usam o mesmo procedimento, sp_replcmds, para ler alterações no log de transações. Quando a captura de dados de alterações é habilitada por conta própria, um trabalho do SQL Server Agent chama sp_replcmds. Quando os dois recursos estão habilitados no mesmo banco de dados, o Agente de Leitor de Log chama o sp_replcmds. Esse agente preenche as tabelas de alteração e do banco de dados de distribuição. Para obter mais informações, consulte Replication Log Reader Agent.

Considere um cenário em que a captura de dados de alteração está habilitada no banco de dados AdventureWorks2022 e há duas tabelas habilitadas para captura. Para popular as tabelas de alteração, o trabalho de captura chama sp_replcmds. O banco de dados está habilitado para replicação transacional, e é criada uma publicação. Agora, o Agente de Leitor de Log é criado para o banco de dados, e o trabalho de captura é excluído. O Agente de Leitor de Log continua a examinar o log do último número de sequência de log confirmado na tabela de alteração. Isso assegura a consistência de dados nas tabelas de alteração. Se a replicação transacional estiver desabilitada nesse banco de dados, o Log Reader Agent será removido e o trabalho de captura, recriado.

Observação

Quando o Agente de Leitor de Log for usado para captura de dados e replicação transacional, as alterações replicadas serão gravadas primeiro no banco de dados de distribuição. Em seguida, as alterações capturadas são gravadas nas tabelas de alteração. As duas operações são confirmadas ao mesmo tempo. Se houver uma latência na gravação no banco de dados de distribuição, haverá uma latência correspondente antes de as alterações aparecerem nas tabelas de alteração.

A opção proc exec da replicação transacional não está disponível quando a opção de captura de dados de alterações está habilitada.

Restauração ou anexação de banco de dados

O SQL Server usa a seguinte lógica para determinar se a captura de dados de alterações permanece habilitada depois que um banco de dados é restaurado ou anexado:

  • Se um banco de dados for restaurado para o mesmo servidor com o mesmo nome de banco de dados, a captura de dados de alteração permanecerá habilitada.

  • Se um banco de dados for restaurado para outro servidor, por padrão a captura de dados de alteração será desabilitada, e todos os metadados relacionados serão excluídos.

    Para manter a captura de dados de alterações, use a opção KEEP_CDC ao restaurar o banco de dados. Para obter mais informações sobre essa opção, consulte RESTORE.

  • Se um banco de dados for desanexado e anexado ao mesmo servidor ou a outro servidor, a captura de dados de alteração permanecerá habilitada.

  • Se um banco de dados for anexado ou restaurado com a opção KEEP_CDC em qualquer edição que não seja Standard, Enterprise ou Instância Gerenciada de SQL, a operação será bloqueada porque a captura de dados de alterações requer as edições Standard, Enterprise ou Instância Gerenciada de SQL do SQL Server. A mensagem de erro 934 é exibida:

    SQL Server cannot load database '%.*ls' because change data capture is enabled. The currently installed edition of SQL Server does not support change data capture. Either restore database without KEEP_CDC option, or upgrade the instance to one that supports change data capture.

Você pode usar sys.sp_cdc_disable_db para remover a captura de dados de alterações de um banco de dados restaurado ou anexado.

Depois de restaurar um banco de dados na Instância Gerenciada de SQL do Azure, o CDA permanecerá habilitado, mas você precisará verificar se os trabalhos de verificação e limpeza foram adicionados e estão em execução. Você pode adicionar manualmente os trabalhos executando sys.sp_cdc_add_job.

Bancos de dados independentes

A captura de dados de alterações não é compatível com os bancos de dados independentes.

Grupos de disponibilidade

Quando você usa grupos de disponibilidade Always On, a enumeração de alterações deve ser feita na réplica secundária para reduzir a carga de disco na réplica primária.

Índices columnstore

A Captura de Dados de Alterações não pode ser habilitada em tabelas com um índice columnstore clusterizado. Começando no SQL Server 2016, ela pode ser habilitada em tabelas com um índice columnstore não clusterizado.

Colunas computadas

A CDA não oferece suporte aos valores de colunas computadas, mesmo que a coluna computada seja definida como persistente. As colunas computadas que são incluídas em uma instância de captura sempre têm um valor de NULL. Esse comportamento é intencional, e não um bug.

Linux

Agora a CDA é compatível com o SQL Server 2017 no Linux a partir do CU18 e o SQL Server 2019 no Linux.

Confira também