升級失敗… Orz
摘要提示
- 升級動機: 看到 Community Server 官方推出 2.1 SP2，想從 2.0 RTM 升級。
- 升級準備: 先做 shadow copy 備份，依說明更新檔案並執行升級腳本。
- 升級步驟: 依流程執行 2.x → 2.1 的 SQL 升級腳本與檔案更新。
- 問題發生: 升級後整個 CS 開不起來，無法正常啟動。
- 錯誤回報限制: CS 內建錯誤回報機制隱藏詳細訊息，只顯示有錯誤。
- 診斷困難: 因錯誤資訊不足，無法快速定位問題原因。
- 外在干擾: 小孩在旁吵鬧，影響處理與排錯的專注度。
- 風險控管: 立即使用 shadow copy 還原，恢復升級前狀態。
- 後續計畫: 暫緩處理，擇日再試升級。
- 情緒註記: 以 Orz 表達升級受挫的無奈與挫折感。
全文重點
作者因看到 Community Server 官方釋出 2.1 SP2，評估與目前使用的 2.0 RTM 相隔已久，決定進行升級。為降低風險，先行建立 shadow copy 備份，再依官方指引完成檔案更新，並執行從 2.x 升至 2.1 的 SQL 升級腳本。然而升級完成後，整個 Community Server 無法啟動。由於 CS 具有自身的錯誤回報機制，詳細錯誤訊息被遮蔽，只知道「有錯誤」卻缺乏可用的診斷資訊，使得排查困難。當下又因小孩在旁干擾，無法專心處理問題，作者便果斷使用先前的 shadow copy 進行還原，讓系統回復到升級前的可用狀態，並決定暫時擱置升級工作，待日後再戰。全文呈現一次看似按表操課的常規升級，卻因錯誤資訊不透明與現場干擾而失敗的經驗，並凸顯事前備份在突發狀況下提供快速回復的重要性，同時也傳達作者面對受挫時的無奈心情。
段落重點
升級動機與準備
作者注意到 Community Server 官方已發佈 2.1 SP2，認為與手上的 2.0 RTM 版本相隔許久，決定嘗試升級。為控制升級風險，先做 shadow copy 作為備份點，接著依照官方說明逐步操作，包括更新應用程式檔案與準備執行資料庫升級腳本，基本準備工作完整且遵循流程。
升級步驟與問題
在實際施作上，作者依序執行 2.x → 2.1 的 SQL 升級腳本並完成檔案更新。然而升級完成後，整個 CS 站台無法啟動。更棘手的是，CS 內建的錯誤回報機制隱藏了詳細例外資訊，只顯示發生錯誤，導致無法快速釐清是哪個環節出錯，是檔案、設定或資料庫遷移造成的問題，排錯起點受限。
還原處置與後續計畫
在無法取得足夠錯誤資訊且現場環境（小孩吵鬧）不利於專注除錯的情況下，作者選擇務實地回復服務可用性，立即透過先前建立的 shadow copy 進行還原，系統恢復到升級前狀態。升級作業暫時中止，確定擇日再戰。全文以輕鬆卻無奈的語氣收束，強調備份的重要與實務上排錯環境對成功與否的影響。
資訊整理
知識架構圖
- 前置知識：
- 了解 Community Server（CS）的版本與架構（Web 應用 + SQL 資料庫）
- 基本備份/還原概念（例如使用 Shadow Copy/快照）
- 資料庫管理與執行升級 SQL Script 的能力
- Web 伺服器（IIS/ASP.NET）與錯誤日誌/Custom Errors 設定
- 升級流程規劃（維護時段、回滾機制）
- 核心概念：
- 版本升級：從 2.0 RTM 升到 2.1 SP2 的檔案與資料庫同步升級
- 備份與回滾：以 Shadow Copy 先做快照，升級失敗可立即復原
- 升級腳本：執行 2.x -> 2.1 的 SQL 升級腳本影響資料結構/資料
- 錯誤可觀測性：CS 內建錯誤回報機制可能隱藏細節，需調整以取得診斷資訊
- 風險控管：在受干擾或無法專注時避免動手、預留重試計畫
- 技術依賴：
- CS 應用程式依賴 IIS/ASP.NET 執行環境與 SQL Server 資料庫
- 升級順序依賴：先更新檔案，再執行資料庫升級腳本，兩者需匹配版本
- 錯誤回報/Custom Errors 設定影響診斷資料取得（需存取伺服器端日誌）
- Shadow Copy/快照技術作為檔案/系統層級的快速回復機制
- 應用場景：
- 升級傳統 Web 平台（如 CS）的小版或 Service Pack
- 升級失敗的快速回復與故障診斷
- 在受限時間或干擾環境下的升級風險管理
- 維運流程標準化（備份、驗證、回滾、再嘗試）
學習路徑建議
- 入門者路徑：
- 認識 CS 架構與版本相容性、閱讀官方升級說明與發行說明
- 學會在檔案與資料庫兩側做完整備份（含 Shadow Copy/DB 備份）
- 建立測試環境複製正式站，先在測試環境演練升級
- 進階者路徑：
- 研究升級 SQL 腳本的變更（Schema 差異、資料遷移步驟、是否可重複執行）
- 配置診斷：關閉自訂錯誤頁或打開詳細錯誤、集中式日誌與監控
- 制定回滾策略與驗證清單：升級後健康檢查、功能驗證、自動化腳本
- 實戰路徑：
- 升級前：凍結變更、通知使用者、設定維護時段、完成快照與 DB 備份
- 升級中：依序更新檔案、執行 SQL 升級、即時檢查事件與應用程式日誌
- 失敗處理：若無法啟動，先取得詳細錯誤再決定修正或回滾（用 Shadow Copy）
- 升級後：驗證關鍵功能、監控一段時間、整理教訓並調整流程
關鍵要點清單
- 完整備份/快照：升級前務必做檔案與資料庫備份（如 Shadow Copy）以便回滾 (優先級: 高)
- 先測後上：於測試環境演練升級流程，避免在正式環境踩雷 (優先級: 高)
- 升級順序正確：先更新程式檔案，再執行對應版本的 SQL 升級腳本 (優先級: 高)
- 版本相容性：確認 2.0 -> 2.1 SP2 的相依條件與相容變更 (優先級: 高)
- 錯誤可視性：關閉自訂錯誤頁/開啟詳細錯誤與日誌以取得具體訊息 (優先級: 高)
- 回滾機制：規劃並測試回滾流程，失敗時能快速恢復服務 (優先級: 高)
- 維護時段：選擇低流量時段並公告，減少影響與壓力 (優先級: 中)
- 日誌與監控：集中收集應用程式、IIS、SQL 的日誌供故障分析 (優先級: 中)
- 升級文件：嚴格依官方升級指南與發行說明操作 (優先級: 高)
- 變更凍結：升級前凍結程式與資料庫變更，降低不確定性 (優先級: 中)
- 腳本冪等性：檢查 SQL 升級腳本是否可重複執行、是否需事前檢查狀態 (優先級: 中)
- 功能驗證清單：升級後依清單逐項驗證關鍵功能可用 (優先級: 高)
- 環境一致性：確保測試與正式環境在版本與設定上足夠一致 (優先級: 中)
- 風險控管：在無法專注或資源不足時暫緩升級，避免擴大問題 (優先級: 中)
- 事後檢討：失敗案例要整理成知識庫，調整下次升級策略 (優先級: 低)
