共用方式為


執行更新資料庫文本時,SQL Server 升級失敗,錯誤碼為 574

本文可協助您針對 SQL Server 累積更新 (CU) 或 Service Pack (SP) 報告執行資料庫升級腳本時發生錯誤 574 的問題進行疑難解答並加以解決。

徵兆

當您套用 CU 或 SP 時,安裝程式可能會回報下列錯誤:

等候 Database Engine 復原控制代碼失敗。 請檢查 SQL Server 錯誤記錄檔以了解潛在原因。

當您檢閱 SQL Server 錯誤記錄檔時,您可能會注意到下列錯誤訊息:

Error: 574, Severity: 16, State: 0.
CONFIG statement cannot be used inside a user transaction.
Error: 912, Severity: 21, State: 2.
Script level upgrade for database 'master' failed because upgrade step 'sqlagent100_msdb_upgrade.sql' encountered error 574, state 0, severity 16.
This is a serious error condition which might interfere with regular operation and the database will be taken offline.
If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting.
Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.
Error: 3417, Severity: 21, State: 3.
Script level upgrade for database 'master' failed because upgrade step 'msdb110_upgrade.sql' encountered error 15173, state 1, severity 16

原因

更新程式可能會在交易內執行一些升級腳本。 這些更新文本的設計假設使用者不會變更系統對象和相關聯的許可權。 如果您不小心對系統物件或許可權進行任何變更,其中有些腳本可能會失敗,而且相關聯的交易可能會變成孤立且保持開啟狀態。 在此案例中,當安裝程式稍後執行用來設定某些組態值的升級腳本 sp_configure 時,會發生錯誤 574。 安裝失敗的實際原因應該取決於檢閱錯誤 574 之前記錄的專案。

例如,類似下列的腳本可能會導致錯誤 574:

BEGIN TRAN
USE MASTER;
GO
EXEC sp_configure 'recovery interval', '4';
RECONFIGURE WITH OVERRIDE;
COMMIT TRAN

解決方法

若要解決此問題,請遵循下列步驟:

  1. 使用 追蹤旗標 902 啟動 SQL Server。 如需詳細資訊,請參閱 使用追蹤旗標 902 啟動 SQL Server 的步驟。

  2. 開啟 SQL Server 錯誤記錄檔,並檢閱錯誤 574 之前的訊息,以識別失敗的交易(請參閱下列 範例模式)。

  3. 根據 [可能原因和解決方案] 區段中的資訊修正失敗的交易。

  4. 從啟動 參數 專案移除追蹤旗標 902,然後重新啟動 SQL Server。

    一旦 SQL Server 在沒有追蹤旗標 902 的情況下啟動,升級腳本將會再次執行。

    • 如果SP/CU 升級文本順利完成,您可以檢查 SQL Server 錯誤記錄檔和啟動程式資料夾以確認。
    • 如果升級腳本再次失敗,請檢查 SQL Server 錯誤記錄檔中是否有其他錯誤,並針對新的錯誤進行疑難解答。

範例模式:授與系統角色許可權的問題

2020-08-17 09:38:12.09 spid11s Adding user 'hostname\svc_sqlagent' to SQLAgentUserRole msdb role...
2020-08-17 09:38:12.09 spid11s
2020-08-17 09:38:12.09 spid11s Granting login access'##MS_SSISServerCleanupJobLogin##' to msdb database...
2020-08-17 09:38:12.10 spid11s A problem was encountered granting access to MSDB database for login '(null)'. Make sure this login is provisioned with SQLServer and rerun sqlagent_msdb_upgrade.sql
2020-08-17 09:38:12.10 spid11s A problem was encountered granting access to MSDB database for login '(null)'. Make sure this login is provisioned with SQLServer and rerun sqlagent_msdb_upgrade.sql
2020-08-17 09:38:12.10 spid11s
2020-08-17 09:38:12.10 spid11s Adding user '##MS_SSISServerCleanupJobLogin##' to SQLAgentUserRole msdb role...

潛在原因和解決方案

  • 用戶選項會導致交易失敗。

    解決方案:連線到 SQL Server、使用 使用者選項 伺服器組態選項檔來識別可能造成問題的選項,以及移除衝突的設定。

    例如,Microsoft支援已看到 IMPLICIT_TRANSACTIONS 設定導致安裝程式失敗的實例。 或者,如果您無法識別衝突的用戶選項,請在 SQL Server Management Studio 中使用下列腳本來移除所有使用者選項(SSMS):

    EXEC sp_configure 'user options', '0'
    GO
    RECONFIGURE WITH OVERRIDE;
    GO
    
  • 孤立的使用者會導致交易失敗。

    解決方案:使用類似下列查詢的查詢來檢查孤立的使用者:

    SELECT dp.type_desc, dp.SID, dp.name AS user_name
    FROM sys.database_principals AS dp
    LEFT JOIN sys.server_principals AS sp
         ON dp.SID = sp.SID
    WHERE sp.SID IS NULL
         AND authentication_type_desc = 'INSTANCE';
    

    如需如何解決孤立使用者的詳細資訊,請參閱針對孤立的用戶進行疑難解答(SQL Server)。

  • 孤立的工作會導致交易失敗。

    解決方案:使用類似下列查詢的查詢來檢查孤立作業:

    SELECT sj.name AS Job_Name,
         sl.name AS Job_Owner
    FROM msdb.dbo.sysjobs_view sj
    LEFT JOIN master.dbo.syslogins sl ON sj.owner_sid = sl.sid
    WHERE sl.name <> 'sa'
    ORDER BY sj.name
    

    此處顯示 NULL 值的任何記錄都表示適用代理程式作業的擁有者是孤立的。 編輯作業,並將擁有者變更為有效的登入。