数据库服务事件的补救

本文介绍在使用数据库服务事件时遇到的问题所需的修复。

提供了以下补救措施：

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

事件名称：

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

事件说明：

当 VM 来宾文件系统的空闲空间低于 10%（由操作系统 df(1) 命令确定）时，针对以下文件系统报告此事件：

问题陈述：

一个或多个 VM 来宾文件系统的空闲空间低于 10%。

风险：

VM 来宾文件系统的空闲空间不足可能会导致磁盘空间分配失败，这可能会导致 Oracle 软件（数据库、集群件、云工具）出现广泛的错误和故障。

操作/修复：

Oracle Cloud 和 DCS Agent 会自动运行，以清除云工具创建的旧日志文件和跟踪文件，以回收文件系统空间。

如果自动文件系统空间回收实用程序无法充分清除旧文件以清除此事件，则执行以下操作：

  1. 删除手动或由客户安装的应用程序或实用程序创建的不需要的文件和/或目录。由客户安装的软件创建的文件不在 Oracle 的自动文件系统空间回收实用程序的范围之内。以下操作系统命令（以 root 用户身份运行）可用于标识占用过多磁盘空间的目录：

    sudo du -hx <file system mount point> | sort -hr

    只能安全地删除您确定的文件或目录。

  2. 使用云工具设置自动清除策略。有关更多信息，请参见 Autologcleanpolicy Commands 。
  3. 打开服务请求，以获得有关减少文件系统空间使用的其他指导。

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

事件名称：

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

事件说明：

当检测到集群就绪服务 (Cluster Ready Service，CRS) 关闭时，将创建类型为 CRITICAL 的事件。

问题陈述：

集群就绪堆栈处于脱机状态或已失败。

风险：

如果 CRS 在节点上处于脱机状态，则该节点无法为应用程序提供数据库服务。

操作/修复：

  1. 检查 CRS 是否已被管理员停止，作为计划内维护事件的一部分，还是扩展或收缩本地存储

    1. 以下打补丁事件将停止 CRS

      1. GRID 更新
      2. 访客更新
      3. 更新主机

  2. 如果 CRS 意外停止，则可以通过发出 crsctl check crs 命令来检查当前状态。

    1. 如果节点未响应，则 VM 节点可能正在重新引导。等待节点重新引导完成，CRS 通常将通过 init 进程启动。
  3. 如果 CRS 仍处于关闭状态，请参考 /u01/app/grid/diag/crs/<node_name>/crs/trace 中的 alert.log 来调查故障原因。查看与关闭事件的日期/时间相对应的日志条目，并对任何可能的补救措施执行操作。
  4. 通过发出 crsctl start crs 命令重新启动 CRS。
  5. 成功重新启动 CRS 将生成结算事件：AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

清算事件：

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

清算事件说明：

成功启动 CRS 后，将创建 INFORMATION 事件。

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

事件名称：

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

事件说明：

当群集就绪服务 (Cluster Ready Service，CRS) 将节点从群集中清除时，将创建 CRITICAL 类型的事件。针对 CRS-1632 错误对 CRS alert.log 进行语法分析，指示正在从群集中删除节点。

问题陈述：

Oracle Clusterware 旨在通过在检测到某个严重问题时从群集中删除一个或多个节点来执行节点逐出。严重的问题可能是节点未通过网络心跳响应，节点未通过磁盘心跳响应，挂起或严重降级的计算机，或者挂起 ocssd.bin 进程。此节点逐出操作的目的是通过删除不健康的成员来维护集群的整体健康状况。

风险：

在重新启动被逐出的节点所用的时间内，该节点无法为应用程序提供数据库服务。

操作/修复：

CRS 节点逐出可能由 OCSSD（又称 CSS 守护进程）、CSSDAGENT 或 CSSDMONITOR 进程导致。这需要确定负责节点逐出和查看相关日志文件的进程。OCSSD 驱逐的常见原因是网络故障/延迟、CSS 投票磁盘的 IO 问题、成员终止升级。CSSDAGENT 或 CSSDMONITOR 逐出可能是操作系统调度程序问题或 CSS 守护进程中的挂起线程。要查看的日志文件包括集群件预警日志、cssdagent 日志、cssdmonitor 日志、ocssd 日志、lastgasp 日志、/var/log/messages、CHM/OS 监视器数据和 opatch lsinventory 详细信息。

