• 沒有找到結果。

設計資料庫伺服器基礎架構

N/A
N/A
Protected

Academic year: 2022

Share "設計資料庫伺服器基礎架構"

Copied!
23
0
0

加載中.... (立即查看全文)

全文

(1)

設計資料庫伺服器基礎架構

部署資料庫伺服器以前,你應該盡量收集關於資料庫伺服器環境的相關資 訊,包括部署資料庫的商業與技術需求,以及資料庫本身的工作負載。彙 整這些資訊後,你可以開始評估資料庫系統需要的硬體與軟體。

本章考試目標

■ 設計資料庫容量需求

o

分析儲存需求

o

分析網路需求

o

分析CPU需求

o

分析目前的組態

o

分析記憶體需求

o

預估成長需求並合併至容量需求

■ 選擇軟體版本與硬體組態

o

選擇作業系統的種類與版本

o

選擇SQL Server 2005的版本

o

選擇CPU種類

o

選擇記憶體選項

o

選擇儲存方式

■ 設計實體儲存方式

o

設計交易記錄檔的儲存方式

o

決定作業系統的安裝位置

o

決定SQL Server服務執行檔的存放位置

o

指定每個資料庫的檔案數量與存放位置

(2)

課程內容:

■ 課程 1:規劃資料庫大小 ...3

■ 課程 2:設計處理器子系統的規模 ...20

■ 課程 3:設計磁碟子系統的大小 ...28

■ 課程 4:評估記憶體需求 ...41

■ 課程 5:選擇Windows與SQL Server版本 ...47

課前準備

為完成本章所有課程,你必須:

■ 將Microsoft SQL Server 2005安裝在名為DBSRV1的電腦。

■ 可以從Microsoft SQL Server Management Studio(SSMS)連接至 SQL Server 2005執行個體。

■ 安裝AdventureWorks資料庫。

(3)

課程1 | 規劃資料庫大小

設計資料庫大小是為了讓資料庫滿足商業需求,這也是容量規劃的其中一 部份。本課程將介紹規劃資料庫伺服器大小的重要觀念與程序。

學習本課程之後,你將能夠:

定義容量規劃(capacity planning)的意義。

瞭解如何規劃資料庫的大小。

描述規劃資料庫伺服器大小的方法。

課程預估學習時間:40分鐘

什麼是容量規劃

容量規劃的意義是針對未來的硬體需要進行預測與準備的過程,包括:測量 現有硬體設備上Web伺服器、應用程式或資料庫伺服器的延展性,預測何 時需要增加新的硬體設備,以及設計未來需要執行關鍵應用程式的硬體系 統。針對資料庫伺服器的容量規劃除了涵蓋上述幾點,還包括評估資料庫 應用程式的效能需求以及分析資料趨勢,以滿足未來的效能需求。

容量規劃可以分為兩種主要項目:容量規劃前置組態(規劃資料庫大小)

與容量規劃後置組態。前置組態包含準備適當的硬體設備,以便處理符合 服務層級協定(service level agreement,SLA)的工作負載。後置組態包含 針對硬體設備執行效能研究、分析資料趨勢、繪製成長曲線,以及預測何 時需要升級或置換現有硬體設備。

舉辦容量規劃會議

評估資料庫伺服器的硬體需求以前,你應該事先與相關人員進行面談,確 定容量規劃的方向。

技術環境

規劃資料庫大小最重要的步驟就是收集資料庫工作負載與環境資訊。只有 少數公司可以在測試伺服器的工作負載後即可取得預算。針對大多數公

(4)

司,必須評估各項重要資訊才能精確規劃資料庫的大小,和各部門的專家 面談後可以取得各些資訊。

與技術專家面談時必須彙整的資訊包含:目前伺服器的資料歷史基準線、

資料庫應用程式產生的磁碟讀寫數目、資料庫使用率增減情況,以及資料 庫整體儲存需求(包括tempdb資料庫、索引、文字檔與備份檔案的儲存空 間)。

商業需求

容量規劃的執行者必須與管理階層面談,除了決定容量規劃的目標與期 望,也要找出可以用在容量規劃的重要資訊。這些資訊包括顧客需求、運 作需求、預算限制、員工成長率,以及新硬體設備的評估週期。

技術需求

容量規劃的技術需求可以在與技術專家與管理階層面談時獲得。例如,與 營運經理面談後,你可以瞭解公司的商業運作要求資料庫的回應時間不可 以超過5秒。根據這些主管的要求,任何新購買的硬體設備必須滿足營運需 求至少三年,從系統上線那一天算起。

