数据库服务事件的补救

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

提供了以下补救措施：

• HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE
• AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN
• AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION
• AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN
• AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN
• AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN
• HEALTH.DB_CLUSTER.CDB.CORRUPTION
• HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG
• HEALTH.DB_CLUSTER.CDB.DATABASE_HANG
• HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE
• HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

事件名称

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

事件说明

根据操作系统 df(1) 命令确定的以下文件系统的 VM 来宾文件系统空闲空间低于空闲空间 10% 时，将报告此事件：

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

问题陈述

一个或多个 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 事件。由于用户操作（例如使用服务器控制实用程序 (srvctl) 或侦听器控制 (lsnrctl) 命令）关闭 SCAN 侦听器时，或者使用这些命令的任何 Oracle Cloud 维护操作（例如执行网格基础结构软件更新）时，此事件的类型为 INFORMATION。当 SCAN 监听程序意外关闭时，事件的类型为 CRITICAL。启动 SCAN 监听程序时将创建相应的 DOWN_CLEARED 事件。

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

问题陈述

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

风险

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

操作/修复

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

INFORMATION 类型的 DOWN 事件

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

类型为 CRITICAL 的 DOWN 事件

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 事件。由于用户操作（例如使用 Server Control Utility (srvctl) 或 Listener Control (lsnrctl) 命令）关闭客户端监听程序时，或者使用这些命令的任何 Oracle Cloud 维护操作（例如执行网格基础结构软件更新）时，事件的类型为 INFORMATION。当客户机监听程序意外关闭时，事件的类型为 CRITICAL。启动客户机监听程序时将创建相应的 DOWN_CLEARED 事件。

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

问题陈述

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

风险

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

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

操作/修复

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

INFORMATION 类型的 DOWN 事件

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

类型为 CRITICAL 的 DOWN 事件

1. 检查客户机监听程序状态并重新启动客户机监听程序：
   • 以 opc 用户身份登录到 VM，然后以 sudo 用户身份登录到 grid：

     [opc@vm ~] sudo su - grid

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

     [grid@vm ~] srvctl status listener

   • 启动客户端监听程序：

     [grid@vm ~] srvctl start listener

   • 在任何节点上重新检查客户机监听程序状态：如果客户机监听程序仍处于关闭状态。调查客户机监听程序失败的原因：
     1. 对于日志中指示的 hostName，使用 tfactl 收集 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. 查看以下位置的监听程序日志：

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

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

事件名称

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

事件说明

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

问题陈述

数据库实例已关闭。

风险

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

操作/修复

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

INFORMATION 类型的 DOWN 事件

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

类型为 CRITICAL 的 DOWN 事件

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

HEALTH.DB_CLUSTER.CDB.CORRUPTION

事件名称

HEALTH.DB_CLUSTER.CDB.CORRUPTION

事件说明

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

问题陈述

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

损坏的块是已更改的块，因此与 Oracle Database 期望的块不同。块损坏可以归类为物理损坏或逻辑损坏：

• 在物理块损坏（也称为介质损坏）中，数据库根本无法识别该块；校验和无效或该块包含所有零。一个更复杂的块损坏的例子是块头和页脚不匹配。
• 在逻辑块损坏中，块的内容在物理上是正确的，并通过物理块检查；但是，块在逻辑上可能不一致。逻辑块损坏的示例包括不正确的块类型、不正确的数据或重做块序列号、行片段或索引条目的损坏或数据字典损坏。

块损坏还可以分为块间损坏和块内损坏：

• 在块内损坏中，损坏发生在块本身中，可以是物理块损坏，也可以是逻辑块损坏。
• 在块间损坏中，损坏发生在块之间，并且只能是逻辑块损坏。

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

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

风险

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

操作/修复

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

我们建议执行以下步骤：

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

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

• OERR：ORA-1578 “ORACLE 数据块损坏 ( 文件号 %s, 块号 %s)”主注释（文档 ID 1578.1）
• 如何使用 RMAN 标识数据库中的所有已损坏对象（文档 ID 472231.1）
• 如何标识 ORA-1578 / RMAN / DBVERIFY 报告的损坏对象（文档 ID 819533.1）
• 处理 Oracle Database 损坏问题的主要说明

注意：

RMAN 可用于恢复物理损坏的一个或多个数据块。此外，如果使用活动数据卫士进行实时应用，则会自动对物理数据损坏进行块自动修复。

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

• 处理 Oracle Database 损坏问题的主要说明
• 如果在主数据库或备用数据库上存在备用数据库和写入损坏，请参见 Resolving ORA-00752 or ORA-600 [3020] During Standby Recovery (Doc ID 1265884.1) 。

