Remediação para Eventos do Serviço Database

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

Nome do Evento

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

Descrição do Evento

Esse evento é relatado quando o espaço livre do sistema de arquivos da VM convidada fica abaixo de 10%, conforme determinado pelo comando df(1) do sistema operacional, para os seguintes sistemas de arquivos:

/
/u01
/u02
/var
/tmp

Instrução do Problema

Um ou mais sistemas de arquivos da VM convidada têm espaço livre abaixo de 10%.

Risco

O espaço livre insuficiente do sistema de arquivos da VM convidada pode causar falha na alocação de espaço em disco, o que pode resultar em erros e falhas muito abrangentes no software Oracle (Banco de Dados, Clusterware, Nuvem, Conjunto de Ferramentas de Nuvem).

Ação/Reparo

O Oracle Cloud e o Agente do DCS são executados automaticamente para expurgar arquivos de log antigos e arquivos de rastreamento criados pelo conjunto de ferramentas de nuvem para recuperar o espaço do sistema de arquivos.

Se os utilitários de reivindicação automática de espaço do sistema de arquivos não puderem expurgar suficientemente arquivos antigos para limpar esse evento, execute as seguintes ações:

Remova os arquivos e/ou diretórios desnecessários criados manualmente ou por aplicativos ou utilitários instalados pelo cliente. Os arquivos criados por software instalado pelo cliente estão fora do escopo dos utilitários de reivindicação automática de espaço do sistema de arquivos da Oracle. O seguinte comando do sistema operacional, executado como usuário root, é útil para identificar diretórios que consomem espaço em disco excessivo:
```
sudo du -hx <file system mount point> | sort -hr
```
Somente remova arquivos ou diretórios que tenha certeza de que podem ser removidos com segurança.
Defina a política de expurgação automática usando o conjunto de ferramentas de nuvem. Para obter mais informações, consulte Comandos Autologcleanpolicy.
Abra uma solicitação de serviço para receber orientações adicionais sobre como reduzir o uso do espaço do sistema de arquivos.

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

Nome do Evento

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

Descrição do Evento

Um evento do tipo CRITICAL é criado quando o CRS (Cluster Ready Service) é detectado como inativo.

Instrução do Problema

A Pilha Pronta do Cluster está no estado off-line ou falhou.

Risco

Se o CRS estiver off-line em um nó, o nó não poderá fornecer serviços de banco de dados para o aplicativo.

Ação/Reparo

Verifique se o CRS foi interrompido pelo administrador, como parte de um evento de manutenção planejado ou de uma expansão ou redução do armazenamento local
1. Os seguintes eventos de aplicação de patch interromperão o CRS
  1. Atualização do GRID
  2. Atualização de Convidado
  3. Atualização do Host
Se o CRS tiver sido interrompido inesperadamente, o status atual poderá ser verificado emitindo o comando crsctl check crs.
1. Se o nó não estiver respondendo, o nó da VM poderá estar sendo reinicializado. Aguarde a conclusão da reinicialização do nó. O CRS normalmente será iniciado por meio do processo init.
Se o CRS ainda estiver inativo, investigue a causa da falha consultando o alert.log encontrado em /u01/app/grid/diag/crs/<node_name>/crs/trace. Revise as entradas de log correspondentes à data/hora do evento inativo e faça qualquer possível remediação.
Reinicie o CRS, emitindo o comando crsctl start crs.
Uma reinicialização bem-sucedida do CRS vai gerar o evento de limpeza: AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

Limpando Evento

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

Descrição da Limpeza de Evento

Um evento INFORMATION é criado depois que o CRS é iniciado com sucesso.

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

Nome do Evento

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

Descrição do Evento

Um evento do tipo CRITICAL é criado quando o CRS (Cluster Ready Service) exclui um nó do cluster. É feito parsing do alert.log no CRS, referente ao erro CRS-1632, indicando que um nó está sendo removido do cluster.

Instrução do Problema

