在使用叢集環境的 32 位元平台上合併 SQL Server ─ 經驗學習

經驗學習

發佈日期: 2004 年 5 月 1 日

作者: Mike Ruthruff

摘要:本報告探討測試案例中所學習到的經驗,在測試案例中,Microsoft 將先前存放在不同實體伺服器中的 Microsoft® SQL Server™ 資料庫合併到單一 32 位元的 Windows 叢集環境中。

本頁內容

概觀
合併環境的組態
在合併環境中管理工作負載效能
使用多重 SQL Server 執行個體
叢集環境的 AWE 考量
結論
附錄 A:儲存體組態和效能
附錄 B:參考資料
附錄 C:硬體組態

概觀

Microsoft® SQL Server™ 在合併環境中的效能主要是取決於所使用的硬體,以及所牽涉 SQL Server 工作負載的特性。32 位元平台架構本身有其限制,會影響 SQL Server 的功能,無法完全發揮運用配備大量實體記憶體的系統。使用多重執行個體是在單一機器上完全運用大量記憶體資源的方法之一,但是使用多重執行個體可能需要更仔細考慮所使用的 SQL Server 微調選項。尤其是結合使用叢集服務與 SQL Server 時,更需要精心思考。

本報告探討測試案例中所學習到的經驗,在測試案例中,Microsoft 建立並操作伺服器,將先前在不同機器上運作的 SQL Server 執行個體合併到單一 32 位元的叢集環境中。本報告所包含的確切內容如下:

  • 可用來執行資料庫合併的 32 位元組態範例。

  • 在儲存區域網路 (SAN) 環境中將 SQL Server 叢集化的相關資訊。

  • 同時執行多重 SQL Server 執行個體的相關資訊,其中包括您可以用來讓效能達到最佳化的微調選項。

  • 在大量記憶體環境中將 SQL Server 叢集化的其他考量。

本報告並無意涵蓋合併 SQL Server 資料庫時可能碰到的所有問題。只是提供您,在特定組態下測試時所學習到的經驗。除此之外,本報告中所探討的測試案例結果也並不一定適用於所有的合併環境。如需更多有關成功地選擇與部署環境以執行 SQL Server 合併作業的必要規劃資訊,請參閱<附錄 B>中的資源<規劃以 Microsoft SQL Server 2000 執行合併作業>。

合併環境的組態

主機硬體組態

Microsoft 在本報告所探討的測試案例中使用的合併伺服器是 Unisys ES7000 伺服器。這部伺服器分成兩個資料分割,每一個資料分割擁有整台機器的一半資源。每個資料分割所設定的組態都是 16 個 CPU、32 GB RAM 與四個 Emulex LP9000 主匯流排介面卡 (HBA)。兩個資料分割都是執行 Microsoft Windows® Server™ 2003 Datacenter 版作業系統與 SQL Server 2000 with Service Pack 3 (SP3)。兩個資料分割都是使用 Windows Clustering 來執行叢集化。使用 EMC PowerPath 軟體在 Windows Cluster 中的兩個節點上的各四個 HBA 之間平衡 I/O。

儲存體組態

Windows Clustering 的需求限定了測試環境中所用的儲存體組態。SQL Server 叢集執行個體所使用的儲存體有兩個主要需求:

  • 撰寫本報告時,SQL Server 並不支援裝載點磁碟區供 SQL Server 的叢集執行個體使用,因此任何共用的磁碟資源都必須使用磁碟機代號。如需裝載點磁碟區的 SQL Server 支援詳細資訊,請參閱<附錄 B>。

  • 每個 SQL Server 執行個體都必須至少擁有一個共用的磁碟資源。

除了上述需求以外,使用 SAN 實作叢集作業時,還有其他特殊考量。如需在 SAN 環境中執行叢集的詳細資訊,請參閱<附錄 B>。