應用程式與查詢調校

如果可以,你應該先調校資料庫應用程式碼與查詢指令,做為規劃資料庫 伺服器大小的準備。畢竟資料庫應用程式的效率是決定資料庫執行效能最 重要的因素。

應用程式調校包括:確認應用程式是否適當開啟與關閉連線,甚至重複使 用資料庫連線;是否以OLEDB函式庫或 .NET Framework與SQL Server互 相通訊;針對以伺服器為基礎的應用程式,是否發揮連線共享(connection pooling)的優點。

查詢調校包括:確認游標、暫時資料表與資料表變數並未濫用;SQL查詢 並未傳回應用程式不需要的資料欄或是使用者不需要的資料;確認資料交 易盡可能簡短。

(5)

收集效能資料與基準線

假如你有一台伺服器準備升級,進行容量規劃會比較簡單。此時你可以監 控目前系統來收集容量規劃的重要資訊,例如:每秒交易量、分頁錯誤

(Page/sec)以及磁碟使用率(% Disk Time)。

收集效能資料的第一步是決定要監控哪些效能計數器。表1-1列出與容量規 劃有關的計數器與說明事項。

計數器 說明

Processor:% Processor Time 平均應低於75%(最好低於50%)

System: Processor Queue Length 每個處理器平均應低於2。在2個處理器 的環境,應該低於4。

Memory—Pages/sec 平均應低於20(最好低於15)

Memory—Available Bytes 應該維持在50 MB以上 Physical Disk—% Disk Time 平均應低於50%

Physical Disk—Avg. Disk Queue Length

每個磁碟平均應低於2。如果是5個磁碟 的陣列,此計數器平均應該低於10。

Physical Disk—Avg. Disk Reads/sec 用來評估磁碟大小與CPU速度。應該低 於磁碟容量的85%。

Physical Disk—Avg. Disk Writes/ sec 用來評估磁碟大小與CPU速度。應該低 於磁碟容量的85%。

Network Interface—Bytes Total/sec 用來評估網路頻寬大小。

SQL Server: Buffer Manager— Buffer Cache Hit Ratio

應該超過90%(理想值是接近99%)

SQL Server: Buffer Manager—Page Life Expectancy

用來評估記憶體大小,應該維持在300 秒以上。

SQL Server: General Statistics— User Connections

用來評估記憶體大小。

SQL Server: Databases—

Transactions/sec

用來評估交易量多寡與CPU速度。

SQL Server: Databases—Data File(s) Size KB

用來評估資料檔大小。

表1-1:SQL Server容量規劃所使用的計數器

(6)

計數器 說明 SQL Server: Databases—Percent Log Used

用來評估交易記錄檔大小。

表1-1:SQL Server容量規劃所使用的計數器(續)

NOTE∣效能基準與使用率的波動

請注意伺服器的使用率在每週(月、季、年)的第一天與最後一天可能有相當大的波動。

Quick Check

1. CPU使用率應該低於百分之多少?

2. Avg. Disk Queue Length應該低於多少?

3. Pages/sec應該低於多少?

Quick Check∣解答

1. 75%(CPU使用率是由% Processor Time測量)

2. 每個磁碟應該低於2 3. 20

效能基準是在一段時間內測量的系統效能表現,例如每天交易量最高的10分 鐘,或是午夜管理工作期間的20分鐘。對比於效能標竿(benchmark)或其 他效能測量方式,效能基準是顯示伺服器子系統的實際表現,以及正式運 作環境內會影響效能的重要因素。

首先,你應該收集伺服器的效能基準以建立使用樣版,並瞭解每天、每個 月與每年中尖峰時間的伺服器使用情況。確認這些尖峰時間的使用率相當 重要,它們有助於規劃可以滿足未來最高處理量的硬體需求。往後至少每 三個月或是在系統變更時收集一次新的效能基準。

為了分析Windows系統監視器收集的資料,你可以將儲存的資料匯出至 Microsoft Excel檔案。此動作會產生類似圖1-1的表格。

(7)

圖1-1:匯出至Excel檔案的效能基準資料

預測資料趨勢

預測資料成長趨勢是容量規劃的一種重要技巧,因為它有助於預測或建議 未來的硬體設備。舉例來說,如果知道目前的資料成長率,容量規劃便可 以判斷目前滿足商業需求的硬體容量何時會不敷使用,或是滿足未來商業 需求的硬體設備可以維持多久。

