监视器里追踪下列计数器。这些计数器包含在 PhysicalDisk 对象中。
• % Disk Time 所选定的磁盘忙于读取操作或写入操作请求的消耗时间百分比。
• % Disk Read Time 所选定的磁盘忙于服务读取操作请求的消耗时间百分比。
• % Disk Write Time 所选定的磁盘忙于服务写入操作请求的消耗时间百分比。
• Avg. Disk Read Queue Length 在采样时间间隔内，所选定的磁盘等待队列中的读取操作请求的平均数。
• Avg. Disk Write Queue Length 在采样时间间隔内，所选定的磁盘等待队列中的写入操作请求的平均数。
• Avg. Disk Queue Length 在采样时间间隔内，所选定的磁盘等待队列中的读取操作和写入操作请求的平均数。
• Disk I/O Count Per Second 由测量周期内，平均所得的每秒磁盘阵列的 I/O 行为。此计数器无法直接透过效能监视器取得，而必须将其它两个可用的计数器数据相加－ Disk Reads/sec 与 Disk Writes/sec 。
• Disk Space Used 目前由数据库或操作系统使用的磁盘空间数量。此计数器无法透过效能监视器取得，使用磁盘管理员可以获得这个信息。
• Disk Space Available 目前可用的磁盘空间数量。此计数器无法透过效能监视器取得，使用磁盘管理员可以获得这个信息。
要启动磁盘管理员，请按一下开始／程序集／系统管理员（公用）／磁盘管理员。关于磁盘管理员的详细信息，请按一下磁盘管理员的说明按钮。
分析磁盘使用数据
分析磁盘使用信息是一个简单的过程。举例来说，如果我们要分析一个系统，就应收集可用的磁盘空间相关数据，以决定哪些空间是闲置的。图6-7显示了数据库可用空间的情况，并以MB为单位。
图6-7 可用磁盘空间预测分析
正如您所看到的，在分析的最初阶段，每 6.15MB 空间就有 2.05MB 的闲置空间，这代表磁盘使用了约 67% 的空间。到 2000 年 1 月 14 日，闲置空间降为 1.5MB，表示磁盘使用了 75% 的空间。使用 Microsoft Excel 来绘制趋势线，会发现到了 2000 年 2 月 18 日，可用空间仅剩 1.3MB，亦即磁盘使用了约 83% 的空间。这时 DBA 可能就需要购买额外的磁盘了。
网络的容量规划
我们将网络的容量规划放在最后，是因为可能无法从系统内部得到够多的容量规划信息。效能监视器并不提供任何计数器来显示网络效能，因此要规划网络的大小是很困难的。不过，网络常常是系统链中最薄弱的一环，因此应试着谨慎务实地加以评估。
要规划网络的大小，需要知道系统上同时联机的使用者数量，每秒通过系统的讯息有多少，以及这些讯息所带来的每秒平均数据量（以字节来计算）。依照这些信息，可约略地估计出网络容量的最低需求为每秒多少个位。举例来说，目标系统可能传输下列数据量：每分钟有 10 个使用者传输 25 个讯息。这些讯息每个长度为 259 个字节。我们可以算出每分钟总共有 250 个讯息，数据总流量为 64,750 字节，也就是每分钟 518,000 个位，或说每秒 8633.33 位。一个小型的网络即可满足这个工作载量。可使用下列公式来预估网络大小：
网络规模＝（每秒的讯息数量）×（讯息长度）×（每字节的位数）
这个计算可以让求出理想的传输缆线应该有多大（即每秒位数）。
除了监控网络使用状况，我们对网络容量规划所能做的仅此而已。此外，在大多数情况下，会使用已设定完成的网络；除非给定的网络不支持您的系统，否则大概很难有其它的选择。
收集网络使用数据
当进行网络的后期容量规划研究时，应追踪 网络监视器 里的 Bytes/Sec Through Network Interface 效能计数器。这个计数器显示了数据线忙碌的时间百分比。
________________________________________
说明
网络监视器的安装介绍可在Windows 2000 Server的说明 安装网络监器 主题中找到。
________________________________________
分析网络使用数据
要分析网络数据，先计算出前面提到的在线容量（即网络规模），然后检查 Bytes/Sec Through Network Interface 计数器。利用这两个数据，借着下列的公式即可计算网络使用率：
网络使用率＝（（每秒通过网络的字节数）÷（网络规模））×100
图6-8显示了一个网络线性成长的范例，图表中绘制出网络使用率与数据的比较情形。
图6-8 网络使用率预测分析
这个图表指出该特定的网络区段将在 2000 年 9 月 28 日达到最大容量。同样的，所收集的资料点越多，预测就越精准。
选择收集的数据
在后期容量规划中，并没有规定要收集多少计数器数据才是最标准的模式。计数器的选择要看所分析的资料及打算研究的细节深度而定。此外除了我们之前介绍的之外，效能监视器也提供了一些在特定状况下很有用的计数器。此处我们来看一个类似这种状况的例子－收集程序信息。
收集程序数据
当需要为工作载量活动做剖面分析时，程序信息就会很有价值。工作载量剖面分析指的是判断出每个使用者实际执行的工作状况。效能监视器提供了数种不同的计数器，可用来帮我们达成这个目的。这些计数器与 Processor 对象中的计数器相当类似，不过在本案例中它们是用来收集程序数据。可在 Process 中找到这些计数器，包括下列几种：
• % Processor Time 该程序的所有执行绪使用处理器来执行指令所消耗的时间百分比。用于处理特定硬件中断或 trap conditions 的程序代码也包括在内。
• % User Time 该程序的执行绪在使用者模式下执行程序代码所消耗时间的百分比。
• % Privileged Time 该程序的执行绪用在 Privileged 模式下执行程序代码所消耗时间的百分比。
• Page Faults/sec 在该程序中由执行绪执行产生的的分页错误率。
• Elapsed Time 执行程序的总消耗时间（秒）。
分析程序信息
分析这些信息并不像如想象般复杂。举例来说，若我们要分析系统的程序来确定执行的是哪一种工作，可以使用像是 ﹪Processor Time 这个计数器来收集程序的数据。该计数器会指出系统投入某操作的使用情形。图6-9显示了应付帐款部门使用 CalProc 查询的使用者程序成长状况。
这些信息是有用的，因为我们可以预测如果增加了更多的应付帐款部门的使用者，后会发生怎样的状况。在此图表中，趋势线显示了使用率正在持续攀升，并将在 2000 年 2 月 18 日达到 30﹪。假定总共有 10 个应付帐款部门的使用者，我们可以估计每个使用者在二月份占用了 3﹪ 的使用率。然后我们可以推论，如果在二月份增加 3 个使用者，那么对于 CalProce 查询将可达到大约 39﹪ 的使用率。
当决定测量的方式时，确定所要分析的对象是很重要的事，因为这会影响所使用的测量设定。如果进行后期容量研究，请记住，您不会希望这个研究导致任何效能问题─也就是说，如果决定要测量所有的对象，并且设定了较小的测量间隔，就等于是在增加效能问题。测量间隔越小，记录写入磁盘就越频繁，而如果测量了很多计数器，那么记录就会非常庞大。如果效能分析必须要有较小的间隔来捕捉效能问题，可使用多个记录的方式。无论如何，每日写入一笔记录对于容量研究来说就已相当足够。