O Oracle Clusterware foi projetado para fazer uma remoção de nó removendo um ou mais nós do cluster se algum problema crítico for detectado. Um problema crítico pode ocorrer por causa de um nó que não está respondendo por meio de pulsação de rede, um nó que não está respondendo por meio de pulsação de disco, uma máquina suspensa ou gravemente degradada ou um processo ocssd.bin suspenso. A finalidade dessa expulsão de nó é manter a integridade geral do cluster removendo membros não íntegros.

Risco

Durante o tempo necessário para reiniciar o nó removido, o nó não poderá fornecer serviços de banco de dados para o aplicativo.

Ação/Reparo

Uma remoção de nó do CRS pode ser causada por processos OCSSD (também conhecidos como daemon CSS), CSSDAGENT ou CSSDMONITOR. Isso requer determinar qual processo foi responsável pela remoção de nó e revisar os arquivos de log relevantes. As causas comuns de remoção de OCSSD são falhas/latências de rede, problemas de Entrada/Saída com voting disks de CSS, dimensionamento de eliminação de membros. As remoções de CSSDAGENT ou CSSDMONITOR podem ser um problema do programador do sistema operacional ou um thread suspenso dentro do daemon CSS. Os arquivos de log a serem analisados incluem log de alerta do clusterware, log do cssdagent, log do cssdmonitor, log do ocssd, log do lastgasp, /var/log/messages, dados do CHM/OS Watcher e detalhes do opatch lsinventory.

Para obter mais informações sobre como coletar arquivos, consulte Autonomous Health Framework (AHF) Trace File Analyzer (TFA) & ORAchk/EXAchk. Para obter mais informações sobre como diagnosticar e solucionar problemas de remoção de nó CRS, consulte Troubleshooting Clusterware Node Evictions (Reboots).

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

Nome do Evento

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

Descrição do Evento

Um evento DOWN é criado quando um listener de SCAN fica inativo. O evento é do tipo INFORMATION quando um listener de SCAN é encerrado por causa da ação do usuário, como com os comandos do Server Control Utility (srvctl) ou do Listener Control (lsnrctl), ou qualquer ação de manutenção do Oracle Cloud que use esses comandos, como executar uma atualização de software do grid infrastructure. O evento é do tipo CRITICAL quando um listener de SCAN fica inativo inesperadamente. Um evento DOWN_CLEARED correspondente é criado quando um listener de SCAN é iniciado.

Há três listeners de SCAN por cluster chamados LISTENER_SCAN[1,2,3].

Instrução do Problema

Um listener SCAN está inativo e não é possível aceitar conexões de aplicativos.

Risco

Se todos os listeners SCAN estiverem inativos, as conexões de aplicativos com o banco de dados por meio do listener SCAN falharão.

Ação/Reparo

Inicie o listener de SCAN para receber o evento DOWN_CLEARED.

Evento DOWN do tipo INFORMATION

Se o evento tiver sido causado por uma ação de manutenção do Oracle Cloud, como executar uma atualização de software do grid infrastructure, nenhuma ação será necessária. O listener de SCAN afetado fará failover automaticamente para uma instância disponível.
Se o evento tiver sido causado pela ação do usuário, inicie o listener de SCAN na próxima oportunidade.

Evento DOWN do tipo CRITICAL

Verifique o status de SCAN e reinicie o listener de SCAN
- Faça log-in na VM como usuário opc e faça sudo para o usuário grid:
```
[opc@vm ~] sudo su - grid
```
- Verifique o status dos listeners de SCAN em qualquer nó:
```
[grid@vm ~] srvctl status scan_listener
```
- Inicie o listener de SCAN:
```
[grid@vm ~] srvctl start scan_listener
```
- Verifique novamente o status dos listeners SCAN em qualquer nó: se o scan_listener ainda estiver inativo, investigue a causa da falha do listener de varredura:
  1. Colete os logs do CRS e do sistema operacional 30 minutos antes e 10 minutos para o <hostName> indicado no log. Observe que a hora no payload do evento sempre é fornecida no UTC: Para a coleta tfactl, ajuste a hora para o fuso horário do cluster de VMs.