对于逻辑损坏（通过参数 kdsgrp1、kclchkblk_3、13013 或 5463 从 ORA-00600 检测到典型错误）

• 有关检测到的错误的更多信息，请参见 Primary Note for Handling Oracle Database Corruption Issues 。
• 如果主数据库存在备用数据库和逻辑损坏，请参见 Resolving Logical Block Corruption Errors in a Physical Standby Database (Doc ID 2821699.1) 。

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

事件名称

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

事件说明

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

问题陈述

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

风险

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

操作/修复

• 要确定每个线程/实例的每小时频率，请参见 Script To Find Redolog Switch History and Find Archivelog Size for Each Instances in RAC (Doc ID 2373477.1) 。
  • 如果任何小时存储桶大于 12，请考虑调整联机重做日志的大小。有关调整大小的步骤，请参阅下面的项目 2。
• 如果数据库暂时变得无响应，则归档程序可能无法跟上生成的重做日志。
  • 请查看 alert.log $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log 中的“所有联机日志都需要归档”，短时间内多个事件可以指示 2 个可能的解决方案。
    1. 如果每个线程的重做日志组数小于 4，请考虑添加其他日志组以达到 4，有关添加重做日志步骤，请参见下面的 item1。
    2. 另一种可能的解决方案是调整重做日志的大小，有关调整步骤，请参见下面的项目 2。
• 有关 Data Guard 和非 Data Guard 的大小调整准则，请参见 Configure Online Redo Logs Appropriately 。
• 为每个线程添加一个重做日志组。其他重做日志应等于当前日志大小。
  1. 使用以下查询：

     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. 使用与当前重做日志相同的大小为每个线程添加一个新组。

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

• 通过添加较大的重做日志并删除当前较小的重做日志来调整联机重做日志的大小。
  1. 使用以下查询：

     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. 为当前存在的每个线程 number_of_groups_per_thread 添加相同数量的重做日志。new_redo_size_in_bytes 应基于 Configure Online Redo Logs Appropriately 。

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

     2. 应删除原始较小的重做日志。只有当重做日志的状态为非活动时，才能删除该日志。要确定重做日志的状态，请发出以下选择。

        select group#, thread#, status, bytes from v$log order by bytes, group#, thread#;

        删除原始较小的重做日志：

        alter database drop logfile <group#>;

• 如果数据库变得无响应，则主日志归档目标和备用数据库可能已满。
  • 有关在 RECO 和 DATA 磁盘组中释放空间的更多信息，请参见 HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE 。

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

事件名称

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

事件说明

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

问题陈述

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

风险

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

操作/修复

调查会话块的原因。

• 查看数据库的 TFA 事件，了解与事件日期/时间对应的以下消息模式：ORA-32701、DIA0 Critical Database Process Blocked 或 "DIA0 Critical Database Process As Root "。

  tfactl events -database <dbName> -instance <instanceName>

• 查看在以下位置关联的 alert.log：

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

• 对于 ORA-32701：重载系统可能会导致进度缓慢，这可以解释为块。阻止程序解析程序可能会尝试通过终止最终阻止程序进程来解决该块。
• 对于 DIA0“Critical Database Process（关键数据库进程）”消息：查看指示进程和块原因的相关诊断行。

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

事件名称

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

事件说明

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

问题陈述

CDB 的每日增量 BACKUP 失败。

风险

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

操作/修复

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

对于 Oracle 托管备份：

• 可以在 /opt/oracle/dcs/log/<hostname>/rman 上找到 RMAN 输出。
• 查看日志中是否存在故障：
  • 如果故障是由 RMAN 外部的外部事件引起的，例如备份位置已满或网络问题，请解决外部问题。
  • 对于其他 RMAN 脚本错误，请收集诊断日志并打开服务请求。

    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

• 如果问题暂时存在或已得到解决，则进行新的增量备份。有关更多信息，请参见 Back Up a Database Using the Console。

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

• 查看备份的 RMAN 日志。

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

事件名称

HEALTH.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 磁盘组容量。有关详细信息，请参阅扩展虚拟机数据库系统的存储。

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

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

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

1. 删除不必要的保证还原点。有关更多信息，请参见 Using Normal and Guaranteed Restore Points 。
2. 删除已在快速恢复区 (Flash Recovery Area，FRA) 外部备份的归档重做日志或数据库备份。有关更多信息，请参见 Maintaining the Fast Recovery Area 。

---

标题和版权信息

Copyright ©2022,2025,

Oracle 和/或其关联公司。