要想預測資料趨勢,請利用已儲存的效能資料建立一份Excel折線圖,再利 用加上趨勢線指令繪製資料趨勢線,結果應類似圖1-2。

70.00%

60.00%

50.00%

40.00%

30.00%

20.00%

10.00%

0.00%

Percent Utilization

Average CPU Utilization

Date

1/1/2006 2/1/2006 3/1/2006 4/1/2006 5/1/2006 6/1/2006 7/1/2006 8/1/2006 9/1/2006 10/1/2006 11/1/2006

圖1-2:CPU效能表現與趨勢線

(8)

除了利用系統監視器收集的統計資料,也可以經由會議或其他地方獲得系 統效能的成長率。例如,你也許和技術人員面談後知道每年的資料庫會成 長40 GB,或是和管理階層開會後發現,每個月資料庫使用者會成長5%。

如欲使用這類資訊來預測資料成長情況,你應該先瞭解資料成長情況分為 幾種。

線性成長

線性成長 (Linear growth)是在每個時間間隔呈現穩定的成長,例如資料庫 一年成長200 GB,或是每年的資料庫交易成長率為每分鐘10個交易。利用線 性成長預測未來資料增加量較為簡單,只要將成長率乘以時間間隔數量。

此方法可以利用下列公式表示:

未來資料量 = 目前資料量 + (成長率x時間間隔數量)

舉例來說,目前資料庫每分鐘有40個交易,每年每分鐘會增加10個交易。

你可以利用下列方式計算出三年後每分鐘資料庫交易量為何:

三年後資料庫交易量=40+(10x3)

三年後資料庫交易量 = 40 + (10 x 3) = 70(每分鐘交易量)

圖1-3顯示每個月線性成長10 MB的儲存空間需求量。

NOTE

∣預測成長率

Excel是可以繪製效能預測結果的工具之一。業界有許多第三廠商提供的軟體工具也可 以藉由效能資料判斷資料成長率。

(9)

圖1-3 :線性成長關係圖

幾何成長

幾何成長(geometric growth)又稱為複數成長(compound growth),它 是在每個時間間隔以穩定比例成長,例如資料庫每個成長2%。如果要以線 性成長預測未來的資料量,可利用下列公式:

未來資料量 = 目前資料量 × (1 + 成長率) 時間間隔數量

利用上述計算公式時,請將成長率轉換成小數資料。舉例來說,如果目前 的資料庫為600 GB,成長率為每個月2%。要計算三年後資料庫大小的方式 為

三年後資料庫大小 = 600 × (1 + .02)36

= 600 (1.02)36

= 600 (2.04)

= 1224 GB

圖1-4顯示每個月幾何成長10%的儲存空間需求量。

J F M A M J J A S O N D

Disk Usage (MB)

150

100

50

Time

Growth = 10 MB / month

(10)

圖1-4 :幾何成長或複數成長關係圖

規劃伺服器規模的方法

規劃伺服器規模的方法取決於許多因素,例如財務資源的多寡、資料庫應 用程式的狀態,以及你打算配置的歷史效能資料量。

下列幾節將介紹如何經由負載測試與工作負載分析來規劃伺服器規模。通 常在設計資料庫伺服器時不會只選擇單一方法,而會結合多種不同的方 法,甚至某些經驗法則。

J F M A M J J A S O N D

Disk Usage (MB)

150

100

50

Time Growth = 10% / month

Exam Tip

針對70-443考試,你只需要瞭解規劃伺服器規模大小的基本觀念即可。

負載測試

負載測試(load testing)是最精確但也是最昂貴的伺服器硬體規模規劃方 式,它會逐漸增加應用程式的工作負載(或是其模擬環境),藉此測試伺 服器的效能表現。通常我們會模擬使用者人數增加,或是提高同時間交易 請求數量。在伺服器處理這些工作負載時,你可以測量伺服器的各種效能 結果。所蒐集的統計資料將有助於設計伺服器硬體設備。

(11)

在負載測試中最重要的資料為「效能曲線的轉折點」(knee in performance curve),它發生在執行效能突然降低到無法接受的情況。

CAUTION

∣設計負載測試

執行負載測試時,應確定測試環境的工作負載及資料交易量與正式伺服器完全相同。

增加工作負載時,單純執行一或兩個隨機選取的預存程序並不同精確測量伺服器的實 際效能表現。