```
[grid@vm ~] tfactl diagcollect -crs -os -node <hostName> 
    –from "<eventTime adjusted for local vm timezone> - 30 minute " 
    -to "<eventTime adjusted for local vm timezone> + 10 minutes"
```
  2. Problemas de listener SCAN são registrados:
```
/u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace
```

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

Nome do Evento

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

Descrição do Evento

Um evento DOWN é criado quando um listener de cliente fica inativo. O evento é do tipo INFORMATION quando um listener de cliente é encerrado por causa da ação do usuário, como com os comandos do Server Control Utility (srvctl) ou do Listener Control (lsnrctl), ou qualquer ação de manutenção do Oracle Cloud que use esses comandos, como executar uma atualização de software do grid infrastructure. O evento é do tipo CRITICAL quando um listener de cliente fica inativo inesperadamente. Um evento DOWN_CLEARED correspondente é criado quando um listener de cliente é iniciado.

Há um listener de cliente por nó, cada um chamado LISTENER.

Instrução do Problema

Um listener de cliente está inativo e não é possível aceitar conexões de aplicativos.

Risco

Se o listener de cliente do nó estiver inativo, as instâncias do banco de dados no nó não poderão fornecer serviços para o aplicativo.

Se o listener de cliente estiver inativo em todos os nós, qualquer aplicativo que estabelecer conexão com qualquer banco de dados usando SCAN ou VIP falhará.

Ação/Reparo

Inicie o listener de cliente para receber o evento DOWN_CLEARED.

Evento DOWN do tipo INFORMATION

Se o evento tiver sido causado por uma ação de manutenção do Oracle Cloud, como executar uma atualização de software do grid infrastructure, nenhuma ação será necessária. O listener de cliente afetado será reiniciado automaticamente quando a manutenção que afeta a instância de grade for concluída.
Se o evento foi causado por uma ação do usuário, inicie o listener de cliente na próxima oportunidade.

Evento DOWN do tipo CRITICAL

Verifique o status do listener do cliente e reinicie o listener do cliente:
- Faça log-in na VM como usuário opc e faça sudo para o usuário grid:
```
[opc@vm ~] sudo su - grid
```
- Verifique o status do listener de cliente em qualquer nó:
```
[grid@vm ~] srvctl status listener
```
- Inicie o listener de cliente:
```
[grid@vm ~] srvctl start listener
```
- Verifique novamente o status do listener do cliente em qualquer nó: se o listener do cliente ainda estiver inativo. Investigue a causa da falha do listener do cliente:
  1. Use tfactl para coletar os logs do CRS e do sistema operacional 30 minutos antes e 10 minutos para o hostName indicado no log. Observe que a hora no payload do evento sempre é fornecida no UTC: Para a coleta tfactl, ajuste a hora para o fuso horário do cluster de VMs.
```
[grid@vm ~] tfactl diagcollect -crs -os -node <hostName> 
    –from "<eventTime adjusted for local vm timezone> - 30 minute " 
    -to "<eventTime adjusted for local vm timezone> + 10 minutes"
```
  2. Revise o log de listener localizado em:
```
/u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace
```

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

Nome do Evento

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

Descrição do Evento

Um evento DOWN é criado quando uma instância do banco de dados fica inativa. O evento é do tipo INFORMATION quando uma instância de banco de dados é encerrada por causa da ação do usuário, como com os comandos SQL*Plus (sqlplus) ou Server Control Utility (srvctl), ou qualquer ação de manutenção do Oracle Cloud que use esses comandos, como executar uma atualização de software home do banco de dados. O evento é do tipo CRITICAL quando uma instância do banco de dados fica inativa inesperadamente. Um evento DOWN_CLEARED correspondente é criado quando uma instância do banco de dados é iniciada.

Instrução do Problema

Uma instância de banco de dados foi desativada.

Risco

Uma instância do banco de dados ficou inativa, o que poderá resultar em desempenho reduzido se as instâncias do banco de dados estiverem disponíveis em outros nós do cluster, ou em período de indisponibilidade total, se as instâncias do banco de dados em todos os nós ficarem inativas.

Ação/Reparo

Inicie a instância do banco de dados para receber o evento DOWN_CLEARED.

Evento DOWN do tipo INFORMATION

Se o evento tiver sido causado por uma ação de manutenção do Oracle Cloud, como executar uma atualização de software do home do banco de dados, nenhuma ação será necessária. A instância do banco de dados afetado será reiniciada automaticamente quando a manutenção que afeta a instância for concluída.
Se o evento tiver sido causado pela ação do usuário, inicie a instância do banco de dados afetado na próxima oportunidade.

Evento DOWN do tipo CRITICAL

Verifique o status do banco de dados e reinicie a instância de banco de dados inativa.
1. Faça log-in na VM como usuário oracle:
2. Defina o ambiente:
```
[oracle@vm ~] . <dbName>.env
```
3. Verifique o status do banco de dados:
```
[oracle@vm ~] srvctl status database -db <dbName>
```
4. Inicie a instância do banco de dados:
```
[oracle@vm ~] srvctl start instance -db <dbName> -instance <instanceName>
```
Investigue a causa da falha da instância do banco de dados.
1. Verifique os eventos do Trace File Analyzer (TFA) para o banco de dados:
```
[oracle@vm ~] tfactl events -database <dbName> -instance <instanceName>
```
2. Verifique o log de alerta do banco de dados localizado em:
```
$ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log
```

HEALTH.DB_CLUSTER.CDB.CORRUPTION

Nome do Evento

HEALTH.DB_CLUSTER.CDB.CORRUPTION

Descrição do Evento

Foi detectada corrupção do banco de dados principal ou stand-by. O alert.log do banco de dados é analisado para verificar se há erros específicos que indiquem corrompimentos de blocos físicos ou lógicos ou de blocos lógicos causados por gravações perdidas.

Instrução do Problema

As corrupções podem levar a erros de aplicativo ou de banco de dados e, na pior das hipóteses, resultar em perda de dados significativa se não tratadas imediatamente.

Um bloco corrompido é um que foi alterado para ser diferente do que o Oracle Database espera encontrar. As corrupções de bloco podem ser categorizadas como físicas ou lógicas:

Em uma corrupção de bloco física, que também é chamada de corrupção de mídia, o banco de dados não reconhece o bloco; a soma de verificação é inválida ou o bloco contém zeros. Um exemplo de corrupção mais sofisticada de bloco seria quando o cabeçalho e o rodapé do bloco não correspondem.
Em uma corrupção de bloco lógica, o conteúdo do bloco é fisicamente mostrado e passa nas verificações de bloco físico; no entanto, o bloco pode estar logicamente inconsistente. Exemplos de corrupção de bloco lógica incluem tipo de bloco incorreto, dados incorretos ou número de sequência de bloco de redo, corrupção de parte de uma linha ou entrada de índice ou corrupções no dicionário de dados.

As corrupções de blocos também podem ser divididas em interblocos e intrabloco:

Em uma corrupção intrabloco, a corrupção ocorre no próprio bloco e pode ser uma corrupção física ou lógica do bloco.
Em uma corrupção interblocos, a corrupção ocorre entre blocos e só pode ser uma corrupção lógica.

A Oracle verifica os seguintes erros no alert.log:

ORA-01578
ORA-00752
ORA-00753
ORA-00600 [3020]
ORA-00600 [kdsgrp1]
ORA-00600 [kclchkblk_3]
ORA-00600 [13013]
ORA-00600 [5463]

Risco

Uma interrupção da corrupção de dados ocorre quando um componente de hardware, software ou rede faz com que dados corrompidos sejam lidos ou gravados. O impacto no nível de serviço de uma interrupção na corrupção de dados pode variar, desde uma pequena parte do aplicativo ou banco de dados (para um único bloco de banco de dados) até uma grande parte do aplicativo ou banco de dados (tornando-o essencialmente inutilizável). Se a ação de remediação não for executada imediatamente, o potencial período de indisponibilidade e a perda de dados poderão aumentar.

Ação/Reparo

No momento, a notificação de evento atual é acionada em corrupções de bloco físicas (ORA-01578), gravações perdidas (ORA-00752, ORA-00753 e ORA-00600 com o primeiro argumento 3020) e corrupções lógicas (típicas detectadas de ORA-00600 com o primeiro argumento de kdsgrp1, kdsgrp1, kclchkblk_3, 13013 ou 5463).

