Diagnosticar problemas

Existem várias razões possíveis para isso. Para resolver esse erro:

1. Verifique se o banco de dados de origem está ativo e acessível.
2. Navegue até o perfil de conexão de origem nas páginas Streams ou Perfis de conexão.
3. Verifique se as informações de conectividade do perfil de conexão estão corretas.
4. Verifique se o nome de usuário e a senha correspondem.
5. Verifique se o nome de usuário existe no banco de dados e se tem os privilégios necessários.
6. Salve as alterações feitas na página Perfis de conexão.

O stream é retomado automaticamente.

1. Verifique se você atende a todos os pré-requisitos Pré-requisitos do peering de VPC.

2. Depois de criar a configuração de conectividade privada, verifique se a rota que contém o endereço IP interno do banco de dados aparece na guia Rotas exportadas da página Peering de rede VPC.

   Para fazer isso, acesse a página Peering de rede VPC e procure o peering que foi adicionado (o nome é peering-[UUID]). A rota pode ser encontrada na guia Rotas exportadas. Se o trajeto não existir, adicione-o manualmente.

3. O Datastream não verifica sobreposições com rotas de peering dinâmico. Fornecer uma sub-rede que se sobrepõe a uma rota dinâmica pode causar problemas de conectividade. Portanto, não recomendamos usar uma sub-rede que faça parte de uma rota dinâmica.
4. Verifique se as rotas personalizadas para os intervalos de endereços IP do Datastream estão sendo anunciadas corretamente. Se as rotas personalizadas estiverem faltando, consulte Rotas anunciadas personalizadas.
5. Se você ainda tiver problemas para se conectar ao banco de dados de origem, consulte Configurar um proxy reverso.

1. Verifique se você atende a todos os pré-requisitos.
2. Verifique se as regras de firewall permitem que a sub-rede do anexo de rede fornecido se conecte ao banco de dados de origem.
3. Verifique se as rotas personalizadas para os intervalos de endereços IP do Datastream estão sendo anunciadas corretamente. Se as rotas personalizadas estiverem faltando, consulte Rotas anunciadas personalizadas.

Você selecionou os métodos públicos de conectividade de rede da lista de permissões de IP ou do túnel SSH de encaminhamento para o perfil de conexão que está criando. No entanto, a política da organização Bloquear métodos de conectividade pública para o Datastream está ativada. Portanto, não é possível selecionar métodos de conectividade pública para seu perfil de conexão.

Para resolver esse problema, selecione o método de conectividade de rede do peering da VPC ou das interfaces do Private Service Connect ou desative a política da organização.

Para desativar a política da organização:

1. Acesse a página Políticas da organização no console Google Cloud .
2. Selecione a política da organização Datastream: bloquear métodos de conectividade pública.

3. Clique em EDITAR.

4. Na seção Aplicável a, selecione Personalizar.

5. Na seção Aplicação, selecione Desativada.

6. Clique em Salvar.
7. Volte para o perfil de conexão do Oracle que você está criando e clique em CRIAR.

Isso pode acontecer se o banco de dados tiver milhares de tabelas e esquemas. Alguns deles podem não ser incluídos na lista de objetos a serem extraídos ao configurar a origem do fluxo no console Google Cloud . Em vez de selecionar Esquemas e tabelas específicos na seção Selecionar objetos a incluir, escolha Personalizado. No campo Critérios de correspondência de objetos, insira os esquemas e as tabelas que você quer que o Datastream extraia.

O Datastream pode descartar eventos sem suporte durante o streaming. Para resolver o problema, faça o seguinte:

• Acione manualmente um preenchimento de toda a tabela. Isso funciona se os eventos descartados forem apenas eventos UPSERT. Se os eventos descartados incluírem eventos DELETE, será necessário truncar a tabela no BigQuery antes de fazer o backfill.

  Para informações sobre como fazer um preenchimento, consulte Iniciar preenchimento.

• Entre em contato com o Suporte do Google e peça para fazer um backfill parcial. Isso só é possível se você puder identificar os eventos descartados com uma cláusula SQL WHERE e se nenhum dos eventos for DELETE.
• Ignore o problema se o número de eventos descartados for baixo ou se eles não forem significativos.