如圖1-5所示,負載測試的結果是一份效能曲線,顯示資料庫伺服器在使用 者人數增加時回應時間如何變長。每個資料庫都會有自己的效能曲線,但 是該曲線的通用樣版應該會維持相同。有一點必須注意:效能低落不一定 緩慢發生。最初當使用者人數增加時,伺服器仍可以負荷 — 此為最佳效能 範圍,結束位置是最高效率點(在不影響伺服器效能的前提下,可以承受 的最多使用者數量)。在圖1-5中,最高效率點發生在100個使用者同時上 線。在正式環境中,資料庫伺服器應該執行於最佳效能的範圍,盡可能不 要超過最高效率點。

NOTE∣效能臨界值

某些子系統的監控標準與「效能曲線轉折點」有關,例如CPU使用率為75%,磁碟使 用率為85%。 關於SQL Server效能瓶頸更直接的觀察方式為:如果Batch Requests/

sec(位於SQL Server:SQL Statistics物件)往上到達某個水平位置,或是升高後趨於平 穩,通常就是遇到效能瓶頸。

(12)

圖1-5:效能曲線

在最高效率點以後如果持續增加使用者,效能通常會開始滑落 — 此區域稱 為壓力區(stress climb),在此範圍代表你應該調校、升級甚至考慮置換 正式伺服器。接下來,經過效能轉折點之後,執行效能將會衰退的相當嚴 重,系統也會變得不穩定。針對圖1-5效能曲線所對應的資料庫,效能轉折 點位於175個使用者同時上線。換言之,175個使用者就是此資料庫伺服器 能夠承受的使用者人數上限。

除了幫助你決定效能曲線的轉折點,負載測試還可以確保未來某段時間內 硬體設備可以滿足SLA的要求。例如,SLA規定CPU使用率必須低於75%,

你應該在伺服器內加入更多CPU,以期在三年內CPU使用率不會超過75%。

雖然利用負載方法來規劃伺服器規模大小擁有明顯的優點,但是此方法對 於許多公司來說,成本仍然太高。預算不高的公司如果想進行容量規劃的 前置準備,可以考慮工作負載分析。

1 10 25 50 75 100 125 150 175 200

Application Response Time (sec.)

15

10

5

Number of Users Maximum efficency

Stress climb

Performance knee

NOTE∣微軟技術中心

如果你希望執行負載測試,但是缺乏足夠的資源,可以向微軟技術中心尋求協助(www.

microsoft.com/services/microsoftservices/srv_tech.mspx)。透過這項服務,技術專家會 以各種組態測試你的應用程式,並協助你設計符合需求的資料庫伺服器。

(13)

工作負載分析

利用工作負載分析(workload analysis)來規劃伺服器規模大小是一個複雜 過程,通常會外包給其他公司或由內部技術專家搭配特殊軟體進行。使用這 種方式的關鍵在於決定或評估下列與資料庫應用程式工作負載有關的參數:

■ 資料處理量

■ CPU使用率

■ 同時間查詢的輸出結果大小

■ 同時間上線的使用者數量

■ 資料庫大小

■ 頻寬需求

資料處理量(每秒讀寫次數):要開始設計磁碟子系統,你需要估計資料庫 應用程式的每秒資料讀寫次數。得到計算結果後,再根據RAID種類調整資 料處理量需求(涵蓋於《評估磁碟子系統大小》一節)。接下來,先將最 後資料處理需求以每秒I/O次數(IOPS)表示,再選擇資料處理量乘以85%

仍可以負擔資料庫應用程式的磁碟系統。

如果資料庫應用程式已經部署,而現有硬體環境尚未到達最大I/O資料處理 量,你可以利用Physical Disk: Disk Reads/sec與Physical Disk: Disk Writes/sec 計數器來判斷每秒讀寫次數,然後比對之前建立的效能基準,藉此預估未來 某段時間(例如三年)的資料成長率,直到硬體設備不敷使用需要更換。

假如應用程式已經開發完畢但是尚未部署,需執行額外工作來評估工作負 載與資料處理需求。你可以從面談程式設計師開始,瞭解資料庫應用程式 的交易種類,然後以SET DTATISTICS IO指令在資料庫上測量每種交易產生 的資料讀寫次數。

下一步,找出每種交易在每天產生的最大交易數。利用此資訊計算出該應 用程式每天產生的最大資料讀寫次數,然後除以每天工作時數換算的秒數

