6. 容量规划
容量规划的种类
容量规划的历史
交易处理
容量规划的原则
内存的容量规划
处理器的容量规划
磁盘子系统容量规划
网络的容量规划
选择收集的数据
本章总结
容量规划包括计算系统所需资源，以及如何将资源的生产效能最佳化，另外也包括规划网络成长，使新增软硬件时减少对系统执行时的影响，又兼顾成本。在本章中将会学习建立一个系统中这个重要步骤的基本要素。
容量规划的种类
容量规划分为两种形式：前期容量规划（Precapacity planning）和后期容量规划（Postcapacity planning）。前期容量规划可视为规模确定（Sizing）规划，预测在指定时间内完成工作量的硬件需求，符合 服务范围同意书 （Service Level Agreement，简称SLA）中的定义。SLA 设定了执行特定功能所需的时间必须被遵守及维护（完成一个动作或交易所使用的时间）。
________________________________________
说明
SLA 是所有参与系统的组织所一致同意的操作条件，用来确保高效能和平顺的系统操作。举例来说，SLA 可用来确保系统对在确定的时间内响应一项查询。此响应时间是所有使用者、操作小组、应用程序小组和效能小组都同意的时间长度。
________________________________________
另外，容量的某些空间（如分配给 CPU 处理能力的空间、磁盘可用空间或可用内存）被保留下来，以保持这些活动在稳定的操作状态及最大负荷条件下的响应时间。在前期容量规划中，由于系统还没有启用，所以并没有可执行的数据可供规划参考，因此必须参考其它信息，规划的结果也往往取决于所参照信息的正确性。举例来说，设计系统的数据库小组可以提供数据库规划蓝图和初始大小的细节；设计应用程序的应用程序小组，以及和应用程序相关的查询，都可以让我们了解一个查询会如何使用系统资源；管理小组则可以提供同时联机的使用者数目，及透过系统查询的数目。这些信息可以提供一个系统可能的工作负载（可以作为决定 CPU 数量的参考），以及数据库大小（作为决定磁盘数量的参考）等等。
后期容量规划可视为预言分析（predictive analysis），是针对已建置完成并使用中的系统，随时的和复杂的研究其软硬件消耗系统资源的情况。后期容量规划确保在系统的资源足以应付未来工作量的成长。研究的主要目的在于提供数据给数据库管理员（DBA），使 DBA 利用数据判别是否应当调整系统，以符合 SLA 中定义的系统执行效能范围。在这一章中，我们将看看两种容量规划－后期容量规划和前期容量规划，并分析它们的异同。
以典型的后期容量规划而言，可以对储存在数据库中的历史效能数据进行分析。透过分析可以预测 CPU 的使用率（透过观察期间 CPU 繁忙的程度）的正常成长趋势，以及磁盘、内存和网络的使用率。也可以预测当新增使用者时，可能引起 CPU、磁盘和内存使用率的遽增程度。这些研究可以非常详细，并可以了解特定使用者的使用方式，以达成预测因新增使用者所引起系统使用率的遽增程度，达到容量规划的目的。
后期容量规划研究除了预测分析之外，也提供了其它实用的功能，例如可透过假设方式估算工作负载。透过所提供的数据了解不同性质的使用者如何使用资源后，我们可以精确的预估，当增加一个特定性质的使用者（如负责应付帐款管理的人员）至系统工作负载中的时候，会如何消耗系统资源。预测分析可让系统管理者有充裕的时间增添所需的硬设备，以因应新增至系统中的使用者，避免降低系统效能与响应时间。
后期容量规划研究也提供微调信息。微调信息（如关于处理查询时磁盘阵列所需用到磁盘 I/O 的信息）来自历史的执行数据，在想要改善系统效能时，可以用来决定应该如何更改系统设定。此信息能显示某个磁盘阵列的活动明显超过另一个磁盘阵列而造成的效能瓶颈。举例来说，新增使用者将造成数据库数据表被存取的次数增加。使用者存取的数据表数目和存取的频率，都可以被监控和追踪。这项信息帮助预测，变更数据表位置是否能避免磁盘子系统达到瓶颈。
容量规划的历史
在早期多使用者的时代，容量规划和执行效能的概念并没有被广泛的理解和发展。到七十年代早期，容量规划项目仅是简单的找出与目标客户执行应用程序方式相近的客户。寻找这些客户并不容易，而要符合公司或组织使用应用程序的方式则更加困难。
到了七十年代中期，客户和应用程序供货商开发了一种分析方法，以执行特定的基准（benchmark）或工作负载，推算一台机器最佳的初始规模。他们建立了与目标客户的应用程序相类似的软件，并在类似的硬件上执行以搜集效能表现的统计资料。这些统计资料随后便被用来决定最能符合客户需求的机器规模，并且依基准推算当系统状况变更时（如增加更多的使用者、处理更多应用程序等），所需的机器规模大小。这个方法最大的缺点是经费太高，所以这些早期仿真使用者使用模式的分析结果，多半被系统厂商用来拟定营销策略，或是和竞争厂商比较同级产品的执行效能。
在这个阶段，分析师发展不同的分析方法，预测使用者在现有系统中使用的情形。表面上看来，这个过程好像不太有挑战性，其实不然。由于测试的理论法并不存在，也缺乏收集数据的工具，就连计算机科学家，像容量规划之父－DR. Jeffrey Buzen，当时仍然在开发使用的理论和决定计算的方式，因此执行上其实还是很辛苦的。
到了八十年代，先前的基准模拟演进成为标准，例如 ST1 基准、TP1 基准和Debit/Credit 基准，不过寻找基准的重点是依系统的用量，找出最有执行效率的硬设备，而不是开发一个使用的基准，让硬设备来符合这个基准。因此使用者仍然不能利用这些基准找出最适用的硬设备，当然这是因为每个人的使用情况都不尽相同。使用者的要求导致了一个计算机公会的形成，即 Transaction Processing Performance Council。此委员会为超过 45 个硬件和软件制造商指定了标准化的交易负荷。这些基准能显示硬件和数据库软件的相关容量；可惜的是，使用者仍旧无法利用这些信息规划一个应用程序的工作量。
________________________________________
说明
公会所提供的基准无法用于规划容量大小，原因在于这些基准无法反应实际的工作量。它们通常设计来展示效能，例如在规定时间内系统能处理多少个交易，由于这些交易所需的时间往往很短，而且处理的数据量少，因此看起来当然像是可以在短时间内处理很多的交易数量，给人系统的执行很强大的印象，但事实上只是因为执行的是设计过的工作量才产生的现象。
________________________________________
在此同时，主从式计算和关系型数据库技术的使用日趋成熟，预测系统初始大小和容量规划的需求也在成长。现在大多数应用程序是依主从式架构编写，服务器一般用于中央数据储存装置，而使用者接口则在本地端的机器或在远程 Web 网站上执行。这样的使用方式让客户端利用原本就已熟悉的 GUI（图形接口），以最具经济效益的方式，有效的利用昂贵服务器的处理功能。当大量的利用服务器执行数据库应用程序，服务器俨然成为大多数大小与容量规划研究的焦点。
时至今日，应用程序仿真基准仍是确定服务器规模最普遍的方法。收集历史效能数据以供容量规划仍是预测机器未来使用的最佳方式。虽然过程昂贵费时，但如果能准确模拟服务器的使用率，就能获得相当的精确性。然而，由于大型项目可能需要使用者或者厂商动辄数百万美元的投资，通常只有最大的客户才能存取这种系统以进行试验。显然的，现阶段我们需要一种针对小型及一般规模系统的容量规划方法。对于这些系统来说，只要透过简易的计算和一般的系统使用知识，即可达到对系统大小与容量规划 90% 的正确度。
交易处理
在本节中，我们要看一下如何分析数据库服务器的 CPU、内存以及磁盘等等使用趋势，以便对一个给定的应用程序选择适当的服务器。一个数据库服务器执行的仅是数据库的功能；以其工作载量的术语来说，在服务器上完成的仅是交易而已。当 SELECT 或 UPDATE 陈述式执行时，数据库服务器会将这些陈述式解译成一连串的读取与写入操作。事实上，任何交易都是由数据库的读取操作与写入操作来组成。在这个不可部分完成的阶段，数据库服务器处理着这些 I/O 操作。我们所选择的系统，必须能掌握交易的型态与数量，并能处理那些交易产生的 I/O 操作。有两种主要交易型态： 在线交易处理 （Online Transaction Processing，OLTP）与 决策支持系统 （Decision Support System，DSS）。
OLTP 交易
OLTP 交易是一个工作载量单位，由于是以实时的方式或在在线模式中处理数据库，因此通常被预期在很短的时间周期内完成。换句话说，这些交易依实时的信息不断的更新数据库，使下一个使用者所存取的信息皆为实时信息。举例来说，一个在线订购系统，其所有存货状态的信息可能遍布于磁盘系统的各数据表中，（如 Item_Table 或是 Stock_Level_Table 数据表内含有商品类型和存货数量的信息），供在线使用者存取数据。当使用者订购了某商品，就会存取数据表，查询是否该商品还有存货。
针对上述这类交易处理系统规划其容量，一般必须透过访谈来搜集信息。访谈中可能会与数据库设计人员、应用程序设计人员以及业务部门交换意见。他们所提出的意见，有助于预测交易数量，预期每日处理交易的时间（例如，有 25000 次交易要在上班的8小时内完成），同时使用者的数量，以及作业尖峰时段（或说尖峰使用期，也就是处理交易时系统负荷最重的时刻）。访谈可能是确定系统规模大小过程装最重要的部分。
________________________________________
说明
在设计 OLTP 系统时，选择拥有足够交易处理能力的硬件，以容纳尖峰使用期的负载，这样就能自动的应付最坏的状况。
________________________________________
________________________________________
真实世界 自动柜员机
现在来看自动柜员机（ATM）的例子。假设您被一家国际银行雇用来设计其芝加哥分行的 ATM 系统。在访谈中发现 ATM 网络的使用尖峰期是在早上11点到下午2点之间的几个小时内－恰巧是多数人吃午饭的时间。有了这个信息，便能选择具有足够容量的交易处理系统以因应这个尖峰使用期。
________________________________________
DSS交易
交易系统的第二种类型是 DSS。DSS 交易传回的信息相当庞大，且处理的时间比 OLTP 交易更长。一个 DSS 交易可能要花掉数小时甚至数天来处理。DSS 系统的应用范例是存货档案系统：除非有特别的更新，否则数据库并不常有写入的操作。这些系统一般可提供信息供管理部门做出重要的决策，比方说，关于业务成长或手中持股等级的决定。另一个范例为，美国空军利用 DSS 系统提供高层人士相关信息，包括喷射战斗机、轰炸机及人员的武器装备、当前位置与状态。
如之前所提到的，由于 DSS 交易数据量较大，通常需要较长的时间处理，因此和 OLTP 交易所需的时间范围不同。OLTP 交易是以唯一键（例如客户号码）来搜集所需的数据，查询的开始与结束仅与唯一键的信息有关。而在 DSS 中，查询并不是由唯一键开始，相反的，它由数据库数据表的起始处开始，从头到尾查询数据表中所有的数据。一个 DSS 交易也会包含任何数据表连结，连向其它数据表以或得更多信息。
________________________________________
说明
在设计 DSS 系统时，选择较大的数据区块，这样每次 I/O 传递操作能传递较多的记录，减少 I/O 活动。
________________________________________
在这类系统中，效能分析师希望看到 CPU 和其它系统资源的使用率可达到100%，因此我们关心的不是系统正在执行的应用类型，而是系统需要多长的时间来处理查询。设计 DSS 系统的一个经验法则为：尽可能加强硬件配备。换言之，不要仅设计足够的磁盘空间应付数据库的需求，而要规划把数据库配置到多个磁盘区以分散 I/O 活动。内存的问题在此处并不列入考虑，因为这里并没有太多的快取（cache）活动。（DSS 交易包括完整数据表扫描，也就是说数据表的查询是从第一行到最后一行。）
________________________________________
真实世界 当季销售
假设您正在将当季销售数字编辑成公司报告，需要收集组织所在地区中本季的商品销售信息。搜寻方式会首先会连结到 region 数据表的第一行，以得到第一个 customer 数据表。在找到第一个客户名称后，会连结到 customer order 资料表，以确定该客户在当季是否订购了商品。持续搜寻第二个客户名称，接着第三个，以此类推。在搜寻完该地区的客户后，才会到下一个 customer 资料表（按地区区分），继续搜寻程序。所以查询的过程通常需要几个小时才能完成。
________________________________________
容量规划的原则
当无法定义尖峰使用期，可以估计在稳定状态过程中预期的交易活动来完成前期容量规划。
________________________________________
说明
固定状态 指的是在上班时间内预估的 CPU 使用率。举例来说，如果预估上班时间内的 CPU 使用率是55%，那么它就是固定状态。如果在同一天中，系统在某一小时的使用率达到 90%，那就是尖峰使用期。
________________________________________
一旦知道上班时间内预估完成的交易最大数量，以及处理的时间长度，就可以计算每一单位时间里的平均交易数量。不过，由于并不知道交易发生的实际速率，您应在规划系统大小时预设保留空间。 保留空间 （reserve capacity）指的是保留一部份系统处理能力，以应付工作负载较高的时期。
一个订购系统的后期容量规划，应包括持续地监控主要效能计数器，以记录系统过去与现在的执行状况。这些信息通常被储存在数据库中，并利用在效能、容量消耗与保留空间的综合报告中。可利用数据库应用程序（如 Microsoft Excel）产生图形、电子表格以及交易活动报告，藉以预测机器资源的使用信息。
CPU使用率
之所以要在机器上建立保留空间，与 曲线拐点（knee of the curve） 理论有关。简单地说，这个理论的推论是，使用率直接影响队列，而队列长度直接影响响应时间（事实上，队列长度是响应时间公式的一部分），因此使用率直接影响响应时间。当响应时间或队列长度这类因子，由线性成长转变为依指数成长，或是趋于渐进线（到无限远），转变的那一点即称为曲线拐点。
________________________________________
真实世界 超级市场的使用率与响应时间
我们以一个超级市场为范例，看看使用率和响应时间的关系。在这里， 使用率 定义为 使用收银员的频率 ， 服务时间 定义为 收银员拿起商品到算帐结束之间的时段 。假设您在凌晨3点来到超级市场，由于是凌晨时分，我们假设和您一样出来晃荡的人不多，因此收银员的使用率为0%，队列长度（排在您前面的人数）也是0，于是收银员的响应时间将等于服务时间（因为几乎是马上响应）。
想象一下同样的情境发生在下午5点的时候。此时超级市场非常繁忙。结帐时有八个人排在您的前面（也就是说，队列长度是8）。现在的响应时间就等于前面八个人服务时间，将上自己所需服务时间的总和（时间的长短还得由购买物品的数量，付款方式等等因素来决定）。收银员在下午5点时的使用率比凌晨3点要高很多，这种差异也直接影响了队列时间的长短与响应时间。
________________________________________
线性成长 vs. 指数成长
一般说来，我们会试着让系统的运作维持线性关系；也就是说，让队列以线性方式成长。如图6-1所示，线性成长指的是队列成长与使用率成长呈正相关的状态。经验法则告诉我们，只要 CPU 使用率保持在75%以下，队列成长就可维持线性。
图6-1 CPU 使用率的线性成长
不过，有时 CPU 会在高于75%的稳定状态中使用。这种情况相当不利－尤其是高使用率会造成队列长度的指数成长。指数成长是几何的增量成长，如图6-2所示。
________________________________________
说明
本章中的每个图形，交易的服务时间假定为0.52秒，并假定每个交易有相同的服务时间。
________________________________________
图6-2 CPU使用率的指数成长
注意 CPU 使用率达到 75% 的地方，队列长度的曲线由线性成长转变为指数成长（也就是说，曲线几乎变成垂直线）。
响应时间
图6-3显示了使用率如何直接影响响应时间。注意类似的曲线也出现在响应时间图表与队列长度图表。这两个图表显示了响应时间急遽增长的情形，这也就是为什么?不要让稳定状态中的 CPU 使用率超过 75% 的原因。这并不是说绝不可执行 CPU 高于 75%，而是说在此情况下执行的越久，对队列长度与响应时间的负面影响就会越大。不要超过曲线拐点－在本例中，这一点是 75% 使用率－是在规划大小时最重要的原则之一，并且在系统需要多少数量的 CPU 时应详加考虑。举例来说，假设在规划系统大小时，发现在计算所有相关因素之后，处理器使用率将达到 180%。您可以忍受像这样一个慢得可怕的系统，或是利用两个 CPU，让每一处理器的使用率降到 90%－只比曲线拐点高出 15%左右。更好的办法是，使用三个 CPU，这样每个 CPU 的使用率就能降到 60%，低于曲线拐点 15%。
这个原则也适用于系统的其它元素，例如磁盘。磁盘的曲线拐点与处理器并不相同－磁盘使用率趋势线的曲线拐点发生在 85% 左右。不论是磁盘容量的大小或是磁盘的 I/O 量，85% 都是合理的门坎。举例来说，一个 9GB 的磁盘，不论何时都不应该储存超过 7.65GB 的数据。数据储存的限制一方面是为了以后的数据成长着想，但更重要的是，由于一个容量已经被填满的磁盘它的搜寻时间也会变长，限制储存的数据量相对地便可降低响应时间。依照同样的原则，如果磁盘的 I/O 量为每秒70次 I/O 操作，磁盘就不可能在稳定状态的运作中保证每秒有超过 60 次的 I/O 达标率。遵循我们提到的这些原则，就可以让响应时间最小化，并且让您的系统总是犹有余刃，因为您不会在最大使用率下使用处理器与磁盘。系统也将有保留空间以应付尖峰使用期的考验。
图6-3 响应时间 vs. CPU使用率
________________________________________
说明
记住一点：要创造出理想的效能，CPU 使用率就应保持在 75% 以下，磁盘使用率则应保持在 85% 以下。
________________________________________
分页错误（Page Faulting）
在规划处理器与磁盘大小时不超过曲线拐点是最重要的原则，那内存呢？要规划内存大小，我们使用 分页错误 的原则。分页错误是系统用来从磁盘撷取数据的正常功能。如果系统需要某一程序代码或数据分页，而数据分页已存在于内存中，此时会产生一个逻辑 I/O 事件，亦即该程序代码或数据会从内存中被读取，而需要程序代码或数据的交易会被处理掉。
但若需要的程序代码或数据不在内存中呢？在这种情况下，我们就必须执行一个实体 I/O 从磁盘读取需要的分页。这个工作是透过分页错误来完成的。当需要的程序代码或数据分页不存在于主存储器中系统的工作集里，系统会发出一个分页错误中断。分页错误会指示系统的其它部分从实体磁盘中撷取程序代码或数据─换句话说，如果系统正在搜寻的程序代码或数据分页不在内存中，系统会发出分页错误指示系统的其它部分执行一个实体 I/O，并到磁盘中去撷取需要的东西。如果分页位于备用清单并因而存在于主存储器中，或是分页正被其它的程序使用中，就不会出现分页错误来从磁盘撷取分页。
实体 I/O 有两种型态：使用者与系统。 使用者实体I/O 是发生在使用者交易要求读取不存在于内存中的数据时。一份单纯的数据会从磁盘传递至内存中。传递过程通常由一些数据流管理器和磁盘控制器一起处理。 系统实体I/O 则是发生在系统里正在执行的程序需要一个不存在于内存中的程序代码分页时。系统会发出一个分页错误中断，并阻止程序执行直到需要的数据从磁盘撷取回来为止。这两种实体 I/O 状况都会延长响应时间，因为从内存中撷取数据的速率是以为秒（百万分之一秒）来计算，而实体 I/O 的速率却是以毫秒（千分之一秒）来计算。由于分页错误活动会导致实体 I/O，并使响应时间延长，我们要让系统达到更好的效能就必须将分页错误最小化。
系统中会发生三种类型的分页错误：
操作系统分页错误 如果正在执行的操作系统发现下一个程序代码地址不在内存中，系统会发出一个操作系统分页错误中断，从磁盘中撷取下一个程序代码地址。就一个程序代码地址错误而言，程序代码数据从磁盘传递至内存需要一个单一的实体 I/O 操作来完成。
应用程序分页错误 如果系统正在执行任何其它的程序代码而下一个程序代码分页不在内存中，系统会发出一个分页错误中断，从磁盘撷取下一个程序代码分页。就这类分页错误而言，程序代码数据从磁盘传递至内存需要一个单一的实体 I/O 操作来完成。
分页错误交换 当数据分页被修改时（称为 dirty 分页），会使用称为 数据分页交换（page fault swap） 的两步骤分页错误，系统不仅会从磁盘撷取新数据，也会将内存中目前的数据写到磁盘里。此两步骤的分页错误需要两次实体 I/O 来完成，但它会保证所有的数据变更都被保存。如果经常发生这种交换的情形，它就有可能是造成响应时间负面影响最严重的因素。分页错误交换比分页错误需要更多时间，因为它导致两次的实体 I/O。因此，应该让系统中分页错误的数量最小化。
在预估一个新系统的最低内存需求时，最好是找出所有在系统上执行的程序（包括操作系统与数据库引擎）的内存规格，以便预测出足以处理所有工作载量的内存总和。并且不要忘记分页错误这个因素。要维持系统的内存在够用的状态，就应收集分页错误活动的信息并保存起来，作为数据库效能参考信息的一部分。当需要额外的内存时，就应在此项目的数据上进行预测分析。应该为尖峰使用期预留足够的可用内存。规划系统时，除了系统将要执行的程序所需的内存之外，试着保持超过 5% 到 10% 的额外内存以备不时之需。
________________________________________
说明
您无法从系统中移除所有的分页错误，但可以将它最小化。当每秒有超过两个分页错误时，就该增加内存。效能监视器（如每秒分页错误计数器）会在稍后的章节里说明。
________________________________________
内存的容量规划
在规划内存容量时，可能需要某些特定的信息，包括在系统上可能出现的同时使用者数量、交易工作负载类型，当然还包括了使用哪一种操作系统。在规划大小时，可能会典型地从一些访谈开始。在本例中，我们规划的是一个数据库服务器的大小，因此与内存使用率及客户端应用程序使用率相关的信息似乎不会影响我们的预估。
数据库服务器处理来自使用者的需求，需找出必要的信息完成交易。要规划数据库服务器内存的大小，就必须知道同时使用者联机的数量，以及这些使用者产生的交易 I/O 数量。这些 I/O 不是读取操作就是写入操作，您必须与应用程序设计人员讨论，因为他们可以提供不同的交易可能产生的 I/O 数量等相关信息。
当为系统计算适当的内存数量时，也应将其它的影响一并计算，例如快取命中率及分页错误。让我们举一个典型的例子。您正在规划一个系统的大小，该数据库服务器将被用在一个 OLTP 订单登记系统，必须知道产生工作负载的同时使用者数量。这部分的信息可以帮助决定需要多少内存。举例来说，您知道在任何给定的时刻里系统上会有 50 个同时使用者。以此系统而言，您必须为使用者准备至少 25MB 的内存。
________________________________________
说明
一般说来，您需要为每个使用者提供 500KB 的内存，因为 500KB 是 shadow process 所需的内存数。 shadow process 是系统中每一个使用者目前的使用者程序。
________________________________________
接下来，您必须知道采用的操作系统是哪一种。在本例中，操作系统是 Windows 2000，使用大约 20MB 的内存。如此一来，内存总和必须高于 45MB。您也必须知道打算要执行的数据库大小－在本例中，Microsoft SQL Server 使用 5.5MB 的内存。需要的内存现在总共为 50.5MB。
所需信息的最后一部分是数据库处理区域的大小。这个区域考虑两个元素：记录文件区域及数据库快取。记录文件区域保存了正在发生的写入活动的相关信息。这个区域非常重要，因为如果交易处理期间出现了系统故障，记录文件区域中保存的信息将被用于回复「之前」的影像－即故障发生之前的数据库影像。记录文件区域同时也是稽核追踪的参考。
数据库快取是系统中一个特别的区域。系统处理的所有数据都会通过此区域。数据库快取越大，快取命中率就会越高。所谓快取命中率，指的是系统需要的数据恰好可以从内存中找到的机率－显然，您会希望系统的快取命中率越高约好。如果所需的信息并没有驻留在高速缓存中，就会导致一个快取错误。快取错误与分页错误是很类似的，系统必须撷取所需信息并放置在高速缓存里。因此，快取区域太小就会造成实体 I/O 的增加，因为系统必须存取磁盘去撷取不存在于快取的数据。这些实体 I/O 当然会增加交易的响应时间。
要计算快取尺寸，使用下列公式：
快取尺寸＝（快取区块尺寸）×（快取中区块的数量）
快取区块尺寸 指的是每 I/O 传递的数据量。记住 SQL Server 有一个预设的快取区块尺寸 8KB。 快取区块数量 则是指您希望快取要保持多少区块。在 OLTP 中，请选择较小的区块尺寸，因为一来传递量不大，二来区块尺寸越小，传递所需的时间就越少。在 DSS 传递中，区块尺寸就应放大，因为其传递量较大，且较大的区块尺寸能降低 I/O 数。
________________________________________
说明
没有一种快取尺寸设定能保证 90% 或者更大的快取命中率。经验法则是小型的系统应有 25MB 的快取尺寸，中型系统为 70MB，大型系统则为 215MB。对特大型的数据库系统（大约300GB），可能要求高达 3GB 的快取以达到理想的快取命中率。
________________________________________
到目前为止，我们已收集到不少的信息，可以开始来计算我们的最低内存需求。下列公式常被用来计算一个系统的最低内存需求：
最低内存需求＝（系统内存）＋（使用者内存）＋（数据库处理内存）
系统内存 是操作系统与 SQL Server 需要的内存量， 使用者内存 是拨给每个同时使用者 500KB 的内存总和量，而 数据库处理内存 是记录文件与快取所需的内存。
这个简单的公式可用来计算 OLTP 与 DSS 应用程序在一般操作时的最低内存需求。在 DSS 系统中，我们应选择较大的快取区块，因为 DSS 应用程序会以循序性读取的方式执行完整的数据表扫描。这种容量设定允许每个实体 I/O 可以读取更多的数据录。此外在 DSS 系统中，也不应使用快取，因为所有的 I/O 都会是实体 I/O。
在 OLTP 应用程序系统里，您应在系统安装后检查快取命中率。快取命中率越高就越能保证系统可有最佳的响应时间和效能。
________________________________________
说明
系统快取命中率的目标应尽可能接近 100% 且最好不要低于 90%。
________________________________________
收集内存使用数据
当系统大小的规划已完成并调整过后，您应例行性地收集内存使用的效能数据。您可以利用这份数据来帮助您确定所建立的系统是否符合 SLA 的要求，包括响应时间、内存与 CPU 使用率等等。资料收集的工作可以透过 Microsoft Windows NT 环境中的 Microsoft 效能监视器来完成。
________________________________________
说明
在 Microsoft Windows 2000 中 Microsoft 效能监视器被称为系统监视器。
________________________________________
记住这是一个容量规划分析，因此报告时间的间隔应该放大。测量期是以小时为单位（大部分情况都是设定为24小时），所以应每24小时报告一次。就容量规划研究来说，每日记录一次并将其写入效能数据库中已相当足够。您用来监视效能的尺度，称作 计数器 ，应该会按报告时间的间隔来平均。在您的容量规划研究里可选择的内存记数器包含在 Memory 对象中。（在效能监视器中，物件是指计数器的选单。）
________________________________________
说明
要启动效能监视器，按一下 开始 / 程序集 / 系统管理工具 / 效能监视器 。在 效能监视器 窗口中，从 编辑 菜单选择 加入到图表 。您可以利用 加入到图表 对话框选择对象和计数器以进行监测。要得到效能监视器进一步的信息，请在 效能监视器 窗口中按一下 说明 。
________________________________________
有下列的计数器：
• Page Faults/sec 即每秒分页错误数。这个计数器包含了系统中每秒发生的分页错误的平均数。记住，当要求的程序代码或数据分页不在工作中或存在于待命内存里，就会发生一个分页错误。
• Cache Faults/sec 即每秒快取错误数。这个计数器包含了系统中每秒发生的快取错误的平均数。记住，只要 Cache Manager 在实时快取中找不到档案的分页时，就会发生快取错误。
• Pages/sec 即每秒分页数。这个计数器包含了每秒系统从磁盘读取或写向磁盘的平均分页数。这个值是另外两个计数器的总和－Pages Input/sec 与 Pages Output/sec。这个计数器所包括的分页流量代表了系统快取为应用程序存取的档案数据，以及从非快取对应的内存档案中读出和读入的分页。如果您非常关心过度的内存压力（也称为trashing）和可能产生过度的分页动作，则应使用此计数器。
• Available Memory 可用内存。这个计数器表明系统中剩余的未使用内存数量。这些内存可被当作数据库或系统使用的额外内存。可用内存是内存规划中最重要的计数器。
________________________________________
说明
Available Memory 并不是效能监视器的一部分。可以在工作管理员中选择效能标页签，并观察尖峰使用期的可用内存而获得该数据。（要叫出工作管理员，在工作列按一下右键并从快捷菜单中选择 工作管理员 。）
________________________________________
至少该选择 Available Memory 和 Page Faults/sec 作为整个容量规划数据收集的一部分。
分析内存数据
一旦收集了数据，这些信息便可绘制成图表以预测未来的趋势。图6-4中的图表显示了预测分析。在本例中，关于可用内存的数据收集是从1999年10月22日开始至2000年1月14日为止。使用 Microsoft Excel 便可将这些数据绘成图表并计算其趋势线。锯齿状曲线显示出实际使用的历史，直线则代表了使用率的线性趋势。现在可以看到，分析预测显示出在2000年2月18日，系统的可用内存将低于6%。
图6-4 线性内存预测分析
图6-5的图表显示了同一时期分页错误的增加情形，这种成长几乎是随着可用内存的减少而逐步攀升。同样的，使用 Microsoft Excel 可以在这些数据记录后将其绘制成图表，锯齿状曲线显示其实际的使用历史，而直线代表了其使用率的线性趋势。在本例中，图表预测到2000年2月18日系统每秒将会有超过6个的分页错误。这个数值表示，到该日期为止，响应时间不仅持续增加，且在该点上响应时间的长度将违反 SLA 的规定。这个预测分析的方法可以有效的追踪内存的资源。
图6-5 线性分页错误预测分析
处理器的容量规划
我们已经分析并规划了内存的大小，接下来该为处理器作容量规划。在这一点上，我们可以对系统作以下假设：
• 应用程序和数据库的设计架构已经完成。
• 固定状态 CPU 使用率的目标应低于75%。
• 预期的快取命中率至少为 90%。
• 任何磁盘的空间使用率或 I/O 活动率都不超过85%。
• 服务器只执行一个数据库。
• 磁盘 I/O 在所有的磁盘之间平均分配。
我们以利用这些假设来作为规划内存大小的原则与门坎，但就 CPU 的容量预期来说，我们需要更多的信息。这些信息可以从数据库设计人员和应用程序设计人员那里获得。
预期一个数据库服务器的 CPU 容量可能并不如想象的那般复杂。记住一点，数据库只处理交易。应用程序是在客户端的机器上执行，因此在我们的计算公式里用不到有关应用程序大小的数据。服务器只会以读取与写入操作的方式来处理使用者的要求，换言之，它处理的是 I/O。应用程序设计人员可以提供一些信息，让您知道交易可能产生的 I/O 相关问题。数据库设计人员则可以提供与数据表和索引相关的信息，这些对象都与交易息息相关。因此，手头上的工作就是判断出交易会产生多少 I/O，以及要花多少时间才可以完成它们。我们必须知道系统将要处理多少交易，以及系统的工作日或尖峰使用期在定义上到底是多少小时。
显然地，针对尖峰使用期来规划大小是比较好的选择，因为这表示了我们建立的机器足以面对最糟的状况。不幸的是，大部分情况下我们很难取得这类信息，能用的信息往往是与稳定状态相关的数据。要对我们即将处理的交易有更深入的了解，我们就必须去「解剖」交易，或者说建立交易的剖面图，才能有助于我们判断出可能产生的读取与写入（I/O）数量，并藉此计算出预期的 CPU 使用率。我们可以利用与数据库设计人员及应用程序设计人员之间的访谈来获得这些信息。首先我们必须知道要透过系统来处理的交易，其类型和数量的多寡，接着我们必须判断出将会产生的 I/O 数量。这个计算可以帮助我们估算出 CPU 的工作载量。
如果是一个已经存在的系统，使用者可以一次只执行一个交易，利用效能监视器来追踪它并藉此判断出产生的 I/O 数量，进而建立交易的剖面图。这份「真实的」信息可用来对使用中的 CPU 调整其速度、类型和数量。
至此，我们对 CPU 容量规划所讨论的焦点集中在使用者交易所产生的 I/O。不过 I/O 也可能是由使用中的容错设备所产生，当我们规划 CPU 的大小时这些额外的 I/O 也必须考虑进去。
容错
今日大部分的计算机公司是透过对 RAID（Redundant Array of Inexpensive Disks，磁盘阵列）技术的支持来提供容错。在 第5章 我们已对 RAID 技术作了详细的说明。如果读者记忆犹新的话，我们曾提到最常用的 RAID 层级如下：
• RAID 0 单一磁盘
• RAID 1 镜像磁盘
• RAID 5 多重磁盘及数据分割
由于 RAID 0 仅需要一个磁盘，因此它可能会发生单点故障－换言之，如果磁盘故障了，在磁盘上的所有数据都会遗失，也就是整个数据库。图5-9显示了 RAID 0 磁盘阵列。而 RAID 1 提供数据库磁盘的镜像备份。当磁盘故障时，故障磁盘上的所有数据都可从备份数据磁盘上完整的取回。如果采用的是 RAID 1，使用者还可得到额外的好处： 分离搜寻 （在 第5章 讨论过），能让系统在两个磁盘上同时进行搜寻，因而大大提升了搜寻速度，减少了交易响应时间。图5-10显示了 RAID 1 磁盘阵列。
RAID 层级的选择会直接影响磁盘 I/O 的数量，因为不同的 RAID 层级，磁盘写入操作的数量也会不同。举例来说，同样的写入要求在 RAID 0 可能仅需一次写入操作就能完成，但在 RAID 1 上就需要两次。如果使用者描述一个交易需要 50 个读取操作及 10 个写入操作，并且要使用 RAID 1，那么写入操作的数量将增加到 20。
如果采用 RAID 0 时需要两个指定的磁盘才能满足需求，改采 RAID 5 时则需要3个磁盘。在 RAID 5 配置中，使用同位数据带来包含有关其它两个磁盘上数据的信息，藉此可重建故障磁盘上的数据。图5-11显示了 RAID 5 磁盘阵列。这种数据库保护模式会使效能和经济的成本都上扬。RAID 5 中的每个写入操作将为每次处理的交易增加两倍的读取操作和写入操作的数量，这是因为每个交易必须写入到两个磁盘中，并且需要读取同位数据，改变及合并成新的数据，然后重新写入。这种重复的过程将稍微的延长交易的响应时间。
要计算不同 RAID 层级的 I/O数量，可利用下列公式。
对于RAID 0：
I/O数量＝（每个交易的读取数量）＋（每个交易的写入数量）
如果一个交易有50个读写操作和10个写入操作，使用 RAIO 0 的 I/O 数量总和为 60。
对于 RAID 1：
I/O数量＝（每个交易的读取数量）＋（2×（每个交易的写入数量））
如果一个交易有 50 个读写操作和 10 个写入操作，使用 RAIO 1 的 I/O 数量总和为70。
对于 RAID 5：
I/O数量＝3×（每个交易的I/O数量）
如果一个交易有 50 个读取操作和 10 个写入操作，读取操作数量总和为 150，写入操作的数量总和为 30。因此使用 RAIO 5 的 I/O 数量总和将为 180。
I/O 的增加是磁盘控制卡功能的问题，虽然对使用者来说显而易见，但使用者并不需要调整应用程序来解决问题。记住一点，您所选择的 RAID 方案将直接影响处理的 I/O 数量。在我们规划容量的期间，读取与写入操作的增加应列入考虑，因为它会影响 CPU 的使用因素及我们决定采用的磁盘数量。
一旦计算了由使用者交易产生的读取与写入操作的总数量，并加上因所选的RAID 层级而产生的额外的 I/O 数量，接着便可利用这些信息计算 CPU 的使用率。下列公式可用来确定系统该有的 CPU 使用率：
CPU使用率＝（流量）×（服务时间）* 100
此处 流量 是指每秒处理的 I/O 数量，而 服务时间 是处理一个典型 I/O 交易所耗费的时间总量。这个公式意味着使用率是系统每秒处理的 I/O 总数乘以执行每个任务的时间，再乘以 100 将它转换为百分比。
要确定系统所需的 CPU 数量，可对即将成为工作载量的交易，个别的进行下列步骤：
1. 使用下列公式计算要透过系统来处理的读取操作总数量：
读取操作总数量＝（每个交易的读取操作数量）×（交易的总数量）
2. 使用下列公式确定有多少读取操作是实体I/O，多少是逻辑I/O：
逻辑读取操作总数量＝（读取操作总数量）×（快取命中率）
实体读取操作总数量＝（读取操作总数量）－（逻辑读取操作总数量）
3. 使用下列公式将每种类型的读取操作总数量转换为每秒的读取操作数量：
每秒逻辑读取操作数量＝（逻辑读取操作总数量）÷（工作周期）
每秒实体读取操作数量＝（实体读取操作总数量）÷（工作周期）
工作周期 是一个以秒为单位的时间长度，指的是执行工作所耗费的时间。
4. 使用下列公式计算出用于处理读取操作的CPU时间总量：
逻辑读取操作时间总量＝（每秒逻辑读取操作数量）×（逻辑读取操作时间）
实体读取操作时间总量＝（每秒实体读取操作数量）×（实体读取操作时间）
逻辑读取操作时间 是处理一个逻辑读取操作所耗费的时间。 实体读取操作时间 是处理一个实体读取操作所耗费的时间。这些读取操作时间可以利用效能监视器来取得数据。（请参阅本节最后一段 ＜取得读取操作时间＞ 。）
________________________________________
说明
一般说来，实体读取操作时间变量为 0.002 秒，逻辑读取操作时间变量为 0.001秒。
________________________________________
5. 使用下列公式计算出不同读取操作的 CPU 使用率：
使用率＝（流量）×（服务时间）×100
可以将使用率分为逻辑和实体读取操作使用率：
逻辑读取操作使用率＝（每秒逻辑读取操作数量）×（逻辑读取操作时间）
实体读取操作使用率＝（每秒实体读取操作数量）×（实体读取操作时间）
这些信息可以用来决定实体读取操作使用率是否过高。随后便可藉此调整快取大小，以便获得更多的逻辑读取操作。
6. 使用下列公式计算要透过系统处理的写入操作总数量：
7. 写入操作总数量＝（每个交易的写入操作数量）×（交易的总数量）×
（RAID增加因素）
RAID增加因素指的是在处理阶段因为RAID层级而应考虑的变量。
8. 使用下列公式计算每秒通过系统的写入操作数量：
每秒写入操作数量＝（写入操作总数量）÷（工作周期）
同样的， 工作周期 是一个以秒为单位的时间长度，指的是执行工作所耗费的时间。
9. 使用下列公式计算出用于处理写入操作的CPU时间总量：
写入操作时间总量＝（每秒写入操作数量）×（CPU写入操作时间）
10. 使用下列公式计算写入操作使用率：
写入操作使用率＝（每秒写入操作数量）×（CPU写入操作时间）×100
11. 使用下列公式计算出交易类型的总CPU使用率：
12. CPU使用率＝（（逻辑读取操作使用率）＋（实体读取操作使用率）＋
（写入操作使用率））×100
我们必须对系统执行的每种交易类型进行计算。举例来说，如果负责的是一个金融系统，交易范围即允许客户提款、存款或是查询余额。最后必须分别对这三种交易类型进行使用率的计算，如此才能正确无误地规划系统的 CPU。
13. 最后，使用下列公式计算出处理器总和使用率：
CPU总和使用率＝所有交易使用率的总和
如果 CPU 总和使用率超过了 75% 的门坎，就该增加更多的 CPU。根据下列公式，额外的 CPU 将可降低 CPU 总和使用率：
CPU总和使用率（＞1 CPU）＝（CPU总和使用率）÷（CPU数量）
增加足够的 CPU 可以让 CPU 总和使用率低于 75%。举例来说，如果 CPU 总和使用率为 180%，可以使用三个 CPU，让 CPU 总和使用率降为 60%。
________________________________________
说明
您可能想知道为何在每个计算中都没有使用到处理器速度这个因素。事实上，我们的使用方式是间接的。处理器速度包含在服务时间中－处理一个交易花费的时间总量。
________________________________________
________________________________________
取得读取操作时间
透过效能监视器可取得系统的读取操作时间。在MS-DOS窗口中输入下面的指令以启用 Diskperf ：
diskperf -y
接着启动效能监视器。在 Physical Disk 物件中寻找 Avg. Disk sec/Read 和 Avg. Disk sec/Write 计数器。注意，这些计数器提供的是实体读取操作的平均读取操作时间。不要误认这些是逻辑读取操作时间。
________________________________________
收集单一 CPU 的使用数据
当系统开始工作，必须追踪 CPU 的使用状况，就如追踪内存使用状况一样。效能监视器中包含了不少与 CPU 个体使用状况有关的计数器。这些计数器包含在 Processor 对象中。就规划目的来说，下列计数器相当有用：
• % Processor Time 处理器忙于执行指令的占用时间百分比。 指令（instruction） 是计算机中执行的基本单元； 执行绪（thread） 是执行指令的对象； 程序（process） 是程序执行时建立的对象。这个计数器可以解释为完成有用工作所花费的时间。
• % Privileged Time 花在 Privileged 模式下的处理器时间百分比。在Privileged 模式中，将执行 Windows NT service layer、Executive routines 和 Windows NT Kernel；同时在 Privileged 模式中，除图形加速器和打印机之外，还要执行大部分装置的驱动程序。
• % User Time 花在使用者模式的处理器时间百分比。在使用者模式中，将执行所有的应用程序和子系统的程序代码。图形引擎、图形装置驱动程序、打印机装置驱动程序和 Window Manager 也将在使用者模式中执行。在使用者模式中执行的程序代码不会破坏 Windows NT Executive， Kernel 或装置驱动程序的完整性。
• % Interrupt Time 由处理器处理硬件中断所花费的占用时间百分比。中断是在 Privileged 模式中执行，因此中断时间是 % Privileged Time 的一个组件。这个计数器可以帮助确定花费在Privileged模式的过多时间的来源。
• Interrupts/sec 这个计数器包含了每秒处理器所经历的装置中断的平均值。在完成一个任务或需要注意时，装置会发出中断讯号给处理器。可以产生中断的装置包括系统定时器、鼠标、数据通讯联机、网络卡以及其它的外部装置。在中断过程中，一般的执行绪执行将被暂停，而且一个中断可以使处理器切换到另一个具有较高优先等级的执行绪。频率中断是频繁和周期性的，并且中断动作在背景执行。
在进行容量规划研究时，并不需要用到所有的计数器－可依研究的深度来选择计数器。不过，至少应使用 % Processor Time 计数器来收集相关数据。
收集多个 CPU 的使用数据
透过效能监视器可以撷取多重 CPU 的系统平均数据。使用 System 对象下的一些计数器：
• % Total Processor Time 每个处理器的 % Processor Times 总和除以系统中处理器的数量。
• % Total Privileged Time 每个处理器的 % Privileged Times 总和除以系统中处理器的数量。
• % Total User Time 每个处理器的 % User Times 总和除以系统中处理器的数量。
• % Total Interrupt Time 每个处理器的 % Interrupt Times 总和除以系统中处理器的数量。
• Total Interrupts/sec 这个计数器包含了每秒处理器所经历的装置中断的平均数。它指出了系统装置在全部以计算机为基础的范围内繁忙的程度。
分析 CPU 资料
使用这些计数器所取得的数据，可用来预测特定 CPU 的使用率成长情形，因为这种成长可能增加了该 CPU 的响应时间。图6-6显示了 CPU 从 1999 年 10 月 22 日至 2000 年 1 月 14 日的使用状况。注意该 CPU 的使用率持续攀升，到 2000 年 2 月 18 日，它将达到 75% 的临界值。
图6-6 线性 CPU 使用率预测分析
________________________________________
说明
收集的资料点越多，预测就越精准。
________________________________________
磁盘子系统容量规划
现在我们已规划了内存和处理器的容量，接着开始进行磁盘子系统的容量规划。关于系统这一部分的容量规划可以说相当容易，因为我们所需的资料大部分都已计算过了。首先我们需要知道的是，要透过系统来处理的 I/O 总数量。这个信息在处理器容量规划中已经取得，其次我们需要知道的是数据库的大小。数据库设计人员可以提供我们这个信息。当规划磁盘子系统的容量时，了解正在规划的数据库大小与每秒 I/O 数是很重要的，因为这两个因素都有可能让我们需要的磁盘驱动器数量变得相当庞大。
许多人在了解到他们的数据库所需的磁盘数量后会感到相当惊讶。不过，额外的磁盘可以提供更多的资料存取点。如果只有一个数据存取点，那就等于建立了一个瓶颈，一旦所有的交易必须通过这个瓶颈，响应时间就会增加。经验法则是，应尽可能建立更多的数据存取点。如果数据存取点够多，就不会遇到少量磁盘可能造成的瓶颈问题。当然也可能因为产生的每秒 I/O 数太多而需要更多的磁盘来容纳这些 I/O，这个需求说不定比容纳数据库还更迫切。
举例来说，假设有一个 10GB 的数据库系统，每秒产生的 I/O 数为 140。磁盘空间使用率的规则为 85%，因此需要一个 12GB 左右的磁盘来容纳数据库。现在，从 I/O 的观点来检查一下我们的磁盘需求。如果磁盘的速率为每秒 70 次 I/O，磁盘 I/O 容量的规则同样是每磁盘 85%，则我们将需要 3 个磁盘才能容纳这个每秒 I/O 数。因此，一旦 I/O 容量分析产生了最大结果－3个磁盘－我们就应该使用 3 个磁盘（空间总和为我们之前所计算的 12GB），每个磁盘的速率为每秒 70 次I/O。
注意我们所规划的仅是最低需求－视情况而定，可以使用更多高容量的磁盘。也请注意在这个分析中我们并没有将 RAID 组态的因素算进去。
________________________________________
说明
当规划磁盘子系统的大小时，不论是针对数据库大小或是使用者产生的每秒 I/O数，永远使用 85% 这个使用率规则。计算之后应采用数值较大的计算结果来作为磁盘数量的标准。此外，记住 85% 是磁盘使用率的绝对最大值。实际上的使用状况应该要低于 85%。也应记住每秒 I/O 数量过多就会导致瓶颈并因而延长了响应时间。
________________________________________
现在让我们更详细的了解一下如何决定适当的磁盘数量来满足系统的需求，这次我们把 RAID 因素也考虑进去。您需要储存三个主要组件：Windows 2000 与 SQL Server、交易记录文件，以及数据库本身。必须先计算出这三个组件各自所需的磁盘数量，然后把这些数量加起来便可了解系统所需的磁盘总数量。
Windows 2000 与 SQL Server 的磁盘需求
首先必须计算出第一个组件－Windows 2000 Server 操作系统与 SQL Server 数据库所需的磁盘数量。一般说来，我们会希望这部分的磁盘是设定为 RAID 1（镜像磁盘）的独立磁盘区，如此便具有最快的复原可能性。需要多少磁盘也许要看磁盘的大小而定，不过通常 Windows 2000 Server 操作系统与 SQL Server 数据库系统只要一个磁盘就可完全安装。计算公式如下：
操作系统与SQL磁盘＝（Windows 2000 Server与SQL 磁盘）×（RAID 增加因素）
在本例中，RAID 增加因素为2（Windows NT 与 SQL Server 放在一个磁盘上，而 RAID 1 磁盘区须有另一个作为镜像磁盘）。不建议将操作系统磁盘区设定为 RAID 5 或 RAID 0。若要使用 RAID 5，至少必须有两个初始化的磁盘，才能让操作系统与数据库执行能以最快的速度复原。
交易记录文件的磁盘需求
接下来要计算出系统的交易记录文件所需的磁盘数量。这个数量要依交易所产生的每秒最大写入操作数而定。记住这些包含着交易记录文件信息的磁盘是最重要的部分－这些磁盘提供稽核追踪，或说是数据库「之前」的影像，在数据库发生问题时是绝对不可或缺的。稽核追踪可以取消因磁盘故障而中断的交易。写入操作数量在规划处理器容量时已经计算过了。现在我们先随便假设一个数目，例如说在 RAID 0 磁盘区上交易将会产生 1,500,000 个写入操作。若给定的记录文件磁盘使用的是 RAID 1，那么在 8 小时内会有 3,000,000 个写入操作，或说是每秒 104.16 个写入操作。（记住使用 RAID 1 的话，交易每秒写入操作数应为 RAID 0 的两倍。）计算磁盘需求数量的公式如下：
交易记录文件磁盘＝（每秒写入操作数量）÷（磁盘I/O容量）
记住 磁盘I/O容量 应为磁盘最大速率的 85%。此外， 最大磁盘I/O 与 每秒写入操作数量 相除所得的结果应无条件进入以求得整数。最后，要确定 每秒写入操作数量 已将 RAID 层级的增加因素考虑进去。以刚刚的例子来说，如果我们使用的磁盘速率为每秒 70 次 I/O，以最大限额 85% 来计算，则每秒 104.16 个写入操作就应该需要 1.7 个磁盘，无条件进入后，即为 2 个磁盘。
数据库的磁盘需求
最后一个步骤是计算出数据库所需的磁盘数量。记住这个数量的计算要依数据库的大小及每秒 I/O 数两个不同的因素各算一次，得出结果后以较大的数值为准来决定所需的磁盘数量。
依数据库大小来计算所需磁盘数量
要决定需要多少磁盘才能容纳数据库，可利用下列公式：
数据库磁盘＝（数据尺寸）÷（磁盘尺寸）+（RAID 增加因素）
记住 磁盘尺寸 应为磁盘最大空间的 85%。此外，公式中 数据尺寸 与 磁盘尺寸 使用的单位必须一致（例如KB或MB）。 RAID增加因素 指的是需要支持容错功能的额外磁盘。以 RAID 1 来说，这个数值应该等于储存数据库所需的磁盘数量；若使用 RAID 5，则只需要一个额外的磁盘。10GB 的数据库若使用 RAID 5，则我们需要 2 个 12GB 的磁盘。
________________________________________
说明
建议使用 RAID 5 来作为数据库磁盘。
________________________________________
依数据库 I/O 来计算所需磁盘数量
一如我们之前的范例，按照数据库 I/O 状况所计算出来的磁盘数量，可能会彻底改变数据库磁盘数量的建议值。要计算这个数量，请遵循下列步骤：
1. 使用下列公式计算要透过系统来处理的读取操作总数量：
读取操作总数量＝（每个交易的读取操作数量）×（交易的总数量）
假设每个交易有 500 个读取操作，且共有 50,000 个交易，则读取操作总数量为 25,000,000 个。
2. 使用下列公式确定有多少读取操作是实体 I/O，多少是逻辑 I/O：
逻辑读取操作总数量＝（读取操作总数量）×（快取命中率）
实体读取操作总数量＝（读取操作总数量）－（逻辑读取操作总数量）
假设目标快取命中率为 90%，则逻辑读取操作总数量为 22,500,000，实体读取操作总数量为 2,500,000。
3. 使用下列公式将实体读取操作总数量转换为每秒的读取操作数量：
每秒实体读取操作数量＝（实体读取操作总数量）÷（工作周期）
工作周期 是一个以秒为单位的时间长度，指的是执行工作所耗费的时间。
4. 在计算 CPU 容量时也需要这个值。以我们的例子来说，如果工作周期为 8小时，则每秒有 86.8 个实体读取操作。
现在计算要透过系统处理的写入操作总数量，可使用下列公式：
写入操作总数量＝（每个交易的写入操作数量）×
（交易的总数量）×（RAID增加因素）
假设使用RAID 5系统而每个交易有10个写入操作，则写入操作总数量为（10）×（50,000）×（3）＝1,500,000。
5. 使用下列公式将实体写入操作总数量转换为每秒的写入操作数量：
每秒实体写入操作数量＝（写入操作总数量）÷（工作周期）
在本例中，实体写入操作为 1,500,000，工作周期 8小时（28,800秒），则每秒实体写入操作数量为 52.1。
6. 使用下列公式计算每秒实体 I/O 数量：
每秒实体I/O数量＝（每秒实体读取操作数量）＋（每秒实体写入操作数量）
在本例中，每秒有 86.8 个实体读取操作及 52.1 个时实体写入操作，亦即每秒有 138.9 个实体 I/O 操作。使用下列公式计算数据库磁盘总数量：
数据库磁盘＝（每秒实体I/O数量）÷（磁盘I/O容量）＋（RAID增加因素）
记住在决定 磁盘I/O容量 时要使用 85% 规则，且 RAID增加因素 为用来支持容错功能所需的额外磁盘数量。以每秒 138.9 个实体 I/O 数量来说，若磁盘速率为每秒 70 次 I/O，且使用 RAID 5，则我们一共需要 4 个磁盘－3 个用来支持总 I/O 数而另一个为 RAID 5 容错所需磁盘。
因此，若依数据库的大小 10GB 来计算，我们的最低需求是一个磁盘，但若以I/O 活动为计算依据，则我们需要3个磁盘（使用 RAID 5）。结论是，要容纳该数据库，我们就必须准备3个磁盘，亦即这两个结果中最大的数目。
到底系统需要多少磁盘？
要找出系统所需的磁盘总数量，可以将上述三个部分的结果加总求出总和。我们需要 2 个磁盘来安装 Windows 2000 Server 与 SQL Server，2 个磁盘来存放交易记录文件，以及 4 个磁盘来容纳数据库，因此整个系统需要 8 个磁盘才能满足需求。
________________________________________
真实世界预留转圜空间
大部分设计人员会使用我们提到的门坎（75%CPU 使用率、85% 磁盘使用率等等）作为最大使用率的标准。绝大多数的情况中，可能想要使用较小的数值。当然，这个选择不见得都是由设计人员来决定。有许多外部因素会影响设计决定，例如公司的硬件预算。一个良好的系统，最大 CPU 使用率的目标应为 65%，磁盘使用率则为 70%。无论如何，应该就所设计的系统类型去找出最理想的使用比率。
________________________________________
收集磁盘使用数据
一旦系统完成设定并开始执行，就应收集磁盘使用数据，并持续评估是否需要进行必要的变更。系统可能扩展给更多的使用者（并因而有更多的交易）、数据库的需求也有可能改变（结果是数据库变得更大）等等。
当执行磁盘使用率的后期容量规划研究时，应在效能监视器里追踪下列计数器。这些计数器包含在 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﹪ 的使用率。
当决定测量的方式时，确定所要分析的对象是很重要的事，因为这会影响所使用的测量设定。如果进行后期容量研究，请记住，您不会希望这个研究导致任何效能问题─也就是说，如果决定要测量所有的对象，并且设定了较小的测量间隔，就等于是在增加效能问题。测量间隔越小，记录写入磁盘就越频繁，而如果测量了很多计数器，那么记录就会非常庞大。如果效能分析必须要有较小的间隔来捕捉效能问题，可使用多个记录的方式。无论如何，每日写入一笔记录对于容量研究来说就已相当足够。
图6-9 使用者程序预测分析
表6-1提供了一个计数器清单。为了能进行一个基础良好的容量规划研究，您应该收集这些计数器的资料。记住，并不是所有的计数器都位于效能监视器中。可使用工作管理员取得 Available Memory 。 Disk Space Used 和 Disk Space Available 则可以用磁盘管理员来撷取。
表6-1 效能监视器中可用的计数器
物件 计数器
处理器 % Processor Time (个别CPU的统计)
系统 % Total Processor Time (所有CPU的平均数)
实体磁盘 % Disk Time (对于所有的磁盘阵列设定)
Avg. Disk Queue Length
内存 Page Faults/second
Available Memory
网络区段 Total Bytes Received/second
这些设定能为系统效能预测分析提供很好的出发点。其中显示了要得到关于CPU、磁盘、内存和网络的信息所必须的元素，而不对系统增加额外的压力，同时也可维护一个较小的数据库。随着对此议题研究愈深，可以增加计数器来扩展想得到的信息。
本章总结
在企业中很少会设有容量规划师，然而大多数的系统却都会使用到此项服务。效能问题不一定要透过自己经年累月的试误经验来解决。有了本章提供的这些基本知识、正确的信息以及计算方式，可以很容易地追踪和预测资源的容量。
