Alterar a captura de dados (CDC) com o Banco de Dados SQL do Azure

Aplica-se a: do Banco de Dados SQL do Azure

Neste artigo, saiba como a captura de dados de alteração (CDC) é implementada no Banco de Dados SQL do Azure para registrar a atividade em um banco de dados quando tabelas e linhas foram modificadas. Para obter detalhes sobre o recurso CDC, incluindo como ele é implementado no SQL Server e na Instância Gerenciada SQL do Azure, consulte O que é captura de dados de alteração (CDC)?

Visão geral

No Banco de Dados SQL do Azure, um agendador de captura de dados de alteração substitui os trabalhos do SQL Server Agent que capturam e limpam dados de alteração para as tabelas de origem. O agendador executa os processos de captura e limpeza automaticamente no escopo do banco de dados, garantindo confiabilidade e desempenho sem dependências externas. Os usuários mantêm a opção de iniciar manualmente os processos de captura e limpeza, conforme necessário.

Um bom exemplo de um consumidor de dados usado por essa tecnologia é um aplicativo de extração, transformação e carregamento (ETL). Um aplicativo ETL carrega incrementalmente dados de alteração de tabelas de origem do SQL Server para um data warehouse ou data mart. Embora a representação das tabelas de origem no data warehouse deva refletir as alterações nas tabelas de origem, uma tecnologia de ponta a ponta que atualize uma réplica da origem não é apropriada. Em vez disso, você precisa de um fluxo confiável de dados de alteração estruturados para que os consumidores possam aplicá-los a representações de destino diferentes dos dados. A captura de dados de alteração do SQL Server fornece essa tecnologia.

Para saber mais sobre a captura de dados de alteração no Banco de Dados SQL do Azure, consulte este episódio de Dados expostos:

Fluxo de dados

A ilustração a seguir mostra o fluxo de dados principal para a captura de dados de alteração com o Banco de Dados SQL do Azure:

Pré-requisitos

Permissões

A função db_owner é necessária para habilitar a captura de dados de alteração para o Banco de Dados SQL do Azure.

Requisitos de computação do Banco de Dados SQL do Azure

Você pode habilitar o CDC no Banco de Dados SQL do Azure para qualquer camada de serviço dentro do modelo de compra baseado em vCore, para bancos de dados únicos e pools elásticos.

Para bases de dados no modelo de compra de DTU , o CDC é suportado para bases de dados na camada S3 ou superior. As camadas de subnúcleo (Basic, S0, S1, S2) não são suportadas pelo CDC.

Habilitar CDC para o Banco de Dados SQL do Azure

Antes de criar uma instância de captura para tabelas individuais, você deve habilitar o CDC para seu Banco de Dados SQL do Azure.

Para habilitar o CDC, conecte-se ao Banco de Dados SQL do Azure por meio do Azure Data Studio ou do SQL Server Management Studio (SSMS). Abra uma nova janela de consulta e habilite o CDC executando o seguinte T-SQL:

EXEC sys.sp_cdc_enable_db;
GO

Quando a captura de dados de alteração está habilitada para um banco de dados, as tabelas de cdc schema, cdc user, metadados e outros objetos do sistema são criados para o banco de dados. O cdc schema contém as tabelas de metadados de captura de dados de alteração e, após o cdc ser habilitado para as tabelas de origem, as tabelas de alteração individuais funcionam como um repositório para os dados de alteração. O cdc schema também contém funções de sistema associadas usadas para consultar dados de alteração.

Ativar CDC para uma tabela

Depois de habilitar o CDC para seu Banco de Dados SQL do Azure, você pode habilitar o CDC no nível da tabela selecionando uma ou mais tabelas para controlar as alterações de dados. Crie uma instância de captura para tabelas de origem individuais usando o procedimento armazenado sys.sp_cdc_enable_table.

Para habilitar o CDC para uma tabela, execute o seguinte T-SQL:

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL;
GO

Colunas na tabela de origem a serem capturadas

Por padrão, todas as colunas na tabela de origem são identificadas como colunas capturadas. Se apenas um subconjunto de colunas precisar ser rastreado, como por motivos de privacidade ou desempenho, use o parâmetro @captured_column_list para especificar o subconjunto de colunas.