(以8小時計算,相當於28,800秒)。上述計算結果會得到資料庫應用程 式概略的資料處理量需求。最後,如果考慮資料頁錯誤(page fault)的 情況,需要將每秒讀取次數加上20(此步驟只有在手動估計讀寫次數時需 要,如果是從實際伺服器的效能資料計算就可以忽略此步驟)。

(14)

CPU使用率:要以工作負載分析來評估CPU數量或等級,必須選擇一種CPU 種類,再以它來估計資料庫應用程式所對應的CPU使用率。得到計算結果 後,就可以預測要有多少個CPU才能讓CPU使用率維持在75%以下。

要估算資料庫應用程式工作負載的CPU使用率,有一種方式是在測試伺服 器上執行SET STATISTICS TIME指令,測量資料庫應用程式內每種交易的執 行時間。為了讓測量結果更精確,測試伺服器的CPU種類必須與未來資料 庫伺服器所使用的CPU相同。知道每個交易的執行時候後,計算每天中每 個交易的最大執行次數。這個過程有助於評估每天中CPU要花多少時間在 處理忙碌的資料庫工作負載。

倘若無法建置測試伺服器,就要將預估每天的讀寫次數以及CPU處理讀寫 過程所費時間結合起來。CPU處理讀寫動作的執行時間可以從伺服器廠商 或CPU製造商的網站取得,或是從業界獨立機構取得,例如交易處理效能 委員會(Transaction Processing Performance Council)的網站(www.tpc.

org)。取得這些資訊以後,就可以進一步計算每天CPU要花多少時間在執 行I/O與處理資料庫工作負載。

一旦知道每天CPU用在處理資料庫工作負載的總時間,將它除以一天內工 作時間換算的總秒數。最後結果就是CPU使用率。

同時間查詢的輸出結果大小:要計算記憶體大小,必須先估計資料庫查詢的 記憶體快取需求以及實際使用的記憶體空間,包括每個查詢的內容文字與 輸出結果平均資料量。得到所需資訊以後,將可以預測使用者每五分鐘執

NOTE

∣讀寫次數百分比

在線上交易處理(OLTP)系統的I/O總數中,大約66%為讀取,33%為寫入。在決策 支援系統(DSS)中,大約90%為讀取,10%為寫入。不同的伺服器環境可能有所差 異。假如你知道系統的I/O總數,不妨利用這些平均值來估計系統讀寫次數。

MORE INFO∣磁碟效能

有關磁碟子系統的更多資訊,請下載這份白皮書「Disk Subsystem Performance Analysis for Windows」,位於http://www.microsoft.com/whdc/device/storage / subsys_perf.mspx

(15)

行這些查詢的最高頻率(五分鐘或300秒是資料停留在記憶體快取的最小時 間間隔)。

估計記憶體的快取空間需求通常是將每個查詢的空間需求乘以執行次數。

有關如何估計記憶體快取的空間需求,請參考《課程4估計記憶體需求》。

同時間上線的使用者:要估計資料庫伺服器的記憶體需求,也要考慮連接至 伺服器的最大人數。知道使用者連線所佔用的記憶體,加上作業系統與SQL Server 2005所使用的記憶體,就可以得到系統整體的記憶體需求。

如果資料庫伺服器早已建置完成,可使用SQL Server: General Statistics物件 的User Connections計數器來判斷使用者連線平均數。利用此資訊就可以預 估未來三年的使用者連線趨勢。如果你無法取得技術資訊,也應該預估尖 峰時間同時上線的使用者人數。

資料庫大小:要評估資料庫伺服器的儲存需求,必須估算資料庫未來的大 小,包括所有索引與系統資料庫(例如tempdb)。考慮影響資料庫成長的 因素後,你可以選擇適當的資料庫儲存方案,其儲存空間的85%應該高於資 料庫的儲存需求。

如果資料庫已經建置完成,可利用SQL Server: Database物件的Data File(s) Size KB計數器所蒐集的歷史資料來確認目前資料庫大小與其成長率,藉此 預估未來某段時間的資料庫成長趨勢。假如資料庫已經建立,但是無法取 得上述資訊。你可以計算各資料表內每筆資料列的長度,乘以資料表的總 資料筆數,得到該資料表的大小。接下來,將所有資料表的大小加總起來 就是資料庫的概略容量。知道資料庫大小再配合其成長率,也可以預估資 料庫未來的容量需求。

假如資料庫尚未建立,你應該和技術專家或商業主管面談,以便估計資料 庫的大小與未來成長率。

NOTE∣索引空間需求

