数据库平台:SunOS 5.8 Generic_108528-23 sun4u sparc SUNW,Ultra-Enterprise
数据库版本:8.1.5.0.0
数据库症状:数据库响应缓慢,应用请求无法返回,业务操作陷于停顿,此时需要DBA介入并进行问题诊断及故障处理。
1. 登录数据库进行检查
首先我们登录数据库,检查故障现象。
经过检查发现,数据块的所有重做日志组除current外都处于active状态:
经过检查发现,数据块的所有重做日志组除current外都处于active状态:
oracle:/oracle/oracle8>sqlplus "/ as sysdba" |
如果数据库异常繁忙,或者DBWR的写出过慢,就可能出现检查点未完成,Oracle却已经用完所有日志文件的情况。在这种情况下,数据库的日志无法生成,整个数据库将处于停顿状态,此时日志文件中会记录类似如下信息:
Mon Jan 23 16:11:39 2006Thread 1 cannot allocate new log, sequence 5871Checkpoint not complete Current log# 2 seq# 5870 mem# 0: +ORADG/danaly/onlinelog/group_2.260.600173851 Current log# 2 seq# 5870 mem# 1: +ORADG/danaly/onlinelog/group_2.261.600173853 |
2. 检查DBWR进程
在本案例中,所有日志组都处于active状态,那么显然DBWR的写出存在问题。
接下来让我们检查一下DBWR的繁忙程度:
SQL> ! |
DBWR的进程号是2266。
使用Top命令观察一下该进程的CPU耗用:
使用Top命令观察一下该进程的CPU耗用:
oracle:/oracle/oracle8>top |
我们注意到,2266号进程消耗的CPU不过0.18%,显然并不繁忙,DBWR并不繁忙,但是检查点无法完成,那么我们可以判断,瓶颈就很可能出现在IO上。
3. 检查IO状况
我们可以使用IOSTAT工具检查系统IO状况:
gqgai:/home/gqgai>iostat -xn 3 |
在以上输出中,我们注意到,存放数据库的主要卷c1t1d0的繁忙程度始终处于99~100,而写速度却只有500K/s左右,这个速度是极为缓慢的。
根据IOSTAT的手册:
(%b percent of time the disk is busy (transactions in progress) |
根据我们的常识,T3盘阵通常按Char写速度可以达到10M/s左右,以前测试过一些Tpcc指标,可以参考:www.eygle.com/unix/Use.Bonnie.To.Test.IO.speed.htm。
而正常情况下的数据库随机写通常都在1~2M左右,显然此时的磁盘已经处于不正常状态,经过确认的确是硬盘发生了损坏,Raid5的Group中损坏了一块硬盘。
经过更换以后系统逐渐恢复正常。