Para habilitar o CDC para uma lista específica de colunas em uma tabela, execute o seguinte T-SQL:

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL,
    @captured_column_list = N'Column1, Column2, Column3';
GO

Uma função para controlar o acesso a uma tabela de alterações

O objetivo da função nomeada é controlar o acesso aos dados de alteração. A função especificada pode ser uma função de servidor fixa existente ou uma função de banco de dados. Se a função especificada ainda não existir, uma função de banco de dados com esse nome será criada automaticamente. Os usuários devem ter a permissão SELECT em todas as colunas capturadas da tabela de origem. Além disso, quando uma função é especificada, os usuários que não são membros da função sysadmin ou db_owner também devem ser membros da função especificada.

Para habilitar o CDC para uma tabela especificando uma função de controle, execute o seguinte T-SQL:

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = N'RoleName'
GO

Se você não quiser usar uma função de regulação, defina explicitamente o parâmetro @role_name como NULL.

Uma função para consultar alterações de rede

Uma instância de captura sempre inclui uma função de valor de tabela para retornar todas as entradas da tabela de mudanças que ocorreram dentro de um intervalo definido. Essa função é nomeada anexando o nome da instância de captura a cdc.fn_cdc_get_all_changes_. Para obter mais informações, consulte cdc.fn_cdc_get_all_changes.

Se o parâmetro @supports_net_changes estiver definido como 1, uma função net changes também será gerada para a instância de captura. Esta função retorna apenas uma alteração para cada linha distinta alterada no intervalo especificado na chamada. Para obter mais informações, consulte cdc.fn_cdc_get_net_changes.

Para dar suporte a consultas de alterações de rede, a tabela de origem deve ter uma chave primária ou um índice exclusivo para identificar linhas exclusivamente. Se um índice exclusivo for usado, o nome do índice deve ser especificado usando o parâmetro @index_name. As colunas definidas na chave primária ou índice exclusivo devem ser incluídas na lista de colunas de origem a serem capturadas.

Para habilitar o CDC para uma tabela com suporte para alterações de rede, execute o seguinte T-SQL:

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL,
    @supports_net_changes = 1
GO

Se a captura de dados de alteração estiver habilitada em uma tabela com uma chave primária existente e o parâmetro @index_name não for usado para identificar um índice exclusivo alternativo, o recurso de captura de dados de alteração usará a chave primária. Alterações subsequentes na chave primária não são permitidas sem primeiro desabilitar a captura de dados de alteração para a tabela. Isso é verdade independentemente de o suporte para consultas de alterações de rede ter sido solicitado quando a captura de dados de alteração foi configurada.

Se não houver uma chave primária em uma tabela no momento em que você habilitá-la para a captura de dados de alteração, a adição subsequente de uma chave primária será ignorada pela captura de dados de alteração. Como a captura de dados de alteração não usa uma chave primária criada depois que a tabela foi habilitada, as colunas de chave e a própria chave podem ser removidas livremente.

Para obter mais informações sobre os argumentos do procedimento armazenado sys.sp_cdc_enable_table, consulte sys.sp_cdc_enable_table.

Desabilitar o CDC para o Banco de Dados SQL do Azure

A desativação do CDC para o Banco de Dados SQL do Azure remove todos os metadados associados à captura de dados de alteração, incluindo o cdc user, o cdc schema, e os processos de captura e limpeza do agendador externo. No entanto, todas as funções de regulação criadas pela captura de dados de alteração não são removidas automaticamente e devem ser excluídas explicitamente.

Não é necessário desativar o CDC para tabelas individuais antes de desabilitar o CDC no nível do banco de dados.

Para desabilitar o CDC no nível do banco de dados, execute o seguinte T-SQL:

EXEC sys.sp_cdc_disable_db;
GO

Gerenciar CDC

No Banco de Dados SQL do Azure, o CDC é um recurso crucial para controlar e gerenciar alterações em suas tabelas de banco de dados. Ao contrário dos ambientes tradicionais do SQL Server, o Banco de Dados SQL do Azure emprega um agendador de captura de dados de alteração para lidar com tarefas CDC em vez de depender de trabalhos do SQL Server Agent. Esse agendador inicia automaticamente processos periódicos de captura e limpeza para tabelas CDC em seu banco de dados, garantindo confiabilidade e desempenho sem dependências externas.