本報告中用於測試案例的儲存體組態是 EMC Symmetrix 5.5 機型 8530 儲存體陣列。在測試期間,該陣列也由另一部主機用來進行其他不相關的 SQL Server 測試。測試案例中,SAN 部份所使用的全部儲存量大約是 1.6 TB,散佈在 22 個邏輯單元數 (LUN) 之間,其中包括 9 個 108 GB LUN 和 13 個 54 GB LUN。這些 LUN 都對應到 Windows 磁碟機代號,而且每個 LUN 都設定為不同的磁碟區。在測試案例中,一共有 16 個 SQL Server 執行個體,每個執行個體都擁有一或兩個磁碟區。資料庫大小從最低 10 GB 一直到最高大約 150 GB。

如需深入檢視本報告所探討測試案例中的儲存體組態及其效能結果,請參閱<附錄 A:儲存體組態和效能>。

資料庫與合併工作負載

Microsoft SQL Server 2000 最多可以在執行 Windows 的單一電腦上,支援 16 個 SQL Server 資料庫引擎的執行個體。在本報告所探討的測試案例中,Microsoft 安裝了 16 個已命名的 SQL Server 執行個體,作為組態中兩個叢集節點上的叢集虛擬伺服器。每個 SQL Server 執行個體都包含 1 到 25 個資料庫,但大部份的執行個體平均有 5 個資料庫。

在這 16 個 SQL Server 執行個體中,有 12 個包含從不同來源收集來的資料庫,來源可能在 Microsoft 部署之內或部署之外,但各個來源都是真正的實際執行資料庫。這些資料庫的工作負載是透過 SQL Profiler 重新執行先前所擷取的生產工作負載追蹤來建立。追蹤中所擷取的工作負載類型主要是線上交易處理 (OLTP) 工作負載,但其中有些追蹤也包含少數與維護相關的查詢,或是其他因為特殊用途而建立的查詢。OLTP 工作負載主要是由插入、刪除及更新資料所組成,同時也有一些選擇性查詢。

另外 4 個 SQL Server 執行個體則包含兩個代表性 OLTP 工作負載的資料庫,以及兩個代表性決策支援系統 (DSS) 的資料庫,也可以稱為關聯式資料倉儲 (RDW) 工作負載。DSS 工作負載是由附平行執行計劃的複雜性唯讀查詢所組成。

在定義合併工作負載以前,Microsoft 首先決定使用特定硬體環境中的工作負載,可以支援多少 SQL Server 執行個體同時並行。在任何時刻能夠同時執行的工作負載量是根據叢集中單一節點的硬體容量來決定。在測試案例中工作負載與硬體組態方面,是以 CPU 資源為限。因為在其他主要硬體資源還沒耗盡以前,CPU 資源就已先耗盡。在同時有 10 個 SQL Server 執行個體並行下執行工作負載,會導致單一節點上的 16 個 CPU 平均使用 80% 的 CPU。這種情形會成為基準合併工作負載,因為已接近單一節點的容量,而剩餘的 CPU 資源只能夠再加入一個到兩個工作負載。

在效能測試時,Microsoft 執行四種不同的合併工作負載案例。所使用的工作負載列於表 1.1。選擇這些案例的原因在於:測量在基準上另外再加入 OLTP、DSS 與資料庫主控台命令 (DBCC) 維護工作負載會產生什麼結果。

表 1.1 合併工作負載詳細資料

工作負載

工作負載描述

工作負載 A (視為基準工作負載)

同時重新執行 10 個 SQL Profiler 追蹤。SQL Profiler 追蹤主要是包含 OLTP 工作負載,加上少數維護式查詢,或其他為特殊用途建立的查詢。

工作負載 B

工作負載 A 另外再加上兩個重新執行 OLTP 工作負載的 SQL Profiler 追蹤。加入 OLTP 工作負載的原因在於加入這兩個工作負載所額外利用的 CPU 資源加起來,跟加入 DSS 或維護工作負載相比,所使用的 CPU 資源很接近。

工作負載 C

工作負載 A 加上 1 個執行 DSS 式工作負載的 SQL Server 執行個體 (包含複雜性選擇查詢)。

工作負載 D

工作負載 A 加上 1 個純粹與執行維護相關的工作負載 (資料庫中所有使用者資料表的 DBCC CHECKDB、DBCC SHOWCONTIG 和 DBREINDEX) 的 SQL Server 執行個體。

