步驟1：創建SQL Server合并方法學

要進行一次成功的企業范圍內的SQL Server合并，你必須首先為你的合并團隊和客戶,以及用戶數據庫的業務擁有者定義合并目標。這些目標根據你的合并方式是互不相同的：在一個虛擬的機器上進行合并，堆砌SQL Server環境，和使用存儲區域網絡（SAN），等。

合并團隊要在事先與客戶探討實際的服務級別協議（SLA）是至關重要的。這些SLA不僅僅會為可用性、支持、更改控制，以及監控，還有性能都提供期望值。一個設置了可支持的期望值的SLA在構建合并努力信心方面還有很長的一段路需要走。

任務關鍵的應用程序應該被標識出來。他們的SLA將會比其它的SLA更嚴厲，要么要求這些應用程序不被合并和，要么進行仔細的計劃來確保SLA能夠在合并的環境中滿足或者超越。標準應該被應用，那些應用程序也應該在合并團隊的所有和控制之下拿出來。

另外一個需要事先協商SLA的原因就是避免范圍的蔓延，如果蔓延了的話，你的合并團隊就不得不解決那些意料之外的性能問題以及增強的功能性。

你的團隊在實行SLA的時候必須考慮各種各樣的場景。例如，一些人可能發現在識別數據庫的時候，應用程序性能很糟糕，而這些數據庫對于合并來說是個不錯的選擇。理想的客戶應該應要求把這些應用程序回爐進行優化。如果你的團隊選擇了優化，那么你就需要負擔起未來事件里面出現的任何性能問題或者bug。英名的選擇就是僅僅識別并返回這些數據庫給業務擁有者，并且在SLA里面詳細說明這個行為。

如果業務單元是不愿意，或者不能被要求回爐和優化這些SQL Server們，那么把它們移動到你的數據中心，并且盡可能地加強標準，但是不要用另外一個SQL Server合并這些數據庫。合并一個性能糟糕的用戶數據庫可能會降低SQL Server上所有其它用戶數據庫的性能。

一旦SLA商議妥當，你的合并團隊就應該創建一個日程表，把整個企業范圍內的計劃劃分為多個階段。

第一階段應該包括哪些具有最不復雜的用戶數據庫的部分。這樣就給了團隊成員一個在遇到更加困難的合并情況之前的實踐機會。這個階段方式還應該教會他們，在數據庫負載隨著時間發生變化的時候，能夠更加游刃有余的在SQL Server之間處理用戶數據庫。例如，當某一個特定的用戶數據庫增長的時候，他可能會使得合并的SQL Server上所有的用戶數據庫的性能都下降。另一方面，當某個應用程序的生命周期到達末尾的時候，那個用戶數據庫需要的資源也會衰落，然后使移動到一個較低馬力的服務器上是可行的。

測試腳本的創建目的應該是幫助測量現有的SQL Server應用程序。它可以讓團隊成員熟悉性能監控和SQL Server Profiler來捕捉和重現代表性的負載，并監控合并解決方案。

合并團隊還應該劃分特定的組，以簡化監控合并解決方案。

一旦合并團隊的成員理解了他們每個任務，并且為合并做好了準備，那么下一個步驟就是分析。

步驟2：分析合并備選數據庫和服務器

在分析階段，合并團隊應該觀察每個SQL Server和他的用戶數據庫來決定他們各自的性能特點，資源需求，依賴性，以及如何移植它們。在合并環境中，多用戶數據庫應該根據性能特點、內部和外部的依賴性，SLA，以及版本，被分組或者堆疊在一起。他們將會劃分為單個的SQL Server，也被叫做SQL Server堆。要針對合并來分析候選的SQL Server和他們的用戶數據庫，有三個部分。

1、分析數據訪問和利用模式，然后分析用戶數據庫安裝的SQL Server環境

2、在合并環境中復制這些模式，那么用戶感覺就會一致，即使不會更好的話。

3、調查其它任何用戶數據庫之外的合并機會。你能將多個SQL Server合并到一個簇中去嗎？你能合并存儲(磁盤陣列和存儲區域網絡)嗎？要合并例如SharePoint Team Services和 Windows SharePoint Services這樣的應用程序有意義嗎，哪一個傾向于快速增長？

讓我們看一下分析階段中的某個詳細方面吧。

你必須對于考慮進行合并的用戶數據庫的利用和訪問模式有一個很好的理解。例如，一些利用和訪問模式是周期性的。一些數據庫是24*7小時的提供訪問，而其它的一些有可能旨在周一到周五的早上9點到晚上5點。基于每小時、每天、每周、每月、每季度，或者每年的數據庫體驗峰值時間。

在業務時間內，SharePoint數據庫通常具有一致的使用方法，然而薪資數據庫卻在每周、每兩周，或者每倆月一次的發薪周期經歷更高的負載。記賬數據庫也可能會每季度或者每年經歷一次負載的高峰。要理解每個負載的周期性本質是非常重要的，這樣的話你就可以捕捉具有代表性的負載。然后，你可以在你的測試環境中使用這個負載，并根據高峰負載時間來進行計劃，而不需要破壞你的經過合并的SQL Server堆中的其它用戶數據庫。

在判斷數據訪問和數據使用模式的過程中，對客戶的交流還有一段很長的道路。他們不僅需要辨別使用峰值時間，還需要負載峰值時間（例如，當批處理任務將極端的負載加載到SQL Server上），以及幫助估計可預期的增長。

