某客户数据库（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 原来的四分之一，此时曾经能够判定主机到存储的链路或存储自身存在异样。