SQL Server 服務因登入失敗無法啟動：根因分析與三種解決方案

錯誤現象

SQL Server 服務 (MSSQLSERVER 或具名執行個體) 啟動失敗，事件檢視器記錄：「因登入失敗而無法啟動服務」 (Error 1069)。

根本原因

SQL Server 服務設定為以特定 Windows 帳號 (預設常為 Administrator 或安裝時指定帳號) 身分執行。若該帳號發生以下變更，服務將無法登入：

• 密碼變更 (定期輪換、人為修改)
• 帳號重新命名 (如 Administrator → Admin)
• 帳號被停用/刪除/鎖定
• 群組原則拒絕「以服務身分登入」權利

三種解決方案 (由易到佳)

方案一：還原帳號密碼 (最快復原)

1. 以具備帳號管理權限的使用者登入 Windows。
2. 開啟「本地用戶和群組」 (lusrmgr.msc)，將服務帳號密碼改回原值，或解除鎖定/啟用帳號。
3. 重新啟動 SQL Server 服務。

適用情境：臨時密碼變更、緊急上線前快速恢復。

方案二：更新服務登入認證 (標準運維)

1. 開啟「服務」 (services.msc)。
2. 找到 SQL Server (MSSQLSERVER) 或對應具名執行個體服務。
3. 右鍵 → 內容 → 登入 索引標籤。
4. 選擇 這個帳號，輸入更新後的帳號名稱與新密碼 (格式：Domain\User 或 .\LocalUser)。
5. 確定 → 重新啟動服務。

適用情境：密碼依政策定期輪換、帳號重命名後的永久修正。

方案三：建立專用服務帳號 (最佳實踐，強烈推薦)

1. 在 AD 或本機建立專用帳號 (如 svc_sqlengine)，設定密碼永不過期、不可變更密碼 (由管理解決方案如 gMSA 管理更佳)。
2. 授予 以服務身分登入 (Log on as a service) 權利：secpol.msc → 本地原則 → 使用者權利指派。
3. 授予資料庫資料/記錄檔目錄、備份目錄、TempDB 目錄的 修改/寫入 NTFS 權限。
4. 按方案二步驟將 SQL Server 服務登入身分更為此專用帳號。
5. (進階) 採用 群組受控服務帳號 (gMSA)：由 AD 自動輪換密碼、免管理 SPN、支援多伺服器，消除密碼過期風險。

優勢：隔離服務身分、避免人員異動/密碼政策影響生產、符合最小權限原則、利於稽核。

預防檢查清單

常見誤區

• 直接用 Domain Admin 執行 SQL 服務：極高風險，違反最小權限，一旦 SQL 被攻破即導致整個網域淪陷。
• 使用 Local System / Network Service：無法存取網路資源 (備份至 NAS、連結伺服器、複寫)，且權限過大 (Local System)。
• 安裝時留空密碼：僅限混合模式且 sa 為空密碼時允許，極不安全，生產環境嚴禁。