某客户数据库（Oracle 10.2.0.4）没做任何更改的状况下，简直每个周末上午业务频繁呈现卡顿提早景象，通过认真诊断初步断定因为业务量激增导致tuxedo参数达到阈值，5月10日优化tuxedo参数后业务中断景象不在呈现。

一周后卡顿又一次呈现，第一工夫捕捉景象深刻诊断，联合数据库awr性能报告和nbu备份慢的景象，经测试后发现存储读取速率只有原来的四分之一(50-80M/s)性能降落显著，最终定位链路异样导致整个存储性能降落，前台反馈卡顿提早。具体分析过程如下：

联合数据库及操作系统资源应用状况，能够看出故障时间段页游数据库始终处于忙碌状态，从数据库期待事件及性能剖析报告中，顶峰时间段数据库正在进行备份操作，耗费了大量I/O资源，操作系统磁盘使用率也十分之高，cpu呈现了局部I/O期待。

以上种种景象根本能够断定，故障时间段操作系统I/O的响应曾经无奈满足以后数据库需要，导致数据库呈现了重大的I/Owww.pizei.com期待，从而间接影响了NBU备份工夫的缩短。

为了证实这一点，具体查看数据库I/O性能指标，如下：

查看故障时间段数据库I/O性能指标，失常状况下数据库对I/O的响应要求在10ms之内，以后的指标远远超过了该值，联合之前操作系统磁盘使用率靠近100%的时候整个I/O的输入也只有39-80M/S之间，异样显著。

进一步咱们还通过dd及磁盘文件拷贝测试，同样发现磁盘I/O读速率只有50-80M/S原来的四分之一，此时曾经能够判定主机到存储的链路或存储自身存在异样。