有关一起收集文件的更多信息，请参见 Autonomous Health Framework (AHF) Trace File Analyzer (TFA) & ORAchk/EXAchk 。有关 CRS 节点逐出故障排除的更多信息，请参见 Troubleshooting Clusterware Node Evictions (Reboots) 。

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

事件名称：

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

事件说明：

当 SCAN 监听程序关闭时，将创建 DOWN 事件。当 SCAN 监听程序因用户操作（例如使用服务器控制实用程序 (srvctl) 或监听程序控制 (lsnrctl) 命令）或任何使用这些命令的 Oracle Cloud 维护操作（例如执行网格基础结构软件更新）而关闭时，该事件的类型为 INFORMATION。当 SCAN 监听程序意外关闭时，事件的类型为 CRITICAL。启动 SCAN 监听程序时将创建相应的 DOWN_CLEARED 事件。

每个集群有三个 SCAN 监听程序，称为 LISTENER_SCAN[1,2,3]。

问题陈述：

SCAN 监听程序已关闭，无法接受应用程序连接。

风险：

如果所有 SCAN 监听程序都已关闭，则通过 SCAN 监听程序与数据库的应用程序连接将失败。

操作/修复：

启动 SCAN 监听程序以接收 DOWN_CLEARED 事件。

类型为 INFORMATION 的 DOWN 事件：

  1. 如果事件是由 Oracle Cloud 维护操作（例如执行网格基础结构软件更新）引起的，则无需执行任何操作。受影响的 SCAN 监听程序将自动故障转移到可用实例。
  2. 如果事件是由用户操作导致的，则在下一个商机启动 SCAN 监听程序。

“严重”类型的“向下”事件：

  1. 检查 SCAN 状态并重新启动 SCAN 监听程序

    • 以 opc 用户身份登录到 VM，以 sudo 身份登录到 grid 用户：

      [opc@vm ~] sudo su - grid

    • 检查任何节点上的 SCAN 监听程序状态：

      [grid@vm ~] srvctl status scan_listener

    • 启动 SCAN 监听程序：

      [grid@vm ~] srvctl start scan_listener

    • 重新检查任何节点上的 SCAN 侦听器状态：如果 scan_listener 仍处于关闭状态，请调查扫描侦听器失败的原因：

      1. 为日志中指示的 <hostName> 收集 30 分钟前和 10 分钟的 CRS 和 OS 日志。请注意，事件有效负载中的时间始终以 UTC 提供：对于 tfactl 集合，请将时间调整为 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. 将记录 SCAN 监听程序问题：

        /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

事件名称：

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

事件说明：

当客户机监听程序关闭时，将创建 DOWN 事件。当客户机监听程序因用户操作（例如使用服务器控制实用程序 (srvctl) 或监听程序控制 (lsnrctl) 命令）或任何使用这些命令的 Oracle Cloud 维护操作（例如执行网格基础结构软件更新）而关闭时，事件的类型为 INFORMATION。当客户机监听程序意外关闭时，事件属于 CRITICAL 类型。启动客户机监听程序时将创建相应的 DOWN_CLEARED 事件。

每个节点都有一个客户机监听程序，每个监听程序名为 LISTENER。

问题陈述：

客户机监听程序已关闭，无法接受应用程序连接。

风险：

如果节点的客户机监听程序已关闭，则节点上的数据库实例无法为应用程序提供服务。

如果客户机监听程序在所有节点上关闭，则使用 SCAN 或 VIP 连接到任何数据库的任何应用程序都将失败。

操作/修复：

启动客户机监听程序以接收 DOWN_CLEARED 事件。

类型为 INFORMATION 的 DOWN 事件：

  1. 如果事件是由 Oracle Cloud 维护操作（例如执行网格基础结构软件更新）引起的，则无需执行任何操作。当影响网格实例的维护完成时，受影响的客户机监听程序将自动重新启动。
  2. 如果事件是由用户操作导致的，则在下一个商机启动客户机监听程序。