在合併環境中管理工作負載效能

SQL Server 微調選項

在大型系統上,使用 SP_CONFIGURE 預存程序中的選項對 SQL Server 進行微調,效能確實可以獲得大幅改善。為了查看不同組態設定在合併環境中對效能所造成的效果,Microsoft 在測試案例中套用不同的設定,然後測量所得到的效能是改善或降低。下面列出的每一種組態都以先前表 1.1 中所提的四種工作負載進行測試:

  • 預設伺服器設定。 所有 SQL Server 執行個體都以預設伺服器設定執行。

  • 關連遮罩 (以 CPU 相關性來平均分配 CPU 資源)。 為 3 個 SQL Server 執行個體的每一組都指定一組 4 個 CPU (隨時都保持總共 12 個現用執行個體)。群組是根據先前執行時所觀察到的 CPU 使用情形來決定。最需要 CPU 資源的 SQL Server 執行個體就配置在不同的群組中。

  • I/O 相關性 (使用 I/O 與 CPU 相關性來設定各 CPU 的功能)。 組態中 16 個 CPU 的分配原則為:12 個 CPU 供 SQL Server 處理使用,另外 4 個 CPU 專門供 I/O 使用。組態中的所有 SQL Server 執行個體都可以使用 12 個 CPU 中的任何一個來執行處理作業。

  • 最高程度的平行處理原則 (限制查詢計劃中的平行處理數量)。 將所有 SQL Server 執行個體的 MAXDOP 選項都設定為 4。其他所有選項都設定為預設值。

  • /3GB、最大伺服器記憶體,以及最小伺服器記憶體。 未測試在 32 位元系統上使用這些設定的情形。

    本報告所探討的測試案例中並未使用 /3GB 開機選項,原因在於組態中所用的系統有 32 GB RAM。若要利用 4GB 以上的實體記憶體,必須使用 Boot.ini 檔中的 /PAE 開機選項來啟動 Windows。在 16 GB 以上實體記憶體的系統上,以 /PAE 啟用 /3GB 會導致作業系統在啟動後,只能在系統上辨識 16 GB 的可用記憶體。

    測試案例也沒有要求對最小伺服器記憶體或最大伺服器記憶體作任何調整,因為組態中使用的系統有 32 GB 實體記憶體,而在任何時刻也都只執行 12 個現用 SQL Server 執行個體。對 32 位元平台上的各個 SQL Server 執行個體來說,實際可行的記憶體限制是剛好在 2 GB 之下,而讓測試案例中 SQL Server 處理所耗用的累計記憶體保持在 24 GB 以下。為 SQL Server 設定記憶體上限是最佳實務,如果執行個體之間可能會有爭用記憶體的情形,就應該在合併環境中設定記憶體上限。在其他執行個體幾乎已耗盡所有可用的系統記憶體時,讓一個 SQL Server 執行個體上線可能會導致所有執行個體的效能都降低。

多重執行個體工作負載效能結果

工作負載效能測試結果顯示,在合併環境中,使用預設伺服器設定值一般都能有很好的整體效能,比其他 SQL Server 微調選項的效能都好。圖 1.1 和圖 1.2 顯示有交易工作負載的所有 SQL Server 執行個體之系統 CPU 使用情形和每秒總交易量 (如需各工作負載類型的詳細資料,請參見表 1.1)。

Dd159894.Cosl3201(zh-tw,TechNet.10).gif

圖 1.1 每秒累計交易

Dd159894.Cosl3202(zh-tw,TechNet.10).gif

圖 1.2 CPU 總用量

圖 1.1 和圖 1.2 顯示,在所有工作負載案例下,設定 CPU 相關性或 I/O 相關性的結果是交易處理能力較低,而且沒有完全運用 CPU 資源。使用這些設定也沒有達到大幅降低內容切換次數的效果。在所有工作負載案例中,每秒內容切換的次數是從 20,000 到 25,000。CPU 相關性與 I/O 相關性是很少使用的設定,只有在少數幾個有大量 CPU 的部署時,為了順利微調單一 SQL Server 執行個體的效能,以管理不相干執行個體同時存在的情況,才會用這種設定。但是在測試案例的合併環境中,讓 SQL Server 管理 CPU 資源可以簡化設定,使所有的工作負載都能獲致更好的整體處理能力。建議您,在考慮使用這些設定之一時,先就每種方案逐一測試之後再決定,因為效能優勢可能會依所牽涉的工作負載特性而有差異。

