CDC (captura de dados de alterações) com o Banco de Dados SQL do Azure

Aplica-se a:Banco de Dados SQL do Azure

• Banco de Dados SQL do Azure
• Instância Gerenciada de SQL do Azure
• SQL Server

Neste artigo, saiba como a CDA (captura de dados de alterações) é implantada 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 de SQL do Azure, consulte O que é CDC (captura de dados de alteração)?

Visão geral

No Banco de Dados SQL do Azure, um agendador da captura de dados de alterações substitui os trabalhos do SQL Server Agent que capturam e limpam dados de alterações para as tabelas de origem. O agendador executa os processos de captura e limpeza automaticamente no escopo do banco de dados, garantindo a confiabilidade e o 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 esta tecnologia é um aplicativo ETL (extração, transformação e carregamento). Um aplicativo de ETL carrega incrementalmente dados de mudança das 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 atualiza uma réplica da origem não é adequada. Em vez disso, você precisa de um fluxo confiável de dados de mudanças, estruturado de modo que os consumidores possam aplicá-lo a diferentes representações de destino dos dados. A captura de dados de alterações do SQL Server fornece essa tecnologia.

Para saber mais sobre a captura de dados de alterações no Banco de Dados SQL do Azure, você também pode consultar este episódio do Data Exposed:

Fluxo de dados

A ilustração a seguir mostra o principal fluxo de dados da captura de dados de alterações 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ções 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 em qualquer camada de serviço do modelo de compra baseado em vCore, tanto para bancos de dados individuais quanto para pools elásticos.

Para bancos de dados no modelo de compra DTU, há suporte para CDC em bancos de dados na camada S3 ou superior. Não há suporte aos níveis Subcore (Basic, S0, S1, S2) para CDC.

Habilitar a CDA para o Banco de Dados SQL do Azure

Antes de criar uma instância de captura para tabelas individuais, habilite a CDA para seu Banco de Dados SQL do Azure.

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

EXEC sys.sp_cdc_enable_db;
GO

Observação

Para determinar se um banco de dados já está habilitado, consulte a coluna is_cdc_enabled na exibição do catálogo sys.databases.

Quando a captura de dados de alterações está habilitada para um banco de dados, cdc schema, cdc user, tabelas de metadados e outros objetos de 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 a habilitação do cdc para as tabelas de origem, as tabelas de alteração individuais servem como repositório de dados de alteração. O cdc schema também contém funções de sistema associadas usadas para consultar dados de alteração.

Importante

A captura de dados de alterações requer o uso exclusivo de cdc schema e cdc user. Se já existir em um banco de dados um esquema ou usuário do banco de dados chamado cdc, você não poderá habilitar o cdc para o banco de dados até que o esquema e/ou o usuário sejam excluídos ou renomeados.

Habilitar o CDC para uma tabela

Depois de habilitar a CDA para seu Banco de Dados SQL do Azure, você poderá habilitar a CDA 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

Dica

O exemplo anterior não usa um @role_name explícito configurando o parâmetro como NULL, mas você pode usar uma função de limitação para limitar o acesso aos dados de alterações.

Colunas da tabela de origem a serem extraídas

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, por exemplo, 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

Dica

Observe que o exemplo anterior não usa um @role_name explícito e configurando o parâmetro como NULL, mas você pode usar uma função de limitação para limitar o acesso aos dados de alterações.

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

O propósito 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 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 não quiser usar uma função de restrição, defina explicitamente o parâmetro @role_name como NULL.

Uma função para consultar alterações líquidas

Uma instância de captura sempre inclui uma função com valor de tabela para retornar todas as entradas de tabela de alterações que ocorreram dentro de um intervalo definido. Essa função é denominada acrescentando o nome da instância de captura para 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 for definido como 1, uma função de alterações líquidas também será gerada para a instância de captura. Essa 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 às consultas de alterações líquidas, a tabela de origem deve ter uma chave primária ou um índice exclusivo para identificar exclusivamente as linhas. Se um índice exclusivo for usado, o nome do índice deverá ser especificado com o uso do parâmetro @index_name . As colunas definidas na chave primária ou índice exclusivo deverão ser incluídas na lista de colunas de origem a serem capturadas.

