計劃執行SQL Server的合並是一項巨大的任務。你可以通過將其分解成獨立的組件來簡化這個項目，如下面的步驟指南所示：
這篇信息是從我們最初的專家電子書《Planning your SQL Server consolidation》中的第二章“Consolidate SQL Servers for availability, scalability and cost savings”中摘錄出來的。這章內容解釋了有關合並的5個步驟，以及其它關鍵的合並考慮。
作者簡介：Hilary Cotter
Hilary Cotter在IT這一行業已經超過了20年，他是一名網絡和數據庫顧問。微軟在2001年首先授予了Cotter微軟SQL Server MVP榮譽。Cotter在多倫多大學得到了機械工程專業的應用科學學士學位，然後在卡爾加裡大學學習經濟，以及伯克利學院學習計算機科學。他編寫了一本有關SQL Server事務復制的書籍，現在正在撰寫的是一本有關合並復制和微軟搜索技術的書籍。
步驟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、在合並環境中復制這些模式，那麼用戶感覺就會一致，即使不會更好的話。
