Diagnosticando e Solucionando Problemas do Oracle Exadata Database Service em Sistemas de Infraestrutura do Exascale

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>

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)

Logs do DBAASCLI