驗證更新是否沒有問題的好方法？
我不知道這是否是一個愚蠢的問題，但我正在將我的測試實例升級到 SQL Server 2014。在安裝累積更新之後，我已經安裝了 SP1。
它工作正常，但有沒有辦法測試它？像一些會因升級失敗而失敗的查詢或過程？
從sqlserverbuilds，我可以看到我有最後一個 SP1 （ SQL2014 的唯一一個）。
正如 TheGameiswar 所提到的，升級顧問對於指出升級可能出現的問題非常有幫助。但是，它只會檢查數據庫中的內容。因此，如果您正在執行臨時查詢，或者更糟糕的是 sql 文件散佈在各處，這些將不會被測試。
當我將我們的 SQL 2000 伺服器升級到 2014 年時，我們到處都有臨時查詢和 sql 文件正在執行，我們需要進行測試以確保它們不會盡我們所能破壞。所以我最終做的是複制我們的生產數據庫並將它們升級到 2014 年。之後，我開始在生產上進行一周的重放跟踪，以擷取所有正在執行的查詢。這讓我可以在 2014 年的伺服器上重放這些跟踪，看看是否會有任何問題。它幫助我找到了許多需要解決的問題。
在進行重放跟踪時要注意的一件非常重要的事情是，您需要確保生產環境和開發環境之間的數據庫 ID 匹配，因為這就是跟踪如何知道在哪個數據庫上執行每個查詢的方式。
如果您正在就升級到SQL 2014 尋求建議，或者您是否擔心將 CU 應用於 SQL 2014 SP1 實例，我不能 100% 確定。
假設您要問的是後者。
這是您在進行 SQL Server 修補時需要考慮的事項。這適用於所有 Microsoft 更新檔 - SQL SP 和 CU 以及 Windows 作業系統更新檔：
- 您可能以前聽過這個：確保先在非生產系統上安裝特定更新檔，然後再將它們安裝到生產伺服器上。並且在非生產安裝和生產安裝之間留出大約 1-2 週的時間。
- 如果您的非生產環境沒有經過負載測試並且不能 100% 匹配您的生產環境，那麼您無法確定只有在生產環境中安裝了更新檔後才會遇到一些奇怪的錯誤。
- 如果你不對非生產環境進行負載測試，最好的辦法是在 Twitter 上聽取 SQL DBA 社區的意見，以防微軟發出“噓聲”並發布一些重大的嚴重破壞事物的錯誤。
- 要考慮的另一件事是 TF 4199（查詢優化器修補程序跟踪標誌）。如果您啟用了此標誌，這將在您安裝包含查詢優化器修補程序的修補程序後啟用 SQL Server 修補程序中包含的查詢優化器修補程序。
注意：TF 4199 有點，雖然在 SQL 2014 中已被 COMPATLEVEL 設置取代，但後來微軟改變了主意，在 2014SP1 中再次開始使用 4199。現在微軟正試圖在 SQL2016 中再次擺脫 4199 - https://support.microsoft.com/en-us/kb/974006