Para habilitar o CDC para uma tabela com suporte para alterações líquidas, 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ções for habilitada em uma tabela com a 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ções usará a chave primária. Alterações subsequentes à chave primária não são permitidas sem primeiro desabilitar a captura de dados de alterações para a tabela. Isso é verdadeiro quer o suporte para consultas de alterações globais tenha sido solicitado ou não durante a configuração do Change Data Capture.

Se não houver nenhuma chave primária em uma tabela no momento em que você a habilitar 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ções não usará uma chave primária criada após a habilitação da tabela, a chave e as colunas de chave poderão ser removidas sem restrições.

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

Dica

Para determinar se uma tabela de origem foi habilitada para captura de dados de alterações, examine a coluna is_tracked_by_cdc na exibição de catálogo sys.tables.

Desabilitar CDC para Banco de Dados SQL do Azure

Desabilitar o CDC no seu Banco de Dados SQL do Azure remove todos os metadados associados à captura de dados de alterações, incluindo o cdc user, o cdc schema e os processos externos de captura e limpeza do agendador. No entanto, quaisquer funções de controle criadas pela captura de dados de alterações não são removidas automaticamente e devem ser excluídas explicitamente.

Observação

Para determinar se um banco de dados tem o CDC habilitado, consulte a coluna is_cdc_enabled no modo de exibição de catálogo .

Não é necessário desabilitar o CDC em tabelas individuais antes de desabilitar o CDC no nível de 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

Dica

Depois de desabilitar a CDA no nível do banco de dados, você precisará habilitar a CDA para tabelas individuais novamente se quiser usar o recurso CDA mais uma vez.

Gerenciar CDC

No Banco de Dados SQL do Azure, a CDA é 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 de CDA, em vez de depender de trabalhos do SQL Server Agent. Esse agendador inicia automaticamente processos periódicos de captura e limpeza de tabelas CDA em seu banco de dados, garantindo confiabilidade e desempenho sem dependências externas.

Captura e limpeza automáticas de CDC

A tarefa de captura do CDC no Banco de Dados SQL do Azure opera sem problemas, sendo executada a cada 20 segundos para rastrear as alterações com eficiência. Ao mesmo tempo, a tarefa de limpeza é executada de hora em hora, garantindo que suas tabelas de CDC permaneçam otimizadas. Os usuários podem ter certeza de que o gerenciamento da CDA ocorre automaticamente sem intervenção manual.

Importante

Se um banco de dados sem servidor tiver a CDA habilitada e estiver em um estado em pausa, a CDA não será executada. A varredura do CDC não afetará o recurso de pausa automática.

Controle manual de CDC

Enquanto o CDC é executado automaticamente, os usuários mantêm a flexibilidade de realizar operações manuais de CDC sob demanda. Os procedimentos sp_cdc_scan e sp_cdc_cleanup_change_tables permitem que você dispare tarefas de captura e limpeza conforme necessário.

Monitorar a CDA

O Banco de Dados SQL do Azure fornece ferramentas valiosas para monitorar atividades da CDA. Duas exibições de gerenciamento dinâmico, sys.dm_cdc_log_scan_sessions e sys.dm_cdc_errors, oferecem insights sobre os processos da CDA, garantindo que você tenha visibilidade total sobre suas alterações de dados.

Personalização da CDC

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

• A frequência das tarefas de captura e limpeza do CDC não pode ser personalizada.
• Os valores pollinginterval e continuous para trabalhos de captura e limpeza não são aplicáveis ao 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.
• Excluir a entrada da tarefa de limpeza interrompe a tarefa de limpeza.
• A tabela cdc.cdc_jobs reside no esquema cdc, não em msdb.

Apesar dessas limitações, ainda é possível 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 o necessário.

Considerações e recomendações de desempenho

Habilitar a captura de dados alterados no Banco de Dados SQL do Azure causa um impacto no desempenho comparável ao de habilitar o CDC para o SQL Server ou para a Instância Gerenciada de SQL do Azure. Porém, vários fatores influenciam o impacto no desempenho ao habilitar o CDC, incluindo:

