SQL Server 就地升級是否像以前那樣不明智？
自 SQL Server 6.5 以來，我一直在開啟和關閉 SQL Server，我腦海中仍然響起的舊建議是永遠不要進行就地升級。
我目前正在將我的 2008 R2 DEV 和 TEST 系統升級到 SQL Server 2012，並且需要使用相同的硬體。不必恢復我的 Reporting Services 配置的想法非常有吸引力，而且我真的很難在時間上明智。不涉及任何分析服務或任何異常或非標準 - 僅安裝數據庫引擎和報告服務。
有沒有人遇到過就地升級的嚴重問題？還是我應該重新評估我對就地升級的立場？
非常簡短的回答- 就地是可以的。之後您可以查看您的配置並實施 SQL Server 2012 的最佳實踐。
SQL Server 升級/遷移的更長答案
所以這是一個意見問題，不一定有錯誤或正確的答案，但出於很多原因，我更喜歡遷移風格升級而不是就地升級。話雖如此 - 我的一些客戶由於各種原因別無選擇，只能就地進行，實際上自 SQL Server 2005 以來，就地升級並沒有以前那麼糟糕。
為什麼我更喜歡遷移而不是就地升級
- 更容易回滾- 如果出現問題，您可以通過簡單地說“我們中止升級。請在我們解決此問題時將連接字元串更改為舊伺服器”來回滾。使用原位，您正在修復它，或者您失敗了。
- 刷新硬體- 硬體變化很快。通過就地升級，您很容易陷入 4 年前適合您公司的硬體，但不適用於今天和未來四年的硬體。無論如何，您可能必須在某個時候為新硬體進行遷移。
- 感覺更好- 當然…這是主觀的，但是知道您從新的作業系統安裝開始感覺很好今天）這可能會在未來讓你頭疼。
- 新作業系統- 如果您今天不是最新最好的作業系統，遷移讓您有機會從新的作業系統版本開始。
- 您可以對其進行測試- 在安裝 SQL 並將其與數據庫和使用情況混為一談之前，是否曾經想在一台新機器上獲得一組基線？你現在可以這樣做了。
- 有時潛入最佳實踐更容易——也許 SQL Server 服務帳戶是本地管理員。也許 Builtin Administrators 是 SA 伺服器角色。也許之前有些事情已經被破解在一起以使其正常工作。您可以解決所有問題並重新開始。
- 免費的測試環境和額外的睡眠- 當您啟用這個新環境時，擁有一個可以在實際切換日之前工作的環境是一個很大的好處。遷移到新環境意味著您可以在工作時間建構它，遠遠早於您的實際切換日，並提前以多種方式對其進行測試。您可以在所有應用程序和系統上執行數天的完整回歸測試，並在實際執行最後一組還原/附加和切換所有應用程序和訪問新環境之前高枕無憂。
- 您不必一次全部完成- 我遇到的一個非常常見的情況是一個試圖整合到幾個實例的環境。也許每個版本一個，也許每個“層”和版本一個。根據測試、項目計劃和供應商認證的及時性，這些項目中的許多項目對各種應用程序和數據庫都有不同的時間表。進行遷移意味著您可以移動那些準備就緒的數據庫，當它們準備就緒時，仍然可以處理那些由於某種原因無法移動的數據庫的請求。
請注意，我並不是說您必須將其作為遷移來執行。如果您不打算在預算範圍內購買新硬體並且無法為此次升級購買新硬體，則 In-Place 可以正常工作。升級過程中的支持比 6.5 天要好得多，因此您不會讓自己處於不利地位。
如果您確實計劃就地進行開發/測試，但想要進行生產遷移，您可以考慮在生產之前至少進行一次遷移。通過這種方式，您可以提前製定清單並處理您沒有想到的任何潛在問題。
附加/分離與備份/恢復遷移
如果您決定採用遷移方法，還有一個您可能仍然需要爭論的決定，那就是您如何將數據庫遷移到新環境。您可以將數據庫與舊伺服器分離並將其附加到新伺服器，也可以將其備份並在那裡恢復。
我更喜歡備份/恢復。我聽說分離/附加的最大優勢是它節省了一些時間。對我來說，備份/恢復勝出有幾個原因：
- 保持舊的可訪問- 這允許您在源伺服器上仍然擁有可訪問的數據庫。分離/附加應該做同樣的事情，但它需要幾個步驟，並且分離/附加存在人為錯誤的空間，這可能會使這複雜化。
- 你保證你有一個備份——你已經確保你已經進行了備份，而不是僅僅從分離中獲取數據庫並可能忘記備份步驟。
- 人為錯誤- 如果您刪除了錯誤的文件、忘記了發送內容的位置或以其他方式弄亂了您的步驟，那麼為數據庫移動數據和日誌文件會冒很大的風險。現在你可以通過複製而不是剪切來緩解這種情況（如果你分離，你應該擺脫剪切和粘貼的習慣），但你仍然可能會搞砸。SQL Server 不再鎖定這些文件，而且意外刪除文件太容易了，我冒著風險。
- **它並沒有那麼慢-**備份和複製它需要更多時間，但我願意為此付出額外的風險並不多。事實上 - 使用完整恢復模型和日誌備份，您可以將停機時間縮短到更低，如下面的“如何使遷移方法更快”中所述
如果您決定進行備份/恢復 - 這意味著您的舊源數據庫仍將線上。我喜歡在備份後使該數據庫離線。在編寫安全、作業、連結伺服器、證書、數據庫郵件設置和其他實例範圍的資訊後，有時我會更進一步，使整個 SQL 實例離線。這避免了在測試期間有人說“一切看起來都很棒！”的問題。一兩天后才意識到他們一直在與舊伺服器上的舊數據庫通信。使這些數據庫離線或整個實例離線可以防止這些誤報和它們造成的混亂。
如何使遷移方法更快
對於繁忙的生產環境，您可以通過使用完全恢復模型最大限度地減少從舊環境切換到新環境所需的停機時間，而停機時間很少。基本上 - 通過恢復最新的完整備份、任何差異備份和任何已採取的日誌備份指定您要遷移到的環境
NORECOVERY- 然後您為最終切換要做的就是恢復尚未恢復的日誌備份和您希望恢復的最終日誌備份，指定WITH RECOVERY. 通過這種方式，對於大型數據庫，通過在停機時間視窗之前支付完整、差異和大多數日誌恢復的成本，可以大大減少實際的切換停機時間視窗。感謝陶在評論中指出這一點！如何使就地升級更安全
在選擇就地方法時，您可以做一些事情來改善您的體驗和結果。
- 備份- 提前對您的環境中的所有使用者和系統數據庫進行適當的備份，並確保它們是好的（我很偏執..我實際上會先在某個地方恢復它們才能真正知道它們是好的..可能會浪費你的時間。 . 但是如果發生災難，您可能會感謝自己）.. 編寫有關該環境中 SQL 和 OS 安裝的任何配置資訊。
- 在開始之前做好測試- 驗證您是否擁有良好的環境和良好的數據庫。您應該做一些事情，例如查看錯誤日誌並定期執行 DBCC CHECKDB，但在進行就地升級之前是開始的好時機。提前解決任何問題。
- 確保作業系統健康——不要只是確保 SQL 是健康的，還要確保你的伺服器是健康的。您的系統或應用程序錯誤事件日誌中有任何棘手的錯誤嗎？你的空閒空間怎麼樣？
- 為最壞的情況做準備——我不久前有一個部落格文章系列，其前提是如果你不為失敗做準備——你實際上是在準備失敗……我仍然相信這一點。因此，請仔細考慮您可能遇到的問題並提前相應地處理它們。讓自己處於“失敗”的心態中，你會想到否則你不會想到的事情。
升級或遷移清單的重要性
如果您決定進行升級（無論是就地升級還是遷移），您應該認真考慮創建一個清單並在每個環境中使用此清單。您應該在此清單中包含很多內容，其中最重要的是：
- 開始- 執行一些操作，例如執行測試升級，在最新的數據庫兼容性級別上測試您的應用程序，並考慮提前執行SQL Server Upgrade Advisor之類的工具，以查看在執行 SQL 之前需要完成哪些類型的任務伺服器升級或遷移。
- 預步驟- 清理、作業系統任務、提前打更新檔、為升級準備應用程序（乾淨關閉、連接字元串工作）、備份等。
- 升級/遷移步驟- 為使升級或遷移成功並按正確順序執行的所有操作。安裝、更改（或不更改，取決於您的測試和方法）對數據庫的兼容性模式更改等。
- 遷移/升級後步驟- 各種測試、發布新版本或新伺服器配置選項、最佳實踐實施、安全更改等。
- 回滾步驟- 在整個過程中，您應該有回滾步驟和里程碑。如果你走到這一步並且發生這種情況，你會怎麼做？什麼是“完全回滾”標準？以及如何進行回滾（反向連接字元串更改、更改設置、返回舊版本、重新安裝（如果有）、如果遷移則指向舊伺服器等）
然後讓將進行生產升級的人在生產以外的某些環境中遵循清單 - 特別是如果可能的話，關閉類似於生產的環境（“產品以南”，正如我所說……）並註意任何問題或要點由於缺少清單，他們不得不從清單中轉移或即興創作。然後將更改合併，並享受您的生產更改的樂趣。
我不能過分強調在遷移或升級後和遷移之前進行徹底測試的重要性。在升級過程中做出回滾決定應該很容易——尤其是在遷移期間。如果有什麼不舒服的地方，請回滾並找出是否在遷移過程中無法有效可靠地解決問題。一旦您生活在這個新環境中並且使用者連接 - 回滾就成為一項艱鉅的任務。您無法將 SQL Server 數據庫還原到早期版本。這意味著手動工作和數據遷移。我總是等待幾個星期來殺死舊環境，但你應該盡你所能避免需要舊環境，方法是在你的實時使用者接觸新環境之前找到所有問題。最好在您開始升級/遷移之前。
關於 SQL Server Reporting Services 遷移/升級 的快速說明 遷移 SSRS 安裝並不是許多人認為的艱鉅任務。這篇technet/books 線上文章實際上非常方便。該文章中最重要的警告之一是**“備份加密密鑰”，**特別是如果您保存了大量敏感資訊，例如預定報告電子郵件收件人電子郵件地址、大量連接的連接資訊等。您不久前可以問我的一位客戶這有多重要。他們知道，因為我搞砸了這一步，並花了很多時間修改報告計劃和連接字元串權限。