Captura e limpeza CDC automáticas

O trabalho de captura CDC no Banco de Dados SQL do Azure opera perfeitamente, sendo executado a cada 20 segundos para controlar as alterações de forma eficiente. Simultaneamente, o trabalho de limpeza é executado a cada hora, garantindo que suas tabelas CDC permaneçam otimizadas. Os usuários podem ter certeza de que o gerenciamento CDC ocorre automaticamente sem intervenção manual.

Controlo CDC manual

Embora o CDC seja executado automaticamente, os usuários mantêm a flexibilidade de executar operações CDC manuais sob demanda. Os procedimentos sp_cdc_scan e sp_cdc_cleanup_change_tables permitem acionar tarefas de captura e limpeza conforme necessário.

Monitorar CDC

O Banco de Dados SQL do Azure fornece ferramentas valiosas para monitorar as atividades do CDC. Duas visualizações dinâmicas de gerenciamento, sys.dm_cdc_log_scan_sessions e sys.dm_cdc_errors, oferecem informações sobre os processos CDC, garantindo que você tenha visibilidade total das alterações de dados.

Personalização CDC

Embora o Banco de Dados SQL do Azure simplifique o gerenciamento do CDC, existem algumas limitações:

• A frequência dos trabalhos de captura e limpeza do CDC não pode ser personalizada.
• Os valores de pollinginterval e continuous para trabalhos de captura e limpeza não são aplicáveis no Banco de Dados SQL do Azure.
• Remover a entrada do trabalho de captura da tabela cdc.cdc_jobs não interrompe o trabalho de captura em segundo plano.
• Deixar cair a entrada do trabalho de limpeza interrompe o trabalho de limpeza.
• A tabela cdc.cdc_jobs reside no esquema cdc, não msdb.

Apesar dessas limitações, você ainda pode personalizar as seguintes opções:

• Consulte a tabela cdc.cdc_jobs para obter detalhes da configuração atual.
• Ajuste as opções maxtrans e maxscans usando o procedimento armazenado sp_cdc_change_job.
• Gerencie trabalhos empregando sp_cdc_drop_job e sp_cdc_add_job conforme necessário.

Considerações e recomendações de desempenho

Habilitar a captura de dados de alteração para o Banco de Dados SQL do Azure tem um efeito de desempenho comparável à habilitação do CDC para SQL Server ou Instância Gerenciada SQL do Azure. No entanto, vários fatores influenciam o efeito de desempenho ao habilitar o CDC, incluindo:

• O número de tabelas habilitadas para CDC em seu Banco de Dados SQL do Azure.

• Frequência das alterações nas tabelas controladas ou volume de transações. As transações ativas impedem o truncamento de log até que a transação seja confirmada e a análise CDC se actualize, ou a transação seja anulada. Isso pode fazer com que o log de transações fique mais cheio do que o normal e deve ser monitorado para que o log de transações não seja preenchido.

• Verifique se há espaço livre disponível na base de dados de origem, pois os artefatos CDC (por exemplo, tabelas de CT, cdc_jobs, etc.) são armazenados na mesma base de dados.

• Se você tem um único banco de dados ou faz parte de um pool elástico.

• Os bancos de dados em um pool elástico compartilham recursos entre eles (como espaço em disco), portanto, habilitar o CDC em vários bancos de dados corre o risco de atingir o tamanho máximo do tamanho do disco do pool elástico. Monitore recursos como CPU, memória e taxa de transferência de log. Para obter mais informações, consulte Gerenciamento de recursos em pools elásticos densos.

• Ao lidar com bancos de dados em pools elásticos, é crucial considerar a contagem de tabelas habilitadas para CDC e o número de bancos de dados aos quais essas tabelas pertencem. Sugerimos avaliar sua carga de trabalho e tomar as medidas necessárias, como dimensionar o pool elástico. Para obter mais informações, consulte Dimensionar recursos do pool elástico no Banco de Dados SQL do Azure.

Considere as seguintes práticas recomendadas ao usar o CDC com o Banco de Dados SQL do Azure:

