Microsoft SQL Server 2000 超級管理手冊(六)
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%以下，佇列成長就可維持線性。
不過，有時 CPU 會在高於75%的穩定狀態中使用。這種情況相當不利－尤其是高使用率會造成佇列長度的指數成長。指數成長是幾何的增量成長，如圖6-2所示。
說明
本章中的每個圖形，交易的服務時間假定為0.52秒，並假定每個交易有相同的服務時間。
注意 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 達成率。遵循我們提到的這些原則，就可以讓回應時間最小化，並且讓您的系統總是猶有餘刃，因為您不會在最大使用率下使用處理器與磁碟。系統也將有保留空間以應付尖峰使用期的考驗。
說明
記住一點：要創造出理想的效能，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-5的圖表顯示了同一時期分頁錯誤的增加情形，這種成長幾乎是隨著可用記憶體的減少而逐步攀升。同樣的，使用 Microsoft Excel 可以在這些資料記錄後將其繪製成圖表，鋸齒狀曲線顯示其實際的使用歷史，而直線代表了其使用率的線性趨勢。在本例中，圖表預測到2000年2月18日系統每秒將會有超過6個的分頁錯誤。這個數值表示，到該日期為止，回應時間不僅持續增加，且在該點上回應時間的長度將違反 SLA 的規定。這個預測分析的方法可以有效的追蹤記憶體的資源。
處理器的容量規劃
我們已經分析並規劃了記憶體的大小，接下來該為處理器作容量規劃。在這一點上，我們可以對系統作以下假設：
應用程式和資料庫的設計架構已經完成。固定狀態 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 數量，可對即將成為工作載量的交易，個別的進行下列步驟：
- 使用下列公式計算要透過系統來處理的讀取操作總數量：
讀取操作總數量＝（每個交易的讀取操作數量）×（交易的總數量）
- 使用下列公式確定有多少讀取操作是實體I/O，多少是邏輯I/O：
邏輯讀取操作總數量＝（讀取操作總數量）×（快取命中率）
實體讀取操作總數量＝（讀取操作總數量）－（邏輯讀取操作總數量）
- 使用下列公式將每種類型的讀取操作總數量轉換為每秒的讀取操作數量：
每秒邏輯讀取操作數量＝（邏輯讀取操作總數量）÷（工作週期）
每秒實體讀取操作數量＝（實體讀取操作總數量）÷（工作週期）
工作週期 是一個以秒為單位的時間長度，指的是執行工作所耗費的時間。
- 使用下列公式計算出用於處理讀取操作的CPU時間總量：
邏輯讀取操作時間總量＝（每秒邏輯讀取操作數量）×（邏輯讀取操作時間）
實體讀取操作時間總量＝（每秒實體讀取操作數量）×（實體讀取操作時間）
邏輯讀取操作時間 是處理一個邏輯讀取操作所耗費的時間。 實體讀取操作時間 是處理一個實體讀取操作所耗費的時間。這些讀取操作時間可以利用效能監視器來取得數據。（請參閱本節最後一段 ＜取得讀取操作時間＞ 。）
說明
一般說來，實體讀取操作時間變數為 0.002 秒，邏輯讀取操作時間變數為 0.001秒。
- 使用下列公式計算出不同讀取操作的 CPU 使用率：
使用率＝（流量）×（服務時間）×100
可以將使用率分為邏輯和實體讀取操作使用率：
邏輯讀取操作使用率＝（每秒邏輯讀取操作數量）×（邏輯讀取操作時間）
實體讀取操作使用率＝（每秒實體讀取操作數量）×（實體讀取操作時間）
這些資訊可以用來決定實體讀取操作使用率是否過高。隨後便可藉此調整快取大小，以便獲得更多的邏輯讀取操作。
- 使用下列公式計算要透過系統處理的寫入操作總數量：
寫入操作總數量＝（每個交易的寫入操作數量）×（交易的總數量）× （RAID增加因素）
RAID增加因素指的是在處理階段因為RAID層級而應考慮的變數。
- 使用下列公式計算每秒通過系統的寫入操作數量：
每秒寫入操作數量＝（寫入操作總數量）÷（工作週期）
同樣的， 工作週期 是一個以秒為單位的時間長度，指的是執行工作所耗費的時間。
- 使用下列公式計算出用於處理寫入操作的CPU時間總量：
寫入操作時間總量＝（每秒寫入操作數量）×（CPU寫入操作時間）
- 使用下列公式計算寫入操作使用率：
寫入操作使用率＝（每秒寫入操作數量）×（CPU寫入操作時間）×100
- 使用下列公式計算出交易類型的總CPU使用率：
CPU使用率＝（（邏輯讀取操作使用率）＋（實體讀取操作使用率）＋ （寫入操作使用率））×100
我們必須對系統執行的每種交易類型進行計算。舉例來說，如果負責的是一個金融系統，交易範圍即允許客戶提款、存款或是查詢餘額。最後必須分別對這三種交易類型進行使用率的計算，如此才能正確無誤地規劃系統的 CPU。
- 最後，使用下列公式計算出處理器總和使用率：
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% 的臨界值。
說明
收集的資料點越多，預測就越精準。
磁碟子系統容量規劃
現在我們已規劃了記憶體和處理器的容量，接著開始進行磁碟子系統的容量規劃。關於系統這一部分的容量規劃可以說相當容易，因為我們所需的資料大部分都已計算過了。首先我們需要知道的是，要透過系統來處理的 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 狀況所計算出來的磁碟數量，可能會徹底改變資料庫磁碟數量的建議值。要計算這個數量，請遵循下列步驟：
使用下列公式計算要透過系統來處理的讀取操作總數量：讀取操作總數量＝（每個交易的讀取操作數量）×（交易的總數量）
假設每個交易有 500 個讀取操作，且共有 50,000 個交易，則讀取操作總數量為 25,000,000 個。
使用下列公式確定有多少讀取操作是實體 I/O，多少是邏輯 I/O：邏輯讀取操作總數量＝（讀取操作總數量）×（快取命中率）
實體讀取操作總數量＝（讀取操作總數量）－（邏輯讀取操作總數量）
假設目標快取命中率為 90%，則邏輯讀取操作總數量為 22,500,000，實體讀取操作總數量為 2,500,000。
使用下列公式將實體讀取操作總數量轉換為每秒的讀取操作數量：每秒實體讀取操作數量＝（實體讀取操作總數量）÷（工作週期）
工作週期 是一個以秒為單位的時間長度，指的是執行工作所耗費的時間。
在計算 CPU 容量時也需要這個值。以我們的例子來說，如果工作週期為 8小時，則每秒有 86.8 個實體讀取操作。現在計算要透過系統處理的寫入操作總數量，可使用下列公式：
寫入操作總數量＝（每個交易的寫入操作數量）× （交易的總數量）×（RAID增加因素）
假設使用RAID 5系統而每個交易有10個寫入操作，則寫入操作總數量為（10）×（50,000）×（3）＝1,500,000。
使用下列公式將實體寫入操作總數量轉換為每秒的寫入操作數量：每秒實體寫入操作數量＝（寫入操作總數量）÷（工作週期）
在本例中，實體寫入操作為 1,500,000，工作週期 8小時（28,800秒），則每秒實體寫入操作數量為 52.1。
使用下列公式計算每秒實體 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.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顯示了一個網路線性成長的範例，圖表中繪製出網路使用率與資料的比較情形。
這個圖表指出該特定的網路區段將在 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-1提供了一個計數器清單。為了能進行一個基礎良好的容量規劃研究，您應該收集這些計數器的資料。記住，並不是所有的計數器都位於效能監視器中。可使用工作管理員取得 Available Memory 。 Disk Space Used 和 Disk Space Available 則可以用磁碟管理員來擷取。
Avg. Disk Queue Length
記憶體 Page Faults/secondAvailable Memory
網路區段 Total Bytes Received/second這些設定能為系統效能預測分析提供很好的出發點。其中顯示了要得到關於CPU、磁碟、記憶體和網路的資訊所必須的元素，而不對系統增加額外的壓力，同時也可維護一個較小的資料庫。隨著對此議題研究愈深，可以增加計數器來擴展想得到的資訊。
本章總結
在企業中很少會設有容量規劃師，然而大多數的系統卻都會使用到此項服務。效能問題不一定要透過自己經年累月的試誤經驗來解決。有了本章提供的這些基本知識、正確的資訊以及計算方式，可以很容易地追蹤和預測資源的容量。