Todos os produtos
Search

Este produto

    Data Management:Erros comuns e solução de problemas do Data Disaster Recovery (DBS)

    Central de documentação

    Data Management:Erros comuns e solução de problemas do Data Disaster Recovery (DBS)

    Última atualização: Jul 04, 2026

    Este tópico descreve erros, como mensagens de exceção e códigos de erro, que podem ocorrer durante a configuração de uma agenda de backup, a execução de uma pré-verificação ou um trabalho de restauração, e explica como resolvê-los.

    Nota

    Caso encontre um erro não descrito neste tópico ou se a solução fornecida não resolver o problema, entre em contato com o suporte técnico pelo grupo do DingTalk (ID: 35585947).

    Erros

    Erros de configuração da agenda de backup

    Falha no teste de conexão com o banco de dados de origem

    Erros de pré-verificação de backup e restauração

    Erros de tarefa de download avançado

    Erros de execução de tarefa

    Erros de agenda de backup

    Falha na conexão com o banco de dados de origem

    Cenário: O teste de conexão falha durante a configuração de uma agenda de backup.

    Possíveis causas:

    • A conta ou a senha do banco de dados está incorreta.

    • O acesso ao banco de dados é restrito por endereço IP de origem.

    • Restrições de firewall no servidor ou na rede do banco de dados de origem.

    • Problemas de conectividade de rede.

    Solução:

    1. Clique em Check no console para visualizar os detalhes da falha de conexão. A caixa de diálogo Check exibe resultados de diagnóstico para MySQL JDBC Connect e Telnet. Utilize esses resultados e as mensagens de erro para determinar a causa da falha.

    2. Verifique se os seguintes testes de diagnóstico foram aprovados.

      • Primeiro, verifique se a conta ou a senha do banco de dados está incorreta ou se o banco de dados restringiu o acesso do IP de origem.

        1. Valide a conta e a senha do banco de dados.

          A partir de um cliente que consiga se conectar ao banco de dados de origem, use a conta e a senha especificadas na agenda de backup para validar as credenciais. Se estiverem incorretas, atualize-as na configuração da agenda de backup e teste a conexão novamente.

        2. Se a conta e a senha estiverem corretas, o banco de dados pode estar restringindo o acesso com base no endereço IP de origem.

          • Para bancos de dados MySQL, utilize um cliente MySQL para se conectar e execute a seguinte instrução SQL. Em seguida, verifique a saída para confirmar se a lista de endereços IP autorizados permite acesso remoto.

            SELECT host,user,authentication_string,password_expired,account_locked FROM mysql.user WHERE user='[$Username]';
            Nota

            Substitua [$Username] pela conta do banco de dados especificada na sua agenda de backup.

          • Para bancos de dados SQL Server:

            • Se o gateway de backup estiver instalado no servidor do banco de dados de origem, defina Address como localhost.

            • Verifique se há um firewall configurado no host do SQL Server ou se algum endpoint ou gatilho no banco de dados de origem restringe o acesso por endereço IP.

          • Para bancos de dados Oracle, verifique o arquivo de configuração sqlnet.ora para confirmar se o parâmetro TCP.VALIDNODE_CHECKING está definido como YES. Se o valor for YES, o banco de dados de origem restringe o acesso com base nos endereços IP de origem.

      • Em seguida, verifique se o servidor e a rede que hospedam o banco de dados possuem restrições de firewall ou se existem problemas de comunicação de rede.

        1. Verifique se o firewall está ativado no servidor do banco de dados de origem e se existem políticas de firewall configuradas.

          • Se o banco de dados de origem estiver instalado em um servidor Windows, abra o Painel de Controle, acesse o Windows Defender Firewall e verifique se há políticas de firewall configuradas.

          • Se o banco de dados de origem estiver instalado em um servidor Linux, execute o comando iptables -L para verificar se há políticas de firewall configuradas.

          • Se o banco de dados estiver instalado em uma instância ECS da Alibaba Cloud, consulte a documentação Adicionar uma regra de grupo de segurança para verificar se o grupo de segurança permite acesso do bloco CIDR necessário. As informações do bloco CIDR estão disponíveis no console.

        2. Verifique se o firewall de rede restringe o acesso do bloco CIDR necessário. As instruções a seguir usam o Cloud Firewall como exemplo.

          1. Faça login no console do Cloud Firewall. No painel de navegação à esquerda, clique em Access Control.

          2. Verifique se existem políticas do Cloud Firewall que bloqueiam o acesso do bloco CIDR necessário. As informações do bloco CIDR estão disponíveis no console.

          Nota

          Se você descartou restrições de firewall, mas a verificação via Telnet ainda falhar, a causa provavelmente é um problema de conectividade de rede. Para obter assistência, entre em contato com o suporte pelo grupo do DingTalk.

    Erros de pré-verificação de backup e restauração

    Falha na conexão com o banco de dados de origem

    Este erro ocorre durante a pré-verificação de uma agenda de backup ou de uma tarefa de restauração.

    Possíveis causas:

    • A conta ou a senha do banco de dados está incorreta.

    • O banco de dados restringe o acesso do endereço IP de origem.

    • Existe um firewall configurado no servidor ou na rede do banco de dados.

    • Existem problemas de comunicação de rede.

    Solução: Consulte a resolução para falha no teste de conexão com o banco de dados de origem, descrita na seção de erros comuns de configuração de agenda de backup.

    Falha na verificação de permissões do banco de dados

    Cenário: Este erro ocorre durante a pré-verificação de uma agenda de backup ou de uma tarefa de restauração.

    Possíveis causas:

    • A conta do banco de dados usada na agenda de backup não possui as permissões necessárias para acessar os dados.

    • A conta do banco de dados usada na tarefa de restauração não possui permissões para gravar dados ou modificar o esquema do banco de dados.

    Solução: Verifique as permissões da conta do banco de dados. Se forem insuficientes, conceda as permissões necessárias à conta ou utilize outra conta que já as possua.

    Nota

    • Para agendas de backup: Para alterar a conta do banco de dados, consulte Modificar a origem do backup.

    • Para tarefas de restauração: Configure uma nova tarefa de restauração e exclua a original que falhou na pré-verificação.

    Falha na verificação do OSS

    Cenário: A pré-verificação de uma agenda de backup ou tarefa de restauração falha.

    Possíveis causas:

    • O armazenamento de backup é um bucket OSS pertencente ao usuário, mas o Data Disaster Recovery não recebeu autorização de serviço para acessá-lo.

    • Ocorreu um problema interno no serviço.

    Solução:

    • Na página Configure Task da agenda de backup desejada, verifique o campo Backup Storage OSS Bucket na seção Basic Information para confirmar se um bucket OSS do usuário está sendo utilizado. Nesse caso, faça login no console do OSS para verificar se o bucket exibido no console do Data Disaster Recovery existe e se a autorização de serviço foi concedida.

    • Se ocorrer um problema interno no serviço, entre em contato com o suporte técnico no grupo do DingTalk.

    Falha na pré-verificação do binlog do banco de dados de origem

    Cenário: A pré-verificação do binlog do banco de dados de origem falha.

    Solução: Esta pré-verificação confirma se o recurso de log binário está habilitado no banco de dados de origem. Uma falha indica que o recurso está desabilitado. Para resolver esse problema, siga estas etapas.

    1. Faça login no servidor que hospeda seu banco de dados MySQL de origem autogerenciado.

    2. Modifique as seguintes configurações no arquivo de configuração do MySQL my.cnf.

      log_bin=mysql_bin