運行基本的正常檢查，例如DBCC CheckAlloc，還有檢查SQL Server的錯誤日至，調試堆的邏輯目錄，以及異常的應用程序日至，其中的任何一點都可能會指向問題或者存在問題的使用模式。有了這個認識之后，你的合并團隊就能夠使用SQL Profiler捕捉有代表性的負載，并且在合并解決方案中作為測試來重現它。然后，他們可以在測試解決方案中，從多個不同的SQL Server上同步在重現負載。在原始的系統中捕捉性能參數，然后與在測試的合并SQL Server上獲得的參數相比較，來量化性能的改善情況。第三章將會詳細討論那些需要收集的特定的性能計數器。

許多的依賴性斗可能會使得用戶數據庫成為合并的糟糕的候選人。這些依賴性要在事先進行辨認出是至關重要的，這樣你就可以為它們進行計劃，或者甚至是在它們上面工作。

步驟3：測試你的SQL Server合并

一旦你完成了對用戶數據庫的分析，你必須仔細決定要把哪個用戶數據庫放在堆棧中。

以下的幾種情況將會強制你在不同的實例中進行合并：

• 用戶數據庫具有不一致的名字沖突。
• 用戶數據庫中的tempdb使用頻繁。
• 來自沒有進過標準整理的SQL Server的用戶數據庫。

我將在本章稍后的內容中給出更加詳細的清單列表，表名為“在單個實例及多個實例中合并的對比”

有些情況下，你被強迫在運行以前版本的SQL Server上進行合并，通常稱為版本堆(version stack)。其中包括版本依賴性或者SQL 全文本搜索的過量使用等情況。

一旦你決定了將哪個數據庫放置在堆中，要仔細的檢查數據訪問和數據使用模式。這些將會幫助你將用戶數據庫在合并的SQL Server上進行分組，以提供優化的性能。例如，將具有較高負載的單個的用戶數據庫放在不同的堆中，然后將負載較低的用戶數據庫添加到這些堆中，并且觀察整體的性能。通過這種方式調整之后，你就會在硬件資源有限的情況下收到較優的吞吐量。

仔細地對你在默認的SQL Server和數據庫設置上進行的任何更改記錄文檔。

步驟4：在產品環境中部署合并數據庫

在你決定了用戶數據庫在合并的SQL Server堆上的最優位置之后，將用戶數據庫從他們當前的產品環境中一個接著一個地移動到新的合并拓撲中去。在你移動了每個用戶數據庫之后，監控對性能產生的影響來確保合并系統仍然保持了引入這些新的用戶數據庫之前的穩定性。

這里有很多種方式將用戶數據庫移動到合并環境中去。一種比較流行的方法就是將每個數據庫從它當前的環境中分離出來，拷貝到合并環境中去，然后把它們附加上去。

然而，復制將會妨礙你將發布的數據庫分離開來。如果你的數據庫是發布的，那么就最好不要復制，移動數據庫，然后重新構建發布和訂閱。在全文本分類的SQL Server 2000數據庫上， 你不得不手工拷貝數據庫和全文本的分類到合并環境中，正如微軟技術支持描述的一樣。也有可能使用拷貝數據庫想到，但是它對于不是小型數據庫的任何東西都無法升級。

在向業務擁有者開放合并數據庫之前，運行預熱腳本來確保第一個用戶在新的合并環境中的體驗不會是一個遲緩的感覺。

步驟5：監控并保持合并SQL Server 數據庫的穩定

即使是經過了最仔細的分析、測試和基準測量，你還是可能會在合并環境中發現驚喜。在合并過程的早期階段，項目團隊就對于通過監控和調整合并的SQL Server上面的用戶數據庫提供優化的性能很熟悉了。

一旦合并SQL Server成為產品，這些監控和調整技巧就會變得毫無價值。此時要調整一些較大的用戶數據庫，特別是當它們擁有外部依賴（例如復制或者全文本搜索）的時候，就會困難重重了，一些較小的可以輕松移動的用戶數據庫需要具有正當的理由，你還需要一個維護窗口。

監控應該允許你在很大程度上具有管理每個合并SQL Server方面的前攝性，特別是在尋找儲運損耗和性能問題的時候。許多商業的監控程序在這一點上都很理想，例如BMC 軟件公司的Patrol,微軟的 MOM ，以及Quest軟件公司的Spotlight等。

監控的目標不僅僅是對于問題具有前攝性，還要交付一個穩定的，統一的SQL Server解決方案，能夠為所有的用戶數據庫，還有更重要的是，能夠滿足或者查閱SLA協商內容的解決方案提供性能和高可用性。一個穩定的環境被定義為一個能夠充分服務所有負載，而不會帶來一丁點的性能下降的環境；從監控的角度來說，它就是一個安靜的服務器，不會產生任何性能警報。

一旦合并SQL Server的第一個階段是穩定的，移動第二階段的數據庫到下一個合并群中去。在第一階段接受的教訓在隨后的各個階段里面還會具有促進作用。

以上的貼士摘自我們最初的專家電子書《Planning your SQL Server consolidation》中的第二章“Consolidate SQL Servers for availability, scalability and cost savings”。本章內容解釋了合并的6個步驟，以及其它有關合并的關鍵考慮。