• O número de tabelas com o CDC habilitado no 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 do log até que a transação seja confirmada e a varredura do CDC a alcance, ou até que a transação seja abortada. 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 fique cheio.

• Verifique se há espaço livre disponível no banco de dados de origem, uma vez que os artefatos da CDA (por exemplo, tabelas CT, cdc_jobs etc.) são armazenados no mesmo banco de dados.

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

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

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

Importante

Essas considerações são diretrizes gerais. Para obter diretrizes precisas para otimizar o desempenho de uma carga de trabalho específica, entre em contato com o suporte da Microsoft.

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

• Teste sua carga de trabalho minuciosamente antes de habilitar o CDC em bancos de dados em produção para ajudar a determinar o SLO apropriado para sua carga de trabalho. Para obter mais inforamções sobre tamanhos de computação do Bancos de Dados SQL do Azure, confira 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 a Hiperescala, para manter o nível de desempenho anterior depois que o CDC tiver sido habilitado no Banco de Dados SQL do Azure. Para obter mais informações, confira Modelo de compra de vCore – Banco de Dados SQL do Azure e camada de serviço de Hiperescala.

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

• Monitore a taxa de geração de log, para obter mais informações, confira Consumo de recursos por cargas de trabalho do usuário e processos internos.

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

Importante

O agendador executa a captura e a limpeza automaticamente no Banco de dados SQL. A tarefa de captura de CDC é executada a cada 20 segundos, e a tarefa de limpeza é executada a cada hora.

• Para evitar um aumento na latência, certifique-se de que o número de bancos de dados com CDC habilitado não ultrapasse a quantidade de vCores alocada a um pool elástico. Para saber mais, confira Gerenciamento de recursos em pools elásticos densos.

• Com base em sua carga de trabalho e em seu nível de desempenho, considere alterar o período de retenção do CDC para um período menor que o padrão de três dias, para garantir que o processo de limpeza consiga acompanhar as mudanças 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.

• Não há Contrato de Nível de Serviço (SLA) previsto para quando as alterações são preenchidas nas tabelas de alterações. A latência de menos de um segundo também não é suportada.

Limitações e problemas conhecidos

Restrições padrão em colunas adicionadas

Quando o CDC estiver habilitado em uma tabela e uma coluna não anulável com uma restrição padrão for adicionada, os dados de linha existentes terão o valor da restrição padrão. No entanto, o CDC usará NULL em vez do valor padrão para linhas existentes . Isso se aplica somente aos dados presentes antes da ADL ser aplicada. Como solução alternativa, emita instruções que não alteram UPDATE para linhas existentes ou execute um ALTER INDEX ... REBUILD no índice clusterizado da tabela. Use ALTER TABLE ... REBUILD no heap se nenhum índice clusterizado estiver presente.

Truncamento agressivo do log

Quando você habilita a CDC (captura de dados de alteração) no Banco de Dados SQL do Azure, o recurso agressivo de truncamento de log da ADR (Recuperação Acelerada de Banco de Dados) é desabilitado. Isso ocorre porque a varredura de 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 varredura do CDC alcance esse ponto, ou até que a transação seja abortada.

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

Embora o CDC tenha suporte para bancos de dados e pools elásticos em qualquer camada de serviço no modelo de compra baseado em vCore, bancos de dados abaixo de S3 (como Basic, S0, S1 e S2) não têm suporte no modelo de compra DTU.

Limites do log do Banco de Dados SQL do Azure

A recuperação acelerada do banco de dados e o CDC são compatíveis. Porém, o comportamento agressivo de truncamento de log da ADR é desabilitado quando a CDA está habilitada. Isso ocorre porque a varredura da CDA acessa e interage ativamente com o log de transações do banco de dados, o que impede o comportamento de truncamento agressivo do log pela ADR.

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

Dica

Se a sua carga de trabalho exigir maior desempenho geral devido à maior taxa de transferência do log de transações e a menores tempos de confirmação de transações, use a camada de serviço Hyperscale.

Operações online

As operações de índice online não têm suporte

As operações de índice online não têm suporte quando a captura de dados de alteração está habilitada em um banco de dados. Você pode encontrar o Erro 18773, "Não foi possível localizar registros de informações de texto para a coluna "%.*ls", ID %d durante a construção do comando.".