在某些大量查詢的資料倉儲系統,索引的空間需求也許是資料表的3到5倍。

(16)

頻寬需求:要評估資料庫伺服器的網路連線需求,必須先統計每個網路連線 上發生的資料流量,以每秒鐘幾KB表示。根據計算結果,選擇可以提供足 夠頻寬的網路技術即可滿足資料庫伺服器的網路頻寬需求。

其他評估系統規模的方法

瞭解如何自行計算伺服器硬體需要的規模大小雖然實用,但是這並非 唯一作法,特別是無法利用負載測試的場合。如果你可以提供未來伺 服器環境的需求,以及欲部署的資料庫應用程式,大多數主要系統廠 商都可以提供你合適的組態方案。此外,業界也有許多評估系統規模 的軟體工具(從伺服器廠商網站免費取得,或是向第三廠商購買),

只要輸入關鍵資料,就會出適合的硬體設備組態。

NOTE∣測量網路頻寬

資料庫伺服器應該直接連接至交換器(switch),而非以集線器(hub)或無線基地 台連接至網路,這樣可確保資料庫伺服器擁有足夠的網路頻寬。如果無法實作此種架 構,就要測量該網路區段的所有流量,而不僅是進出資料庫伺服器的流量。

如果資料庫伺服器已經上線,可以利用效能主控台內Network Interface物件 的Bytes Total/sec計數器或是第三廠商軟體工具來測量尖峰時間的網路流量與 使用率(網路使用率等於 Bytes Total/sec除以網路頻寬)。藉由這些資訊將 可以預估未來某段時間的網路流量成長率。最後,如果實作其他與網路有關 的技術,例如資料庫鏡像或資料庫複寫,也要考慮額外產生的網路流量。

NOTE

Bytes Total/sec計數器

在效能主控台中,Network Interface與Server物件都擁有Bytes Total/sec計數器,差別在 於:利用Network Interface物件必須指定欲測量進出流量的網路介面卡;利用Server物 件的計數器則是測量伺服器上所有網路介面卡的進出流量。

如果無法實際測量上述流量,你可以建置一台測試伺服器來測量伺服器連 線的頻寬需求。實際需求取決於許多因素,例如是否實作資料庫鏡像,或 是資料庫複寫架構的種類為兩層式或三層式。

(17)

PRACTICE

∣分析資料庫伺服器的效能

在此練習中,你將使用某些可測量資料庫伺服器效能的計數器。

1. 開啟Windows系統管理工具,執行「效能」。

2. 在「主控台根目錄」下,選擇「效能記錄及警示」節點下的「計數器 記錄檔」。

3. 在「計數器記錄檔」上點選滑鼠右鍵,執行〔新增記錄檔設定〕。

4. 在「名稱」欄位內鍵入SQL Server Performance Counters,點選【確 定】開啟『SQL Server Performance Counters』對話盒。

5. 在「一般」頁籤內,點選【新增計數器】,開啟『新增計數器』對話 盒。

6. 選擇〔使用本機電腦計數器〕。

7. 在『新增計數器』對話盒內,閱讀表1-2列出的各項計數器說明,然後 分別加入這些計數器。

效能物件 計數器 執行個體

SQL Server: Buffer Manager Buffer cache hit ratio N/A SQL Server: Databases Transactions/sec _Total SQL Server: Databases Data File(s) Size (KB) _Total SQL Server: General Statistics User Connections N/A 表1-2:要加入的SQL Server計數器

8. 在『新增計數器』對話盒,點選【關閉】。

9. 在『SQL Server Performance Counters』對話盒,點選「排程」頁 籤。

10. 在「啟動記錄檔」區域,選擇〔手動〕。

(18)

11. 點選【確定】。

依照預設,效能主控台會將計數器記錄在C:\PerfLogs資料夾。如果系 統詢問你是否建立此資料夾,請點選【是】。在效能主控台內會產生 一個新的SQL Server Performance Counters記錄檔,當你選取「計數 器記錄檔」時會顯示在右側窗格。

12. 在SQL Server Performance Counters記錄檔上點選右鍵,執行〔啟 動〕。記錄檔會變成綠色,代表它正在執行並蒐集統計資訊。

13. 過了一分鐘後,在SQL Server Performance Counters記錄檔上點選右 鍵,執行〔另存設定〕。

14. 在『另存新檔』對話盒內點選【儲存】,以預設檔名儲存在預設路 徑。

