应用反应晚上出帐慢，分析一下。

    上午一来，应用反应晚上出帐的时候速度慢了将近一倍。时间大概在1、2点和5、6点左右。因为当时没有做跟踪，已经无法判断具体什么问题，只能根据日志记录做一些分析了。

    首先检查alert日志发现在出现问题的两个时段有很多alter table …… begin backup语句，应该是DSG软件在做数据库备份（因为我不负责备份，所以无法控制。呵呵，自己都很奇怪，dba竟然不需要管数据库备份）。同时，发现两个时段间数据库日志切换频繁。根据这些信息，大概可以简单分析，由于出帐时期写操作频繁，与备份的大量读操作产生冲突，而且当时的归档也会比较频繁会加剧io问题，还可以导致redo日志等待archve的问题（这样就比较危险了）。因为系统没有采用CBO方式，发生执行计划改变的可能性不大。因此只能建议以后在出帐时候不用启动备份（即使是rman）

 

   另外，在日志中发现了坏块信息：

Corrupt block relative dba: 0x2a41bb3f (file 169, block 113471)
Fractured block found during backing up datafile
Data in bad block -
 type: 2 format: 2 rdba: 0x2a41bb3f
 last change scn: 0x0105.291ea52c seq: 0x3c flg: 0x04
 consistency value in tail: 0xb159020a
 check value in block header: 0xeb7d, computed block checksum: 0xce4b
 spare1: 0x0, spare2: 0x0, spare3: 0x0

***
Reread of blocknum=113471, file=/dev/rorcl_index045. found same corrupt data

 

Corrupt block relative dba: 0x4940824f (file 293, block 33359)
Fractured block found during backing up datafile
Data in bad block -
 type: 2 format: 2 rdba: 0x4940824f
 last change scn: 0x0105.289fbc45 seq: 0x1 flg: 0x04
 consistency value in tail: 0x67de022d
 check value in block header: 0x67bd, computed block checksum: 0x817f
 spare1: 0x0, spare2: 0x0, spare3: 0x0

***
Reread of blocknum=33359, file=/dev/rorcl_data202. found valid data

 

还好最后成功读取了，这个问题一般在备份的时候同时有频繁事务的时候会发生，备份读取块的时候发现块断裂（block is fractured）了，也就是说这时候对这个块正在有操作进行，造成一个块的内部前后不一致就会出现这样的信息。当然，系统会自动重读这个块，如果还不成功的话就会假定这个块是坏块了。解决这个问题也很简单，不要在表空间io活动频繁的时候做备份就是了:)