[Oracle]Redo log日志组故障分析(2)

ZDNet软件频道　时间：2008-09-22　作者：eygle | eygle　我要评论()
本文关键词：数据库 Oracle 日志组 redo log

数据库平台：SunOS 5.8 Generic_108528-23 sun4u sparc SUNW,Ultra-Enterprise 数据库版本：8.1.5.0.0 数据库症状：数据库响应缓慢，应用请求无法返回，业务操作陷于停顿，此时需要DBA介入并进行问题诊断及故障处理。

使用Top命令观察一下该进程的CPU耗用:

Oracle:/Oracle/Oracle8>top
last pid: 21145;  load averages:  3.38,  3.45,  3.67               18:53:38
725 processes: 711 sleeping, 1 running, 10 zombie, 3 on cpu
CPU states: 35.2% idle, 40.1% user,  9.4% kernel, 15.4% iowait,  0.0% swap
Memory: 3072M real, 286M free, 3120M swap in use, 1146M swap free
   PID USERNAME THR PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
 11855 smspf      1  59    0 1355M 1321M cpu/0   19:32 16.52% Oracle
  2264 Oracle     1   0    0 1358M 1316M run    283.3H 16.36% Oracle
 11280 Oracle     1  13    0 1356M 1321M sleep   79.8H  0.77% Oracle
  6957 smspf     15  29   10   63M   14M sleep  107.7H  0.76% java
 17393 smspf      1  30    0 1356M 1322M cpu/1  833:05  0.58% Oracle
 29299 smspf      5  58    0 8688K 5088K sleep   18.5H  0.38% fee_ftp_get
 21043 Oracle     1  43    0 3264K 2056K cpu/9    0:01  0.31% top
 20919 smspf     17  29   10   63M   17M sleep  247:02  0.29% java
 25124 smspf      1  58    0   16M 4688K sleep    0:35  0.25% smif_status_rec
  8086 smspf      5  23    0   21M   13M sleep   41.1H  0.24% fee_file_in
 16009 root       1  35    0 4920K 3160K sleep    0:03  0.21% sshd2
 25126 smspf      1  58    0 1355M 1321M sleep    0:26  0.20% Oracle
  2266 Oracle     1  60    0 1357M 1317M sleep  811:42  0.18% Oracle
 11628 smspf      7  59    0 3440K 2088K sleep    0:39  0.16% sgip_client_ltz
 26257 smspf     82  59    0  447M  178M sleep  533:04  0.15% java

　　我们注意到，2266号进程消耗的CPU不过0.18%,显然并不繁忙,DBWR并不繁忙，但是检查点无法完成，那么我们可以判断，瓶颈就很可能出现在IO上。

　　3. 检查IO状况

　　我们可以使用IOSTAT工具检查系统IO状况：

gqgai:/home/gqgai>iostat -xn 3
                    extended device statistics
    r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
......
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t6d0
    1.8   38.4   32.4  281.0  0.0  0.7    0.0   16.4   0  29 c0t10d0
    1.8   38.4   32.4  281.0  0.0  0.5    0.0   13.5   0  27 c0t11d0
   24.8   61.3 1432.4  880.1  0.0  0.5    0.0    5.4   0  26 c1t1d0
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    9.1   0   0 hurraysms02:vold(pid238)
                    extended device statistics
    r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
........
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t6d0
    0.3    8.3    0.3   47.0  0.0  0.1    0.0    9.2   0   8 c0t10d0
    0.0    8.3    0.0   47.0  0.0  0.1    0.0    8.0   0   7 c0t11d0
   11.7   65.3  197.2  522.2  0.0  1.6    0.0   20.5   0 100 c1t1d0
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 hurraysms02:vold(pid238)
                    extended device statistics
    r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
........
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t6d0
    0.3   13.7    2.7   68.2  0.0  0.2    0.0   10.9   0  12 c0t10d0
    0.0   13.7    0.0   68.2  0.0  0.1    0.0    9.6   0  11 c0t11d0
   11.3   65.3   90.7  522.7  0.0  1.5    0.0   19.5   0  99 c1t1d0
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 hurraysms02:vold(pid238)
                    extended device statistics
    r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
........
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t6d0
    0.0    8.0    0.0   42.7  0.0  0.1    0.0    9.3   0   7 c0t10d0
    0.0    8.0    0.0   42.7  0.0  0.1    0.0    9.1   0   7 c0t11d0
   11.0   65.7  978.7  525.3  0.0  1.4    0.0   17.7   0  99 c1t1d0
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 hurraysms02:vold(pid238)
                    extended device statistics
    r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
........
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t6d0
    0.3   87.7    2.7  433.7  0.0  2.2    0.0   24.9   0  90 c0t10d0
    0.0   88.3    0.0  436.5  0.0  1.8    0.0   19.9   0  81 c0t11d0
   89.0   54.0  725.4  432.0  0.0  2.1    0.0   14.8   0 100 c1t1d0
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 hurraysms02:vold(pid238)

　　在以上输出中，我们注意到，存放数据库的主要卷c1t1d0的繁忙程度始终处于99~100,而写速度却只有500K/s左右，这个速度是极为缓慢的。

　　根据IOSTAT的手册:

(%b percent of time the disk is busy (transactions in progress)
Kw/s kilobytes written per second)

　　根据我们的常识，T3盘阵通常按Char写速度可以达到10M/s左右，以前测试过一些Tpcc指标，可以参考：www.eygle.com/unix/Use.Bonnie.To.Test.IO.speed.htm。

　　而正常情况下的数据库随机写通常都在1~2M左右，显然此时的磁盘已经处于不正常状态，经过确认的确是硬盘发生了损坏，Raid5的Group中损坏了一块硬盘。

　　经过更换以后系统逐渐恢复正常。

我要评论()

我有话要说订阅 RSS 探客网资源发送给朋友

上一篇:网页设计基础:Div+CSS布局入门教程

下一篇:WebLogic Server实现双向SSL

数据库

Oracle

日志组

redo log

最受关注的文章：

最新更新文章：

用户评论

评论列表
本篇文章共有条评论
点击这里查看更多评论>>

用户名

评论内容

发表时间

- 发表评论 -

推荐阅读

视频

微软嵌入式产品总监谈WEC 7的7大

《边看边读》第14期：读《Java加