15. 在SQL Server Performance Counters記錄檔上點選右鍵,執行〔停 止〕。

16. 在「我的文件」內,開啟SQL Server Performance Counters.HTM檔 案。

17. 花點時間瀏覽這份HTM檔案的內容。請特別注意不同的圖表設定,

觀察它們如何影響資料呈現,並留意所有計數器的平均、最高與最低 值。

18. 關閉SQL Server Performance Counters.HTM檔案。

19. 關閉效能主控台。

課程總結

■ 容量規劃是一個管理目前硬體容量與預測硬體需求的過程,包括處理 資料庫工作負載需要的硬體等級。

■ 如果你擁有一台舊伺服器,打算升級或置換。事先收集其效能基準有 助於預測未來需要的硬體設備。

■ 負載測試是最精確也是最昂貴的資料庫伺服器硬體規模評估方式。

(19)

■ 如果無法以負載測試評估資料庫伺服器的規模,可採用工作負載分 析。此過程包含預估與資料庫工作負載有關的資料。

■ 你應該借重系統廠商的專業與軟體工具來進行容量規劃。

課程回顧

你可以利用下列問題來測驗課程1「規劃資料庫的大小」的吸收程度。如果 你傾向以電子形式進行測驗,可以在書附光碟內找到這些題目。

1. 資料庫伺服器目前擁有四個CPU與六個實體磁碟。從效能主控台取得 的哪種資訊與系統效能瓶頸有關?

A. Physical Disk物件的% Disk Time averages計數器值超過40%

B. Processor物件的% Processor Time計數器值平均為65%

C. SQL Server: Buffer Manager物件的Buffer Cache Hit Ratio計數器 值等於85%

D. System物件的Processor Queue Length計數器值平均為4

2. 如果資料庫伺服器透過兩張網路卡連接至網路,下列哪一種計數器可 以判斷目前進出資料庫伺服器的所有流量?

A. Network Interface: Bytes Total/sec B. Network Interface: Current Bandwidth C. Network Interface: Packets/sec

D. Server: Bytes Total/sec

3. 資料庫目前大小為100 GB,每個月會成長2%。假設目前的成長率維持 不變,四年後資料庫大小為何?

A. 259 GB B. 178 GB C. 235 GB D. 288 GB

NOTE

∣解答

這些問題的解答,與每個答案的正確與錯誤解釋,都可以在本書最後的《解答》部分 找到。

(20)

■ 使用檔案群組的技巧將物件分開存放在不同實體磁碟。

■ 將同一個連結查詢的不同資料表存放在不同檔案群組。由於查詢資料 時可以透過平行磁碟I/O,執行效率得以提升。

■ 將大量存取的資料表與這些資料表的非叢集索引分開存放在不同檔案 群組。如果其資料檔位於不同實體磁碟,就可以藉由平行I/O提升存 取效能。

■ 請勿將交易記錄檔與資料檔存放在相同磁碟。

PRACTICE

∣建立 Test資料庫

在此練習中,你將演練建立資料庫的方式,並檢視其預設組態。

Exercise 1:檢視資料庫屬性

在此練習中,你將檢視AdventureWorks資料庫的檔案組態與相關設定。

1. 在DBSRV1,啟動SSMS。

2. 在SSMS的物件總管內,展開「資料庫」節點。

3. 點選AdventureWorks資料庫,按下滑鼠右鍵後執行【屬性】。

4. 在資料庫屬性對話盒,點選「檔案」頁面。

5. 回答以下問題:

AdventureWorks資料庫有哪些檔案?

答案:AdventureWorks資料庫有兩個檔案。

6. 回答以下問題:

AdventureWorks_Data.mdf檔案的初始大小為何?

答案:AdventureWorks_Data.mdf的初始大小為164 MB.

7. 回答以下問題:

AdventureWorks_Data.mdf的「自動成長」設定為何?

答案:自動成長為16 MB,不限制成長。

(21)

8. 在AdventureWorks_Data.mdf檔案的自動成長欄位,點選【. . .】按 鈕。

9. 在『變更AdventureWorks_Data的自動成長』對話盒內,瀏覽 AdventureWorks_Data.mdf檔案的自動成長設定。

10. 回答以下問題:

AdventureWorks_Data.mdf的檔案上限為何?

答案:此檔案的檔案大小上限設定為〔不限制檔案成長〕。

11. 點選【取消】,關閉『變更AdventureWorks_Data的自動成長』對話 盒。

12. 在資料庫屬性對話盒內,選擇「檔案群組」頁面。