Recomendamos as seguintes etapas:

Confirme se essas corrupções foram relatadas no arquivo de rastreamento alert.log. Registre uma SR (Solicitação de Serviço) com o relatório EXAchk mais recente, trecho do alert.log e do arquivo de rastreamento contendo os erros de corrupção, qualquer histórico de alterações recentes de aplicativos, bancos de dados ou softwares e qualquer log do sistema, do clusterware e do banco de dados durante o mesmo período. Para todos esses casos, uma coleta do TFA deve estar disponível e ser anexada à SR.
Para obter mais informações sobre recomendações de reparo, consulte Primary Note for Handling Oracle Database Corruption Issues.

Para corrupções físicas ou erros ORA-1578, as seguintes notas serão úteis:

Observação:

O RMAN pode ser usado para recuperar um ou vários blocos de dados que estão corrompidos fisicamente. Também usando o Active Data Guard com aplicação em tempo real, o reparo de bloqueio automático de corrupções físicas de dados teria ocorrido automaticamente.

Para corrupções lógicas causadas por gravações perdidas (ORA-00752, ORA-00753 e ORA-00600 com o primeiro argumento 3020) nos bancos de dados principal ou stand-by, elas serão detectadas no processo de redo apply principal ou stand-by. As observações a seguir serão úteis:

Primary Note for Handling Oracle Database Corruption Issues
Se você tiver uma corrupção de gravação stand-by e perdida no principal ou no stand-by, consulte Resolving ORA-00752 or ORA-600 [3020] During Standby Recovery (Doc ID 1265884.1).

Para corrupções lógicas (típicas detectadas de ORA-00600 com argumentos kdsgrp1, kclchkblk_3, 13013 ou 5463)

Para obter mais informações sobre o erro detectado, consulte Primary Note for Handling Oracle Database Corruption Issues.
Se você tiver uma corrupção lógica e do stand-by no principal, consulte Resolving Logical Block Corruption Errors in a Physical Standby Database (Doc ID 2821699.1).

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

Nome do Evento

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

Descrição do Evento

Um evento do tipo CRITICAL será criado se um CDB (banco de dados contêiner) não puder arquivar o redo log on-line ativo ou não conseguir arquivar o redo log on-line ativo com rapidez suficiente para os destinos de arquivamento de log.

Instrução do Problema

A Instância RAC do CDB pode ser temporariamente ou permanentemente interrompida em decorrência da incapacidade do LGWR (gravador de log) de gravar os buffers de log em um redo log on-line. Isso ocorre porque todos os logs on-line precisam de arquivamento. Quando o arquivador (ARC) puder arquivar pelo menos um redo log on-line, o LGWR poderá retomar a gravação dos buffers de log em redo logs on-line e o impacto do aplicativo será reduzido.

Risco

Se o arquivador ficar temporariamente sem resposta, os aplicativos poderão sofrer um breve blecaute ou paralisação ao tentar confirmar alterações no banco de dados. Se o arquivador não for restaurado, os processos de aplicação poderão sofrer atrasos prolongados no processamento.

Ação/Reparo

Para determinar a frequência horária de cada thread/instância, consulte Script To Find Redolog Switch History and Find Archivelog Size For Each Instance In RAC (Doc ID 2373477.1).
- Se qualquer bucket por hora for maior que 12, considere redimensionar os redo logs on-line. Consulte o item 2 abaixo para ver as etapas de redimensionamento.
Se o banco de dados ficar temporariamente sem resposta, talvez o arquivador não consiga acompanhar o log de redo gerado.
- Verifique se no arquivo alert.log, $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log, há a mensagem "All online logs need archiving"; vários eventos em um curto período podem indicar 2 soluções possíveis.
  1. Se o número de grupos de redo logs por thread for menor que 4, considere adicionar mais grupos de logs para chegar a 4. Consulte o item 1 abaixo para adicionar etapas de redo log.
  2. A outra solução possível seria redimensionar os redo logs. Consulte o item 2 abaixo para ver as etapas de redimensionamento.
