ORACLE BUG

贴日志一则，以备参考

2011-06-29

1：错误信息

今天检查济南数据库服务器的时候发现了服务器很卡，用TOP了下，

如下显示：

Tasks: 255 total,  44 running, 209 sleeping,   0 stopped,   2 zombie

Cpu(s): 38.1%us, 61.9%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Mem:   3735552k total,  3725004k used,    10548k free,    76100k buffers

Swap: 81915424k total,    41364k used, 81874060k free,  3049708k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                

21946 oracle    25   0 2140m 199m 197m R 16.9  5.5  59:05.34 oracle                                                                 

 3189 oracle    25   0 2139m  10m 9964 R 16.6  0.3 126:45.65 oracle                                                                 

 3195 oracle    25   0 2154m  43m  40m R 16.6  1.2 128:38.06 oracle                                                                 

21942 oracle    25   0 2140m 182m 180m R 16.6  5.0  60:58.37 oracle                                                                 

31907 oracle    25   0 2139m  14m  13m R 16.6  0.4 124:05.30 oracle                                                                 

 8577 oracle    25   0 2140m 212m 209m R 16.3  5.8  64:55.10 oracle                                                                 

27213 oracle    25   0 2140m 263m 261m R 15.6  7.2  78:32.64 oracle                                                                 

 3233 oracle    25   0 2154m  27m  15m R 14.6  0.7 124:07.92 oracle                                                                 

21944 oracle    25   0 2140m 185m 182m R 13.0  5.1  77:07.27 oracle                                                                 

 8821 oracle    25   0 2149m 796m 789m R 12.6 21.8 128:27.70 oracle                                                                 

 3199 oracle    25   0 2141m 471m 468m R 10.3 12.9 125:53.46 oracle                                                                 

 3239 oracle    25   0 2139m  12m  10m R  9.0  0.3 125:40.45 oracle                                                                 

                                                              

全是ORACLE的进程占据，发现不对劲，再去看ALERT日志中，虽然邮件监控没有出现错误，但是出现了以下的错误信息：

Tue Jun 28 00:00:47 2011

Starting control autobackup

Tue Jun 28 00:00:50 2011

Errors in file /opt/oracle/database/admin/gis/udump/gis_ora_30566.trc:

Tue Jun 28 00:00:50 2011

Errors in file /opt/oracle/database/admin/gis/udump/gis_ora_30566.trc:

Tue Jun 28 00:00:50 2011

Errors in file /opt/oracle/database/admin/gis/udump/gis_ora_30566.trc:

Control autobackup written to DISK device  handle '/opt/oracle/database/flash_recovery_area/GIS/autobackup/2011_06_28/o1_mf_s_754963247_70kb9k1y_.bkp'

 

查看TRC里的内容如下：

[oracle@localhost bdump]$ cat /opt/oracle/database/admin/gis/udump/gis_ora_30566.trc

/opt/oracle/database/admin/gis/udump/gis_ora_30566.trc

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production

With the Partitioning, OLAP and Data Mining options

ORACLE_HOME = /opt/oracle/product/10g

System name:    Linux

Node name:      localhost.localdomain

Release:        2.6.18-194.el5xen

Version:        #1 SMP Tue Mar 16 22:08:06 EDT 2010

Machine:        i686

Instance name: gis

Redo thread mounted by this instance: 1

Oracle process number: 34

Unix process pid: 30566, image: oracle@localhost.localdomain (TNS V1-V3)

*** 2011-06-28 00:00:50.258

*** ACTION NAME:(0000090 STARTED111) 2011-06-28 00:00:50.254

*** MODULE NAME:(backup archivelog) 2011-06-28 00:00:50.254

*** SERVICE NAME:(SYS$USERS) 2011-06-28 00:00:50.254

*** SESSION ID:(137.42394) 2011-06-28 00:00:50.254

2：错误分析

   从错误信息Control autobackup written to DISK device  handle 来看，查了网上的资料，说是RMAN原因是开启了controlfile autoback，所以每次备份或者更改数据库结构时候，都会触发Starting control autobackup，然后连续三个error。想想，的确，之前的数据库一切正常，而我改了RMAN里的自动备份控制文件之后就变这样了，而且到了oracle 进程挂起的地步了，无法进入正常停止数据库，只好重新启动操作系统来执行了。

参考文档：http://hi.baidu.com/edeed/blog/item/f3d4f603109b5d713912bb06.html

3：错误解决

   操作系统REBOOT, 重新启动之后，一切恢复正常，同时取消掉控制文件的自动归档。
RMAN>CONFIGURE CONTROLFILE AUTOBACKUP CLERA;

4: 分析

   1）这个是个BUG，而且这个BUG和操作系统平台有比较大的关系，济南这个库的平台为REDHAT 5.5，而其他设置了控制文件自动备份的几个数据库都没有问题，其他几个平台的操作系统平台为REDHAT 4.5,CENTOS 5.5  现在的平台都是32位的。

   2）其次，网上介绍这个BUG是可以忽略的，我觉得也是的，因为ORACLE在日志里并没有以ORA的错误出现，怀疑是应用引起的，由于当时数据库完全挂起，连接不上数据库，所以无法做分析，从对比的角度来看，的确是这个BUG引起的，当然不排除应用的影响，虽然很小。取消后，数据库正常了，继续观察中。