主頁 > 知識(shí)庫 > SQL Server作業(yè)報(bào)錯(cuò)特殊案例分析

SQL Server作業(yè)報(bào)錯(cuò)特殊案例分析

熱門標(biāo)簽:怎樣在地圖上標(biāo)注路線圖標(biāo) 百度地圖標(biāo)注不同路線 奧威地圖標(biāo)注多個(gè)地方 外呼系統(tǒng)電銷專用 武漢長(zhǎng)沙外呼系統(tǒng)方法和技巧 智能語音外呼系統(tǒng)選哪家 京華物流公司地圖標(biāo)注 優(yōu)質(zhì)地圖標(biāo)注 千呼電銷機(jī)器人價(jià)格

發(fā)現(xiàn)問題

一個(gè)作業(yè)報(bào)錯(cuò),報(bào)錯(cuò)信息如下,從錯(cuò)誤信息根本看不出為什么出錯(cuò),手工運(yùn)行作業(yè)又成功了。一時(shí)不清楚什么原因?qū)е伦鳂I(yè)出錯(cuò)。

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.

如上截圖所示,從這里可以看到出錯(cuò)信息的Sql Severity級(jí)別為13, 通過數(shù)據(jù)庫引擎錯(cuò)誤嚴(yán)重性(Database Engine Error Severities),我們可以知道13意味著Indicates transaction deadlock errors. 也就是說出現(xiàn)死鎖,導(dǎo)致作業(yè)的會(huì)話成為了死鎖的犧牲品。不過也很奇怪,以前也遇到過作業(yè)由于出現(xiàn)死鎖,導(dǎo)致作業(yè)失敗的情況。都會(huì)在Message里面有提示,但是這個(gè)實(shí)例的版本SQL Server 2012 SP3(11.0.6020.0),出現(xiàn)死鎖,居然沒有提示相關(guān)死鎖信息。不清楚是Bug還是其它原因。

嚴(yán)重性級(jí)別

下表列出并說明 SQL Server 數(shù)據(jù)庫引擎所引起錯(cuò)誤的嚴(yán)重級(jí)別。

嚴(yán)重級(jí)別

描述

0-9

返回不太嚴(yán)重的狀態(tài)信息或報(bào)表錯(cuò)誤的信息性消息。 數(shù)據(jù)庫引擎 不會(huì)引起嚴(yán)重級(jí)別為 0 到 9 的系統(tǒng)錯(cuò)誤。

10

返回不太嚴(yán)重的狀態(tài)信息或報(bào)表錯(cuò)誤的信息性消息。 由于兼容性原因, 數(shù)據(jù)庫引擎 在將錯(cuò)誤信息返回到調(diào)用應(yīng)用程序前將嚴(yán)重性級(jí)別從 10 轉(zhuǎn)換為 0。

11-16

指示可由用戶糾正的錯(cuò)誤。

11

指示給定的對(duì)象或?qū)嶓w不存在。

12

特殊嚴(yán)重性,用于因特殊查詢提示而不使用鎖定的查詢。 在某些情況下,因?yàn)闆]有用鎖保證一致性,由這些語句所執(zhí)行的讀取操作會(huì)產(chǎn)生不一致的數(shù)據(jù)。

13

指示事務(wù)死鎖錯(cuò)誤。

14

指示安全性相關(guān)錯(cuò)誤,如權(quán)限被拒絕。

15

指示 Transact-SQL?命令中的語法錯(cuò)誤。

16

指示可由用戶糾正的常規(guī)錯(cuò)誤。

17-19

指示無法由用戶糾正的軟件錯(cuò)誤。 請(qǐng)將問題通知系統(tǒng)管理員。

17

指示語句導(dǎo)致 SQL Server?用盡資源(如數(shù)據(jù)庫的內(nèi)存、鎖或磁盤空間)或超出了系統(tǒng)管理員設(shè)置的某些限制。

18

指示 數(shù)據(jù)庫引擎 軟件中有問題,但可完成執(zhí)行語句,并且可維護(hù)到 數(shù)據(jù)庫引擎 實(shí)例的連接。 每當(dāng)出現(xiàn)嚴(yán)重級(jí)別為 18 的消息時(shí)均應(yīng)通知系統(tǒng)管理員。

19

指示超出了不可配置的 數(shù)據(jù)庫引擎 限制并且當(dāng)前批處理已終止。 嚴(yán)重級(jí)別為 19 或更高的錯(cuò)誤消息將停止執(zhí)行當(dāng)前的批處理。 嚴(yán)重級(jí)別為 19 的錯(cuò)誤很少,必須由系統(tǒng)管理員或主要支持提供商更正。 當(dāng)引發(fā)嚴(yán)重級(jí)別為 19 的消息時(shí),請(qǐng)與系統(tǒng)管理員聯(lián)系。 嚴(yán)重級(jí)別從 19 到 25 的錯(cuò)誤消息均寫入錯(cuò)誤日志。

20-24