“严重”类型的“向下”事件：

  1. 检查客户机监听程序状态并重新启动客户机监听程序：

    • 以 opc 用户身份登录到 VM，以 sudo 身份登录到 grid 用户：

      [opc@vm ~] sudo su - grid

    • 检查任何节点上的客户机监听程序状态：

      [grid@vm ~] srvctl status listener

    • 启动客户机监听程序：

      [grid@vm ~] srvctl start listener

    • 在任意节点上重新检查客户机监听程序状态：如果客户机监听程序仍处于关闭状态。调查客户机监听程序失败的原因：

      1. 使用 tfactl 可在 30 分钟前收集 CRS 和 OS 日志，在 10 分钟内收集日志中指示的 hostName。请注意，事件有效负载中的时间始终以 UTC 提供：对于 tfactl 集合，请将时间调整为 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. 查看位于以下位置的监听程序日志：

        /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

事件名称：

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

事件说明：

数据库实例关闭时将创建 DOWN 事件。当数据库实例因用户操作（例如使用 SQL*Plus (sqlplus) 或 Server Control Utility (srvctl) 命令）或使用这些命令的任何 Oracle Cloud 维护操作（例如执行数据库主目录软件更新）而关闭时，该事件属于 INFORMATION 类型。当数据库实例意外关闭时，事件的类型为 CRITICAL。启动数据库实例时会创建相应的 DOWN_CLEARED 事件。

问题陈述：

数据库实例已关闭。

风险：

数据库实例已关闭，如果集群中的其他节点上有数据库实例可用，这可能会导致性能降低；如果所有节点上的数据库实例都已关闭，则会导致完全停机。

操作/修复：

启动数据库实例以接收 DOWN_CLEARED 事件。

类型为 INFORMATION 的 DOWN 事件：

  1. 如果事件是由 Oracle Cloud 维护操作（例如执行数据库主目录软件更新）引起的，则无需执行任何操作。当影响实例的维护完成时，受影响的数据库实例将自动重新启动。
  2. 如果事件是由用户操作导致的，则在下一个机会启动受影响的数据库实例。

“严重”类型的“向下”事件：

  1. 检查数据库状态并重新启动关闭数据库实例。

    1. 以 oracle 用户身份登录到 VM：

    2. 设置环境：

      [oracle@vm ~] . <dbName>.env

    3. 检查数据库状态：

      [oracle@vm ~] srvctl status database -db <dbName>

    4. 启动数据库实例：

      [oracle@vm ~] srvctl start instance -db <dbName> -instance <instanceName>

  2. 调查数据库实例失败的原因。

    1. 查看数据库的跟踪文件分析器 (TFA) 事件：

      [oracle@vm ~] tfactl events -database <dbName> -instance <instanceName>

    2. 查看位于以下位置的数据库预警日志：

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

运行状况。DB_CLUSTER.CDB.CORRUPTION

事件名称：

运行状况。DB_CLUSTER.CDB.CORRUPTION

事件说明：

在主数据库或备用数据库中检测到数据库损坏。对于指示物理块损坏、逻辑块损坏或丢失写入导致的逻辑块损坏的任何特定错误，将解析数据库 alert.log。

问题陈述：

损坏可能会导致应用程序或数据库错误，在更糟糕的情况下，如果未及时解决，会导致大量数据丢失。

损坏的块是已更改的块，因此它不同于 Oracle Database 期望查找的内容。块损坏可归类为物理或逻辑：

区块腐败也可以分为区块间腐败和区块内腐败：

Oracle 在 alert.log 中检查以下错误：

风险：

当硬件、软件或网络组件导致读取或写入损坏的数据时，会发生数据损坏中断。数据损坏中断的服务级别影响可能有所不同，从应用程序或数据库的一小部分（到单个数据库块）到应用程序或数据库的一大部分（使其基本上不可用）。如果不及时采取补救措施，可能会增加潜在的停机时间和数据丢失。

操作/修复：

当前事件通知当前会触发物理块损坏 (ORA-01578)、写入丢失（ORA-00752、ORA-00753 和 ORA-00600，第一个参数为 3020）和逻辑损坏（通常从 ORA-00600 检测到，第一个参数为 kdsgrp1、kdsgrp1、kclchkblk_3、13013 或 5463）。

我们建议采取以下步骤：

  1. 确认这些损坏已在 alert.log 跟踪文件中报告。使用最新的 EXAchk 报告记录服务请求 (Service Request，SR)，记录包含损坏错误的 alert.log 和跟踪文件的摘录，记录最近应用程序、数据库或软件更改的任何历史记录，以及同一时间段内的任何系统、集群件和数据库日志。对于所有这些情况，TFA 集合应可用且应附加到 SR。
  2. 有关修复建议的更多信息，请参阅用于处理 Oracle Database 损坏问题的主要说明。

