SQL Server 服務啟動數秒後自動停止：如何從 ERRORLOG、服務帳戶、master 與 tempdb 找出原因？
SQL Server 啟動後停止應先讀取 ERRORLOG 和 Windows 事件，再檢查服務帳戶、啟動參數、系統資料庫、磁盤與修補程式。
先控制風險，再實施變更建議先在測試環境或單一對象上驗證，保存設定、日誌和可復原備份。涉及生產切換、批次策略、資料庫修復或儲存重建時，應設定維護時段和明確復原條件。
1. 結論與適用範圍
服務控制器只會顯示啟動失敗，真正原因通常記錄在 SQL Server ERRORLOG。不要反復啟動或重裝覆蓋證據，應先定位日誌檔案和最後一個錯誤，再判斷是權限、路徑、系統資料庫、連接埠、資源還是修補程式問題。
該問題涉及 SQL Server、ERP、資料庫復原或版本遷移。任何高風險操作前都應保留可驗證備份。
2. 需要優先關注的風險信號
- 服務顯示“啟動後停止”，事件 17058、17113、17204 或 945 等。
- 近期修改服務帳戶、磁盤盤符、資料庫路徑、防毒策略或修補程式後發生。
3. 遷移或處理前的檢查清單
- 從 SQL Server Configuration Manager 確認實例、服務帳戶和啟動參數。
- 讀取當前 ERRORLOG 與應用程式事件，找到第一個致命錯誤而非最後的停止提示。
- 檢查 master、model、msdb、tempdb 路徑、目錄權限、磁盤空間和檔案損壞。
- 檢查連接埠佔用、證書、TLS、服務帳戶密碼和“作為服務登入”權限。
唯讀檢查與驗證範例
sc query MSSQLSERVER
Get-WinEvent -FilterHashtable @{LogName="Application"; ProviderName="MSSQLSERVER"} -MaxEvents 30
netstat -ano | findstr :1433corp.example、192.0.2.0/24 與 203.0.113.0/24 均為檔案範例。只有在確認實際環境參數後，才能取代為實際值。
4. 推薦實施步驟
- 修復明確的路徑或權限後再啟動，每次只改變一個條件。
- tempdb 路徑無效時復原到可用目錄；系統資料庫損壞時按備份和重建方案處理。
- 服務帳戶變更必須透過 Configuration Manager，不直接在 services.msc 隨意修改。
- 保留 ERRORLOG、事件和操作記錄，必要時先複寫資料庫檔案再進行高風險修復。
遙距還是現場處理？日誌、設定和少量對象通常可先遙距評估；涉及物理伺服器、儲存、機房供電、批次切換或復原演練時，應安排受控現場維護時段。浙江、上海、江蘇可根據項目情況上門，其他地區可遙距協助。
5. 驗證、復原與常見誤區
- 服務穩定運行並透過多次重新啟動。
- 所有資料庫在線，SQL Agent、備份、應用程式連線和監聽連接埠正常。
- 事件日誌沒有持續 I/O、權限、復原或斷言錯誤。
常見錯誤做法
- 刪除 master 或日誌檔案。
- 看到磁盤有空間就排除所有儲存問題。
- 未經分析反復重裝 SQL Server。
常見問題
服務啟動後停止是否一定是資料庫損壞？
不是，帳戶、權限、路徑、連接埠、證書和修補程式都可能導致。
能否直接刪除 tempdb 檔案？
應先確認啟動參數和路徑，按受控方式處理，不能在未知狀態下隨意刪除。