將 MAXDOP 選項設定為 4 而不採用預設值 (0) 時,所顯示的兩種工作負載方案可取得更高的交易處理能力。雖然所使用的 CPU 資源總量較低,但卻產生交易處理能力較高的現象。執行特定查詢時,SQL Server 查詢處理器會建立平行執行計劃,結果可能會在所有可用的 CPU 中執行查詢。在所有可用的 CPU 中平行執行一項查詢,對該特定查詢可能會有效能提升優勢,但可能會需要更多 CPU 資源,因此可能阻撓其他同時也在系統上執行的查詢效能。在擁有許多 CPU 的系統上,對 MAXDOP 選項設定限制可能會比較有利。建議您同時測試設定及不設定 MAXDOP 選項的情形,以確保沒有任何一個或一組查詢會佔去機器上不成比例的大量資源。

異質工作負載效能結果

一般來說,最佳實務是將不同類型的工作負載 (例如,DSS 與 OLTP) 分別放在不同的伺服器上,但這並不一定就是適合所有合併案例的實際可行作法。為了判定 DSS 工作負載對其他同時並行的 OLTP 工作負載之影響,Microsoft 在包含大量耗用 I/O 的 DSS 工作負載之測試案例中使用一個合併工作負載。DSS 工作負載包含一組複雜性選取查詢 (有許多複雜性聯結並大量使用 tempdb 資料庫)。合併工作負載如圖 1.1 和圖 1.2 中的工作負載 C 所示。圖 1.3 和圖 1.4 顯示,測試案例中的 DSS 與維護工作負載讀取 I/O 的活動增加。

Dd159894.Cosl3203(zh-tw,TechNet.10).gif

圖 1.3 每秒磁碟讀取量

Dd159894.Cosl3204(zh-tw,TechNet.10).gif

圖 1.4 每秒磁碟寫入量

如圖例所示,包含 DSS 與維護查詢的工作負載所執行磁碟讀取的數目高於主要是由 OLTP 查詢所組成的工作負載。對耗用大量 I/O 之工作負載 (例如,DSS) 對整個系統的效能衝擊,大半取決於磁碟子系統的效能。在測試案例中,DSS 工作負載是同時執行,對 OLTP 工作負載效能的衝擊極低。這是在未對 I/O 子系統作任何特殊微調之下達到的效能。

由於測試案例中有大量資料庫以及與資料庫相關的檔案,儲存體的設定並未實際對資料、記錄和任何 tempdb 檔進行隔離;同樣地,儲存體設定也未實際對含 DSS 工作負載的 SQL Server 執行個體與含 OLTP 工作負載的執行個體進行隔離,而是將儲存體組態打散分佈在各 LUN 中,由 SAN 盡可能跨多個實體磁碟公開 (Expose)。對 SQL Server 來說,在磁碟層級上實際隔離資料與記錄檔永遠是最佳實務,但是在合併環境中,這種方法也許不會永遠都是最實際的作法,尤其是在使用儲存區域網路 (SAN) 的環境中。在許多情況下,儲存體確實可以跟其他系統共用,本報告所探討的測試案例中的情況就是跟其他系統共用。可在單一系統上成功地合併異質工作負載的能力幾乎是取決於工作負載特性與 I/O 子系統的效能。若想要合併 I/O 特性極為不同的工作負載,就應該先仔細執行測試,判斷對整個系統 I/O 效能的影響。

使用多重 SQL Server 執行個體

對本報告所探討的測試案例來說,有兩個主要原因要使用多重 SQL Server 執行個體:

  • 測試的目標是建立同時執行許多 SQL Server 執行個體的大型伺服器的環境,以便測量效能,並判斷微調該環境效能的最佳作法。

  • 在 32 位元平台上,使用多重 SQL Server 執行個體可以完全發揮運用安裝在 Unisys ES7000 伺服器上的大量實體記憶體 (每個叢集節點 32 GB,結果是每一個 SQL Server 執行個體大約配置到 2 GB 記憶體)。