• Teste sua carga de trabalho completamente antes de habilitar o CDC em bancos de dados em produção para ajudá-lo a determinar o SLO adequado para sua carga de trabalho. Para obter mais informações sobre as dimensões de computação da Base de Dados SQL do Azure, consulte Camadas de serviço.

• Considere dimensionar o número de vCores, ou fazer a transição para uma camada de banco de dados mais alta, como Hyperscale, para manter o nível de desempenho anterior depois que o CDC tiver sido habilitado em seu Banco de Dados SQL do Azure. Para obter mais informações, consulte o modelo de compra vCore - Azure SQL Database e a camada de serviço Hyperscale .

• Monitore de perto a utilização do espaço. Para obter mais informações, consulte Gerenciar espaço de arquivo para bancos de dados no Banco de Dados SQL do Azure.

• Monitorize a taxa de geração de logs; para obter mais informações, consulte Consumo de recursos por cargas de trabalho de usuário e processos internos.

• Os processos de verificação e limpeza CDC fazem parte da carga de trabalho regular do banco de dados (também consomem recursos). Dependendo do volume de transações, a degradação do desempenho pode ser substancial devido aos processos de verificação e limpeza não acompanharem a carga de trabalho, pois linhas inteiras são adicionadas às tabelas de alteração e, para operações de atualização, a pré-imagem também é incluída. Sugerimos avaliar a sua carga de trabalho e tomar as medidas necessárias de acordo com as recomendações anteriores. Para obter mais informações, consulte a seção de gerenciamento CDC neste artigo.

• Para evitar um aumento na latência, certifique-se de que o número de bancos de dados habilitados para CDC não ultrapasse a contagem de vCores alocados para um pool elástico. Para saber mais, consulte Gerenciamento de recursos em pools elásticos densos.

• Com base na sua carga de trabalho e no seu nível de desempenho, considere alterar o período de retenção CDC para menos do que o padrão de três dias para garantir que o processo de limpeza possa acompanhar as alterações na tabela de mudanças. Manter um período de retenção menor enquanto monitora o tamanho do banco de dados é uma boa prática.

• Nenhum contrato de nível de serviço (SLA) é fornecido quando as alterações são preenchidas nas tabelas de alterações. A latência do subsegundo também não é suportada.

Problemas conhecidos e limitações

Truncamento agressivo de log

Quando você habilita a captura de dados de alteração (CDC) no Banco de Dados SQL do Azure, o recurso de truncamento de log agressivo da Recuperação Acelerada de Banco de Dados (ADR) é desabilitado. Isso ocorre porque a verificação CDC acessa o log de transações do banco de dados. As transações ativas impedem o truncamento do log de transações até que a transação seja confirmada e a verificação CDC seja alcançada ou a transação seja abortada.

Ao habilitar o CDC, recomendamos usar a opção de índice retomável ao criar ou reconstruir um índice. Os índices retomáveis não mantêm uma transação de longa duração aberta e permitem o truncamento de log durante a operação para um melhor gerenciamento do espaço de log. Para obter mais informações, consulte Diretrizes para operações de índice online - Considerações sobre índice retomável.

Camada de serviço do Banco de Dados SQL do Azure

Embora o CDC seja suportado para bancos de dados e pools elásticos em qualquer camada de serviço dentro do modelo de aquisição baseado em vCore, bancos de dados inferiores ao escalão S3 (como Basic, S0, S1, S2) não são suportados no modelo de aquisição de DTU .

Limites de log do Banco de Dados SQL do Azure

A recuperação acelerada de banco de dados e o CDC são compatíveis. No entanto, o comportamento agressivo de truncamento de log do ADR é desativado quando o CDC está ativado. Isso deve-se ao facto de a varredura CDC aceder e interagir ativamente com o log de transações da base de dados, o que impede o comportamento agressivo de truncamento do log do ADR.

Ao habilitar o CDC, você pode observar uma maior utilização do log de transações. Talvez seja necessário dimensionar para uma camada de serviço ou tamanho de computação mais alto para garantir que espaço suficiente no log de transações esteja disponível para as necessidades de todas as suas cargas de trabalho.

As instruções DDL online não são suportadas

