這篇文章主要給大家介紹了關於SQL Server作業報錯特殊案例的相關資料，文中通過示例代碼介紹的非常詳細，對大家的學習或者使用SQL Server具有一定的參考學習價值，需要的朋友們下面來一起學習學習吧
發現問題
一個作業報錯，報錯信息如下，從錯誤信息根本看不出爲什麼出錯，手工運行作業又成功了。一時不清楚什麼原因導致作業出錯。
Message
Executed as user: NT SERVICE\SQLSERVERAGENT. ...eration. [SQLSTATE 01003] (Message 8153) Mar 6 2019 8:09AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:10AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:17AM [SQLSTATE 01000] (Message 0) Mar 6 2019 11:17AM [SQLSTATE 01000] (Message 0) Mar 7 2019 1:03PM [SQLSTATE 01000] (Message 0) Mar 6 2019 4:06PM [SQLSTATE 01000] (Message 0) Mar 7 2019 4:07PM [SQLSTATE 01000] (Message 0) Mar 6 2019 1:40PM [SQLSTATE 01000] (Message 0) Mar 7 2019 1:36PM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:02AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:06AM [SQLSTATE 01000] (Message 0) Mar 7 2019 9:47AM [SQLSTATE 01000] (Message 0) Mar 6 2019 5:38PM [SQLSTATE 01000] (Message 0) Mar 7 2019 5:34PM [SQLSTATE 01000] (Message 0) Mar 6 2019 3:16PM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:07AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:09AM [SQLSTATE 01000] (Message 0) Mar 7 2019 2:18PM [SQLSTATE 01000] (Message 0) Mar 7 2019 1:24PM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:11AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:12AM [SQLSTATE 01000] (Message 0) Mar 6 2019 11:34AM [SQLSTATE 01000] (Message 0) Mar 7 2019 11:39AM [SQLSTATE 01000] (Message 0) Mar 7 2019 4:20PM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:51AM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:44AM [SQLSTATE 01000] (Message 0) Mar 7 2019 7:31AM [SQLSTATE 01000] (Message 0) Mar 6 2019 10:46AM [SQLSTATE 01000] (Message 0) Mar 6 2019 10:10AM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:08AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:04AM [SQLSTATE 01000] (Message 0) Mar 7 2019 3:19PM [SQLSTATE 01000] (Message 0) Mar 6 2019 9:02AM [SQLSTATE 01000] (Message 0) Mar 7 2019 9:01AM [SQLSTATE 01000] (Message 0) Mar 7 2019 9:48AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:01AM [SQLSTATE 01000] (Message 0) Mar 6 2019 4:16PM [SQLSTATE 01000] (Message 0) Mar 6 2019 2:17PM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:31AM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:04AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:08AM [SQLSTATE 01000] (Message 0) Mar 6 2019 1:08PM [SQLSTATE 01000] (Message 0) Mar 7 2019 1:04PM [SQLSTATE 01000] (Message 0) Mar 7 2019 2:03PM [SQLSTATE 01000] (Message 0) Mar 6 2019 3:18PM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:16AM [SQLSTATE 01000] (Message 0) Mar 6 2019 2:14PM [SQLSTATE 01000] (Message 0) Mar 6 2019 4:13PM [SQLSTATE 01000] (Message 0) Mar 7 2019 4:10PM [SQLSTATE 01000] (Message 0) Mar 6 2019 9:02AM [SQLSTATE 01000] (Message 0) Mar 7 2019 2:01PM [SQLSTATE 01000] (Message 0) Mar 7 2019 7:44AM [SQLSTATE 01000] (Message 0) Mar 6 2019 5:38PM [SQLSTATE 01000] (Message 0) Mar 7 2019 5:34PM [SQLSTATE 01000] (Message 0) Mar 6 2019 5:38PM [SQLSTATE 01000] (Message 0) Mar 7 2019 5:34PM [SQLSTATE 01000] (Message 0) Mar 6 2019 2:03PM [SQLSTATE 01000] (Message 0) Mar 6 2019 3:05PM [SQLSTATE 01000] (Message 0) Mar 7 2019 7:01PM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:05AM [SQLSTATE 01000] (Message 0) Mar 6 2019 3:47PM [SQLSTATE 01000] (Message 0) Mar 6 2019 9:16AM [SQLSTATE 01000] (Message 0) Mar 6 2019 2:18PM [SQLSTATE 01000] (Message 0) Mar 7 2019 2:18PM [SQLSTATE 01000] (Message 0) Mar 7 2019 2:36PM [SQLSTATE 01000] (Message 0) Mar 6 2019 9:20AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:32AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:13AM [SQLSTATE 01000] (Message 0) Mar 6 2019 1:31PM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:06AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:07AM [SQLSTATE 01000] (Message 0) Mar 6 2019 3:16PM [SQLSTATE 01000] (Message 0) Mar 6 2019 3:16PM [SQLSTATE 01000] (Message 0) Mar 6 2019 9:03AM [SQLSTATE 01000] (Message 0) Mar 6 2019 11:59AM [SQLSTATE 01000] (Message 0) Mar 7 2019 12:01PM [SQLSTATE 01000] (Message 0) Mar 6 2019 2:59PM [SQLSTATE 01000] (Message 0) Mar 6 2019 11:49AM [SQLSTATE 01000] ... The step failed.
如上截圖所示，從這裏可以看到出錯信息的Sql Severity級別爲13， 通過數據庫引擎錯誤嚴重性（Database Engine Error Severities），我們可以知道13意味着Indicates transaction deadlock errors. 也就是說出現死鎖，導致作業的會話成爲了死鎖的犧牲品。不過也很奇怪，以前也遇到過作業由於出現死鎖，導致作業失敗的情況。都會在Message裏面有提示，但是這個實例的版本SQL Server 2012 SP3（11.0.6020.0），出現死鎖，居然沒有提示相關死鎖信息。不清楚是Bug還是其它原因。
嚴重性級別
下表列出並說明 SQL Server 數據庫引擎所引起錯誤的嚴重級別。
|
嚴重級別 |
描述 |
|
0-9 |
返回不太嚴重的狀態信息或報表錯誤的信息性消息。 數據庫引擎 不會引起嚴重級別爲 0 到 9 的系統錯誤。 |
|
10 |
返回不太嚴重的狀態信息或報表錯誤的信息性消息。 由於兼容性原因， 數據庫引擎 在將錯誤信息返回到調用應用程序前將嚴重性級別從 10 轉換爲 0。 |
|
11-16 |
指示可由用戶糾正的錯誤。 |
|
11 |
指示給定的對象或實體不存在。 |
|
12 |
特殊嚴重性，用於因特殊查詢提示而不使用鎖定的查詢。 在某些情況下，因爲沒有用鎖保證一致性，由這些語句所執行的讀取操作會產生不一致的數據。 |
|
13 |
指示事務死鎖錯誤。 |
|
14 |
指示安全性相關錯誤，如權限被拒絕。 |
|
15 |
指示 Transact-SQL?命令中的語法錯誤。 |
|
16 |
指示可由用戶糾正的常規錯誤。 |
|
17-19 |
指示無法由用戶糾正的軟件錯誤。 請將問題通知系統管理員。 |
|
17 |
指示語句導致 SQL Server?用盡資源（如數據庫的內存、鎖或磁盤空間）或超出了系統管理員設置的某些限制。 |
|
18 |
指示 數據庫引擎 軟件中有問題，但可完成執行語句，並且可維護到 數據庫引擎 實例的連接。 每當出現嚴重級別爲 18 的消息時均應通知系統管理員。 |
|
19 |
指示超出了不可配置的 數據庫引擎 限制並且當前批處理已終止。 嚴重級別爲 19 或更高的錯誤消息將停止執行當前的批處理。 嚴重級別爲 19 的錯誤很少，必須由系統管理員或主要支持提供商更正。 當引發嚴重級別爲 19 的消息時，請與系統管理員聯繫。 嚴重級別從 19 到 25 的錯誤消息均寫入錯誤日誌。 |
|
20-24 |
指示系統問題並且是致命錯誤，這意味着正在執行某語句或批處理的 數據庫引擎 任務已停止運行。 此任務記錄了所發生事件的有關信息，然後終止。 在大多數情況下，應用程序與 數據庫引擎 實例的連接也可能終止。 如果發生這種情況，該問題可能使應用程序無法重新連接。 |
|
20 |
指示語句遇到了問題。 由於該問題隻影響了當前任務，數據庫本身未必已經損壞。 |
|
21 |
指示遇到了影響當前數據庫中所有任務的問題，但數據庫本身未必已經損壞。 |
|
22 |
指示消息中所指定的表或索引因軟件或硬件問題而損壞。 |
|
23 |
指示整個數據庫的完整性因硬件或軟件問題而出現問題。 |
|
24 |
指示介質故障。 系統管理員可能需要還原數據庫。 您可能還需要致電硬件供應商 |
參考資料：
https://docs.microsoft.com/zh-cn/sql/relational-databases/errors-events/database-engine-error-severities?view=sql-server-2017
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對神馬文庫的支持。