二、处理过程

1、在发现节点1异常宕机时立即尝试手工启动数据库，但是在数据库正常启动后马上又会被中断，而且报相同的ora-600错误；错误提示大概的意思是指SMON在做临时段清理时发生了内部错误，最后触发数据库宕机。

2、根据错误提示在Oracle 的在线支持网站上找到了相应的处理方法。通过手工方式清理临时段数据。

1）查询出需要手工清理的临时段数据

2）   执行临时段清理操作

Mark the segment as corrupted:

exec dbms_space_admin.segment_corrupt('BSS_ODS_DATA',112,138958) ;

exec dbms_space_admin.segment_corrupt('BSS_ODS_DATA',126,997454) ;

Drop the segment:

exec dbms_space_admin.segment_drop_corrupt('BSS_ODS_DATA',112,138958);

exec dbms_space_admin.segment_drop_corrupt('BSS_ODS_DATA',126,997454) ;

3）清理第一条临时段数据很快成功，值得注意的是第二个参数应该使用的Relative file number,而不是absolute file number。

4）13点15分左右清理好第二条临时段数据，到13点22分两个节点的数据库正常启动。

三、故障原因分析

1、目前可以确认的是，数据库异常宕机和后面数据库不能正常启动的原因是由于在BSS_ODS_DATA这个生产表空间上存在两条临时段数据，而且SMON进程尝试自动清理失败而导致的。

2、BSS_ODS_DATA表空间上临时段的产生原理，用户在表空间上执行create table/index等DDL命令创建某个表/索引时都将会产生临时段。但是按照Oralce数据库的工作原理无论出现什么情况，SMON进程总是会去自动清理临时段。

3、SMON进程清理临时段触发内部错误和数据库宕机，需要Oracle公司给出官方的解释和预防措施。目前已经向Oracle公司提出SR服务请求，需要等待他们的反馈和回应。

四、附录

相关术语解释：

SMON：

Oracled 数据库SMON(system monitor process)系统监控后台进程，有时候也被叫做system cleanup process，这么叫的原因是它负责完成很多清理(cleanup)任务。

SMON清理临时段(SMON cleanup temporary segments)：

这里的临时段主要指的是永久表空间(permanent tablespace)上的临时段，

永久表空间上同样存在临时段，譬如当我们在某个永久表空间上使用create table/index等DDL命令创建某个表/索引时，服务进程一开始会在指定的永久表空间上分配足够多的区间(Extents)，这些区间在命令结束之前都是临时的(Temporary Extents)，直到表/索引完全建成才将该temporary segment转换为permanent segment。另外当使用drop命令删除某个段时，也会先将该段率先转换为temporary segment，之后再来清理该temporary segment(DROP object converts the segment to temporary and then cleans up the temporary segment)。 常规情况下清理工作遵循谁创建temporary segment，谁负责清理的原则。换句话说，因服务进程rebuild index所产生的temporary segment在rebuild完成后应由服务进程自行负责清理。一旦服务进程在成功清理temporary segment之前就意外终止了，亦或者服务进程在工作过程中遇到了某些ORA-错误导致语句失败，那么SMON都会被要求负责完成temporary segment的清理工作。