Para obter diretrizes de dimensionamento para Data Guard e não Data Guard, consulte Configurar Redo Logs On-line Apropriadamente.

Adicione um grupo de redo logs para cada thread. O redo log adicional deve ser igual ao tamanho do log atual.

Use a seguinte consulta:

select max(group#) Ending_group_number, thread#, 
    count(*) number_of_groups_per_thread, 
    bytes redo_size_in_bytes from v$log group by thread#,bytes

Adicione um novo grupo por thread usando o mesmo tamanho dos redo logs atuais.

alter database add logfile thread <thread_number> 
    group <max group + 1> ('<DATA_DISKGROUP>') size <redo_size_in_bytes>

Redimensione os redo logs on-line adicionando redo logs maiores e eliminando os redo logs menores atuais.
1. Use a seguinte consulta:
```
select max(group#) Ending_group_number, thread#, 
    count(*) number_of_groups_per_thread, 
    bytes redo_size_in_bytes from v$log group by thread#,bytes
```
2. Adicione o mesmo número de redo logs para cada thread number_of_groups_per_thread que existe no momento. O new_redo_size_in_bytes deve se basear em Configurar Redo Logs On-line Apropriadamente.
  1. ```
  alter database add logfile thread <thread_number> 
      group <max group + 1> ('<DATA_DISKGROUP>') size <new_redo_size_in_bytes>
```
2. Os redo logs menores originais devem ser excluídos. Um redo log só poderá ser excluído se seu status for inativo. Para determinar o status de um redo logs, execute a seleção a seguir.
```
  select group#, thread#, status, bytes from v$log order by bytes, group#, thread#;
```
  Exclua os redo logs originais menores:
```
  alter database drop logfile <group#>;
```
Se o banco de dados não responder, o destino e a alternativa do arquivo de log principal poderão estar cheios.
- Para obter mais informações sobre como liberar espaço nos grupos de discos RECO e DATA, consulte HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE.

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

Nome do Evento

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

Descrição do Evento

Um evento do tipo CRITICAL é criado quando um processo ou sessão não responde no banco de dados contêiner (CDB).

Instrução do Problema

O Resolvedor de Bloqueador detectou um processo que não responde ou um bloco e gerou uma mensagem de erro ORA-32701. Além disso, esse evento poderá ser gerado se o Processo de Diagnóstico (DIA0) detectar que um processo crítico do banco de dados ficou sem resposta.

Risco

Um processo que não responde ou um bloco pode indicar problemas relacionados a recursos, sistema operacional ou codificação de aplicativos.

Ação/Reparo

Investigar a causa do bloco de sessão.

Nos eventos do TFA do banco de dados, verifique os seguintes padrões de mensagem correspondentes à data/hora do evento: ORA-32701, "DIA0 Critical Database Process Blocked" ou "DIA0 Critical Database Process As Root".
```
tfactl events -database <dbName> -instance <instanceName>
```

Revise o alert.log associado no seguinte local:

$ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log

Para ORA-32701: Um sistema com sobrecarga pode causar um progresso lento, que pode ser interpretado como um bloco. O Blocker Resolver pode tentar resolver o bloco encerrando o processo final de bloqueio.
Para DIA0 Mensagens do Processo do Banco de Dados Crítico: Revise as linhas de diagnóstico relacionadas que indiquem o processo e o motivo do bloco.

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

Nome do Evento

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

Descrição do Evento

Um evento do tipo CRITICAL será criado se houver um backup do CDB com um status FAILED relatado na view v$rman_status.

Instrução do Problema

Falha em um BACKUP incremental diário do CDB.

Risco

Uma falha do backup pode comprometer a capacidade de usar os backups para restauração/recuperabilidade do banco de dados. O Objeto de Ponto de Recuperação (RPO) e o Objeto de Tempo de Recuperação (RTO) podem ser afetados.

Ação/Reparo

Verifique os logs do RMAN correspondentes à data/hora do evento. Observe que o timestamp do evento eventTime está em UTC. Ajuste conforme necessário para o fuso horário da VM.

Para backups gerenciados pela Oracle:

A saída do RMAN pode ser encontrada em /opt/oracle/dcs/log/<hostname>/rman.

Verifique se há alguma falha no log:

Se a falha for por causa de um evento externo fora do RMAN, por exemplo, o local do backup estava cheio ou um problema de rede, resolva o problema externo.

Para outros erros de script do RMAN, colete os logs de diagnóstico e abra uma Solicitação de Serviço.

dbcli collect-diagnostics -h

Usage: collect-diagnostics [options]
  Options:
    --components, -c
       Supported components: [all, dcs, crs, acfs, asm, db]
       all -- Collects diagnosis for all supported components [all, dcs, crs, acfs, asm, db]
       dcs -- Collects diagnosis for dcs
       crs -- Collects diagnosis for crs
       acfs -- Collects diagnosis for acfs
       asm -- Collects diagnosis for asm.
       db -- Collects diagnosis for db.
       For multiple parameter values, follow the example as "-c c1 c2"
       Default: [dcs]
    --dbNames, -d
       Comma separated database names. Valid only if 'db' or 'all' specified in Components list.
    --endTime, -et
       End time of diagnostic logs. Please give time in yyyy-MM-dd HH:mm:ss format
    --help, -h
       get help
    --json, -j
       json output
    --objectstoreuri, -ou
       Pre Authenticated Request URI
    --redaction, -r
       Diagnostic logs redaction. Might take longer time with some components.
    --startTime, -st
    Start time of diagnostic logs. Please give time in yyyy-MM-dd HH:mm:ss format

Se o problema for transitório ou resolvido, faça um novo backup incremental. Para obter mais informações, consulte Fazer Backup de um Banco de Dados Usando a Console.

Para backup gerenciado e de propriedade do cliente obtido por meio do RMAN:

Verifique os logs do RMAN para o backup.

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

Nome do Evento

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

Descrição do Evento

Um evento do tipo CRITICAL é criado quando um grupo de discos ASM atinge o uso de espaço de 90% ou mais. Um evento do tipo INFORMATION é criado quando o uso do espaço de grupo de discos ASM cai abaixo de 90%.

Instrução do Problema

O uso do espaço de grupo de discos ASM está em 90% ou mais.

Risco

O espaço insuficiente de grupo de discos do ASM pode causar falha na criação do banco de dados, falha na criação do tablespace e do arquivo de dados, falha na extensão automática do arquivo de dados ou falha no rebalanceamento do ASM.

Ação/Reparo

O espaço usado do grupo de discos do ASM é determinado pela execução da consulta a seguir enquanto conectado à instância do ASM.

sudo su - grid
sqlplus / as sysasm

select 'ora.'||name||'.dg', total_mb, free_mb, 
    round ((1-(free_mb/total_mb))*100,2) pct_used from v$asm_diskgroup;

NAME             TOTAL_MB    FREE_MB   PCT_USED
---------------- ---------- ---------- ----------
ora.DATAC1.dg     75497472    7408292      90.19
ora.RECOC1.dg     18874368   17720208       6.11

A capacidade do grupo de discos do ASM pode ser aumentada das seguintes maneiras:

Dimensione o armazenamento do Cluster de VMs para adicionar mais capacidade de grupo de discos do ASM. Para obter mais informações, consulte Expandir o Armazenamento para um Sistema de Banco de Dados de Máquina Virtual.

O uso do espaço de grupo de discos DATA pode ser reduzido das seguintes maneiras:

Elimine arquivos de dados não utilizados e arquivos temporários dos bancos de dados. Para obter mais informações, consulte Eliminando Arquivos de Dados.

O uso do espaço de grupo de discos RECO pode ser reduzido das seguintes maneiras:

Elimine Pontos de Restauração Garantidos desnecessários. Para obter mais informações, consulte Usando Pontos de Restauração Normais e Garantidos.
Exclua redo logs arquivados ou backups de banco de dados já submetidos a backup fora da Área de Recuperação Flash (FRA). Para obter mais informações, consulte Mantendo a Área de Recuperação Rápida.