de instruções DDL online não são suportadas quando a captura de dados de alteração é habilitada em um banco de dados.

Personalização de captura e limpeza

Não é possível configurar a frequência da captura e dos processos de limpeza para CDC nos Bancos de Dados SQL do Azure. O agendador executa a captura e a limpeza automaticamente.

Falha no SQL Database do Azure

Em cenários de failover local ou GeoDR, se o banco de dados tiver o CDC habilitado, o processo de captura e limpeza de alterações de dados ocorrerá automaticamente no novo banco de dados primário após o failover.

Microsoft Entra ID

Se você criar um banco de dados no Banco de Dados SQL do Azure como um usuário do Microsoft Entra e habilitar o CDC nele, um usuário SQL (por exemplo, até mesmo um na função sysadmin) não poderá desabilitar/fazer alterações nos artefatos CDC. No entanto, outro usuário do Microsoft Entra é capaz de ativar/desabilitar o CDC no mesmo banco de dados.

Da mesma forma, se você criar um banco de dados como um usuário SQL, habilitar/desabilitar a captura de dados de alteração como um usuário do Microsoft Entra não funcionará.

A habilitação do CDC falhará se você criar um banco de dados no Banco de Dados SQL do Azure como um usuário do Microsoft Entra, não habilitar o CDC e tentar habilitar o CDC depois de restaurar o banco de dados.

Para resolver esse problema, conecte-se ao banco de dados com sua conta de administrador do Microsoft Entra e execute o seguinte T-SQL:

ALTER AUTHORIZATION ON DATABASE::[<restored_db_name>] TO [<azuread_admin_login_name>];

EXEC sys.sp_cdc_enable_db;

Restauração em ponto no tempo (PITR)

Se você habilitou o CDC no Banco de Dados SQL do Azure como um usuário SQL, o PITR (point-in-time-restore retém o CDC) no banco de dados restaurado, a menos que ele seja restaurado para um SLO subcore. Se for restaurado para um SLO subcore, os artefatos CDC não estarão disponíveis.

Se você habilitar o CDC em seu banco de dados como um usuário do Microsoft Entra, não será possível restaurar point-in-time (PITR) para um SLO subcore. Restaure o banco de dados para o mesmo SLO ou superior que a origem e, em seguida, desative o CDC, se necessário.

Solução de problemas

Esta seção fornece orientação e etapas de solução de problemas associadas ao CDC no Banco de Dados SQL do Azure. Erros relacionados ao CDC podem obstruir o bom funcionamento do processo de captura e levar à expansão do log de transações do banco de dados.

Para examinar esses erros, pode consultar a visualização de gestão dinâmica sys.dm_cdc_errors. Se a exibição de gerenciamento dinâmico sys.dm_cdc_errors retornar erros, consulte a seção a seguir para entender as etapas de mitigação.

Estas são as diferentes categorias de solução de problemas incluídas nesta seção:

Categoria	Descrição
Metadados modificados	Inclui informações sobre como mitigar problemas relacionados ao CDC quando a tabela rastreada foi modificada ou descartada.
Gerenciamento de espaço de banco de dados	Inclui informações sobre como mitigar problemas quando o espaço do banco de dados tiver sido esgotado.
limitação do CDC	Inclui informações sobre como mitigar problemas causados por limitações do CDC.

Metadados modificados

Erro 200/208 - Nome do objeto inválido

• Causa: O erro poderá ocorrer quando os metadados CDC forem eliminados. Para que o CDC funcione corretamente, você não deve modificar manualmente nenhum metadados CDC, como o CDC schema, alterar tabelas, procedimentos armazenados do sistema CDC, permissões de cdc user padrão (sys.database_principals) ou renomear o cdc user.

• Recomendação: Para resolver esse problema, você precisa desativar e reativar o CDC para seu banco de dados. Ao habilitar a captura de dados de alteração para um banco de dados, ele cria o esquema cdc, o usuário cdc, tabelas de metadados e outros objetos do sistema para o banco de dados. Você precisará reativar manualmente CDC para tabelas individuais depois que o CDC estiver habilitado para o banco de dados.

Erro 1202 - A entidade de banco de dados não existe ou o usuário não é membro

