升級不踩雷：DBA 必讀的五大致命盲點
SQL Server 升級/遷移看似例行公事，實則暗藏殺機。Roman Rehak 總結五大常見錯誤，逐項拆解應對之道。
1. 測試不足：只跑「能連線」不跑「真實負載」
- 必須測試 所有連接應用、SSIS 套件、Agent 作業、複寫、連結伺服器、CLR 組件、動態 SQL。
- SQL 2000 → 2005/2008 語法大幅變更（如
NOLOCK 需加 WITH、*= 外聯結棄用），對所有預存程序執行 sp_recompile 或 ALTER PROC ... WITH RECOMPILE 強制重編譯，並實際執行每支程式碼驗證。
- 動態 SQL 錯誤無法靜態偵測，唯有實跑工作負載才能暴露。
2. 未讀升級白皮書
- 微軟每版本提供 Upgrade Advisor / Data Migration Assistant (DMA) 白皮書，列出棄用功能、行為變更、相容性層級影響。
- 雖枯燥，但完讀並標註專案相關項目，可避免上線後發現關鍵功能失效（如
FASTFIRSTROW、COMPUTE BY 等舊語法）。
- 若時間極緊，至少確認「下版本移除功能」清單並優先修正。
3. 主觀假設現有硬體能跑新版本
- 新版本通常需更多記憶體、CPU、I/O（如 2005 比 2000 門檻大幅提高）。
- 唯一驗證方式：同樣硬體安裝新舊版本，跑基準測試對比；或用虛擬化隔離環境 A/B Test。
- 硬體老舊（>5 年）時，升級常須同步換鐵，納入專案預算與時程。
4. 未調整相容性層級
- 還原舊版備份到新版本後，資料庫預設保留舊相容性層級（如 90 = 2005），舊語法仍能跑，造成「升級成功」假象。
- 必須 逐一將所有使用者資料庫（含 model、msdb）調整為新版本相容性層級（如 110 = 2012），並完整回測。
- 緊急時可暫時調回舊層級賺時間，但須設定截止日期強制遷移。
5. 沒有回滾計畫
- 備份 ≠ 回滾計畫。複寫環境下，單純還原資料庫會導致複寫拓撲破裂，需
sp_removedbreplication 重建。
- 24/7 系統採用 並行升級策略：新硬體佈署新版本 → 雙寫/資料同步 → 驗證無誤 → 切換 DNS/連接字串 → 保留舊環境 48h 觀察。
- 定義明確的 Go/No-Go 標準（錯誤率、效能基準、關鍵功能清單），達標才切換。
升級專案檢核表
階段關鍵動作產出物
| 規劃 | 清查所有相依物件、讀白皮書、建基準測試 | 升級規格書、風險登記冊 |
| 測試 | DMA 掃描、完整回測、效能對比、相容性層級切換驗證 | 測試報告、已知問題清單 |
| 預演 | 生產資料匿名化子集演練、計時、文件化步驟 | 標準作業程序 (SOP)、回滾腳本 |
| 上線 | 維護窗口執行、即時監控、Go/No-Go 決策點 | 上線確認單、事後複盤報告 |