不同伺服器的每一組資料庫都被放入本身的 SQL Server 執行個體中,簡化測試案例中的整體部署作業與組態。不同伺服器的資料庫備份都儲存在合併伺服器上。

若是從不同的伺服器將資料庫合併到同一個 SQL Server 執行個體上,一定要記得考慮登入衝突之類的問題,以及定序的設定與排序順序及其他伺服器的特定設定。對應到不同 SQL Server 執行個體可簡化此處理。除此之外,具有多重 SQL Server 執行個體可提供隔離工作負載的能力,而每一個執行個體都有本身的 tempdb 資料庫。如需規劃及處理這些部署問題的詳細資訊,請參閱<附錄 B>中的<規劃以 Microsoft SQL Server 2000 執行合併作業>。

在設定了 4 GB 以上實體記憶體的 32 位元平台上,您可以使用 Address Windowing Extensions (AWE) 或多重 SQL Server 執行個體,作為完全發揮運用大量實體記憶體的方法。AWE 在某些案例中可能會運作順利,但是您要了解 AWE 記憶體只能用來作資料快取。程序快取、連線、鎖定以及其他 SQL Server 內部資源的記憶體必須來自虛擬記憶體的 2 GB (或 3 GB,取決於所使用的設定) 部份。在需要支援大量資料庫與使用者連線的系統上,多重 SQL Server 執行個體可能是完全解除由 32 位元平台加在這些資料結構上的 2 GB 或 3 GB 記憶體限制的最佳方法。

桌面堆積考量

在眾多服務於各別使用者帳戶下執行的環境中,要了解這樣可能會耗盡桌面的堆積資源,而且可能需要執行一些微調,才能確保服務可以順利啟動。以特定使用者帳戶執行的各種服務會在其本身的 Windows 工作站中執行。各個 Windows 工作站可以包含零或多個桌面,而各個桌面物件各有相關聯的桌面堆積。Windows 有一定數量的桌面堆積可用,而當可用的桌面堆積已耗盡時,啟動服務時可能會失敗。您可以使用登錄設定由各個 Windows 工作站配置的桌面堆積量,您可能需要降低由各非互動式桌面所配置的量,才能讓所有服務啟動而不致失敗。您是否需要做這種設定,取決於所執行的服務數量以及個別使用者帳戶的數量。請參閱<附錄 B>,取得更多 Windows 工作站、桌面、可能會發生的錯誤類型,以及如何控制由各非互動性 Windows 工作站所配置的桌面堆積量等的相關資訊。

叢集環境的 AWE 考量

測量過測試案例中合併環境的工作負載效能以後,Microsoft 測試了已啟用 AWE 的 SQL Server 執行個體,判斷它們在容錯移轉中如何反應運作。

AWE 記憶體和啟動效能

當 SQL Server 啟動設定為使用 AWE 記憶體的執行個體時,它必須在處理啟動時配置並認可記憶體頁面。基於安全的理由,SQL Server 使用的記憶體頁面必須在由 SQL Server 處理使用之前,以零初始化。啟動 SQL Server 所需的時間取決於 Windows 是否有足夠以零初始化的記憶體頁,可在處理啟動時滿足配置要求。若可用的記憶體頁不足,就必須在處理啟動時以零初始化記憶體頁。在終止 SQL Server 處理時,隨著記憶體頁面釋回 Windows 並放在可用清單上,Windows 就有零頁執行緒 (優先權 0) 可實體清空記憶體頁。在 Windows Server 2003 (以及<附錄 B>所提的 Windows 2000 Service Pack 3 或附 Hotfix 的更新版本) 上,以頁面的零初始化作業是在所有 CPU 之間平行運作。在舊版 Windows 上,以記憶體頁面的零初始化作業是在單一執行緒上運作,可能會造成在大量記憶體系統上執行而已啟用 AWE 的 SQL Server 執行個體啟動時間很慢。