• Causa: O erro pode ocorrer quando o utilizador CDC tiver sido removido. Para que o CDC funcione corretamente, você não deve modificar manualmente nenhum metadados CDC, como CDC schema, alterar tabelas, procedimentos armazenados do sistema CDC, permissões de cdc user padrão (sys.database_principals) ou renomear cdc user.

• Recomendação: Verifique se o usuário cdc existe em seu banco de dados e também tem a função db_owner atribuída. Para criar o usuário cdc, consulte o exemplo Criar usuário cdc e atribuir função.

Erro 15517 - Não é possível executar como o principal de banco de dados porque o principal não existe

• Causa: Este tipo de entidade não pode ser simulado ou não tens permissão. O erro pode ocorrer quando os metadados CDC foram descartados ou não fazem mais parte da função db_owner. Para que o CDC funcione corretamente, você não deve modificar manualmente nenhum metadados CDC, como CDC schema, alterar tabelas, procedimentos armazenados do sistema CDC, permissões de cdc user padrão (sys.database_principals) ou renomear o cdc user.

• Recomendação: Verifique se o usuário cdc existe em seu banco de dados e também tem a função db_owner atribuída. Para criar o usuário cdc, consulte o exemplo Criar usuário cdc e atribuir função.

Erro 18807 - Não é possível encontrar um ID de objeto para a tabela do sistema de replicação

• Causa: Este erro acontece quando o mecanismo de banco de dados do SQL Server não consegue localizar ou acessar a tabela do sistema de replicação '%s.' A tabela pode estar ausente ou inacessível. Para que o CDC funcione corretamente, não modifique manualmente quaisquer metadados CDC, como o CDC schema, tabelas de alterações, procedimentos armazenados do sistema CDC, as permissões padrão cdc user (sys.database_principals) ou renomeie o cdc user.

• Recomendação: Verifique se a tabela do sistema existe e está acessível consultando a tabela diretamente. Consulte o sys.objects catálogo do sistema, defina a cláusula de predicado com is_ms_shipped=1 e schema_name=cdc para listar todos os objetos relacionados ao CDC. Se a consulta não retornar nenhum objeto, você deverá desabilitar e reativar o CDC para seu banco de dados. Habilitar a captura de dados de alteração para um banco de dados cria o cdc schema, cdc user, tabelas de metadados e outros objetos do sistema para o banco de dados. Você precisará reativar manualmente CDC para tabelas individuais depois que o CDC estiver habilitado para o banco de dados.

Erro 21050 - Somente membros da função de servidor fixa sysadmin ou db_owner podem executar esta operação

• Causa: O usuário cdc foi removido da função de banco de dados db_owner ou da função de servidor sysadmin.

• Recomendação: Certifique-se de que o usuário cdc tenha a função db_owner atribuída. Para criar o usuário cdc, consulte o exemplo Criar usuário cdc e atribuir função.

Gerenciamento de espaço de banco de dados

Erro 1105 - Não foi possível alocar espaço para o objeto no banco de dados porque o grupo de arquivos está cheio

• causa: Este erro ocorre quando o grupo de arquivos primário de um banco de dados fica sem espaço e o Banco de dados SQL não consegue alocar mais espaço para um objeto (como uma tabela ou índice) dentro desse grupo de arquivos.

• Recomendação: Para resolver esse problema, exclua todos os dados desnecessários em seu banco de dados para liberar espaço. Identifique tabelas, índices ou outros objetos não utilizados no grupo de arquivos que podem ser removidos com segurança. Monitore a utilização do espaço de perto, para obter mais informações, consulte Gerenciar espaço de arquivo para bancos de dados no Banco de Dados SQL do Azure.

  Caso a eliminação de dados/objetos desnecessários não seja uma opção, considere o dimensionamento para uma camada de banco de dados mais alta.

Erro 1132 - O pool elástico atingiu seu limite de armazenamento

• Causa: Este erro ocorre quando o uso de armazenamento no pool elástico excedeu o limite alocado.

• Recomendação: Para resolver esse problema, implemente estratégias de arquivamento e limpeza de dados para manter apenas os dados necessários nos bancos de dados que fazem parte do pool elástico. Monitore de perto a utilização do espaço. Para obter mais informações, consulte Gerenciar espaço de arquivo para bancos de dados no Banco de Dados SQL do Azure.

  Caso arquivar dados ou descartar dados/objetos desnecessários não seja uma opção, considere dimensionar para uma camada de banco de dados mais alta.

