一、選擇SQL Server升級方法
升級SQL Server的方法歸結為幾個業務目標：最短的停機時間、最少的花費、最小的風險。
這幾個目標通常是無法兼具的，以下每種方法都有利弊，因此根據業務情況選擇正確的升級方法非常重要。
1. 業界最常用的升級或遷移SQL Server方法
全備還原
附加和分離
就地升級
大型數據庫的差異還原
使用日志傳送升級SQL Server
滾動升級（停機時間最短）
2. SQL Server升級 vs 遷移
首先區別一下SQL Server中的遷移和升級術語，有時這些術語會被互換使用，但它們確實有一些不同之處。
1) 升級SQL Server意味着
只升級Edition，例如從SQL Server 2014標准版（SE）升級到SQL Server 2014企業版（EE）。
只升級Version，例如從SQL Server 2012（EE）升級到SQL Server 2016（EE）。
升級Edition和Version。例如從SQL Server 2012（SE）升級到SQL Server 2017（EE）。
Service Pack（SP）和累積更新（CU）的安裝相當於小版本升級。
2) 遷移可能包括也可能不包括SQL Server的升級，但這意味着將數據庫從一個實例移動到另一個實例。
例如更換SQL Server的物理機或操作系統
例如一個SQL Server實例上可能存在太多數據庫，並且維護作業執行與業務時間重疊，想分割負載。
例如同一VM機器上啟動了多個SQL Server實例，需要申請新的VM並移動一些實例到新機器。
例如將數據庫從本地遷移到雲，例如Azure。
當然，遷移還可以包括升級SQL Server。
下面我們討論上面列表中提到的升級方法思路，具體操作方法不一一列出了。
二、 使用全備+還原進行SQL Server升級
這是遷移期間升級數據庫的最基本、最簡單的方法，這種升級方法是50G以下的數據庫的理想選擇。
這其實就是異機全備+還原了，操作方法非常簡單，這里略了。
三、 使用分離和附加數據庫進行SQL Server升級
這是在遷移期間升級的另一種基本且簡單的方法，但注意它不是推薦的最佳實踐方法。思路與前一種方法基本相同，對於較小的數據庫，使用“備份和還原”進行升級更加安全可靠。
這不是推薦的遷移數據庫的方法，因為您可能會遇到各種類型的問題。例如，如果源與目標之間存在SQL Server排序規則差異，attach可能會失敗。
如果在新服務器上復制數據庫文件的目錄沒有SQL Server服務帳戶的適當權限，則可能會失敗。另一個重要原因是，如果在分離數據庫並嘗試附加之間的時間已經過了一兩天，文件可能被誤刪除。
如果服務器重新啟動，文件可能會損壞。
假設數據庫大於50 GB，並且還有預算限制。在這種情況下，哪種升級方法是合適的？
四、 就地升級
參考：https://blog.51cto.com/daisywei/1878767
此方法不能用於遷移，因為所有操作都發生在同一服務器上，因此稱為“就地升級”。這是最便宜、最快但卻最危險的升級方法，不建議在生產SQL Server使用。
由於是直接升級現有SQL Server實例（所有系統和用戶數據庫的系統對象都會升級），如果出現任何問題，很可能將無法回滾（虛擬機可以打快照、物理機做存儲快照）。預算較低且無法花錢購買硬件和軟件許可證的公司可以選擇這種方法，但是在升級失敗的情況下，回退舊版本的花費很可能更多，並且還需要更多時間。另一個警告是，在就地升級期間，無法添加其他SQL Server功能，只能在安裝完成后進行。
五、 差異還原升級
1. 場景
假設在sample模式下有一個大型數據庫，比如500 GB，在每周日晚進行一次完整備份，並在其他6晚進行差異備份。
此數據庫位於SQL Server 2012（源）上，另有一個SQL Server 2017實例（目標），希望升級和遷移源實例。這兩個SQL Server位於不同的數據中心，兩個數據中心之間的網絡帶寬為10 GB。進行遷移的唯一可用窗口是星期六早上，期望在2小時內完成遷移，隨后進行測試。
設置一個文件復制作業在星期日晚上的完整備份完成后運行，將備份文件復制到目標服務器。星期一早上，驗證目標服務器上的備份文件是否可用。
星期一晚上在目標服務器上以no Recovery 模式還原備份。
從星期二到星期五，利用作業復制備份文件到目標服務器並以no Recovery 模式還原差異備份。
星期六上午7點，維護窗口前一小時，在源服務器上啟動數據庫的最后一次差異備份。由於已精心計算，可以完美地計時並且備份在上午8點結束。立即將數據庫設置為只讀，避免丟失數據。
手動將最后一個差異備份文件復制到目標服務器並使用Recovery模式還原。
將兼容模式更改為最新，並將數據庫升級到新的SQL版本。
將應用程序連接指向升級后的數據庫，測試應用程序。
這種使用差異還原的方法在復雜性較低但數據庫很大的情況下工作很簡單。
關於回滾策略，如果升級失敗，只需將源服務器上的數據庫更改回讀寫模式，應用切回即可。
六、 使用日志傳送升級SQL Server/使用高性能模式的數據庫鏡像
其實這就是把前面那種手動備份+復制+還原的方法大部分讓sqlserver自動做了。
1. 場景
有2個企業版SQL Server 2012實例SQL1和SQL2，操作系統是Windows Server 2012 R2。SQL1到SQL2的數據庫DB3（500 GB）設置了事務日志傳送。
現在希望將這些企業版SQL Server 2012升級到標准版SQL Server 2017以節省許可成本，還希望利用2017的一些新功能。自SQL Server 2016 SP1以來，微軟已在SE中提供了許多EE級功能，例如壓縮和數據庫快照等。
2. 執行
決定使用當前的日志傳送設置進行並排升級。當前的Windows Server 2012 R2操作系統支持SQL Server 2017，因此無需升級操作系統。計划首先升級SQL2，如果出現任何問題，回滾計划是將應用程序切回SQL Server 2012的SQL1實例。
當前生產環境日志傳送簡圖（均為2012 EE）：
注意SQL Server 2012 EE無法直接升級到SQL Server 2017 SE，因為這是從高edition降到了低edition 。因此需要在Domain2中安裝另一個SQL Server 2017 SE版本的SQL3實例，如果是2012 EE到2017 EE，則不需要。
以下是使用SQL Server日志傳送升級和/或遷移數據庫的一般步驟：
停掉實例SQL1和SQL2上的日志傳送作業
在SQL1上，使用NORECOVERY選項對DB3的last事務日志進行備份。使用NORECOVERY選項進行日志備份時，會將DB3數據庫置於還原模式，這樣將沒有用戶可以連接到它
BACKUP LOG [DB3] TO DISK = 'C:\SQLBackups\DB3.trn' WITH NORECOVERY;
手動在SQL2上運行復制和還原作業以確保應用所有日志（若已應用可略過）
手動復制對DB1進行的last日志備份，並使用WITH RECOVERY選項在SQL2 DB3上手動進行還原。使用with recovery應用日志時，DB3將在SQL2上online
RESTORE LOG DB3 FROM DISK = 'C:\SQL2012\SQL2\LogShip\DB3.trn' WITH RECOVERY
在SQL2上完整備份DB3
在SQL3上還原DB3，將DB3兼容級別更新為140
USE [master]
GO
ALTER DATABASE [DB3] SET COMPATIBILITY_LEVEL = 140
GO
將應用程序連接到SQL3的DB3進行測試，SQL3現在是新的主實例
如果驗證成功，則升級已經完成后，可以在此處停止。但是，如果要創建日志傳送，還需執行以下后續步驟
在Domain1中安裝SQL Server 2017實例SQL4，將作為新的輔助SQL Server
創建從SQL3到SQL4的日志傳送
卸載SQL1和SQL2實例
3. 使用日志傳送升級的優點
大多數數據可以預先移動到目標SQL Server，在實際數據遷移時需要的停機時間更少。如果數據庫非常大，並且源和目標SQL實例位於不同的域中，這將特別有用。
與就地升級相比，有了回滾方案，如果輔助數據庫的升級不順利，可以通過將應用程序連接回舊數據庫版本來回滾。要使舊數據庫聯機，只需發出以下命令：
RESTORE DATABASE [DB3] WITH RECOVERY;
一個主數據庫可以有多個輔助數據庫。升級一個輔助數據庫后，它可以作為其余輔助服務器的主數據庫。
4. 使用日志傳送升級的優點
故障轉移不方便
應用程序停機是不可避免的，而且時間可能還是比較長
日志傳送需要另一個SQL Server，因此需要額外的硬件和許可成本。
必須為每個數據庫設置事務日志傳送，如果有超過20個數據庫，你會崩潰的。在這種情況下，對大於50 GB的數據庫，建議使用“日志傳送”方法。對於小於50 GB的數據庫，建議使用“全備還原”升級方法。50 GB不是微軟設置的數字，是個經驗值。
七、 滾動升級
對於核心數據庫，業務要求停機時間最短，例如在5分鍾內完成Windows和SQL Server升級。此時應該如何規划？
1. 滾動升級
滾動升級需要至少2個SQL Server實例。升級前，主服務器和從服務器始終保持同步。可用性組（AlwaysOn AG）是進行滾動升級的一種方法，通過此方法，可保證最短的停機時間（用戶、作業、鏈接服務器等在從服務器上都可用並准備就緒）
當應用程序連接到主節點時，進行從節點升級。只要從實例版本不低於與主節點，AG同步就不會斷。不過在從節點進行升級時，事務在從服務器上將被阻塞，直到升級完成。當從實例完成升級時，確保從庫已應用所有事務（建議設為同步模式）並且兩個數據庫都處於同步狀態，然后再手動故障轉移到輔助實例，此步驟可確保故障轉移期間零數據丟失。
升級后的輔助節點承擔主節點的角色，在舊主節點的版本與新主節點相同之前，事務不會在舊主節點應用。升級完成后，可以選擇故障轉移回到原主節點。在滾動升級中，應用程序基本不會停止（切換期間有中斷）。
2. 業務場景
有一個業務關鍵數據庫（500 GB），已設置2節點AG（SQLA和SQLB）。這些SQL Server運行在最新的Windows操作系統，版本為SQL Server 2016 SP2。現在需要將它們升級到SQL Server 2017，在升級過程中，需要保證始終有主從同步、同時停機時間最短。
3. 執行步驟
由於要求保證始終有主從同步，需要再建一個SQLC實例，作為第三個異步副本添加到AG（一主兩從）
SQLA SQLB SQLC AG1
Primary Secondary （同步） Secondary （異步）
首先升級SQLC。在升級時，SQLA和SQLB處於同步狀態，應用程序正常運行
下一步升級SQLB。在升級時，SQLA和SQLC保持同步，應用程序正常運行（A主C從，A版本低於C）
升級並同步SQLB后，將AG1故障轉移到SQLB。SQLB 變為主庫，應用程序通過vip連接到SQLB。SQLC開始與SQLB同步。SQLA無法同步，因為其版本低於主庫SQLB
升級SQLA
等待SQLA升級完成后重新與SQLB同步
如果您願意，可以在升級后將主庫故障轉移回SQLA
參考
https://www.mssqltips.com/sqlservertip/5646/choosing-a-sql-server-upgrade-method--part-1/
https://www.mssqltips.com/sqlservertip/5652/sql-server-upgrade-methods-inplace-upgrades-and-differential-restore-upgrades--part-2/
https://www.mssqltips.com/sqlservertip/5669/side-by-side-sql-server-upgrade-with-log-shipping--part-3/
https://www.mssqltips.com/sqlservertip/5737/minimizing-downtime-for-sql-server-upgrades--part-4/
https://www.mssqltips.com/sqlservertip/1233/differential-database-backups-for-sql-server/
http://www.sqlservercentral.com/articles/SQL/152815/
https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/upgrading-always-on-availability-group-replica-instances?view=sql-server-2017
————————————————
版權聲明：本文為CSDN博主「Hehuyi_In」的原創文章，遵循CC 4.0 BY-SA版權協議
原文鏈接：https://blog.csdn.net/Hehuyi_In/article/details/89670209