贴日志一则,以备参考
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引起的,当然不排除应用的影响,虽然很小。取消后,数据库正常了,继续观察中。