Limitação do CDC

Erro 2628 - string ou dados binários seriam truncados na tabela

• Causa: Alterar o tamanho das colunas de uma tabela habilitada para CDC usando instruções DDL pode causar problemas com o processo de captura CDC subsequente. O sys.dm_cdc_errors Dynamic Management View (DMV) é útil para verificar qualquer CDC em busca de problemas relatados, como os erros número 2628 e 8115.

• Recomendação: Antes de fazer qualquer alteração no tamanho da coluna, você deve avaliar se a alteração é compatível com os dados existentes nas tabelas de alteração CDC. Para resolver esse problema, você precisa desabilitar e reativar o CDC para seu banco de dados. Para obter mais informações sobre como ativar o CDC para um banco de dados ou uma tabela, consulte as seções Ativar CDC para Azure SQL Database e Ativar CDC para uma tabela neste artigo.

Erro 22830 - A função interna 'SUSER_SNAME' no contexto de representação não é suportada nesta versão do SQL Server

• Cause: Este erro ocorre ao ativar o CDC se existir um disparador de utilizador na base de dados que faz uma chamada para SUSER_SNAME() em create_table. Você pode listar gatilhos com o seguinte script Transact-SQL. Este comando fornece as informações do gatilho do objeto e do object_idcorrespondente.

  SELECT name,
      object_id
  FROM sys.triggers
  WHERE parent_class_desc = 'DATABASE'
      AND is_disabled = 0;
  

  Depois de obter as definições de gatilho, você pode procurar chamadas que estão sendo feitas para SYSTEM_USER com o seguinte script:

  SELECT OBJECT_DEFINITION(object_id) AS trigger_definition;
  

• Recomendação: Para resolver esse problema, siga estas etapas para cada gatilho de usuário obtido do script anterior.

  • Desative o gatilho
  • Ativar CDC
  • Reativar o gatilho

Para obter mais informações, consulte DESATIVAR TRIGGER.

Erro 913 - O trabalho de captura CDC falha ao processar alterações para uma tabela com o tipo de dados CLR do sistema

• Causa: Este erro ocorre ao ativar o CDC numa tabela com o tipo de dados CLR do sistema, realizar alterações DML e, em seguida, executar alterações DDL na mesma tabela, enquanto o trabalho de captura do CDC está a processar alterações relacionadas com outras tabelas.

• Recomendação: As etapas recomendadas são desativar o DML na tabela, executar um trabalho de captura para processar alterações, executar DDL para a tabela, executar um trabalho de captura para processar alterações DDL e, em seguida, reativar o processamento DML. Para obter mais informações, consulte tarefa de captura de CDC falha ao processar alterações numa tabela com o tipo de dados CLR do sistema (geometria, geografia ou hierarchyid).

Criar usuário e atribuir função

Se o cdc user foi removido, você pode adicionar manualmente o usuário de volta.

Use o seguinte script T-SQL para criar um usuário (cdc) e atribuir a função adequada (db_owner).

IF NOT EXISTS (
    SELECT *
    FROM sys.database_principals
    WHERE NAME = 'cdc'
)
BEGIN
    CREATE USER [cdc] WITHOUT LOGIN
    WITH DEFAULT_SCHEMA = [cdc];
END

EXEC sp_addrolemember 'db_owner', 'cdc';

Verificar e adicionar associação de função

Para verificar se cdc usuário pertence à função sysadmin ou db_owner, execute a seguinte consulta T-SQL:

EXECUTE AS USER = 'cdc';

SELECT is_srvrolemember('sysadmin'), is_member('db_owner');

Se o usuário cdc não pertencer a nenhuma das funções, execute a seguinte consulta T-SQL para adicionar db_owner função ao usuário cdc.

EXEC sp_addrolemember 'db_owner' , 'cdc';

Conteúdo relacionado

• Trabalhar com Dados de Mudança
• Controlar alterações de dados (SQL Server)
• Administrar e monitorizar a captura de dados de alterações
• Tabelas temporais