我有一个HP Proliant BL68C G5服务器，运行Windows Server 2008 R2标准版服务器，用作Oracle 11g数据服务器。
该机器本身具有20GB内存，双Xeon 2.4ghz CPU，Smart Array P400i上的146gb SAS驱动器（Raid 1 + 0）作为操作驱动器，HP Eva FC SANarrays用于Oracle文件。
我检查了FC HBA和SAN控制器的固件更新，确保Windows是最新的，而且我使用的是最新的惠普驱动程序。
但是，Oracle数据库的性能有所下降，一位Oracle顾问看了看Oracle的安装情况，并build议说他们是磁盘子系统的问题。
在一个典型的忙碌会议中，我跑了15分钟，我得到了下面的数字。
％磁盘时间：平均：61最大：15,145
平均。 磁盘读取队列长度：平均：1.043最大值：8.755
平均。 磁盘写入队列长度：平均：1.911最大值：756.456
％处理器时间：平均：2.529最大：23.655
平均。 磁盘秒/读：平均：0.013最大：0.041
平均。 磁盘秒/写入：平均：0.008最大值：0.153
内存可用By：avg：1.0780e + 010最大：1.0796e + 010
从我的理解，平均数字是好的，但最高的数字是非常高的。 我也明白磁盘时间并不是使用SANarrays时最好的数字，但最大队列长度让我担心，这与Oracle所说的磁盘访问速度缓慢有关。
我考虑过networking访问，同期看来最多有75MB的stream量，考虑到networking使用千兆位以太网，这似乎并不是很多。
有没有人遇到过类似的情况，或有任何指示我可以进一步调查。
机器的性能对我来说似乎非常好，但被locking在与甲骨文的战斗中，以certificate他们的软件导致了磁盘问题，而不是SAN本身，这是相当令人沮丧的。
我试图全面地描述我的描述，但是如果有人有任何的build议和需要更多的信息，请不要犹豫，问。
平均。 磁盘秒/读：平均：0.013最大：0.041
平均。 磁盘秒/写入：平均：0.008最大值：0.153
我看到的唯一相关的柜台。 真。 排队lentsh是很难判断。
对于高端市场来说，平均水平和高水平都是很高的。 看起来像IO瓶颈或configuration问题的地方。
机器的性能对我来说似乎非常好，但被locking在与甲骨文的战斗中，以certificate他们的软件导致了磁盘问题，而不是SAN本身，这是相当令人沮丧的。
主要是因为它是SAN。 这是慢的。 对于像我这样的中档DAS系统（Velociraptors，没有SAS光盘），这个数字会太高，对于一个真正的SAN来说，他们确实真的很高。
但最大队列长度让我担心，它与Oracle所说的磁盘访问速度缓慢有关。
现在，这是棘手的事情。 队列长度的解释取决于许多因素，这并非没有必要说的。 756k磁盘队列长度意味着oracle在SAN上转储很多东西，而SAN不回答。 清楚地表明瓶颈。 但是数字是什么意思？
另一方面，秒/写从0.008吨.153秒。 0.153真的很慢。 0.008不是很快开始（假设一个真正的SAN）。
绝对不是Oracle的问题 – 你的光盘子系统是瓶颈。
由于这看起来像一个Windows盒子，您可能会从Perfmon中获得更好的指标。 将平均队列长度与“Average Disk Transfer / sec”结合起来。 这两个应该让你更好地了解你似乎看到的存储瓶颈。 如果在磁盘传输同时激增的情况下队列长度急剧上升，那么这是一个非常明显的迹象，表明您的SAN不能满足需求。
另一件要注意的是性能随时间的推移。 如果这个756平均队列长度已经到位了4秒，那么这是一个单一的爆发，并且比每隔15秒左右看到它接近这些水平更不重要。
无论如何，这听起来像是你已经在推动你的存储极限了。