平台:SunOS 5.8 Generic_108528-23 sun4u sparc SUNW,Ultra-Enterprise
Vf BU@H} UrP0数据库:8.1.5.0.0
7IG0An f6a"EI0症状:响应缓慢，应用请求已经无法返回
查看redo log 大小及组数，是否合理。
{#M2s$]"x6d8y0r u;nK0登陆数据库,发现redo日志组除current外都处于active状态 
 
   ITPUB个人空间w+`pq+BP^ 
   
 
   如果日志都处于active状态，那么显然DBWR的写已经无法跟上log switch触发的检查点。 
   
 
    
 
     接下来让我们检查一下DBWR的繁忙程度: 
     
 
     ITPUB个人空间 n*F]$_J$Xv0[0~ 
     
 
     DBWR的进程号是2266。
#y^,N%l9w\8c7d([0使用Top命令观察一下: 
     
 
     
 
     5}Qu:y Q~ C0yb0 
     我们注意到，2266号进程消耗的CPU不过0.18%,显然并不繁忙,那么瓶颈就很可能在IO上。
;g%nzU U@FE0使用IOSTAT工具检查IO状况。 
     
 
     ITPUB个人空间GYR1K't;H4GI-Wf\ 
     
 
     我们注意到，存放数据库的主要卷c1t1d0的繁忙程度始终处于99~100,而写速度却只有500K/s左右，这个速度是极为缓慢的。
Ts(h Rn5} On%|0(%b percent of time the disk is busy (transactions in progress)ITPUB个人空间 o;F?o#o ogE*O0Q
Kw/s kilobytes written per second)ITPUB个人空间/j^]:z{(C6p
根据我们的常识T3盘阵通常按Char写速度可以达到10M/s左右，以前测试过一些Tpcc指标，可以参考: 
     Use bonnie to Test system IO speed 
     。ITPUB个人空间'^0w'N!c%G_)k
而正常情况下的数据库随机写通常都在1~2M左右，显然此时的磁盘已经处于不正常状态，经过确认的确是硬盘发生了损坏，Raid5的Group中损坏了一块硬盘。
Bz ["JsSk4T{0经过更换以后系统逐渐恢复正常。 
    
 
   
 
  
 
 
 
 
 
  active 
  log 
  redo 
  oracle 性能调优 
  
 
 
 
 
 
  
0
 
   
  
收藏
 
  
 
 
 
 
 
   上一篇：安装11G R2 RAC的一个问... 
   下一篇：全文检索(oracle text... 
  
 
 
 
 
 
  
 
    noavatar_middle.gif 
  
 
  
 
   gjm008 
   
167篇文章，74W+人气，1粉丝