Personalização de captura e limpeza

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

Failover no Banco de Dados SQL 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

Observação

O Microsoft Entra ID era anteriormente conhecido como Azure Active Directory (Azure AD).

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 do SQL (por exemplo, até mesmo um na função sysadmin) não poderá desabilitar nem fazer alterações nos artefatos do CDC. No entanto, outro usuário do Microsoft Entra pode habilitar ou desabilitar o CDC no mesmo banco de dados.

Da mesma forma, se você criar um banco de dados como um usuário SQL, a habilitação ou desabilitação da captura de dados de alterações como um usuário do Microsoft Entra não funcionará.

A habilitação da CDA 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 a CDA e tentar habilitar a CDA depois de restaurar o banco de dados.

Para resolver esse problema, conecte-se ao banco de dados com sua conta do 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 pontual (PITR)

Se você habilitou a CDA no Banco de Dados SQL do Azure como usuário do SQL, a PITR (restauração pontual) manterá a CDA no banco de dados restaurado, a menos que ele tenha sido restaurado para um SLO de subnúcleo. Se ele tiver sido restaurado para um SLO de subnúcleo, os artefatos da CDA não estarão disponíveis.

Se você habilitar o CDC no seu banco de dados como um usuário do Microsoft Entra, não será possível fazer uma restauração pontual (PITR) para um SLO de subnúcleo. Restaure o banco de dados para o mesmo SLO do banco de dados de origem ou para um SLO superior e, em seguida, desative o CDC, se necessário.

Solução de problemas

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

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

Observação

Para obter mais informações sobre um código de erro específico, consulte Eventos e erros do mecanismo de banco de dados.

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 removida.
Gerenciamento de espaço do banco de dados	Inclui informações sobre como mitigar problemas quando o espaço do banco de dados se esgotou.
Limitação do CDC	Inclui informações sobre como mitigar problemas causados por limitações da CDA.

Metadados modificados

Erro 200/208 – nome de objeto inválido

• Causa: o erro pode ocorrer quando os metadados do CDC tiverem sido descartados. Para que a CDA funcione corretamente, não modifique manualmente nenhum metadado da CDA, como CDC schema, tabelas de alterações, procedimentos armazenados do sistema da CDA e permissões padrão do usuário cdc user (sys.database_principals), nem altere o nome do usuário cdc user.

• Recomendação: Para resolver esse problema, você precisa desabilitar e reabilitar o CDC no seu banco de dados. Ao habilitar uma captura de dados de alterações para um banco de dados, o esquema cdc, usuário cdc, as tabelas de metadados e outros objetos de sistema são criados para o banco de dados. Você precisará reativar manualmente o CDC nas tabelas individuais depois que o CDC for habilitado para o banco de dados.

Observação

Os objetos encontrados na exibição do catálogo do sistema sys.objects com is_ms_shipped=1 e schema_name=cdc não devem ser alterados nem descartados.

Erro 1202 - a entidade de segurança do banco de dados não existe ou o usuário não é membro

• Causa: o erro pode ocorrer quando o usuário do CDC foi removido. Para que a CDA funcione corretamente, não modifique manualmente nenhum metadado da CDA, como CDC schema, tabelas de alterações, procedimentos armazenados do sistema da CDA e permissões padrão do usuário cdc user (sys.database_principals), nem altere o nome do usuário 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 na condição da entidade de segurança do banco de dados porque essa entidade de segurança não existe

• Causa: este tipo de entidade não pode ser representada, ou você não tem permissão. O erro pode ocorrer quando os metadados da CDA foram descartados ou não fazem mais parte da função db_owner. Para que a CDA funcione corretamente, não modifique manualmente nenhum metadado da CDA, como CDC schema, tabelas de alterações, procedimentos armazenados do sistema da CDA e permissões padrão do usuário cdc user (sys.database_principals), nem altere o nome do usuário 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 uma ID de objeto para a tabela do sistema de replicação

• Causa: esse erro ocorre 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 os metadados CDC, como o CDC schema, as tabelas de alterações, os procedimentos armazenados do sistema CDC, as permissões de cdc user padrão (sys.database_principals) ou renomeie o cdc user.