对于物理损坏或 ORA-1578 错误，以下说明将很有帮助：

注： RMAN 可用于恢复物理损坏的一个或多个数据块。还使用实时应用的活动数据卫士，将自动修复物理数据损坏的块。

对于主数据库或备用数据库上丢失的写入（带有第一个参数 3020 的 ORA-00752、ORA-00753 和 ORA-00600）导致的逻辑损坏，将在主数据库或备用数据库的重做应用进程中检测到它们。以下说明将很有帮助：

对于逻辑损坏（通常从 ORA-00600 检测到，参数为 kdsgrp1、kclchkblk_3、13013 或 5463）

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

事件名称：

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

事件说明：

如果容器数据库 (Container Database，CDB) 无法归档活动的联机重做日志或无法将活动的联机重做日志快速归档到日志归档目标，则会创建类型为 CRITICAL 的事件。

问题陈述：

由于日志写进程 (LGWR) 无法将日志缓冲区写入联机重做日志，CDB RAC 实例可能会暂时或永久停止。这是因为所有联机日志都需要归档。一旦归档程序 (Archiver，ARC) 可以归档至少一个联机重做日志，LGWR 将能够恢复将日志缓冲区写入联机重做日志，并减轻应用程序的影响。

风险：

如果归档程序临时变得无响应，则应用程序在尝试提交数据库更改时可能会经历短暂的棕色或停滞。如果归档程序未恢复，应用程序进程可能会遇到延长的处理延迟。

操作/修复：

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

事件名称：

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

事件说明：

当容器数据库 (Container Database，CDB) 中的进程或会话变得无响应时，将创建 CRITICAL 类型的事件。

问题陈述：

Blocker Resolver 检测到无响应进程或块，并生成了 ORA-32701 错误消息。此外，如果诊断过程 (DIA0) 检测到关键数据库进程变得无响应，则可能会引发此事件。

风险：

无响应的进程或块可以指示资源、操作系统或与应用程序编码相关的问题。

操作/修复：

调查会话块的原因。

运行状况：DB_CLUSTER.CDB.BACKUP_FAILURE

事件名称：

运行状况：DB_CLUSTER.CDB.BACKUP_FAILURE

事件说明：

如果 v$rman_status 视图中报告了状态为“失败”的 CDB 备份，则会创建类型为 CRITICAL 的事件。

问题陈述：

CDB 的每日增量备份失败。

风险：

备份失败可能会影响使用备份来恢复/恢复数据库的能力。可恢复性点对象 (Recoverability Point Object，RPO) 和可恢复性时间对象 (Recoverability Time Object，RTO) 可能会受到影响。

操作/修复：

查看与事件日期/时间相对应的 RMAN 日志。请注意，事件时间戳 eventTime 为 UTC，根据 VM 时区的需要进行调整。

对于 Oracle 托管备份：

对于通过 RMAN 进行的客户拥有和托管备份：

运行状况：DB_CLUSTER.DISK_GROUP.FREE_SPACE

事件名称：

运行状况：DB_CLUSTER.DISK_GROUP.FREE_SPACE

事件说明：

当 ASM 磁盘组达到 90% 或更高的空间使用率时，将创建类型为 CRITICAL 的事件。当 ASM 磁盘组空间使用量低于 90% 时，将创建类型为 INFORMATION 的事件。

问题陈述：

ASM 磁盘组空间使用率达到或超过 90%。

风险：

ASM 磁盘组空间不足可能会导致数据库创建失败、表空间和数据文件创建失败、自动数据文件扩展名失败或 ASM 重新平衡失败。

操作/修复：

ASM 磁盘组已用空间由连接到 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

可以通过以下方式增加 ASM 磁盘组容量：

  1. 扩展 VM 集群存储以添加更多 ASM 磁盘组容量。有关更多信息，请参见 Scale the DB System 。

可以通过以下方式减少 DATA 磁盘组空间使用：

  1. 从数据库中删除未使用的数据文件和临时文件。有关详细信息，请参阅删除数据文件。

可以通过以下方式减少 RECO 磁盘组空间使用：

  1. 删除不必要的保证还原点。有关更多信息，请参阅使用正常和保证还原点。
  2. 删除已在快速恢复区 (Flash Recovery Area，FRA) 外部备份的归档重做日志或数据库备份。有关详细信息，请参阅维护快速恢复区。