实例宕机引发的ORA-00240错误

事故第二天进行了数据库的alert log分析，从日志中可以看到数据库在实例NODE2发生宕机后，RAC已经做出了实例切换步骤，但在切换的

1.环境描述

OS：AIX6.1

Oracle ：11.2.0.3.0 RAC

2.事故发生

数据库NODE 2所在小型机发生宕机事故，，本应正常切换至NODE1，但切换失败，重启系统得以解决。

3.事故分析

事故第二天进行了数据库的alert log分析，从日志中可以看到数据库在实例NODE2发生宕机后，RAC已经做出了实例切换步骤，但在切换的过程中遭遇了ORA-00240、ORA-29770错误，导致当时数据库没有切换成功。下面是日志的详细分析。

数据库在当时经历了大致以下几个重要步骤：

1.  Beginning instance recovery of 1 threads

数据库开始在本地恢复宕机的实例

2.  Started redo application at

Thread 2: logseq 4556, block 368380

    数据库开始从在线redo日志序号为4556的日志恢复

3.  Completed instance recovery at

Thread 2: logseq 4556, block 376983, scn 3502123313

    数据库redo日志4556已经恢复成功。

4.  Redo thread 2 internally disabled at seq 4557 (SMON)

当数据库准备恢复4557的日志时，遭遇失败。

5  ORA-00240: control file enqueue held for more than 120 seconds

日志中开始出现ora-00240错误，提示控制文件被持有超过120秒。

6  ORA-29770: global enqueue process DIA0 (OSID 12517556) is hung for more than 300 seconds

Incident details in:

紧接着出现ora29770错误，数据库进程DIA0 hung住超过5分钟。

在当天实例宕机的20分钟左右时间内，当时系统的监控等脚本均无法执行，分析Oracle awr报告得知在当天宕机的时间内，未宕机的NODE1系统CPU资源几乎耗尽。

经过分析与推测，DIA0进程的主要作用是处理数据库死锁、hung住的一个进程，日志中的现象应该是这个进程发现控制文件被持有超过120秒，属于错误行为，进程开始处理这一问题，但当时系统cpu资源耗尽，进程DIA0解决故障超过5分钟，导致出现了ora-29770错误。

所以认定这次实例切换失败的主要原因在于ORA-00240错误。根据日志中给出的trace文件，查看trace文件中的具体报错原因。

自学 PHP、MySQL和Apache

本书将PHP开发与MySQL应用相结合，分别对PHP和MySQL做了深入浅出的分析，不仅介绍PHP和MySQL的一般概念，而且对PHP和MySQL的Web应用做了较全面的阐述，并包括几个经典且实用的例子。 本书是第4版，经过了全面的更新、重写和扩展，包括PHP5.3最新改进的特性（例如，更好的错误和异常处理），MySQL的存储过程和存储引擎，Ajax技术与Web2.0以及Web应用需要注意的安全

400

查看详情

从trace日志中分析得知，当时控制文件被持有超过120秒的主要原因是KSV master wait等待，KSV master wait耗费了2分03秒。

4.事故分析结论

根据以上现象及日志体现，从oracle官方metalink中查找资料得知这是一个bug [BUG ID 1308282.1]

下面是官方metalink文档中关于这个bug的解释：

High 'ksv master wait' And 'ASM File Metadata Operation' Waits In Non-Exadata 11g

Symptoms

High waits for 'ksv master wait' while doing an ASM file metadata operation were reported when a data migration utility was running.  This wait was also seen for a drop of a tablespace.

The AWR showed the top events were CPU (> 100%), with 'ASM file metadata operation' (7%).

Cause

Event 'KSV master wait' indicates the process on the RDBMS side is waiting for a reply from a process on the ASM side.  In 11g, the parameter cell_offload_processing is set to TRUE.  Although that is a parameter is not applicable for non-Exadata databases, it caused ASM to try to deliver smart-scan results.  The issue was reported in Bug 11800170 - ASM IN KSV WAIT AFTER APPLICATION OF 11.2.0.2 GRID PSU.

After applying the workaround for this issue (see Solution below), a drop of a tablespace that used to take 13 minutes took 4 seconds.

Solution

The following solutions are available for non-Exadata databases:

For the quickest solution, use the workaround.  The workaround does not negatively impact non-Exadata databases. This parameter is to be set on the database instance.

alter system set cell_offload_processing = false;

Upgrade to 12.1, when available. OR

Apply the 11.2.0.3 patch set  OR

Apply one-off Patch 11800170, if available for your RDBMS and Grid Homes

Note:  At the time this note was written (March 2011), neither 12.1 nor 11.2.0.3 were available.

官方文档中给出的最快解决方式是修改oracle中的一个参数cell_offload_processing，修改为false。