CDA (captura de dados de alterações) com o Banco de Dados SQL do Azure
Aplica-se a:
Banco de Dados SQL do Azure
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 CDA, incluindo como ele é implementado no SQL Server e na Instância Gerenciada de SQL do Azure, consulte CDA com SQL Server.
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 de forma incremental os dados de alterações de tabelas de origem do SQL Server em 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, é necessário um fluxo seguro de dados de alteração, estruturado de forma que consumidores possam aplicá-lo às representações dos dados de destino. 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 fluxo de dados da entidade de segurança para a 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 a CDA 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 individuais e pools elásticos.
Para bancos de dados no modelo de compra DTU, a CDA tem suporte para bancos de dados na camada S3 ou superior. Não há suporte para os níveis Subcore (Basic, S0, S1, S2) para CDA.
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 a CDA, conecte-se ao seu 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 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ções e, depois que a cda é habilitada para tabelas de origem, as tabelas de alterações individuais servem como repositório para dados de alterações. 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 houver um esquema ou usuário de banco de dados chamado cdc em um banco de dados, você não poderá habilitar a cda para o banco de dados até que o esquema e/ou o usuário sejam descartados ou renomeados.
Habilitar a CDA 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 a CDA 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.
As 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, por exemplo, por motivos de privacidade ou desempenho, use o parâmetro @captured_column_list para especificar o subconjunto de colunas.
Para habilitar a CDA 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 a CDA para tabela especificando uma função de limitação, 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, confira 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, confira cdc.fn_cdc_get_net_changes.
Para dar suporte às consultas de entradas, a tabela de origem deve ter uma chave primária ou índice exclusivo para identificar 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 a CDA 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çõ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 quando ela for habilitada para captura de dados de alterações, a adição subsequente de uma chave primária será ignorada pela captura de dados de alterações. 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 do procedimento armazenado sys.sp_cdc_enable_table, confira sys.sp_cdc_enable_table (Transact-SQL).
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 CDA para Banco de Dados SQL do Azure
A desabilitação da CDA para seu Banco de Dados SQL do Azure remove todos os metadados de captura de dados de alterações associados, incluindo o cdc user, o cdc schema e os processos de captura e limpeza do agendador externo. No entanto, nenhuma função associada criada pela captura de dados de alterações é removida automaticamente e deverá ser excluída explicitamente.
Observação
Para determinar se um banco de dados tem o cdc habilitado, consulte a coluna na exibição de catálogo sys.databases.
Não é necessário desabilitar CDA para tabelas individuais antes de desabilitar a CDA no nível do banco de dados.
Para desabilitar a CDA 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 a CDA
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ática de CDA
O trabalho de captura da CDA no Banco de Dados SQL do Azure opera perfeitamente, sendo executado a cada 20 segundos para controlar as alterações de modo eficiente. Ao mesmo tempo, o trabalho de limpeza é executado a cada hora, garantindo que suas tabelas de CDA 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 verificação da CDA não afetará o recurso de pausa automática.
Controle manual da CDA
Enquanto a CDA é executada automaticamente, os usuários mantêm a flexibilidade para executar operações manuais da CDA 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 CDA
Embora o Banco de Dados SQL do Azure simplifique o gerenciamento da CDA, existem algumas limitações:
- A frequência dos trabalhos de captura e limpeza da CDA não pode ser personalizada.
- Os valores
pollingintervalecontinuouspara 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_jobsnão interrompe o trabalho de captura em segundo plano. - Eliminar a entrada do trabalho de limpeza interrompe esse trabalho.
- A tabela
cdc.cdc_jobsreside no esquemacdc, não emmsdb.
Apesar dessas limitações, ainda é possível personalizar as seguintes opções:
- Consulte a tabela
cdc.cdc_jobspara obter detalhes da configuração atual. - Ajuste as opções
maxtransemaxscansusando o procedimento armazenadosp_cdc_change_job. - Gerencie trabalhos empregando
sp_cdc_drop_jobesp_cdc_add_jobconforme o necessário.
Considerações e recomendações de desempenho
Habilitar a captura de dados de alterações no Banco de Dados SQL do Azure tem um efeito de desempenho comparável a habilitar a CDA para o SQL Server ou da Instância Gerenciada de SQL do Azure. Porém, vários fatores influenciam o efeito de desempenho ao habilitar o CDA, incluindo:
O número de tabelas habilitadas para CDA 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 verificação da CDA seja atualizada, 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 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, a habilitação da CDA em vários bancos de dados corre o risco de atingir o tamanho máximo do 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 a contagem de tabelas habilitadas para CDA 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 escalar 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 completamente antes de habilitar a CDA em bancos de dados em produção para ajudá-lo 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 escalar o número de vCores ou fazer a transição para uma camada de banco de dados mais alta, como Hiperescala, para manter o nível de desempenho anterior depois que a CDA tiver sido habilitada 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 verificação e limpeza da CDA fazem parte da carga de trabalho regular do banco de dados (também consumindo 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. O trabalho de captura de CDA é executado a cada 20 segundos, e o trabalho de limpeza é executado a cada hora.
Para evitar um aumento de latência, garanta que o número de bancos de dados habilitados para a CDA não ultrapasse a contagem de vCores alocados em um pool elástico. Para saber mais, confira Gerenciamento de recursos em pools elásticos densos.
Com base em sua carga de trabalho e nível de desempenho, considere alterar o período de retenção da CDA para um número menor do que o padrão de três dias para garantir que o processo de limpeza possa acompanhar as alterações na tabela de alterações. 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
Truncamento agressivo do log
Quando você habilita a CDA (captura de dados de alterações) no Banco de Dados SQL do Azure, o recurso de truncamento de log agressivo da ADR (Recuperação Acelerada de Banco de Dados) é desabilitado. Isso ocorre porque a verificação CDA 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 da CDA seja atualizada, 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 fique cheio.
Ao habilitar a CDA, recomendamos usar a opção de índice retomável ao criar ou recompilar um índice. O índice retomável não manterá uma transação de longa execução aberta e permite o truncamento do log durante essa operação para melhor gerenciamento do espaço do 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 a CDA tenha suporte para bancos de dados e pools elásticos em qualquer camada de serviço dentro do modelo de compra baseado em vCore, bancos de dados inferiores ao S3 (como Basic, S0, S1, S2) não têm suporte no modelo de compra DTU.
Limites de log do Banco de Dados SQL do Azure
A Recuperação Acelerada de Banco de Dados e a CDA não são compatíveis no Banco de Dados SQL do Azure. Isso ocorre porque a verificação da CDA acessa e interage ativamente com o log de transações do banco de dados, o que pode entrar em conflito com o comportamento agressivo de truncamento de log de ADR.
Para evitar problemas de escalabilidade e gerenciamento de espaço, monitore de perto seu Banco de Dados SQL do Azure e considere escalar para uma camada de banco de dados mais alta e permitir que seu log de transações cresça de acordo com suas necessidades de carga de trabalho.
Dica
Se sua carga de trabalho exigir maior desempenho geral devido à maior produtividade do log de transações e tempos de confirmação de transações mais rápidos, use a camada de serviço de Hiperescala.
Personalização de captura e limpeza
Não é possível configurar a frequência da captura e os processos de limpeza da CDA nos bancos de dados SQL do Azure. O agendador executa a captura e a limpeza automaticamente.
Failover no Banco de Dados SQL do Azure
No caso de cenários de failover local ou GeoDR, se o banco de dados tiver CDA habilitada, 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 a CDA nele, um usuário do SQL (por exemplo, sequer um na função sysadmin) não poderá desabilitar/fazer alterações nos artefatos da CDA. No entanto, outro usuário do Microsoft Entra pode habilitar ou desabilitar a CDA 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;
PITR (Restauração pontual)
Se você tiver habilitado a CDA em seu banco de dados SQL do Azure como usuário SQL, a restauração pontual (PITR) também manterá a CDA no banco de dados restaurado, a menos que ele seja restaurado para o SLO de subnúcleo. Se restaurado para o SLO de subnúcleo, os artefatos de CDA não estarão disponíveis.
Se você habilitar a CDA em seu banco de dados como um usuário do Microsoft Entra, não será possível fazer a restauração pontual (PITR) em um SLO de subnúcleo. Restaure o banco de dados para o mesmo SLO de origem ou superior e desabilite a CDA, 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. Os erros relacionados ao CDA podem obstruir o funcionamento adequado 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 à CDA quando a tabela rastreada foi modificada ou descartada. |
| 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 da CDA | 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 metadados da CDA foram 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áriocdc user(sys.database_principals), nem altere o nome do usuáriocdc user.Recomendação: para resolver esse problema, desabilite e reative a CDA para 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á reabilitar manualmente a CDA para tabelas individuais depois que a CDA for habilitada 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 é um membro.
Causa: o erro pode ocorrer quando o usuário da CDA foi descartado. 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áriocdc user(sys.database_principals), nem altere o nome do usuáriocdc user.Recomendação: verifique se o usuário
cdcexiste em seu banco de dados e também tem a funçãodb_owneratribuída. Para criar o usuáriocdc, consulte o exemplo Criar usuário cdc e atribuir função.
Erro 15517 – não é possível executar como o entidade de segurança do banco de dados porque essa entidade de segurança não existe
Causa: esse tipo de entidade de segurança não pode se passar por outra pessoa 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, comoCDC schema, tabelas de alterações, procedimentos armazenados do sistema da CDA e permissões padrão do usuáriocdc user(sys.database_principals), nem altere o nome do usuáriocdc user.Recomendação: verifique se o usuário
cdcexiste em seu banco de dados e também tem a funçãodb_owneratribuída. Para criar o usuáriocdc, 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 SQL Server não consegue localizar ou acessar a tabela do sistema de replicação '%s'. Isso pode ocorrer porque a tabela está ausente ou inacessível. 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áriocdc user(sys.database_principals), nem altere o nome do usuáriocdc 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, defina a cláusula de predicado com
is_ms_shipped=1eschema_name=cdcpara listar todos os objetos relacionados à CDA. Se a consulta não retornar nenhum objeto, você deverá desabilitar e reabilitar a CDA para seu banco de dados. Habilitar uma captura de dados de alterações para um banco de dados cria ocdc schema, ocdc user, as tabelas de metadados e outros objetos de sistema para o banco de dados. Você precisará reabilitar manualmente a CDA para tabelas individuais depois que a CDA for habilitada 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
cdcfoi removido da função de banco de dadosdb_ownerou da função de servidorsysadmin.Recomendação: verifique se o usuário
cdctem a funçãodb_owneratribuída. Para criar o usuáriocdc, 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ção da CDA
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 DMV (Exibição de Gerenciamento Dinâmico)
sys.dm_cdc_errorsé útil para verificar qualquer CDA em busca de problemas relatados, como os números do erro 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, desabilite e reabilite a CDA para 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: o erro ocorrerá durante a habilitação da CDA se existir um gatilho de usuário no banco de dados, que tem uma chamada para
SUSER_SNAME()emcreate_table. Você pode listar gatilhos com o seguinte script Transact-SQL. Este comando fornece os detalhes do disparador de objeto e oobject_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 estejam sendo feitas para
SYSTEM_USERcom 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 a CDA
- Reabilitar o gatilho
Para obter mais informações, consulte o artigo DESABILITAR GATILHO (Transact-SQL).
Erro 913: o trabalho de captura da CDA falha ao processar alterações em uma tabela com o tipo de dados CLR do sistema.
Causa: esse erro ocorre ao habilitar a CDA em uma tabela com o tipo de dados CLR do sistema, fazer alterações no DML e fazer alterações de DDL na mesma tabela enquanto o trabalho de captura da CDA está processando alterações relacionadas a outras tabelas.
Recomendação: as etapas recomendadas são fechar para novas sessões o DML para a 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 então reabilitar o processamento de DML. Para obter mais informações, consulte O trabalho de captura da CDA falha ao processar alterações.
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
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de