指示系統(tǒng)問題并且是致命錯(cuò)誤,這意味著正在執(zhí)行某語句或批處理的 數(shù)據(jù)庫引擎 任務(wù)已停止運(yùn)行。 此任務(wù)記錄了所發(fā)生事件的有關(guān)信息,然后終止。 在大多數(shù)情況下,應(yīng)用程序與 數(shù)據(jù)庫引擎 實(shí)例的連接也可能終止。 如果發(fā)生這種情況,該問題可能使應(yīng)用程序無法重新連接。

此范圍內(nèi)的錯(cuò)誤消息可以影響同一數(shù)據(jù)庫中所有正在訪問數(shù)據(jù)的進(jìn)程,并可能指示數(shù)據(jù)庫或?qū)ο笠褤p壞。 嚴(yán)重級(jí)別從 19 到 24 的錯(cuò)誤消息均寫入錯(cuò)誤日志。

20

指示語句遇到了問題。 由于該問題只影響了當(dāng)前任務(wù),數(shù)據(jù)庫本身未必已經(jīng)損壞。

21

指示遇到了影響當(dāng)前數(shù)據(jù)庫中所有任務(wù)的問題,但數(shù)據(jù)庫本身未必已經(jīng)損壞。

22

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

很少發(fā)生嚴(yán)重級(jí)別為 22 的錯(cuò)誤。 如果發(fā)生這種錯(cuò)誤,請(qǐng)運(yùn)行 DBCC CHECKDB 以確定數(shù)據(jù)庫中的其他對(duì)象是否也已損壞。 這種問題可能只是出現(xiàn)在緩存中而不存在于磁盤本身。 如果發(fā)生此錯(cuò)誤,請(qǐng)重新啟動(dòng) 數(shù)據(jù)庫引擎 實(shí)例更正此問題。 若要繼續(xù)工作,則必須重新連接到 數(shù)據(jù)庫引擎實(shí)例;否則,請(qǐng)使用 DBCC 修復(fù)該問題。 在某些情況下,可能需要還原數(shù)據(jù)庫。

如果重新啟動(dòng) 數(shù)據(jù)庫引擎 的實(shí)例不能解決此問題,那么問題就是出在磁盤上。 有時(shí),銷毀錯(cuò)誤消息中指定的對(duì)象可以解決此問題。例如,如果消息報(bào)告 數(shù)據(jù)庫引擎 的實(shí)例在非聚集索引中發(fā)現(xiàn)了長(zhǎng)度為 0 的行,則請(qǐng)刪除該索引并重建。

23

指示整個(gè)數(shù)據(jù)庫的完整性因硬件或軟件問題而出現(xiàn)問題。

很少發(fā)生嚴(yán)重級(jí)別為 23 的錯(cuò)誤。 如果發(fā)生這種錯(cuò)誤,請(qǐng)運(yùn)行 DBCC CHECKDB 以確定損壞的程度。 這種問題可能只是出現(xiàn)在緩存中而未出現(xiàn)在磁盤本身。 如果發(fā)生此錯(cuò)誤,請(qǐng)重新啟動(dòng) 數(shù)據(jù)庫引擎 實(shí)例更正此問題。 若要繼續(xù)工作,則必須重新連接到 數(shù)據(jù)庫引擎實(shí)例;否則,請(qǐng)使用 DBCC 修復(fù)該問題。 在某些情況下,可能需要還原數(shù)據(jù)庫。

24

指示介質(zhì)故障。 系統(tǒng)管理員可能需要還原數(shù)據(jù)庫。 您可能還需要致電硬件供應(yīng)商

參考資料:

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

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了,希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,謝謝大家對(duì)腳本之家的支持。

您可能感興趣的文章:
  • linux mysql 報(bào)錯(cuò):MYSQL:The server quit without updating PID file
  • mysql報(bào)錯(cuò):MySQL server version for the right syntax to use near type=InnoDB的解決方法
  • SQL Server附加數(shù)據(jù)庫報(bào)錯(cuò)無法打開物理文件,操作系統(tǒng)錯(cuò)誤5的圖文解決教程
  • mysql啟動(dòng)報(bào)錯(cuò)MySQL server PID file could not be found
  • SQL Server 2005/2008 導(dǎo)入導(dǎo)出數(shù)據(jù)常見報(bào)錯(cuò)解決方法
  • SQLServer中bigint轉(zhuǎn)int帶符號(hào)時(shí)報(bào)錯(cuò)問題解決方法
  • 一個(gè)函數(shù)解決SQLServer中bigint 轉(zhuǎn) int帶符號(hào)時(shí)報(bào)錯(cuò)問題
  • SQL Server2005打開數(shù)據(jù)表中的XML內(nèi)容時(shí)報(bào)錯(cuò)的解決辦法
  • sql server利用不同語種語言顯示報(bào)錯(cuò)錯(cuò)誤消息的方法示例

標(biāo)簽:威海 銅仁 天水 七臺(tái)河 防疫戰(zhàn)設(shè) 益陽 來賓 宿州

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《SQL Server作業(yè)報(bào)錯(cuò)特殊案例分析》,本文關(guān)鍵詞  SQL,Server,作業(yè),報(bào)錯(cuò),特殊,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《SQL Server作業(yè)報(bào)錯(cuò)特殊案例分析》相關(guān)的同類信息!
  • 本頁收集關(guān)于SQL Server作業(yè)報(bào)錯(cuò)特殊案例分析的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章