binlog_format=row
server_id=2 # Must be an integer greater than 1. This is an example value.
binlog_row_image=full # This parameter is required if the source database runs MySQL 5.6 or later.
      Nota

      O caminho padrão do arquivo de configuração my.cnf é /etc/my.cnf. O caminho real pode variar dependendo da sua instalação.

    3. Reinicie o serviço do MySQL executando os seguintes comandos.

      [$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
[$Mysql_Dir]/bin/safe_mysqld &
      Nota

      Substitua [$Mysql_Dir] pelo diretório de instalação do MySQL.

    4. Faça login no banco de dados MySQL de origem autogerenciado e execute a seguinte instrução SQL para confirmar se o recurso de log binário está habilitado.

      SHOW variables LIKE '%log_bin%';

      A saída a seguir indica que o recurso está habilitado:

      MariaDB [pro1]> show variables like '%log_bin%';
+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| log_bin                          | ON    |
| log_bin_trust_function_creators  | OFF   |
| sql_log_bin                      | ON    |
+----------------------------------+-------+
3 rows in set (0.00 sec)

    5. Execute a pré-verificação do DBS novamente.

    Falha na verificação do formato do binlog de origem

    Cenário: A pré-verificação do formato do log binário do banco de dados de origem falha.

    Solução: Esta verificação confirma se o formato do log binário do banco de dados de origem está definido como ROW. Se a pré-verificação falhar, o formato não está definido como ROW. Para resolver esse problema, siga estas etapas.

    1. Faça login no servidor onde seu banco de dados MySQL de origem autogerenciado está em execução.

    2. Modifique o arquivo de configuração do MySQL my.cnf para definir o parâmetro binlog_format como ROW.

      log_bin=mysql_bin
binlog_format=ROW  # Set the binary log format to ROW.
server_id=2 # This must be an integer greater than 1. This is an example value.
binlog_row_image=full # This parameter is required if the source database runs MySQL 5.6 or later.
      Nota

      O caminho padrão do arquivo de configuração my.cnf é /etc/my.cnf. O caminho real pode variar conforme sua instalação.

    3. Reinicie o MySQL executando os seguintes comandos.

      [$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
[$Mysql_Dir]/bin/safe_mysqld &
      Nota

      Substitua [$Mysql_Dir] pelo diretório de instalação do MySQL.

    4. Faça login no banco de dados MySQL de origem autogerenciado e execute a seguinte instrução SQL para verificar se o formato do log binário está definido como ROW.

      SHOW variables LIKE "%binlog_format%";

      A saída a seguir indica que o formato do log binário está definido como ROW:

      MariaDB [(none)]> show variables like "%binlog_format%";
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| binlog_format   | ROW   |
+-----------------+-------+
1 row in set (0.01 sec)

    5. Execute a pré-verificação do DBS novamente.

    Falha na verificação do binlog_row_image

    Cenário: A pré-verificação do parâmetro binlog_row_image do banco de dados de origem falha.

    Solução: Esta verificação aplica-se ao MySQL 5.6 ou posterior. Ela confirma se o parâmetro binlog_row_image está definido como full. Uma falha indica que o log binário não está registrando imagens completas de linha. Para resolver esse problema, siga estas etapas.

    1. Faça login no servidor que hospeda seu banco de dados MySQL de origem autogerenciado.

    2. Modifique o arquivo de configuração my.cnf do MySQL para definir o parâmetro binlog_row_image como full.

      log_bin=mysql_bin
binlog_format=row  # Set the binlog format to row.
server_id=2 # Must be an integer greater than 1. This is an example value.
binlog_row_image=full # This parameter is required if the source database is MySQL 5.6 or later.
      Nota

      O caminho padrão do arquivo de configuração my.cnf é /etc/my.cnf. O caminho real pode variar.

    3. Execute os seguintes comandos para reiniciar o MySQL.

      [$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
[$Mysql_Dir]/bin/safe_mysqld &
      Nota

      Substitua [$Mysql_Dir] pelo diretório de instalação do MySQL.

    4. Faça login novamente no banco de dados MySQL de origem autogerenciado e execute a seguinte instrução SQL para confirmar se o parâmetro binlog_row_image está definido como full.

      show variables like "%binlog_row_image%";

    5. Execute a pré-verificação novamente.

    Falha na verificação do server_id do banco de dados de origem

    Cenário: A verificação do server_id falha para o banco de dados de origem.

    Solução: Ao iniciar uma tarefa de migração incremental de dados do MySQL, uma verificação de server_id é realizada no banco de dados de origem durante a fase de pré-verificação. A seção a seguir descreve como resolver uma falha na verificação de server_id para um banco de dados MySQL de origem autogerenciado.

    1. Faça login no servidor do banco de dados MySQL autogerenciado e execute a seguinte instrução SQL para verificar o valor do parâmetro server_id.

      SHOW variables LIKE '%server_id%';

    2. O parâmetro server_id deve ser definido como um número inteiro maior que 1. Execute a seguinte instrução SQL para modificar o valor de server_id.

      SET global server_id=[$ID];
      Nota

      • Substitua [$ID] por um número inteiro maior que 1. Certifique-se de que o ID seja único e não esteja sendo usado por outro servidor de banco de dados.

      • Se o banco de dados autogerenciado estiver em modo primário/secundário, garanta que essa alteração não afete a replicação primário-secundário.

      • Após executar esta instrução, você também deve modificar o valor de server_id no arquivo de configuração. Caso contrário, uma reinicialização reverterá essa alteração.

    3. Execute a pré-verificação novamente.

    Falha na verificação do log binário do banco de dados de origem

    Cenário: Ao iniciar uma agenda de backup para um banco de dados MySQL autogerenciado, a verificação do log binário falha.

    Solução:

    1. Execute o seguinte comando na CLI do MySQL para verificar se o log binário está habilitado:

      SHOW variables LIKE 'log_%';

    2. Se o valor de 'log_bin' na saída for 'OFF', o log binário está desabilitado. Para habilitá-lo em um sistema Linux, edite o arquivo de configuração my.cnf usando o comando 'vim':

      mysql> show variables like 'log_%';
+-----------------------------------------+---------------------+
| Variable_name                           | Value               |
+-----------------------------------------+---------------------+
| log_bin                                 | OFF                 |
| log_bin_basename                        |                     |
| log_bin_index                           |                     |
| log_bin_trust_function_creators         | OFF                 |
| log_bin_use_v1_row_events               | OFF                 |
| log_builtin_as_identified_by_password   | OFF                 |
| log_error                               | /var/log/mysqld.log |
| log_error_verbosity                     | 3                   |
| log_output                              | FILE                |
| log_queries_not_using_indexes           | OFF                 |
| log_slave_updates                       | OFF                 |
| log_slow_admin_statements               | OFF                 |
| log_slow_slave_statements               | OFF                 |
| log_statements_unsafe_for_binlog        | ON                  |
| log_syslog                              | OFF                 |
| log_syslog_facility                     | daemon              |
| log_syslog_include_pid                  | ON                  |
| log_syslog_tag                          |                     |
| log_throttle_queries_not_using_indexes  | 0                   |
| log_timestamps                          | UTC                 |
| log_warnings                            | 2                   |
+-----------------------------------------+---------------------+
21 rows in set (0.00 sec)
      # Open the /etc/my.cnf file.
vim /etc/my.cnf

# Press i to enter edit mode.
# Add the following parameters.
log_bin = mysql_bin
binlog_format = row
server_id = 2
expire_logs_days = 30

# Press Esc to exit edit mode, and then enter :wq to save your changes and exit.

    3. Reinicie o banco de dados MySQL autogerenciado.

      systemctl restart mysqld
      Nota

      As alterações no arquivo de configuração só entram em vigor após a reinicialização da instância do banco de dados. Recomendamos reiniciar sua instância de banco de dados autogerenciada fora dos horários de pico.

      Após a reinicialização do MySQL, execute o comando da Etapa 1 para verificar se o log binário está habilitado. Em seguida, reinicie a agenda de backup.

    Falha na verificação do mecanismo de armazenamento

    Solução: Esta verificação determina se o banco de dados de origem utiliza um mecanismo de armazenamento não suportado para migração incremental de dados. A migração incremental de dados de MySQL para MySQL não suporta os mecanismos de armazenamento FEDERATED e MRG_MyISAM. Se a verificação falhar, significa que as tabelas a serem migradas utilizam um desses mecanismos de armazenamento.

    Na página Configure Task da agenda de backup, clique em Edit Backup Objects. Remova os bancos de dados e tabelas que utilizam um mecanismo de armazenamento não suportado e execute o backup novamente.

    Nota

    Após as alterações nos objetos de backup entrarem em vigor, o sistema inicia imediatamente um novo backup. Esse processo pode afetar o banco de dados de origem e suas cargas de trabalho. Recomendamos modificar a configuração fora dos horários de pico.

    Verificação do formato da senha do MySQL

    Cenário: A pré-verificação de uma agenda de backup ou de uma tarefa de restauração falha.

    Solução: Um formato de senha antigo foi detectado. Consulte old_passwords.

    Conflito de nome de objeto

    Cenário: O objeto selecionado para restauração possui o mesmo nome de um objeto de banco de dados existente no destino.

    Solução: Configure uma nova tarefa de restauração e selecione Rename Object with the Same Name ou clique em Edit para renomear o objeto de destino. Você pode então excluir a tarefa de restauração que falhou.

    Erros comuns em tarefas de download avançado

    Sintoma: Na página de detalhes de Backup and Restoration de uma instância no console do ApsaraDB RDS, não é possível clicar no botão Download Instance Backup File para criar uma tarefa de download avançado.

    DBS-DownloadTask.Region

    Causa: O recurso não está disponível na região atual.

    Solução: Entre em contato com nossa equipe de suporte no grupo do DingTalk (ID: 35585947) para solicitar este recurso.

    DBS-DownloadTask.InstanceInfo

    Causa: O serviço de download falhou ao recuperar informações sobre a instância do ApsaraDB RDS.

    Solução: Verifique se a instância do ApsaraDB RDS está em um estado anormal ou se foi excluída.

    DBS-DownloadTask.DbType

    Causa: O mecanismo de banco de dados da instância do ApsaraDB RDS não suporta o recurso de download avançado.

    Solução: O recurso de download avançado está disponível apenas para ApsaraDB RDS for MySQL e ApsaraDB RDS for PostgreSQL.

    DBS-DownloadTask.CustinId

    Causa: Este recurso ainda não está habilitado para sua instância do ApsaraDB RDS.

    Solução: Este recurso pode estar em lançamento gradual e ainda não estar disponível para sua instância. Você pode entrar em contato com o suporte técnico no grupo de suporte ao cliente (ID do grupo DingTalk: 35585947) e informar seus requisitos.

    DBS-DownloadTask.CustinName

    Causa: Este recurso ainda não está habilitado para sua instância do ApsaraDB RDS porque está em lançamento gradual.

    Solução: Para solicitar acesso, entre em contato com o suporte técnico no grupo do DingTalk (ID: 35585947).

    DBS-DownloadTask.user

    Causa: Este recurso não está habilitado para sua instância do ApsaraDB RDS.

    Solução: Este recurso pode estar em período de lançamento gradual e ainda não estar disponível para sua instância. Você pode entrar em contato com o suporte técnico no grupo do DingTalk (ID do Grupo: 35585947) para enviar sua solicitação.

    DBS-DownloadTask.Instance.Version

    Possível causa: A versão secundária do mecanismo da instância do ApsaraDB RDS está desatualizada.

    Solução: A versão secundária do mecanismo da sua instância deve ser 20201031 ou mais recente. Para atualizar a versão secundária do mecanismo, consulte Atualizar a versão secundária do mecanismo. Se encontrar problemas durante a atualização, entre em contato com o suporte técnico do ApsaraDB RDS.

    Nota

    Para mais informações, consulte Pré-requisitos para baixar backups.

    DBS-DownloadTask.Instance.Storage.Type

    Causa: O tipo de armazenamento da sua instância do ApsaraDB RDS não suporta o recurso de download avançado.

    Solução: Apenas instâncias que utilizam discos em nuvem suportam o recurso de download avançado. Acesse a página Basic Information da sua instância do ApsaraDB RDS para verificar se o Storage Type é cloud disk.

    DBS-DownloadTask.Instance.Param

    Causa: O recurso de download avançado está indisponível devido a configurações incorretas de parâmetros na instância do ApsaraDB RDS.

    Solução: Certifique-se de que a versão secundária do mecanismo da sua instância do ApsaraDB RDS não esteja desatualizada e que os dados de backup não estejam criptografados. Para detalhes, consulte Pré-requisitos para download avançado.

    DBS-DownloadTask

    Possível causa: A instância do ApsaraDB RDS não suporta o recurso de download avançado.

    Solução: Certifique-se de que sua instância do ApsaraDB RDS atenda aos pré-requisitos para o recurso de download avançado. Para mais informações, consulte os seguintes tópicos:

    Nota

    Antes de usar o recurso de download avançado, leia a documentação para entender seus detalhes, incluindo suas limitações.

    DBS-OtherError

    Causa: Outros problemas impedem o uso do recurso de download avançado.

    Solução: Certifique-se de que sua instância RDS atenda aos pré-requisitos para o recurso de download avançado.

    Nota

    • Antes de usar este recurso, revise a documentação de download avançado, incluindo as limitações do recurso.

    • Se o problema persistir, entre em contato com o grupo de suporte ao cliente (ID do grupo DingTalk: 35585947).

    Erros comuns de tarefas

    DBS-000000

    Cenário: Um backup físico completo falha.

    Causa: O serviço não consegue se conectar ao gateway de backup especificado na agenda de backup, e a tarefa falha após atingir o limite máximo de 100 tentativas. Uma causa comum é um gateway de backup offline.

    Exemplo:

    DBS-000000 Scheduling failed, the task has been retried, exceeding the maximum limit

    Solução:

    1. Na página Configure Task da agenda de backup desejada, verifique se o status do gateway de backup é Offline.

    2. No painel de navegação à esquerda, clique em Backup Gateways. Na página Backup Gateways, localize o gateway desejado pelo Backup Gateway Hostname. Verifique se o endereço IP, o nome do host e a hora do último heartbeat estão corretos. O status atual é exibido na coluna Status.

    3. Verifique o status de execução e a configuração de rede do servidor onde o gateway de backup está instalado.

      Se o servidor estiver funcionando corretamente e a conexão de rede estiver estável, reinicie o gateway de backup. Algumas versões anteriores do gateway de backup podem ter vulnerabilidades. Recomendamos atualizar o gateway de backup. Para mais informações, consulte atualizar gateway de backup.

      Nota

      Se o gateway de backup ainda falhar ao iniciar após concluir estas etapas, entre em contato com o suporte técnico no grupo do DingTalk.

    DBS-000001

    Cenário: Uma tarefa de backup lógico completo falha.

    Causa: A tarefa falhou após exceder o limite máximo de tentativas.

    Exemplo:

    DBS-000001 Scheduling failed, the task has been retried, exceeding the maximum limit or hang more than 7 hours

    Solução: Reinicie a tarefa e monitore seu status. Se o erro persistir, entre em contato com o suporte no grupo do DingTalk.

    DBS-000002

    Cenário: Falha durante um backup lógico de esquema ou um backup completo.

    Causa: Não há recursos de serviço disponíveis.

    Exemplo:

    DBS-000002 Because the current system has no available resources, scheduling timeout...

    Solução: Entre em contato com o suporte técnico no grupo do DingTalk para diagnosticar a falha.

    DBS-000003

    Cenário: Uma tarefa de link falha.

    Causa: Nenhuma instância foi encontrada para a tarefa.

    Exemplo:

    DBS-000003  No instance was found for this task

    Solução: Entre em contato com o suporte técnico no grupo do DingTalk para obter assistência.

    DBS-000004

    Cenário: Uma tarefa de backup físico ou restauração falha ao iniciar.

    Causa: Ocorreu uma exceção durante o agendamento da tarefa de backup físico ou restauração.

    Exemplo:

    DBS-000004 + [Detailed error message]

    Solução: Tente executar a tarefa novamente. Se o erro persistir, entre em contato com o suporte técnico no grupo do DingTalk.

    DBS-000005

    Cenário: Uma tarefa de backup lógico ou restauração falha ao iniciar.

    Causa: Ocorreu um erro de agendamento.

    Exemplo:

    DBS-000005 + [Detailed error message]

    Solução: Tente executar a tarefa novamente. Se o erro persistir, entre em contato com o suporte técnico no grupo do DingTalk.

    DBS-000006

    Cenário: Uma tarefa de backup físico ou restauração atinge o tempo limite antes de iniciar.

    Causa: A tarefa falha ao iniciar devido a um erro de agendamento ou um problema de recursos.

    Exemplo:

    DBS-000006 + [Detailed error message]

    Solução: Tente executar a tarefa com falha novamente. Se a tarefa falhar novamente, entre em contato com o suporte técnico no grupo do DingTalk.

    DBS-000007

    Cenário: Ocorre um tempo limite ao iniciar uma tarefa de backup lógico ou restauração.

    Causa: Ocorre um erro de agendamento ou um problema de recursos durante a inicialização da tarefa.

    Exemplo:

    DBS-000007 + [Detailed error message]

    Solução: Reinicie a tarefa com falha. Se o erro persistir, entre em contato com o suporte pelo grupo de clientes.

    DBS-002003

    Cenário: Um backup físico completo nativo de um banco de dados SQL Server falha.

    Causa: O banco de dados não pode ser acessado. Isso pode ocorrer se você não tiver as permissões necessárias, se o banco de dados não existir ou se seu estado impedir o acesso.

    Exemplo:

    DBS-002003, message:User does not have permission to alter database 'UFTData305999_000002', the database does not exist, or the database is not in a state that allows access checks..
DBS-002003, message:User does not have permission to alter database 'UFDATA
DBS-002003, message:User 'guest' does not have permission to run DBCC LOGIN
DBS-002003 ["The TCP/IP connection to the host localhost, port 1433 has failed. Error: "Connection refused: connect. Verify the connection properties, check that an instance of SQL Server is running on the host and accepting TCP/IP connections at the port, and that no firewall is blocking TCP connections to the port."."].

    Solução:

    1. Verifique se o banco de dados está online. Se estiver offline, coloque-o online.

    2. Se o banco de dados estiver sendo restaurado, aguarde a conclusão da restauração antes de reiniciar a tarefa.

    3. Verifique se a conexão está criptografada.

      SELECT encrypt_option FROM sys.dm_exec_connections WHERE session_id = @@SPID

    4. Verifique o registro para ver se a criptografia Transport Layer Security (TLS) está habilitada.

      HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.x\Server
## 1.x indicates the version of TLS, for example, 1.0, 1.1, 1.2, or 1.3.

      Se esta entrada de registro existir e seu valor for 1, a criptografia TLS está habilitada. Para desabilitar a criptografia TLS, siga estas etapas:

      1. Altere o valor da entrada de registro de 1 para 0.

      2. Na caixa de pesquisa Iniciar do Windows, procure por Internet Options. Clique na aba Advanced, role para baixo, desmarque as caixas de seleção Use TLS 1.0, Use TLS 1.1, Use TLS 1.2 e Use TLS 1.3, e clique em OK. As alterações entram em vigor após reiniciar o computador.

      3. Reinicie o computador e tente executar a tarefa de backup novamente.

    DBS-002009

    Cenário: Um backup de esquema falha.

    Possíveis causas:

    • O nome da conta do banco de dados ou a senha está incorreto.

    • As permissões da conta do banco de dados foram alteradas ou o banco de dados restringe o acesso do IP de origem.

    • As regras de firewall do banco de dados ou de seu servidor foram alteradas.

    • Problemas de conectividade de rede, por exemplo, os mapeamentos de rede foram alterados.

    Exemplo:

    DBS-002009 com.alibaba.dts.exception.message.LocalException: DBS-002009 Connect db jdbc:mysql://*:*?useSSL=false timeout.

    Solução: Para solução de problemas, consulte a seção "Falha no teste de conexão com o banco de dados de origem" deste tópico. Primeiro, verifique se a conexão falhou devido a alterações no nome da conta do banco de dados, senha, permissões da conta, IP de origem ou regras de firewall. Se essas configurações não foram alteradas, verifique e regenere os mapeamentos de rede:

    1. Acesse a página Configure Task da agenda de backup desejada e clique em Edit Backup Objects no canto superior direito da seção Basic Information.

    2. Insira novamente o nome da conta do banco de dados e a senha, e clique em Test Connection.

      Durante o teste de conexão, o sistema verifica e regenera os mapeamentos de rede em segundo plano, conforme necessário. A página de configuração inclui campos para o nome da conta do banco de dados e senha. Para o método de conexão, você pode selecionar unencrypted connection ou SSL secure connection.

      Nota

      Se o teste de conexão ainda falhar mesmo com a configuração correta do banco de dados de origem, entre em contato com o suporte técnico no grupo do DingTalk.

    3. Após o sucesso do teste de conexão, clique em Next.

    4. Selecione novamente os bancos de dados e tabelas para backup e clique em Save para atualizar a agenda de backup.

      Após clicar em Save, a nova configuração entra em vigor e um backup é iniciado imediatamente. Esta ação pode afetar o banco de dados de origem e suas cargas de trabalho. Recomendamos alterar a configuração fora dos horários de pico.

    DBS-102001

    Cenário: Pode ocorrer em várias situações.

    Causa: O backup é concluído, mas o relatório dos objetos de backup para o metadatabase falha. Este é um problema comum em backups de esquema. Tentar executar a tarefa novamente pode resolver o problema.

    Exemplo:

    DBS-102001 java.lang.IllegalStateException: The RecordSplit must be in FAILED or SUCCE

    Solução: Tente executar a tarefa novamente. Se o problema persistir, entre em contato com o suporte técnico no grupo do DingTalk.

    DBS-105001

    Cenário: Este erro pode ocorrer durante várias operações.

    Causa: O relatório do heartbeat para o metadatabase atingiu o tempo limite.

    Exemplo:

    DBS-105001 com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Could not create connection to database server. Attempted reconnect 3 times. Giving up.
com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Too many connections

    Solução: Tente executar a tarefa novamente. Se o problema persistir, entre em contato com o suporte técnico no grupo do DingTalk.

    DBS-106001

    Cenário: Este erro pode ocorrer em vários estágios.

    Possível Causa: Um erro interno do OSS.

    Exemplo:

    DBS-106001 java.lang.RuntimeException: com.taobao.amp.error.RequestError: Please conta...
DBS-106001  error task count 2 reached to the max limit.

    Solução: Para obter ajuda, entre em contato conosco no grupo do DingTalk.

    DBS-202002

    Cenário: Uma tarefa falha ao fazer backup de dados para um bucket OSS pertencente ao cliente.

    Causa: O serviço OSS está suspenso devido a pagamento em atraso.

    Exemplo:

    DBS-202002 java.io.IOException: com.taobao.amp.error.RequestError: UserDisable

    Solução:

    • Na página Backup Task Configuration do plano de backup desejado, verifique se o seu plano de backup atual utiliza um bucket OSS pertencente ao cliente. Você pode confirmar isso verificando o campo Backup Storage OSS Bucket na seção Basic Information. Se estiver usando um bucket OSS do cliente, verifique sua fatura do OSS quanto a pagamentos em atraso. Após pagar a fatura, tente executar a tarefa de backup novamente.

    • Se você não estiver usando um bucket OSS pertencente ao cliente, entre em contato com o suporte técnico no grupo do DingTalk.

    DBS-203101

    Cenário: Um backup físico completo nativo de um banco de dados SQL Server falha.

    Possíveis causas:

    • O banco de dados não está em execução.

    • A criptografia SSL está habilitada para o banco de dados.

    Exemplo:

    DBS-203101 Connect db failure

    Solução:

    1. Use o SQL Server Management Studio (SSMS) para fazer login usando o número da porta e verifique se o banco de dados existe e está em execução.

      Por padrão, você pode fazer login sem um número de porta. Para especificar um número de porta, adicione-o após o nome do host com uma vírgula, por exemplo, localhost,1433.

      Nota

      Apenas conexões TCP são suportadas.

    2. Certifique-se de que a criptografia SSL não esteja habilitada para o banco de dados. Abra o SQL Server Configuration Manager. No painel esquerdo, navegue até SQL Server network configuration > protocols for MSSQLSERVER. Clique com o botão direito e selecione properties. Na aba flags, verifique se force encryption está definido como yes. Se estiver definido como yes, altere para no.

    DBS-203102

    Cenário: Um backup físico nativo de um banco de dados SQL Server falha.

    Possíveis causas:

    • O banco de dados foi excluído.

    • O banco de dados de origem foi renomeado.

    • O banco de dados está em um estado anormal e não pode sofrer backup.

    Exemplo:

    DBS-203102 Could not find database ......

    Solução:

    1. Verifique se o banco de dados foi excluído. Nesse caso, reconfigure os objetos de backup.

      Na página Configure Task da agenda de backup desejada, clique em Edit Backup Objects na seção Basic Information.

      Nota

      Salvar a nova configuração inicia imediatamente um backup. Este processo pode afetar seu banco de dados de origem e operações comerciais.

    2. Verifique se o banco de dados de origem foi renomeado. Nesse caso, siga as instruções na etapa anterior para reconfigurar os objetos de backup.

    3. Certifique-se de que o banco de dados esteja online.

    4. Se o banco de dados estiver em estado de recuperação, aguarde a conclusão da recuperação e reinicie a tarefa.

    5. Se o recurso de fechamento automático do banco de dados estiver habilitado, defina-o como False. No SQL Server Management Studio (SSMS), clique com o botão direito no banco de dados desejado e selecione Properties. Na página Options, localize a configuração na seção Auto.

    DBS-203103

    Cenário: Um backup físico completo nativo de um banco de dados SQL Server falha.

    Causa: O banco de dados está desligado.

    Exemplo:

    DBS-203103 The database server already shutdown

    Solução: Inicie o serviço do banco de dados.

    DBS-203104

    Cenário: Um backup físico completo nativo de um banco de dados SQL Server falha.

    Causa: Um problema com os componentes VDI.

    Exemplo:

    DBS-203104 Wait VDI timeout 30s

    Solução: Verifique os eventos do Windows para solucionar problemas com os componentes VDI. Após resolver quaisquer problemas, tente executar a tarefa novamente. Se não encontrar problemas, aguarde um pouco e tente realizar o backup novamente. Se o erro persistir, entre em contato com o grupo do DingTalk para obter assistência.

    DBS-203201

    Cenário: Este erro ocorre durante um backup físico completo nativo de um banco de dados SQL Server.

    Possíveis causas:

    • Várias tarefas de backup estão sendo executadas simultaneamente para o mesmo banco de dados.

    • O erro é causado por truncamento de log. As possíveis causas incluem:

      • Backup simultâneo por outra ferramenta.

      • Uma operação recente de redução de banco de dados (shrink database).

      • Uma alteração no modelo de recuperação do banco de dados.

      • Outras ações que podem causar truncamento de log.

    Exemplo:

    DBS-203201 database xxx backupable lsn {1} exceeded limit {2}
    database XXXXXX  backupable lsn 10000000000000000009 exceeded limit 10000000000000000001,,already increment backup name:,backup datetime:2024-01-19 00:00:00

    Solução:

    • Várias tarefas de backup estão sendo executadas simultaneamente para o mesmo banco de dados.

      • Se várias tarefas de backup estiverem configuradas para serem executadas no mesmo banco de dados simultaneamente, suspenda as outras tarefas para garantir que apenas uma tarefa seja executada por vez.

      • Se você usar um script para backups agendados, certifique-se de que nenhuma outra tarefa de backup seja executada simultaneamente no mesmo banco de dados.

      • Se uma tarefa de backup incremental que abrange vários bancos de dados falhar para alguns deles, desative e reative a tarefa.

    • O erro é causado por truncamento de log.

      • O backup está incompleto devido ao truncamento de log. Inicie um novo backup completo a partir do console.

    DBS-203202

    Cenário: Um backup incremental de um banco de dados SQL Server falha.

    Possíveis causas:

    • Um backup incremental começa antes da conclusão de um backup completo. Este problema pode ocorrer quando você configura uma tarefa de backup pela primeira vez.

    • A opção CopyOnly está selecionada na configuração da tarefa de backup. Backups completos criados com esta opção não podem servir como base para backups incrementais.

    Exemplo:

    DBS-203202 BACKUP LOG {0} cannot be performed because there is no current database backup

    Solução: Execute manualmente um backup completo e reinicie o backup incremental que falhou.

    DBS-203203

    Cenário: Ocorre um erro durante um backup físico completo nativo de um banco de dados SQL Server.

    Causa: Backups de log de transações não são suportados porque o modelo de recuperação do banco de dados não está definido como FULL.

    Exemplo:

    DBS-203203 Only support increment trnsaction log backup in FULL MODE, database {0}

    Solução: Execute a seguinte instrução SQL para alterar o modelo de recuperação para FULL:

    ALTER DATABASE [your_database_name] SET RECOVERY FULL

    DBS-203205

    Cenário: Um backup físico completo nativo de um banco de dados SQL Server falha.

    Causa: O banco de dados está offline.

    Exemplo:

    DBS-203205 database  state is； DBS-203205 database AIS20210425120342 state is {1}

    Solução:

    • Verifique se o banco de dados está online. Caso contrário, coloque-o online.

    • Se o banco de dados estiver sendo restaurado, aguarde a conclusão da restauração antes de reiniciar a tarefa.

    DBS-203206

    Cenário: Um backup físico completo nativo de um banco de dados SQL Server falha.

    Causa: O banco de dados não pode ser aberto porque está indisponível ou corrompido.

    Exemplo:

    DBS-203206 message:Database 'UFTData992044_000002' cannot be opened due to

    Solução:

    • Certifique-se de que o banco de dados esteja online.

    • Se o banco de dados estiver sendo restaurado, aguarde a conclusão da recuperação antes de reiniciar a tarefa.

    DBS-203240

    Cenário: Backup físico completo nativo do SQL Server.

    Causa: A conta não possui a permissão sysadmin.

    Exemplo:

    DBS-203240, message:User 'guest' does not have permission to run DBCC LOGIN

    Solução: Atualize a agenda de backup para usar uma conta com as permissões necessárias ou conceda a permissão sysadmin à conta atual. Para detalhes sobre como alterar a conta do banco de dados, consulte Modificar o banco de dados de origem para backup.

    DBS-203301

    Cenário: Uma restauração completa de um banco de dados SQL Server falha.

    Possível Causa: Para evitar perda de dados, você deve fazer backup do log final (tail log) antes de restaurar um banco de dados. Este erro ocorre se o log final não tiver sido submetido a backup.

    Nota

    Um log final contém os registros de log de transações gerados desde o último backup de log.

    Exemplo:

    DBS-203301 The tail of the log for the database {0} has not been backed up. Use BACKUP LOG WITH NORECOVERY to backup the log if it contains work you do not want to lose. Use the WITH REPLACE or WITH STOPAT clause of the RESTORE statement to just overwrite the contents of the log

    Solução:

    1. Para fazer backup do log final, execute o seguinte comando.

      BACKUP LOG [Name of the database to restore] TO DISK='C:\backupdir\moyun_test.trn' WITH NORECOVERY;

    2. Reinicie a tarefa de restauração completa que falhou.

    DBS-203302

    Cenário: Uma restauração a partir de um backup físico completo nativo de um banco de dados SQL Server falha.

    Causa: O backup do log de transações termina em LSN {0}, que é anterior ao LSN {1} necessário para continuar a restauração. Isso indica uma lacuna na cadeia de backup de logs.

    Exemplo:

    DBS-203302 the log in this backup set terminates at LSN {0}, which is too early to apply to the database. A more recent log backup that includes LSN {1} can be restored

    Solução: Entre em contato com o suporte técnico no grupo do DingTalk para obter assistência.

    DBS-301005

    Cenário: Um backup físico completo de uma instância Oracle falha.

    Causa: A instância Oracle não está em modo de arquivamento, que é obrigatório para um backup físico completo.

    Exemplo:

    DBS-301005, message:INNER_ERROR[301005]:database is no archive mode
DBS-301005, message:INNER_ERROR[301005]:user="" ConnectString="" standalone params= ......

    Solução: Habilite o modo de arquivamento. Para instruções detalhadas, consulte Habilitar modo de arquivamento.

    DBS-301502

    Cenário: Ocorre um erro durante um backup físico do MySQL.

    Causa: Uma operação DDL que não pode ser registrada no redo log é executada durante o backup.

    Exemplo:

    DBS-301502, without redo logging

    Solução: Tente realizar o backup novamente quando nenhuma operação DDL estiver em execução.

    DBS-301503

    Cenário: Um backup físico do MySQL falha.

    Causa: A velocidade de geração do redo log excede a velocidade do backup.

    Exemplo:

    DBS-301503, log copying being too slow

    Solução: Aumente o tamanho do arquivo de redo e agende backups fora dos horários de pico.

    DBS-301504

    Cenário: Um backup físico de uma instância MySQL falha.

    Causa: Este erro ocorre porque uma ou mais tabelas na instância MySQL têm criptografia habilitada, um recurso que o Database Backup Service não suporta.

    Exemplo:

    DBS-301504, missing encryption

    Solução: Desative a criptografia e tente realizar o backup novamente. Se preferir não desativar a criptografia, entre em contato com o atendimento ao cliente para solicitar um reembolso da agenda de backup.

    DBS-301505

    Cenário: Um backup físico de um banco de dados MySQL falha.

    Causa: O sistema encerra o processo de backup.

    Exemplo:

    DBS-301505, signal: terminated

    Solução: Reinicie a tarefa.

    DBS-302035

    Cenário: Um backup físico completo de um banco de dados Oracle falha.

    Causa: Não foi possível obter a função da instância Oracle.

    Exemplo:

    DBS-302035 USER_CAN_NOT_LOAD_INSTANCE_ROLE[302035]

    Solução:

    1. Faça login no servidor que hospeda a instância do banco de dados.

    2. Execute o seguinte comando para fazer login no banco de dados como administrador do sistema:

      sqlplus / as sysdba

    3. Execute a seguinte instrução SQL para verificar se um resultado é retornado:

      select database_role from v$database;

      Se nenhum resultado for retornado, investigue a causa. Se um resultado for retornado, entre em contato com o suporte no grupo do DingTalk.

    DBS-400001

    Cenário: Um backup físico completo nativo ou uma tarefa de conversão completa de dados falha.

    Causa: A tarefa fica sem memória porque as especificações da agenda de backup são insuficientes.

    Exemplo:

    DBS-400001 , message :Java heap space. 
DBS-400001 java.lang.OutOfMemoryError: Java heap space

    Solução: Atualize as especificações da agenda de backup. Para aumentar temporariamente o limite de memória para uma tarefa urgente, como uma tarefa de restauração, entre em contato com o suporte técnico no grupo do DingTalk. Para instruções, consulte Atualizar uma agenda de backup.

    DBS-999999 ou nenhum código de erro

    Cenário: Ocorre um erro durante qualquer tarefa.

    Causa: A exceção é indefinida ou o sistema falhou ao retornar o código de erro correspondente.

    Exemplo:

    DBS-999999 + [error message]

    Solução: Copie a mensagem de erro e pesquise-a neste tópico para ver se um código de erro diferente descreve o problema. Se não conseguir encontrar uma solução, entre em contato com o suporte técnico no grupo do DingTalk.