在測試案例中,設定為使用大約 31.5 GB RAM 而已啟用 AWE 的 SQL Server 執行個體啟動時間是從 30 秒以下一直到大約 4 分鐘,依是否需要記憶體頁面以零進行初始化而定。已啟用 AWE 的 SQL Server 執行個體若耗費相當長的時間才能啟動,可能就需要變更與叢集服務相關的一些設定。叢集服務在 SQL Server 資源上有「暫止逾時」屬性。如果 SQL Server 未在所設定逾時時間內啟動,叢集服務就會向服務控制管理員 (Service Control Manager) 發出停止要求,然後會再度嘗試重新啟動服務。在配備大量記憶體的系統中,若 SQL Server 已啟用 AWE,逾時可能需要從預設的 30 秒調整到更高的逾時值。

已啟用 AWE 的 SQL 執行個體與容錯移轉

對於各節點上實體記憶體大於 4 GB 伺服器上的現用/現用叢集方案,您可以設定已啟用 AWE 記憶體的 SQL Server 執行個體。SQL Server 會允許您設定該記憶體,讓多重節點上執行的全部執行個體所耗用的累計記憶體大於單一節點上可用的實體記憶體。由於 AWE 記憶體是以靜態方式配置,一直要到處理終止才會釋出,最好是永遠都設定 SP_CONFIGURE 最大伺服器記憶體選項,限制由任何一個執行個體耗用的記憶體量,以確保永遠都會有足夠的實體記憶體可供任何可能有容錯移轉的執行個體使用。一般認為最佳實務是:設定現用/現用叢集,讓跨節點上耗用的累計資源永遠都不會超過在單一節點上可用的資源。如此可確保萬一發生容錯移轉,永遠都會有適當的系統資源。相關連的負面交換代價就是:記憶體並不是隨時都在使用。

在容錯移轉情勢下已啟用 AWE 的 SQL Server 執行個體行為,與啟動時任何已啟用 AWE 的 SQL Server 執行個體行為相同。其行為介紹如下:

  • 若有 2 GB 以下的實體 RAM 可供使用,當已啟用 AWE 的 SQL Server 執行個體啟動時,不管 AWE 設定是如何,都會回復到動態記憶體模型。

  • 如果可用的實體記憶體 RAM 稍微大於 2 GB (也就是從 128 到 300 MB 的額外記憶體),當已啟用 AWE 的 SQL Server 執行個體啟動時,將會要求在啟動時可用的所有記憶體,最多可達伺服器最高記憶體設定。如果最高的伺服器記憶體設定是零,執行個體會盡可能取得所需記憶體,但同時也會留下一些記憶體供作業系統使用 (最少有 128 MB)。

測試案例中的組態顯示,如果已啟用 AWE,SQL Server 永遠都會設法為 Windows 留下稍微多一點的實體記憶體,大概從 128 到 300 MB。事實上在效能測試中,不管 AWE 設定是如何,SQL Server 永遠都會設法為 Windows 留下這麼多空間。

表 1.2 中包含在不同的 AWE 容錯移轉方案中,容錯移轉之前與之後的記憶體耗用範例。在各個方案中,已啟用 AWE 的執行個體組態都是將已啟用 AWE 的選項設定為一,而最小伺服器記憶體等於最大伺服器記憶體。

表 1.2 AWE 記憶體耗用情形

方案

記憶體總計 (每個節點)

容錯移轉前的記憶體耗用情形

容錯移轉後的記憶體耗用情形

兩個已啟用 AWE 的執行個體 (每個節點一個,現用/現用)。

每個執行個體的最大伺服器記憶體設定都是 = 20 GB。

32 GB

節點 1 上的執行個體有 20 GB。

節點 2 上的執行個體有 20 GB。

節點 1 上的原始執行個體有 20 GB。

容錯移轉執行個體大約有 11.7 GB。

四個已啟用 AWE 的執行個體 (每個節點兩個,現用/現用)。

每個執行個體的最大伺服器記憶體設定都是 = 10 GB。

32 GB

節點 1 上的每個執行個體都有 10 GB。