Um erro ao buscar dados contínuos de captura de dados de alteração (CDC, na sigla em inglês) poderá acontecer se a configuração de geração de registros complementar não estiver correta no banco de dados de origem. Verifique se a geração de registros complementares está configurada corretamente. Especificamente, confirma se a geração de registros complementares está ativada nas tabelas do banco de dados que estão sendo transmitidas da origem para o destino. O stream é retomado automaticamente.

Os arquivos de registros podem ter sido excluídos. A Oracle limpa os arquivos de registro assim que possível, a menos que você especifique um período de rotação mínimo para mantê-los. No servidor Oracle, defina por quanto tempo os arquivos de registros serão retidos. Por exemplo, use CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS; para manter os arquivos de registros por pelo menos quatro dias.

Para uma implantação do RDS, use exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',96);.

Isso pode acontecer em streams contínuos do MySQL se a configuração do binlog estiver incorreta no banco de dados de origem. Para resolver esse erro, execute as seguintes ações:

1. Verifique se o binlog está configurado corretamente.
2. Confirme se o formato de registro binário do banco de dados do MySQL está definido como ROW.
3. Reinicie o stream.

Isso pode acontecer quando o banco de dados de origem não segue a matriz de suporte da versão. Para resolver esse erro, execute as seguintes ações:

1. Verifique se o banco de dados de origem está de acordo com a matriz.
2. Recrie o stream com o banco de dados de origem atualizado.

Aumente a capacidade do Datastream de ler do banco de dados de origem:

• Reduza o tamanho máximo do arquivo de registro binário (binlog) do banco de dados de origem. A redução do tamanho aumenta o número de arquivos binlog.
• Se houver vários arquivos binlog, defina o número de tarefas simultâneas máximas de CDC para o fluxo de acordo. Ter vários arquivos binlog permite que o Datastream leia eventos do banco de dados de origem simultaneamente, até o número definido no campo maxConcurrentCdcTasks.

Verifique se a decodificação lógica está configurada corretamente. Consulte Configurar um banco de dados PostgreSQL de origem.

1. Mude a identidade da réplica para DEFAULT:

   ALTER TABLE TABLE_NAME REPLICA IDENTITY DEFAULT

   Substitua TABLE_NAME pelo nome da tabela em que você quer mudar a identidade de réplica.
2. Remova a tabela da lista de objetos a serem incluídos no fluxo. Para mais informações, consulte Modificar informações de configuração sobre o banco de dados de origem.
3. Exclua a tabela do BigQuery. Para mais informações, consulte Excluir tabelas.
4. No Datastream, adicione a tabela ao fluxo novamente editando a configuração de origem.

A captura de dados de alteração (CDC) precisa estar ativada no banco de dados. O Datastream precisa de acesso direto de leitura aos registros de transações para replicar mudanças em tempo real no banco de dados de origem e receber informações completas do registro. Ative a CDC para o banco de dados e tente de novo.

Para informações sobre como ativar a CDC em um banco de dados, consulte Configurar um banco de dados de origem do SQL Server.

A captura de dados alterados (CDC) precisa estar ativada em todas as tabelas incluídas no fluxo. O Datastream precisa de acesso direto de leitura aos registros de transações para replicar as mudanças em tempo real nas tabelas de origem e receber informações completas de registros. Ative a CDC para as tabelas incluídas no fluxo e tente de novo.

Para informações sobre como ativar o CDC para tabelas de origem, consulte Configurar um banco de dados SQL Server de origem.

Esse problema pode ocorrer quando os registros de transações não existem mais no banco de dados de origem. Ao replicar dados de uma origem do SQL Server usando o método CDC de registros de transações, os registros podem ser truncados antes que o Datastream os leia. Quando isso acontece, o Datastream não consegue replicar o banco de dados de origem para o destino de maneira confiável.

Para resolver o problema, recupere seu stream ou use o método CDC de tabelas de mudanças. Para mais informações sobre as diferenças entre os dois métodos, consulte Visão geral do SQL Server como uma fonte.

O usuário do app conectado ou do app cliente externo configurado para autenticar a conexão entre sua organização do Salesforce e o Datastream não tem permissões suficientes para acessar os dados que você quer replicar. Verifique se você configurou a fonte do Salesforce corretamente. Para mais informações, consulte Configurar uma origem do Salesforce.

