Solución para eventos de Database Service

En este artículo se describen las correcciones necesarias para los problemas encontrados al utilizar eventos de Database Service.

Están disponibles las siguientes soluciones:

Temas relacionados

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

Nombre de evento

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

Descripción del Evento

Este evento se notifica cuando el espacio libre del sistema de archivos de VM de invitado es inferior al 10 % , según lo determina el comando df(1) del sistema operativo, para los siguientes sistemas de archivos:

  • /
  • /u01
  • /u02
  • /var
  • /tmp

Explicación del problema

Uno o más sistemas de archivos de invitado de VM tienen menos del 10 % de espacio libre.

Riesgo

Un espacio libre insuficiente en el sistema de archivos de invitado de VM puede provocar un fallo de asignación de espacio en disco, lo que puede causar errores y fallos de amplio alcance en el software de Oracle (Database, Clusterware, herramientas en la nube).

Acción/reparación

Oracle Cloud y el agente DCS se ejecutan automáticamente para depurar archivos log antiguos y archivos de rastreo creados por las herramientas en la nube para reclamar espacio del sistema de archivos.

Si las utilidades de recuperación automática de espacio en el sistema de archivos no pueden depurar suficientemente los archivos antiguos para borrar este evento, realice las siguientes acciones:

  1. Elimine los archivos y/o los directorios innecesarios creados manualmente o por aplicaciones o utilidades instaladas por el cliente. Los archivos creados por el software instalado por el cliente están fuera del alcance de las utilidades de recuperación automática de espacio en el sistema de archivos de Oracle. El siguiente comando del sistema operativo, cuando se ejecuta como usuario root, es útil para identificar directorios que consumen un espacio en disco excesivo: 
    sudo du -hx <file system mount point> | sort -hr

    Elimine solo los archivos o los directorios de los que tenga la total certeza de que se pueden eliminar de forma segura.

  2. Defina la política de depuración automática mediante herramientas en la nube. Para obtener más información, consulte Comandos de autoologcleanpolicy.
  3. Abra una solicitud de servicio para recibir orientación adicional sobre la reducción del uso del espacio en el sistema de archivos.

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

Nombre de evento

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

Descripción del Evento

Se crea un evento de tipo CRITICAL cuando se detecta que Cluster Ready Service (CRS) ha dejado de funcionar.

Explicación del problema

La pila de Cluster Ready (CRS) tiene el estado fuera de línea o ha fallado.

Riesgo

Si la CRS está fuera de línea en un nodo, el nodo no puede proporcionar servicios de base de datos para la aplicación.

Acción/reparación

  1. Compruebe si el administrador ha parado CRS, como parte de un evento de mantenimiento planificado, o si ha escalado o reducido verticalmente el almacenamiento local
    1. Los siguientes eventos de aplicación de parche pararán CRS
      1. Actualización de GRID
      2. Actualización de invitado
      3. Actualización de host
  2. Si la CRS se ha parado de forma inesperada, se puede comprobar el estado actual emitiendo el comando crsctl check crs.
    1. Si el nodo no responde, es posible que se esté reiniciando el nodo de VM. Espere a que finalice el reinicio del nodo. CRS normalmente se iniciará mediante el proceso init.
  3. Si la CRS sigue caída, investigue la causa del fallo consultando alert.log, que se encuentra en /u01/app/grid/diag/crs/<node_name>/crs/trace. Revise las entradas de log que corresponden a la fecha/hora del evento de caída y actúe sobre cualquier posible solución.
  4. Reinicie CRS emitiendo el comando crsctl start crs.
  5. Un reinicio correcto de CRS generará el evento de borrado: AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

Evento de borrado

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

Descripción de evento de borrado

Se crea un evento INFORMATION cuando la CRS se inicia correctamente.

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

Nombre de evento

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

Descripción del Evento

Se crea un evento de tipo CRITICAL cuando Cluster Ready Service (CRS) expulsa un nodo del cluster. Se analiza alert.log de la CRS en busca del error CRS-1632, que indica que se está eliminando un nodo del cluster.

Explicación del problema

Oracle Clusterware está diseñado para realizar una expulsión de nodo mediante la eliminación de uno o más nodos del cluster si se ha detectado algún problema crítico. Un problema crítico podría ser un nodo que no responde a través de un latido de red, un nodo que no responde a través de un latido de disco, una máquina bloqueada o gravemente degradada, o un proceso ocssd.bin bloqueado. El objetivo de esta expulsión de nodo es mantener el estado general del cluster mediante la eliminación de miembros en mal estado.

