1. 程式人生 > 資料庫 >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

指示系統問題並且是致命錯誤,這意味著正在執行某語句或批處理的資料庫引擎任務已停止執行。此任務記錄了所發生事件的有關資訊,然後終止。在大多數情況下,應用程式與資料庫引擎例項的連線也可能終止。如果發生這種情況,該問題可能使應用程式無法重新連線。

此範圍內的錯誤訊息可以影響同一資料庫中所有正在訪問資料的程序,並可能指示資料庫或物件已損壞。嚴重級別從 19 到 24 的錯誤訊息均寫入錯誤日誌。

20

指示語句遇到了問題。由於該問題隻影響了當前任務,資料庫本身未必已經損壞。

21

指示遇到了影響當前資料庫中所有任務的問題,但資料庫本身未必已經損壞。

22

指示訊息中所指定的表或索引因軟體或硬體問題而損壞。

很少發生嚴重級別為 22 的錯誤。如果發生這種錯誤,請執行 DBCC CHECKDB 以確定資料庫中的其他物件是否也已損壞。這種問題可能只是出現在快取中而不存在於磁碟本身。如果發生此錯誤,請重新啟動資料庫引擎例項更正此問題。若要繼續工作,則必須重新連線到資料庫引擎例項;否則,請使用 DBCC 修復該問題。在某些情況下,可能需要還原資料庫。

如果重新啟動資料庫引擎的例項不能解決此問題,那麼問題就是出在磁碟上。有時,銷燬錯誤訊息中指定的物件可以解決此問題。例如,如果訊息報告資料庫引擎的例項在非聚集索引中發現了長度為 0 的行,則請刪除該索引並重建。

23

指示整個資料庫的完整性因硬體或軟體問題而出現問題。

很少發生嚴重級別為 23 的錯誤。如果發生這種錯誤,請執行 DBCC CHECKDB 以確定損壞的程度。這種問題可能只是出現在快取中而未出現在磁碟本身。如果發生此錯誤,請重新啟動資料庫引擎例項更正此問題。若要繼續工作,則必須重新連線到資料庫引擎例項;否則,請使用 DBCC 修復該問題。在某些情況下,可能需要還原資料庫。

24

指示介質故障。系統管理員可能需要還原資料庫。您可能還需要致電硬體供應商

參考資料:

https://docs.microsoft.com/zh-cn/sql/relational-databases/errors-events/database-engine-error-severities?view=sql-server-2017

總結

以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,謝謝大家對我們的支援。