• Recomendação: verifique se a tabela do sistema existe e se pode ser acessada consultando a tabela diretamente. Consulte o catálogo do sistema sys.objects e 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 depois habilitar novamente o CDC no seu banco de dados. Habilitar uma captura de dados de alterações para um banco de dados cria o cdc schema, o cdc user, as tabelas de metadados e outros objetos de sistema para o banco de dados. Você precisará reativar manualmente o CDC nas tabelas individuais depois que o CDC for habilitado para o banco de dados.

Erro 21050 – apenas membros da função de servidor fixa sysadmin ou db_owner podem realizar essa 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: verifique se o usuário cdc 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.

Gerenciamento de espaço do 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: esse 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 possam ser removidos com segurança. Monitore a utilização do espaço de perto. Para obter mais informações, confira Gerenciar espaço de arquivo para bancos de dados no Banco de Dados SQL do Azure.

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

Importante

Para obter informações detalhadas sobre os tamanhos da computação (SLO) do Banco de Dados SQL do Azure (banco de dados individual), consulte Limites de recursos para bancos de dados únicos usando o modelo de compra de vCore e Limites de recursos para bancos de dados únicos usando o modelo de compra de DTU — Banco de Dados SQL do Azure.

Erro 1132 – o pool elástico atingiu seu limite de armazenamento.

• Causa: esse 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 o espaço de arquivo para bancos de dados no banco de dados SQL do Azure.

  Caso o arquivamento de dados ou o descarte de dados/objetos desnecessários não sejam opções, considere o dimensionamento para uma camada de banco de dados mais alta.

Importante

Para obter informações detalhadas sobre tamanhos de computação do Banco de Dados SQL do Azure (banco de dados individual), confira Limites de recurso para pools elásticos usando o modelo de compra vCore e Limites de recursos para pools elásticos usando o modelo de compra de DTU.

Limitações de CDC

Erro 2628 – cadeia de caracteres ou dados binários seriam truncados na tabela

• Causa: alterar o tamanho das colunas de uma tabela habilitada para CDA usando instruções DDL pode causar problemas com o processo subsequente de captura da CDA. A sys.dm_cdc_errors Exibição de Gerenciamento Dinâmico (DMV) é útil para verificar se há problemas relatados em qualquer CDC, como os erros 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 da CDA. Para resolver esse problema, você precisa desabilitar e reabilitar o CDC no seu banco de dados. Para obter mais informações sobre como habilitar a CDA para um banco de dados ou uma tabela, confira Habilitar a CDA para um banco de dados SQL do Azure e Habilitar a CDA para uma tabela neste artigo.

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

• Causa: Este erro ocorre ao habilitar o CDC se existir um gatilho definido pelo usuário no banco de dados que contenha uma chamada para SUSER_SNAME() em create_table. Você pode listar gatilhos com o seguinte script Transact-SQL. Este comando fornece os detalhes do disparador de objeto e o object_id correspondente:

  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 estejam sendo feitas para SYSTEM_USER com o seguinte script:

  SELECT OBJECT_DEFINITION(object_id) AS trigger_definition;
  

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

  • Desabilitar o gatilho
  • Habilitar CDC
  • Reativar o gatilho

Para obter mais informações, confira DISABLE TRIGGER.

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

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

• Recomendação: as etapas recomendadas são suspender temporariamente as operações de DML na tabela, executar um trabalho de captura para processar as alterações, executar o DDL da tabela, executar um trabalho de captura para processar as alterações de DDL e, em seguida, reativar o processamento de DML. Para mais informações, veja falhas no trabalho de captura CDC ao processar alterações para uma tabela com tipo de dado CLR do sistema (geometria, geografia ou hierarquicida).

Criar usuário e atribuir função

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

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 o usuário cdc 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 a função db_owner ao usuário cdc.

EXEC sp_addrolemember 'db_owner' , 'cdc';

Conteúdo relacionado

• Trabalhando com dados de mudança
• Controlar alterações de dados (SQL Server)
• Administrar e monitorar a captura de dados de alterações
• Tabelas temporais