Riesgo

Durante el tiempo que se tarda en reiniciar el nodo expulsado, el nodo no puede proporcionar servicios de base de datos para la aplicación.

Acción/reparación

Una expulsión de nodo de CRS puede estar causada por procesos OCSSD (también conocido como daemon de CSS), CSSDAGENT o CSSDMONITOR. Esto requiere determinar qué proceso era responsable de la expulsión del nodo y revisar los archivos log relevantes. Las causas comunes de expulsión por OCSSD son los fallos/latencias de red, las incidencias de E/S con discos de quorum de CSS y la escalada de finalización de miembros. Los expulsiones por CSSDAGENT o CSSDMONITOR pueden ser un problema del programador del sistema operativo o un thread bloqueado en el daemon de CSS. Los archivos log que se revisan incluyen log de alertas de clusterware, log de cssdagent, log de cssdmonitor, log de ocssd, log de lastgasp, /var/log/messages, datos de CHM/OS Watcher y detalles de opatch lsinventory.

Para obtener más información sobre la recopilación de archivos, consulte Autonomous Health Framework (AHF) Trace File Analyzer (TFA) & ORAchk/EXAchk . Para obtener más información sobre la solución de problemas de expulsión de nodos de CRS, consulte Troubleshooting Clusterware Node Evictions (Reboots).

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

Nombre de evento

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

Descripción del Evento

Se crea un evento de tipo DOWN cuando deja de funcionar un listener de SCAN. El evento es de tipo INFORMATION cuando se cierra un listener de SCAN debido a la acción del usuario, como con los comandos de la utilidad de control de servidor (srvctl) o de control del listener (lsnrctl), o cualquier acción de mantenimiento de Oracle Cloud que utilice esos comandos, como realizar una actualización del software de infraestructura de grid. El evento es de tipo CRITICAL cuando un listener de SCAN deja de funcionar inesperadamente. Se crea el evento DOWN_CLEARED correspondiente cuando se inicia un listener de SCAN.

Existen tres listeners de SCAN por cluster denominados LISTENER_SCAN[1,2,3].

Explicación del problema

Un listener de SCAN está caído y no puede aceptar conexiones de aplicación.

Riesgo

Si todos los listeners de SCAN están caídos, fallarán las conexiones de aplicación a la base de datos a través del listener de SCAN.

Acción/reparación

Inicie el listener de SCAN para recibir el evento DOWN_CLEARED.

Evento DOWN de tipo INFORMATION

  1. Si el evento lo ha causado una acción de mantenimiento de Oracle Cloud, como realizar una actualización del software de infraestructura de cuadrícula, no es necesario realizar ninguna acción. El listener de SCAN afectado realizará un failover automáticamente en una instancia disponible.
  2. Si el evento lo ha causado la acción del usuario, inicie el listener de SCAN en la siguiente oportunidad.

