Os backups de banco de dados podem falhar durante o estágio de configuração do RMAN ou durante um job de backup do RMAN em execução. As tarefas de configuração do RMAN incluem validar a conectividade de destino de backup, a instalação do módulo de backup e as alterações de configuração do RMAN. Os arquivos de log examinados dependem do estágio em que a falha ocorre.

1. Faça log-on no host como o usuário oracle.
2. Verifique o arquivo de log aplicável:
   • Para identificar o ID do job de um backup automatizado, use o comando dbaascli database backup --dbname <dbname> --showHistory. Isso exibe o histórico de todos os jobs de backup, incluindo seus IDs de job correspondentes.
   • Os logs de job estão disponíveis em /var/opt/oracle/log/dtrs/jobs/, nomeados usando o formato <job_id>.log. Se um job falhar, um log de depuração correspondente <job_id>.debug também será gerado no mesmo local.
   • Você pode encontrar os logs de execução do comando RMAN correspondentes para operações de backup, recuperação e configuração no diretório /var/opt/oracle/log/<dbname>/dtrs/rman/bkup.

1. Em um prompt de comando, verifique o status do agente:

   systemctl status dbcsagent.service

2. Se o agente estiver no estado interromper/aguardando, tente reiniciá-lo:

   systemctl start dbcsagent.service

3. Verifique o status do agente novamente para confirmar se ele tem o status interromper/executando:

   systemctl status dbcsagent.service

1. Crie um usuário Swift em sua tenancy. Consulte Como Trabalhar com Tokens de Autenticação.
2. Com o usuário criado na etapa anterior, use o comando a seguir para verificar se o host pode acessar o armazenamento de objetos.

   curl -v -X HEAD -u <user_ID>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>

   Consulte Perguntas mais Frequentes sobre o serviço Object Storage para obter a região correta a ser usada. Consulte Noções Básicas de Namespaces do Serviço Object Storage para obter informações sobre seu namespace do serviço Object Storage.
3. Se você não conseguir se conectar ao armazenamento de objetos, consulte o tópico Pré-requisitos para Backups no Exadata Cloud Service para obter informações sobre como configurar a conectividade do armazenamento de objetos.

Se um comando interativo, como oraenv, ou qualquer comando que possa retornar uma mensagem de erro ou advertência, for adicionado ao arquivo .bash_profile para o usuário grid ou oracle, as operações do serviço Database, como backups automáticos, poderão ser interrompidas e não ser concluídas. Verifique o arquivo .bash_profile para esses comandos e remova-os.

As operações de backup exigem espaço no diretório /u01 do sistema de arquivos host. Use o comando df -h no host para verificar o espaço disponível para backups. Se o espaço do sistema de arquivos for insuficiente, você poderá remover os arquivos antigos de log e rastreamento para liberar espaço.

Talvez seu sistema não tenha a versão necessária do módulo de backup (opc_installer.jar). Consulte Não é possível usar Backups Gerenciados em seu Sistema de Banco de Dados para obter detalhes sobre esse problema conhecido. Para corrigir o problema, você pode seguir o procedimento nesta seção ou simplesmente atualizar seu sistema de banco de dados e o próprio banco de dados com o patch do pacote mais recente.

A personalização do arquivo de perfil do site ($ORACLE_HOME/sqlplus/admin/glogin.sql) pode causar falha nos backups gerenciados no Oracle Cloud Infrastructure. Especificamente, comandos interativos podem levar a falhas de backup. A Oracle recomenda não modificar esse arquivo para bancos de dados hospedados no Oracle Cloud Infrastructure.

O banco de dados deve estar ativo e em execução (de preferência em todos os nós) enquanto o backup está em andamento.

Ao provisionar um novo banco de dados, o modo de arquivamento é definido como ARCHIVELOG por padrão. Este é o modo de arquivamento obrigatório para operações de backup. Verifique a definição do modo de arquivamento para o banco de dados e altere-a para ARCHIVELOG, se aplicável.

Instance <instance_identifier> is running on node *<node_identifier>. Instance status: Stuck Archiver

Consulte ORA-00257: Erro do Archiver (ID do Documento 2014425.1) para obter informações sobre como resolver um processo archiver paralisado.

Instance <instance_identifier> is running on node *<node_identifier>. Instance status: Open

Se o status da instância não mudar após a resolução do problema subjacente com o dispositivo ou recurso que está cheio ou indisponível, tente reiniciar o banco de dados usando o comando srvctl para atualizar o status do banco de dados no clusterware.

A edição de determinados parâmetros de configuração do RMAN pode levar a falhas de backup no Oracle Cloud Infrastructure. Para verificar a configuração do RMAN, use o comando show all no prompt de linha de comando do RMAN.