13. 回答以下問題:

AdventureWorks資料庫有幾個檔案群組?

答案:AdventureWorks資料庫只有一個檔案群組。

14. 點選【取消】,關閉資料庫屬性對話盒。

Exercise 2:

1. 在SSMS內點選「資料庫」節點,執行【新增資料庫】。

2. 在『新增資料庫』對話盒的「資料庫名稱」欄位,鍵入Test。

3. 花點時間瀏覽Test.mdf與Test_log.ldf檔案的預設組態。

4. 在Test.mdf的「路徑」欄位,點選【. . .】按鈕開啟『尋找資料夾』對 話盒。在此可指定新資料庫檔案的存放路徑。

5. 點選【取消】,關閉『尋找資料夾』對話盒。

6. 點選【取消】關閉『新增資料庫』對話盒,不用真正建立資料庫。

7. 關閉SSMS。

(22)

課程總結

■ 設計資料庫伺服器的磁碟子系統時,請確定資料庫工作負載不會超過 磁碟資料處理量與儲存空間的85%。

■ 資料庫伺服器的基本儲存準則是將作業系統與SQL Server放在鏡像磁 碟,將交易記錄檔存放在第二個鏡像磁碟,將資料檔存放在RAID 5或 RAID 10陣列。

課程回顧

你可以利用下列問題來測驗課程2「規劃磁碟子系統的大小」的吸收程度。

如果你傾向以電子形式進行測驗,可以在書附光碟內找到這些題目。

1. 你準備將現有資料庫轉移到執行SQL Server 2005的新伺服器。下列哪 種資訊有助於評估四年內資料庫的大小?

A. 與行銷部門同仁面談 B. 資料庫大小的成長趨勢 C. 資料庫使用率的成長趨勢 D. 與資料庫設計師面談

2. 下列何者並非RAID 1優於RAID 5之處?

A. 回復速度較快

B. 每個byte的儲存成本較低 C. 寫入效率較高

D. 可做為作業系統的磁碟

3. 關於交易記錄檔的描述,何者為真?

A. 交易記錄檔與資料檔應該存放在不同實體磁碟 B. 適合存放在RAID 5儲存設備

C. 該檔案產生的讀取次數會高於寫入次數 D. 產生I/O數量與資料庫的I/O數量一樣

(23)

4. 哪一種RAID組態適合存放作業系統?

A. RAID 0 B. RAID 1 C. RAID 5 D. RAID 10

5. 你正準備為一個忙碌OLTP系統建立一台資料庫伺服器,應該將SQL Server安裝在哪個磁碟?

A. 存放交易記錄檔的磁碟 B. 存放資料檔的磁碟 C. 存放作業系統的磁碟 D. 存放自己獨立的磁碟

6. 關於某資料庫的資料檔,下列敘述何者為真?

A. 如果建立多個資料檔並存放在不同磁碟,通常可以提升存取效 能。

B. 如果將交易記錄檔與資料檔存放在一起,通常可以提升存取效 能。

C. 大多數資料庫至少要有兩個資料檔與一個交易記錄檔。

D. 大多數資料庫只需要一個資料檔。

NOTE

∣解答

這些問題的解答,與每個答案的正確與錯誤解釋,都可以在本書最後的《解答》部分 找到。

―未完,詳見悅知文化Microsoft SQL Server 2005設計資料庫伺服器基礎架構一書-

參考文獻

相關文件

Client: Angular 、 Cordova Server: Node.js(Express) 資料庫: MySQL. 套件管理: Node Package

  SOA 記錄裏,記載著關於該 域名權責區域的一些主 要網域名稱伺服器 ( primary DNS server) 和其它 相關的次要名稱伺服器 ( secondary DNS server)

例如 : http ( 網頁伺服器所用的協定 ) 定義了 client 如何向 server request 網頁及 server 如何 將網頁及其中的各種內容回傳給 client 。. 提供服務給 application layer

(A)SQL 指令是關聯式資料庫的基本規格(B)只有 SQLServer 2000 支援 SQL 指令(C)SQL 指令 複雜難寫,適合程式進階者使用(D)是由 Oracle

Note that if the server-side system allows conflicting transaction instances to commit in an order different from their serializability order, then each client-side system must apply

Using MS Access to design database, learning SQL commands and create forms and

[r]

Remote root compromise Web server defacement Guessing/cracking passwords Copying databases containing credit card numbers Viewing sensitive data without authorization Running a