Evento DOWN de tipo CRITICAL

  1. Compruebe el estado de SCAN y reinicie el listener de SCAN
    • Conéctese a la VM como usuario opc y utilice sudo para el usuario grid: 
      [opc@vm ~] sudo su - grid
    • Compruebe el estado de los listeners de SCAN en cualquier nodo:
      [grid@vm ~] srvctl status scan_listener
    • Inicie el listener de SCAN:
      [grid@vm ~] srvctl start scan_listener
    • Vuelva a comprobar el estado de los listeners de SCAN en cualquier nodo: si scan_listener sigue caído, investigue la causa del fallo del listener de SCAN:
      1. Recopile los logs de CRS y del sistema operativo 30 minutos antes, y 10 minutos antes para el <hostName> indicado en el log. Tenga en cuenta que la hora de la carga útil del evento siempre se proporciona en UTC: para la recopilación tfactl, ajuste la hora a la zona horaria del cluster de VM. 
        [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. Las incidencias del listener de SCAN se registran en:
        /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

Nombre de evento

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

Descripción del Evento

Se crea un evento de tipo DOWN cuando deja de funcionar un listener de cliente. El evento es de tipo INFORMATION cuando se cierra un listener de cliente debido a la acción del usuario, como con los comandos de la utilidad de control de servidor (srvctl) o de control del listener (lsnrctl), o cualquier acción de mantenimiento de Oracle Cloud que utilice esos comandos, como realizar una actualización del software de infraestructura de grid. El evento es de tipo CRITICAL cuando un listener de cliente deja de funcionar inesperadamente. Se crea el evento DOWN_CLEARED correspondiente cuando se inicia un listener de cliente.

Hay un listener de cliente por nodo, cada uno de los cuales se denomina LISTENER.

Explicación del problema

Un listener de cliente está caído y no puede aceptar conexiones de aplicación.

Riesgo

Si el listener de cliente del nodo está caído, las instancias de base de datos del nodo no pueden proporcionar servicios para la aplicación.

Si el listener de cliente está caído en todos los nodos, cualquier aplicación que se conecte a cualquier base de datos mediante SCAN o VIP fallará.

Acción/reparación

Inicie el listener de cliente para recibir el evento DOWN_CLEARED.

Evento DOWN de tipo INFORMATION

  1. Si el evento lo ha causado una acción de mantenimiento de Oracle Cloud, como realizar una actualización del software de infraestructura de cuadrícula, no es necesario realizar ninguna acción. El listener de cliente afectado se reiniciará automáticamente cuando se complete el mantenimiento que afecta a la instancia de cuadrícula.
  2. Si el evento lo ha causado la acción del usuario, inicie el listener del cliente en la siguiente oportunidad.

Evento DOWN de tipo CRITICAL

  1. Compruebe el estado del listener de cliente y reinicie el listener de cliente:
    • Conéctese a la VM como usuario opc y utilice sudo para el usuario grid:
      [opc@vm ~] sudo su - grid
    • Compruebe el estado del listener del cliente en cualquier nodo:
      [grid@vm ~] srvctl status listener
    • Inicie el listener del cliente:
      [grid@vm ~] srvctl start listener
    • Vuelva a comprobar el estado del listener de cliente en cualquier nodo: si el listener de cliente sigue caído. Investigue la causa del fallo del listener de cliente:
      1. Utilice tfactl para recopilar los logs de CRS y del sistema operativo 30 minutos antes, y 10 minutos antes para el hostName indicado en el log. Tenga en cuenta que la hora de la carga útil del evento siempre se proporciona en UTC: para la recopilación tfactl, ajuste la hora a la zona horaria del cluster de VM.
        [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 el log del listener ubicado en:
        /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

Nombre de evento

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

Descripción del Evento

Se crea un evento de tipo DOWN cuando deja de funcionar una instancia de base de datos. El evento es de tipo INFORMATION cuando se cierra una instancia de base de datos debido a la acción del usuario, como con los comandos de SQL*Plus (sqlplus) o de la utilidad de control de servidor (srvctl), o cualquier acción de mantenimiento de Oracle Cloud que utilice esos comandos, como realizar una actualización del software del directorio raíz de base de datos. El evento es de tipo CRITICAL cuando una instancia de base de datos deja de funcionar inesperadamente. Se crea el evento de tipo DOWN_CLEARED correspondiente cuando se inicia una instancia de base de datos.

Explicación del problema

Se ha caído una instancia de base de datos.

Riesgo

Una instancia de base de datos se ha caído, lo cual puede causar una reducción del rendimiento si las instancias de base de datos están disponibles en otros nodos del cluster, o bien un tiempo de inactividad total si las instancias de base de datos de todos los nodos están caídas.

Acción/reparación

Inicie la instancia de base de datos para recibir el evento DOWN_CLEARED.

Evento DOWN de tipo INFORMATION

  1. Si el evento lo ha causado una acción de mantenimiento de Oracle Cloud, como realizar una actualización del software del directorio raíz de base de datos, no es necesario realizar ninguna acción. La instancia de base de datos afectada se reiniciará automáticamente cuando se complete el mantenimiento que afecta a la instancia.
  2. Si el evento lo ha causado la acción del usuario, inicie la instancia de base de datos afectada en la siguiente oportunidad.

Evento DOWN de tipo CRITICAL

  1. Compruebe el estado de la base de datos y reinicie la instancia de base de datos caída.
    1. Conéctese a la VM como usuario oracle:
    2. Defina el entorno:
      [oracle@vm ~] . <dbName>.env
    3. Compruebe el estado de la base de datos:
      [oracle@vm ~] srvctl status database -db <dbName>
    4. Inicie la instancia de la base de datos:
      [oracle@vm ~] srvctl start instance -db <dbName> -instance <instanceName>
  2. Investigue la causa del fallo de la instancia de base de datos.
    1. Revise los eventos de Trace File Analyzer (TFA) para la base de datos:
      [oracle@vm ~] tfactl events -database <dbName> -instance <instanceName>
    2. Revise el log de alertas de base de datos ubicado en:
      $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log

HEALTH.DB_CLUSTER.CDB.CORRUPTION

Nombre de evento

HEALTH.DB_CLUSTER.CDB.CORRUPTION

Descripción del Evento

Se han detectado daños de base de datos en la base de datos principal o en espera. El archivo alert.log de la base de datos se analiza en busca de errores específicos indicativos de daños en bloques físicos, daños en bloques lógicos o daños en bloques lógicos causados por escrituras perdidas.

Explicación del problema

Las corrupciones pueden provocar errores en la aplicación o en la base de datos y, en el peor de los casos, pueden provocar una pérdida significativa de datos si no se resuelven rápidamente.

Un bloque corrupto es un bloque que se ha modificado de modo que difiere de lo que Oracle Database espera encontrar. Las corrupciones de bloques se pueden clasificar como físicas o lógicas:

  • En la corrupción de un bloque físico, que también se denomina corrupción del medio, la base de datos no reconoce el bloque en absoluto; el total de control no es válido o el bloque solo contiene ceros. Un ejemplo de corrupción de bloque más sofisticada es cuando la cabecera y el pie de página del bloque no coinciden.
  • En una corrupción de bloque lógica, el contenido del bloque es físicamente correcto y supera las comprobaciones de bloque físico; sin embargo, el bloque puede tener una lógica que no es consistente. Algunos ejemplos de corrupción de bloque lógica son un tipo de bloque incorrecto, número de secuencia de bloque de redo o de datos incorrecto, corrupción de una parte de fila o una entrada de índice, o corrupciones del diccionario de datos.

Las corrupciones de bloques también se pueden dividir en corrupción entre bloques y corrupción dentro del bloque:

  • En una corrupción dentro del bloque, la corrupción se produce en el propio bloque y puede ser una corrupción de bloque físico o lógico.
  • En una corrupción entre bloques, la corrupción se produce entre los bloques y solo puede ser una corrupción de bloques lógicos.

Oracle comprueba los siguientes errores en alert.log:

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

Riesgo

Una interrupción por corrupción de datos se produce cuando un componente de hardware, de software o de red hace que se lean o escriban datos dañados. El impacto en el nivel de servicio de una interrupción por corrupción de datos puede variar desde una pequeña parte de la aplicación o la base de datos (un único bloque de base de datos) hasta una gran parte de la aplicación o la base de datos (que la convierte prácticamente básicamente en inutilizable). Si no se realiza una acción de solución rápidamente, puede aumentar la posibilidad de que se produzca un tiempo de inactividad y la pérdida de datos.

Acción/reparación

La notificación del evento actual se dispara actualmente en corrupciones de bloques físicos (ORA-01578), escrituras perdidas (ORA-00752, ORA-00753 y ORA-00600, donde el primer argumento es 3020) y corrupciones lógicas (se detectan normalmente a partir de ORA-00600, donde el primer argumento es kdsgrp1, kdsgrp1, kclchkblk_3, 13013 o 5463).

Se recomiendan los siguientes pasos:

  1. Confirme que estas corrupciones se han notificado en el archivo de rastreo alert.log. Registre una solicitud de servicio (SR) con el último informe EXAchk, el extracto de alert.log y el archivo de rastreo que contiene los errores de corrupción, cualquier historial de cambios recientes de aplicación, base de datos o software, y todos los logs del sistema, el clusterware y las bases de datos durante el mismo período de tiempo. Para todos estos casos, debe haber una recopilación de TFA disponible que se debe anexar a la solicitud de servicio.
  2. Para obtener más información sobre las recomendaciones de reparación, consulte Primary Note for Handling Oracle Database Corruption Issues.

En cuanto a las corrupciones físicas o los errores ORA-1578, las siguientes notas le resultarán útiles:

Note:

RMAN se puede utilizar para recuperar uno o varios bloques de datos que estén físicamente corruptos. Además, mediante el uso de Active Data Guard con la aplicación en tiempo real, la reparación automática de las corrupciones en datos físicos se habría producido de manera automática.

En el caso de las corrupciones lógicas causadas por escrituras perdidas (ORA-00752, ORA-00753 y ORA-00600, donde el primer argumento es 3020) en las bases de datos principal o en espera, se detectarán en la base de datos principal o con el proceso de aplicación de redo de la base de datos en espera. Las siguientes notas le serán útiles:

En el caso de las corrupciones lógicas (normalmente detectadas a partir de ORA-00600 con los argumentos kdsgrp1, kclchkblk_3, 13013 o 5463)

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

Nombre de evento

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

Descripción del Evento

Se crea un evento de tipo CRITICAL si una base de datos de contenedores (CBD) no puede archivar el redo log en línea activo o no puede archivar el redo log en línea activo lo suficientemente rápido en los destinos de archivo log.

Explicación del problema

La instancia de RAC de CDB se puede retener de forma temporal o permanente debido a la incapacidad del escritor de log (LGWR) para escribir los buffers de log en un redo log en línea. Esto ocurre porque todos los logs en línea requieren archivado. Una vez que el archivador (ARC) pueda archivar al menos un redo log en línea, LGWR podrá reanudar la escritura de los buffers de log en los redo logs en línea y se aliviará el impacto de la aplicación.

Riesgo

Si el archivador deja de responder temporalmente, es posible que las aplicaciones experimenten una breve interrupción o estancamiento al intentar confirmar los cambios en la base de datos. Si el archivador no se restaura, los procesos de aplicación pueden experimentar retrasos prolongados en el procesamiento.

Acción/reparación

  • Para determinar la frecuencia por hora de cada thread/instancia, consulte Script To Find Redolog Switch History And Find Archivelog Size For Each Instances In RAC (ID de documento 2373477.1).
    • Si algún intervalo por hora es mayor que 12, considere la posibilidad de cambiar el tamaño de los redo logs en línea. Consulte el punto 2 a continuación para conocer los pasos de cambio de tamaño.
  • Si la base de datos deja de responder temporalmente, es posible que el archivador no puedan continuar con el redo log generado.
    • Busque en alert.log, $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log "All online logs need archiving"; varios eventos en un breve período pueden indicar 2 posibles soluciones.
      1. Si el número de grupos de redo logs por thread es menor que 4, considere la posibilidad de agregar grupos de logs adicionales para llegar a 4. Consulte el punto 1 a continuación para conocer los pasos para agregar redo logs.
      2. La otra solución posible es cambiar el tamaño de los redo logs. Consulte el punto 2 a continuación para conocer los pasos para cambiar el tamaño.
  • Para obtener las directrices de ajuste de tamaño para Data Guard y entornos que no sean de Data Guard, consulte Configuración adecuada de redo logs en línea.
  • Agregue un grupo de redo logs para cada thread. El redo log adicional debe ser igual al tamaño de log actual.
    1. Utilice la siguiente 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. Agregue un nuevo grupo por thread con el mismo tamaño que los redo logs actuales.
      alter database add logfile thread <thread_number> 
    group <max group + 1> ('<DATA_DISKGROUP>') size <redo_size_in_bytes>
  • Cambie el tamaño de los redo logs en línea agregando redo logs más grandes y borrando los redo logs más pequeños actuales.
    1. Utilice la siguiente 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. Agregue el mismo número de redo logs para cada thread number_of_groups_per_thread que existe actualmente. new_redo_size_in_bytes se debe basar en Configuración adecuada de redo logs en línea. 
      1. alter database add logfile thread <thread_number> 
    group <max group + 1> ('<DATA_DISKGROUP>') size <new_redo_size_in_bytes>
      2. Se deben suprimir los redo logs originales más pequeños. Un redo log solo se puede suprimir si su estado es inactivo. Para determinar el estado de los redo logs, emita la siguiente selección. 
        select group#, thread#, status, bytes from v$log order by bytes, group#, thread#;

        Suprima los redo logs más pequeños originales:

        alter database drop logfile <group#>;
  • Si la base de datos no responde, el destino principal del archivo log y la alternativa pueden estar llenos.

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

Nombre de evento

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

Descripción del Evento

Se crea un evento de tipo CRITICAL cuando un proceso o sesión deja de responder en la base de datos de contenedores (CDB).

Explicación del problema

El solucionador de bloqueos ha detectado un proceso o bloque que no responde y ha generado un mensaje de error ORA-32701. Además, este evento puede iniciarse si el procedimiento de diagnóstico (DIA0) detecta que un proceso crítico de base de datos no responde.

Riesgo

Un proceso que no responde o un bloque puede indicar problemas relacionados con la codificación de recursos, sistemas operativos o aplicaciones.

Acción/reparación

Investigue la causa del bloque de sesión.

  • Revise los eventos de TFA de la base de datos en busca de los siguientes patrones de mensaje correspondientes a la fecha/hora del evento: ORA-32701, "DIA0 Critical Database Process Blocked" o "DIA0 Critical Database Process As Root". 
    tfactl events -database <dbName> -instance <instanceName>
  • Revise el archivo alert.log asociado a la siguiente ubicación: 
    $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log
  • Para ORA-32701: un sistema sobrecargado puede provocar el progreso lento, que se puede interpretar como un bloque. El solucionador de bloqueos puede intentar resolver el bloque finalizando el proceso de bloqueador final.
  • Para los mensajes DIA0 Critical Database Process: revise las líneas del diagnóstico relacionadas que indican el proceso y el motivo del bloque.

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

Nombre de evento

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

Descripción del Evento

Se crea un evento de tipo CRITICAL si hay una copia de seguridad de CDB con el estado FAILED notificado en la vista v$rman_status.

Explicación del problema

Fallo de BACKUP incremental diario de la CDB.

Riesgo

Un fallo de la copia de seguridad puede comprometer la capacidad de utilizar las copias de seguridad para la restauración/recuperación de la base de datos. El objeto de punto de capacidad de recuperación (RPO) y el objeto de tiempo de capacidad de recuperación (RTO) pueden verse afectados.

Acción/reparación

Revise los logs de RMAN correspondientes a la fecha/hora del evento. Tenga en cuenta que el registro de hora del evento eventTime está en UTC. Ajústelo según sea necesario para la zona horaria de la máquina virtual.

Para las copias de seguridad gestionadas por Oracle:

  • La salida de RMAN se puede encontrar en /opt/oracle/dcs/log/<hostname>/rman.
  • Revise el log por si hay fallos:
    • Si el fallo se debe a un evento externo fuera de RMAN, por ejemplo, que la ubicación de la copia de seguridad estaba llena o una incidencia de red, resuelva la incidencia externa.
    • Para otros errores del script de RMAN, recopile los logs de diagnóstico y abra una solicitud de servicio.
      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
  • Si la incidencia es transitoria o se resuelve, realice una nueva copia de seguridad incremental. Para obtener más información, consulte Copia de seguridad de una base de datos mediante la consola.

Para una copia de seguridad gestionada y propiedad del cliente realizada a través de RMAN:

  • Revise los logs de RMAN para la copia de seguridad.

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

Nombre de evento

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

Descripción del Evento

Se crea un evento de tipo CRITICAL cuando un grupo de discos de ASM alcanza un uso de espacio del 90 % o superior. Se crea un evento de tipo INFORMATION cuando el uso de espacio del grupo de discos de ASM cae por debajo del 90 %.

Explicación del problema

El uso de espacio de grupo de discos de ASM es igual o superior al 90 %.

Riesgo

Un espacio de grupo de discos de ASM insuficiente puede provocar un fallo de creación de base de datos, un fallo de creación de tablespace y archivo de datos, un fallo de extensión automática de archivo de datos o un fallo de reequilibrio de ASM.

Acción/reparación

El espacio utilizado del grupo de discos de ASM está determinado por la ejecución de la siguiente consulta mientras está conectado a la instancia de 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

La capacidad de los grupos de discos de ASM se puede aumentar de las siguientes formas:

  1. Escale el almacenamiento de cluster de VM para agregar más capacidad de grupo de discos de ASM. Para obtener más información, consulte Ampliación de almacenamiento de un sistema de base de datos de máquina virtual.

El uso del espacio del grupo de discos DATA se puede reducir de las siguientes maneras:

  1. Borre archivos de datos y archivos temporales no utilizados de las bases de datos. Para obtener más información, consulte Borrado de archivos de datos.

El uso de espacio del grupo de discos RECO se puede reducir de las siguientes maneras:

  1. Borre puntos de restauración garantizados innecesarios. Para obtener más información, consulte Uso de puntos de restauración normales y garantizados.
  2. Suprima los redo logs archivados o las copias de seguridad de base de datos ya realizadas fuera del área de recuperación de flash (FRA). Para obtener más información, consulte Mantenimiento del área de recuperación rápida.