Consulte a lista a seguir de parâmetros para obter detalhes sobre as definições de configuração do RMAN que não devem ser alteradas para bancos de dados no Oracle Cloud Infrastructure.

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS;

CONFIGURE CONTROLFILE AUTOBACKUP ON;

CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 5 BACKUP TYPE TO COMPRESSED BACKUPSET;

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2 G;

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS  'SBT_LIBRARY=/var/opt/oracle/dbaas_acfs/<db_name>/opc/libopc.so, ENV=(OPC_PFILE=/var/opt/oracle/dbaas_acfs/<db_name>/opc/opc<db_name>.ora)';

CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO 'SBT_TAPE';

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2 G;

CONFIGURE ENCRYPTION FOR DATABASE ON;

Os backups do RMAN falharão quando um arquivo de wallet de armazenamento de objetos for perdido. O arquivo de wallet é necessário para ativar a conectividade com o armazenamento de objetos.

Os backups do banco de dados falharão se a wallet de TDE não estiver no estado correto. Os seguintes cenários podem causar este problema:

Se o banco de dados foi iniciado usando o SQL*Plus e a variável de ambiente ORACLE_UNQNAME não foi definida, é porque a wallet não foi aberta corretamente.

srvctl start database -d <db_unique_name>

Em um ambiente multitenant para versões do Oracle Database que suportam o armazenamento de chaves no nível do PDB, cada PDB tem sua própria chave de criptografia principal. Para bancos de dados Oracle 18c, essa chave de criptografia é armazenada em um único armazenamento de chaves usado por todos os contêineres. (O Oracle Database 19c não suporta um armazenamento de chaves no nível do PDB.) Depois de criar ou conectar um novo PDB, crie e ative uma chave de criptografia principal para ele. Caso contrário, a coluna STATUS na view v$encryption_wallet mostrará o valor OPEN_NO_MASTER_KEY.

Para verificar o status da chave de criptografia principal e criar uma chave principal, faça o seguinte:

1. Verifique a coluna STATUS na view v$encryption_wallet, conforme mostrado no seguinte exemplo:

   
   SQL> alter session set container=pdb2;
   Session altered.
   
   SQL> select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;
   
   WRL_TYPE   WRL_PARAMETER                                   STATUS             WALLET_TYPE
   ---------- ----------------------------------------------- ------------------ -----------
   FILE       /var/opt/oracle/dbaas_acfs/testdb30/tde_wallet/ OPEN_NO_MASTER_KEY AUTOLOGIN

2. Confirme se o PDB está no modo aberto READ WRITE e se ele não está restrito, conforme mostrado no seguinte exemplo:

   
   SQL> show pdbs
   
   CON_ID CON_NAME     OPEN MODE              RESTRICTED
   ------ ------------ ---------------------- ---------------
   2      PDB$SEED     READ ONLY              NO
   3      PDB1         READ WRITE             NO
   4      PDB2         READ WRITE             NO

   O PDB não pode ser aberto no modo restrito (a coluna RESTRICTED deve mostrar NO). Se no momento o PDB estiver no modo restrito, verifique as informações na view PDB_PLUG_IN_VIOLATIONS e resolva o problema antes de continuar. Para obter mais informações sobre a view PDB_PLUG_IN_VIOLATIONS e o status restrito, consulte o Oracle Multitenant Administrator's Guide para saber sobre banco de dados plugável para sua versão do Oracle Database.

3. Crie e ative uma chave de criptografia principal para o PDB:

   • Defina o contêiner como PDB:

     ALTER SESSION SET CONTAINER = <pdb>;

   • Crie e ative uma chave de criptografia principal no PDB executando este comando:

     ADMINISTER KEY MANAGEMENT SET KEY USING TAG '<tag>' 
     FORCE KEYSTORE IDENTIFIED BY <keystore-password> WITH BACKUP USING '<backup_identifier>';

   Observe o seguinte:

   • A cláusula USING TAG é opcional e pode ser usada para associar uma tag à nova chave de criptografia principal.

   • A cláusula WITH BACKUP é opcional e pode ser usada para criar um backup do armazenamento de chaves antes da criação da nova chave de criptografia principal.

   Você também pode usar os comandos dbaascli dbaascli tde status e dbaascli tde rotate masterkey para investigar e gerenciar suas chaves.

4. Verifique se o status da wallet foi alterado de OPEN_NO_MASTER_KEY para OPEN, consultando a view v$encryption_wallet, conforme mostrado na etapa 1.

Os parâmetros de configuração relacionados à wallet de TDE podem causar falha nos backups.

# ls -altr /var/opt/oracle/dbaas_acfs/<database_name>/tde_wallet/ewallet.p12
total 76
-rw------ 1 oracle oinstall 5467 Oct 1 20:17 ewallet.p12

O arquivo da wallet de TDE deve ter permissões de arquivo com o valor octal "600" (-rw-------) e o proprietário desse arquivo deve fazer parte do grupo de sistemas operacionais oinstall.

# ls -altr /var/opt/oracle/dbaas_acfs/<database_name>/tde_wallet/cwallet.sso
total 76
-rw------ 1 oracle oinstall 5512 Oct 1 20:18 cwallet.sso

O arquivo da wallet de log-in automático deve ter permissões de arquivo com o valor atual "600" (-rw-------) e o proprietário desse arquivo deve fazer parte do grupo de sistemas operacionais oinstall.

Em cada nó de computação associado à configuração do Data Guard, colete arquivos de log pertencentes ao problema que você teve.

• Arquivos de log do estágio de ativação (como aqueles que documentam a operação Criar Banco de Dados Stand-by) e os logs do correspondente sistema principal ou stand-by.
• Arquivos de log do ID do job de ativação. Por exemplo: 23.
• Locais de arquivos de log de ativação por estágio de ativação e sistema Exadata (principal ou stand-by)
• Arquivos de log de nome do banco de dados (db_name ou db_unique_name, dependendo do caminho do arquivo).

O Implantador do Data Guard (DGdeployer) é o processo que executa a configuração. Ao configurar o banco de dados principal, ele cria o arquivo /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log.

Esse log deve conter a causa raiz de uma falha ao configurar o banco de dados principal.

• O log principal do utilitário de linha de comando dbaasapi é: /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Procure entradas que contenham dg_api.
• Um log stand-by do utilitário de linha de comando dbaasapi é: /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Nesse log, procure entradas que contenham dg_api.
• O outro log stand-by é: /var/opt/oracle/log/<dbname>/dgcc/dgcc.log. Este log é o log de configuração do Data Guard.

• O ODCE (Oracle Cloud Deployment Engine) cria o arquivo /var/opt/oracle/log/<dbname>/ocde/ocde.log. Esse log deve conter a causa de uma falha na criação do banco de dados stand-by.
• O utilitário de linha de comando dbaasapi cria o arquivo var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Procure entradas que contenham dg_api.
• O arquivo de log de configuração do Data Guard é /var/opt/oracle/log/<dbname>/dgcc/dgcc.log.

• DGdeployer é o processo que executa a configuração. Ele cria o arquivo /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log a seguir. Esse log deve conter a causa raiz de uma falha ao configurar o banco de dados stand-by.
• O utilitário de linha de comando dbaasapi cria o arquivo /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log. Procure entradas que contenham dg_api.
• O log de configuração do Data Guard é /var/opt/oracle/log/<dbname>/dgcc/dgcc.log.

DGdeployer é o processo que executa a configuração. Ao configurar o Data Guard, ele cria o arquivo /var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.log. Esse log deve conter a causa raiz de uma falha ao configurar o banco de dados principal.

Em cada nó dos sites principal e stand-by, colete arquivos de log para o nome do banco de dados relacionado (db_name).

• Log de alerta de banco de dados: /u02/app/oracle/diag/rdbms/<dbname>/<dbinstance>/trace/alert_<dbinstance>.log
• Log do Data Guard Broker: /u02/app/oracle/diag/rdbms/<dbname>/<dbinstance>/trace/drc<dbinstance>.log
• Arquivo de log de ferramentas na nuvem para o Data Guard: /var/opt/oracle/log/<dbname>/odg/odg.log

A senha digitada para ativar o Data Guard não correspondeu à senha do administrador principal para o usuário SYS. Esse erro ocorre durante o estágio Validar Principal de ativação.

O banco de dados pode não estar em execução. Esse erro ocorre durante o estágio Validar Principal de ativação. Verifique com srvctl e sql no host se o banco de dados está ativo e em execução em todos os nós.

Não foi possível configurar o banco de dados principal. Comandos inválidos do Data Guard ou falha na reconfiguração do listener podem causar esse erro.

Não foi possível criar a wallet de TDE. Não foi possível preparar os arquivos do armazenamento de chaves (wallet) do Oracle TDE (Transparent Database Encryption) para transporte até o site stand-by. Esse erro ocorre durante o estágio de criação da Wallet de TDE da ativação. Um dos itens a seguir pode causar falha neste estágio:

• Não foi possível acessar os arquivos da wallet de TDE
• Os comandos de ativação não puderam criar um arquivo compactado contendo os arquivos da wallet

Procedimento de diagnóstico e solução de problemas:

1. Certifique-se de que o cluster esteja acessível. Para verificar o status de um cluster, execute o seguinte comando:

   crsctl check cluster -all

2. Se o cluster estiver desativado, execute o seguinte comando para reiniciá-lo:

   crsctl start crs -wait

3. Se esse erro ocorrer quando o cluster estiver acessível, verifique os logs para criar a Wallet de TDE (estágio de ativação) para determinar a causa e a solução do erro.

O arquivo compactado que contém a wallet de TDE provavelmente não foi transmitido para o site stand-by. Uma nova tentativa geralmente resolve o problema.

• Os sites principal e stand-by podem não ser capazes de estabelecer comunicação entre si para configurar o banco de dados stand-by. Esses erros ocorrem durante o estágio de configuração do banco de dados stand-by da ativação. Nesse estágio, as configurações são executadas no banco de dados stand-by, incluindo a duplicação do rman do banco de dados principal. Para resolver esse problema:
  1. Verifique o status de conectividade dos sites principal e stand-by.
  2. Assegure-se de que o host possa se comunicar pela porta 1521 com todas as portas. Verifique a configuração de rede, incluindo NSGs (Grupos de Segurança de Rede), Listas de Segurança de Rede e a configuração de pareamento remoto de VCN, se aplicável. A melhor maneira de testar a comunicação entre o host e outros nós é acessar os bancos de dados usando o SQL*PLUS, de principal para stand-by e de stand-by para principal.
• Os VIPs ou listeners SCAN talvez não estejam em execução. Use o teste acima para ajudar a identificar o problema.

Possíveis causas:

• VIPs ou listeners SCAN podem não estar em execução. Você pode confirmar esse problema usando os comandos a seguir em qualquer nó do cluster.

  • [grid@exa1-****** ~]$ srvctl status
                scan

  • [grid@exa1-****** ~]$ srvctl status
                  scan_listener

• Os bancos de dados podem não estar acessíveis. Você pode confirmar esse problema tentando estabelecer conexão usando um alias existente do Oracle Net.

Procedimento de diagnóstico e solução de problemas:

1. Como usuário do Sistema Operacional oracle, verifique a existência de um alias do Oracle Net para o CDB (banco de dados contêiner). Procure um alias em $ORACLE_HOME/network/admin/<dbname>/tnsnames.ora.

   O exemplo a seguir mostra uma entrada para um banco de dados contêiner denominado db12c:

   cat $ORACLE_HOME/network/admin/db12c/tnsnames.ora 
   DB12C = (DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = exa1-*****-scan.********.******.******.com)(PORT = 1521)) 
   (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = db12c.********.******.******.com) 
   (FAILOVER_MODE = (TYPE = select) (METHOD = basic))))

2. Verifique se você pode usar o alias para se conectar ao banco de dados. Por exemplo, como sysdba, digite o seguinte comando:

   sqlplus sys@db12c

Uma possível causa desse erro é que as senhas do usuário sys ou system do Oracle Database para o banco de dados e para a wallet de TDE talvez não sejam iguais. Para comparar as senhas:

1. Conecte-se ao banco de dados como usuário sys e verifique o status do TDE em

   V$ENCRYPTION_WALLET

   .
2. Conecte-se ao banco de dados como usuário systeme verifique o status do TDE em

   V$ENCRYPTION_WALLET

   .
3. Atualize as senhas aplicáveis para que correspondam. Faça log-in no host do sistema como opc e execute os seguintes comandos:
   1. Para alterar a senha SYS:

      sudo dbaascli database changepassword --dbname <database_name>

   2. Para alterar a senha da wallet de TDE:

      sudo dbaascli tde changepassword --dbname <database_name>

Para possíveis causas e soluções de problemas da wallet de TDE, consulte Wallet de TDE e Falhas de Backup.

Quando os comandos de switchover, failover e restabelecimento são executados, várias mensagens de erro podem ocorrer. Consulte a documentação do Oracle Database para obter essas mensagens de erro.

Observação

A Oracle recomenda o uso da interface de linha de comando (dgmgrl) do broker do Data Guard para validar as configurações.

1. Como Usuário Oracle, conecte-se ao banco de dados principal ou stand-by com dgmgrl e verifique a configuração e o banco de dados:

   dgmgrl sys/<pwd>@<database>
   DGMGRL> VALIDATE CONFIGURATION VERBOSE
   DGMGRL> VALIDATE DATABASE VERBOSE <PRIMARY>
   DGMGRL> VALIDATE DATABASE VERBOSE <STANDBY>

2. Consulte a documentação do Oracle Database para verificar a respectiva mensagem de erro. Por exemplo:
   • ORA-16766: O redo apply foi interrompido.
   • ORA-16853: O atraso para aplicação excedeu o limite especificado.
   • ORA-16664: Não é possível receber o resultado de um membro (no banco de dados stand-by).
   • ORA-12541: TNS: não há listener (no banco de dados principal)

Para saber a causa e a solução, analise os erros nas Mensagens de Erro do Banco de Dados.

Logs do DBAASCLI