節點 2 上的每個執行個體都有 10 GB。

節點 1 上的每個原始執行個體都有 10 GB。

如果執行個體是連續進行容錯移轉:

容錯移轉的第一個執行個體取得 10 GB。容錯移轉的第二個執行個體則回復為動態記憶體。

如果執行個體是同時進行容錯移轉:

每一個執行個體所耗用的記憶體量都不同;但是兩個執行個體耗用的累計記憶體總量將會接近 11.7 GB。

如果有執行個體是在未啟用 AWE 的機器上執行,當已啟用 AWE 的執行個體上線以後,其結果並不會 降低任何非 AWE 執行個體所耗用的記憶體;未啟用 AWE 的執行個體會保留所擁有的全部記憶體。不管非 AWE 執行個體是忙碌或閒置都是這種情形。產生這種現象的原因是:SQL Server 會在啟動時,根據最大伺服器記憶體設定與可用的實體記憶體來決定要配置的 AWE 記憶體量。

雖然 SQL Server 永遠都會設法為作業系統保留空間,但當系統的可用實體記憶體非常少,而又有其他執行個體上線時,系統可能會開始使用分頁檔中的虛擬記憶體 (亦稱為分頁作業)。這樣可能就會對整體系統效能產生負面衝擊。為多重 SQL Server 執行個體設定記憶體時,應該要牢記這些考量。

結論

SQL Server 在合併環境中的效能主要是取決於所使用的硬體,以及所牽涉 SQL Server 工作負載的特性。本報告所探討的測試方案提供 SQL Server 在合併環境中所表現行為的相關資訊。但是要了解這裡所報告的結果並不一定都適用於每一種組態。將各個不同的 SQL Server 執行個體合併到單一伺服器上時,千萬要仔細思考,決定在您目前系統中資源的使用情形。如需將多個執行個體合併到單一伺服器上的詳細資訊,請參閱<附錄 B>中的資源。

下面是一份本報告中所探討重點的清單:

  • SQL Server 2000 最多支援 16 個執行個體在單一 Windows 執行個體上同時並行。在實際情況下,所支援的執行個體數目是受限於可用的硬體資源。測試案例中的硬體在耗盡 CPU 資源以前,能夠支援 12 個執行個體的工作負載同時並行。

  • 如果在 SAN 環境中將 SQL Server 叢集化,必須了解有特殊的考量存在,建議您與儲存廠商密切合作來進行。此外,還要確定組態中的所有硬體都在 Windows「硬體相容性清單」(HCL) 上。

  • 在包含多個 SQL Server 執行個體的合併環境中,測試方案的結果顯示不需要作任何 CPU 或 I/O 相關性微調,事實上微調還可能會降低工作負載效能。但是微調 MAXDOP 選項確實會在某些情況下提升工作負載效能。

  • 在 SQL Server 執行個體使用 AWE 記憶體的叢集環境中,SQL Server 執行個體於容錯移轉時取得的記憶體量取決於可用的記憶體量。在某些情況下,已啟用 AWE 的執行個體可能會回復為動態記憶體模型。

附錄 A:儲存體組態和效能

本報告中探討的 32 位元平台合併作業測試使用 EMC Symmetrix 5.5 機型 8530 儲存體陣列。SQL Server 叢集化執行個體的需求決定本測試中儲存體的設定方式。SQL Server 叢集上的儲存體有兩個主要需求:

  1. 撰寫本報告時,SQL Server 並不支援裝載點磁碟機,以供 SQL Server 的叢集執行個體使用。您必須使用磁碟機代號代表任何共用的磁碟資源。

  2. SQL Server 的每個執行個體都必須至少擁有一個共用的磁碟資源。