A API Bulk 2.0 está ativada por padrão nas edições Performance, Unlimited, Enterprise e Developer. Essa mensagem de erro indica que a API está desativada na sua edição ou que as credenciais usadas não têm permissões suficientes. Verifique se o perfil de usuário que você usa tem a permissão API Enabled concedida.

Você excedeu o limite de consultas da API do Salesforce. Essa mensagem aparece quando você atinge 90% da cota de limite da API. Nesse caso, o Datastream tenta de novo mais tarde. Considere aumentar sua cota da API do Salesforce.

Ao consultar registros excluídos, o Salesforce limita a resposta a 600.000 identificadores de registro. A menor granularidade de consulta no Salesforce é de um minuto. Se você excluir mais de 600.000 registros em um minuto, o Salesforce vai retornar esse erro.

O Datastream não consegue autenticar com o Salesforce. Você provavelmente usou as credenciais ou o nome de domínio errados.

Quando você seleciona o modo de gravação Somente anexar para seu stream, os dados são anexados no BigQuery como um stream de eventos INSERT, UPDATE-INSERT, UPDATE-DELETE e DELETE, sem consolidação. Isso pode fazer com que linhas duplicadas sejam gravadas no BigQuery ao fazer um backfill ou quando ocorre um problema e o gravador do BigQuery tenta novamente as operações de gravação. Para resolver o problema, recomendamos que você execute regularmente uma consulta de remoção de duplicação semelhante a esta:

Verifique se há uma chave primária na tabela de origem. O BigQuery precisa dele para mesclar as mudanças na tabela de destino.

Se não houver uma chave primária, considere adicionar uma na tabela de origem ou de destino. Para adicionar uma chave primária à tabela de destino do BigQuery, siga estas etapas:

1. Pausar a transmissão.
2. Trunque a tabela no BigQuery.
3. Adicione a chave primária à definição da tabela.
4. Retome o stream.
5. Aciona o preenchimento da tabela.

Por padrão, o Datastream não oferece suporte à adição de uma chave primária a uma tabela já replicada para o BigQuery sem uma chave primária nem à remoção de uma chave primária de uma tabela replicada para o BigQuery com uma chave primária. No entanto, é possível mudar a definição de chave primária de uma tabela de origem replicada para o BigQuery que já tenha uma chave primária:

1. Verifique a métrica de latência total do fluxo e aguarde pelo menos o tempo da latência atual para garantir que todos os eventos em andamento sejam gravados no destino. Isso permite que todos os eventos com a chave primária original sejam transmitidos com sucesso.
2. Pause o stream.
3. Copie o comando da linguagem de definição de dados (DDL) CREATE TABLE para a tabela no BigQuery:

       SELECT ddl FROM PROJECT_ID.DATASET.INFORMATION_SCHEMA.TABLES
         WHERE table_name='TABLE_NAME';

   Substitua:

   • PROJECT_ID: o identificador do seu Google Cloud projeto.
   • DATASET_ID: o identificador do conjunto de dados no BigQuery.
   • TABLE_NAME: o nome da tabela para a qual você quer copiar o comando DDL.
4. Exclua a tabela no BigQuery.
5. Ajuste o comando DDL CREATE TABLE com as novas chaves primárias. Inclua as chaves de partição e cluster e o max_staleness OPTION:

       CREATE TABLE `[PROJECT_ID].[DATASET_ID].[TABLE_NAME]`
       (
         product_id INT64 NOT NULL,
         product_name STRING,
         datastream_metadata STRUCT,
         PRIMARY KEY (product_id) NOT ENFORCED
       )
       CLUSTER BY dept_no
       OPTIONS(
         max_staleness=INTERVAL '0-0 0 0:MINS:0' YEAR TO SECOND
       );
       ;
       

   Substitua:

   • PROJECT_ID: o identificador do seu Google Cloud projeto.
   • DATASET_ID: o identificador do conjunto de dados no BigQuery.
   • TABLE_NAME: o nome da tabela para a qual você copiou o comando DDL.
   • MINS: o número de minutos que você quer definir para a opção max_staleness, por exemplo, 15.
6. Execute a consulta ajustada para recriar a tabela no BigQuery.
7. Retome o stream.
8. Inicie o preenchimento da tabela.