設定儲存體陣列時,由於檔案總數太大,在磁碟旋轉時實際將資料、記錄和任何 tempdb 檔隔離分開事實上並不可行。此外,可用的磁碟機代號數目有限,叢集化時必須使用這些代號的需求迫使我們決定將資料、記錄與 tempdb 檔都放在相同的 LUN 上。結果是使得特定 SQL Server 執行個體的所有檔案都共用相同的實體磁碟,而且各執行個體都擁有一或兩個 LUN 作為共用的磁碟資源。儲存體陣列的設定可以讓每一個 LUN 盡可能橫跨多個實體磁碟,並使用 RAID (獨立磁碟容錯陣列) 1+0,以便將效能最佳化。所有 SQL Server 虛擬執行個體中的資料、記錄檔總計大約有 191 個 (不包括 tempdb 與系統資料庫檔案)。表 B.1 提供各 LUN 使用情形的相關資訊。

表 B.1 LUN 組態

LUN 數目

大小

使用情形

旋轉軸

LD0 – LD12

54 GB

資料、記錄與 tempdb 檔

每個 LUN 總共 8 個

LD13 – LD21

108 GB

資料、記錄與 tempdb 檔

每個 LUN 總共 16 個

這裡列出圖表 B 1 和 B 2,以供參考在此儲存體組態下測試期間所達到的 I/O 效能。在效能測試中,硬體資源是受限於 CPU 可用性。即使沒有設計中的實體隔離,I/O 效能都很好。

Dd159894.Cosl3205(zh-tw,TechNet.10).gif

圖 B.1 預設組態設定下的磁碟處理能力

Dd159894.Cosl3206(zh-tw,TechNet.10).gif

圖 B.2 預設組態設定下的平均磁碟延遲

圖 B.1 中的工作負載 A、B、C 和 D 都是本報告 (表 1.1)<資料庫與合併工作負載>中所描述的工作負載。如需這些工作負載的詳細資料,請參見該節中的表 1.1。

附錄 B:參考資料

規劃以 Microsoft SQL Server 2000 執行合併作業 (英文)

http://www.microsoft.com/technet/prodtechnol/sql/2000/plan/SQL2KCon.mspx

叢集化與 SAN

Microsoft Windows 叢集:存放區域網路 (英文)

http://www.microsoft.com/windowsserver2003/techinfo/overview/san.mspx

Microsoft 知識庫文件編號 304415 連接到相同 SAN 裝置的多重叢集支援

http://support.microsoft.com/default.aspx?kbid=304415

Microsoft 知識庫文件編號 280297 如何在叢集伺服器上設定掛接點磁碟區

http://support.microsoft.com/default.aspx?kbid=280297

Microsoft 知識庫文件編號 819546 掛接磁碟區的 SQL Server 2000 支援

http://support.microsoft.com/default.aspx?kbid=819546

桌面堆積考量

Microsoft 知識庫文件編號 184802 PRB:User32.dll 或 Kernel32.dll 無法初始化

http://support.microsoft.com/default.aspx?kbid=184802

視窗工作站 (英文)

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/window_stations.asp

AWE 和大型記憶體支援

Microsoft 知識庫文件編號 329914 啟用 AWE 的 SQL Server 2000 需要較長時間啟動

http://support.microsoft.com/default.aspx?kbid=329914

Microsoft 知識庫文件編號 283037 Windows 2000 和 Windows Server 2003 提供大型記憶體支援

http://support.microsoft.com/default.aspx?kbid=283037

Microsoft 知識庫文件編號 274750 HOW TO:在 SQL Server 上設定 2 GB 以上的記憶體

http://support.microsoft.com/default.aspx?kbid=274750

附錄 C:硬體組態

本報告所探討的測試方案是使用下列環境來進行:

伺服器

Unisys ES7000

  • 32 Intel® Pentium® III 700 MHz Xeon 處理器

  • 64 GB RAM

  • 8 個 Emulex LP9000 PCI 主匯流排介面卡 (HBA)

儲存體

EMC Symmetrix 5.5 (機型 8530) 配備 16 GB 快取、96 個 10 K RPM 73 GB 磁碟機,以及 12 條光纖主機連線。用 RAID 1+0 作組態設定。

結構交換器

EMC 品牌 McData director class、1 Gbs、64 埠光纖交換器

作業系統

Microsoft Windows Server 2003 Datacenter Edition

資料庫伺服器

Microsoft SQL Server 2000 企業版,Build 2000.80.194.0,Service Pack 3

顯示: