SQL Server作業(yè)報錯特殊案例分析過程及方法
時間：2024-02-07 12:09作者：下載吧人氣：22
發(fā)現(xiàn)問題
一個作業(yè)報錯，報錯信息如下，從錯誤信息根本看不出為什么出錯，手工運行作業(yè)又成功了。一時不清楚什么原因?qū)е伦鳂I(yè)出錯。
Message
Executed as user: NT SERVICESQLSERVERAGENT. …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， 通過數(shù)據(jù)庫引擎錯誤嚴重性（Database Engine Error Severities），我們可以知道13意味著Indicates transaction deadlock errors. 也就是說出現(xiàn)死鎖，導致作業(yè)的會話成為了死鎖的犧牲品。不過也很奇怪，以前也遇到過作業(yè)由于出現(xiàn)死鎖，導致作業(yè)失敗的情況。都會在Message里面有提示，但是這個實例的版本SQL Server 2012 SP3（11.0.6020.0），出現(xiàn)死鎖，居然沒有提示相關(guān)死鎖信息。不清楚是Bug還是其它原因。
嚴重性級別
下表列出并說明 SQL Server 數(shù)據(jù)庫引擎所引起錯誤的嚴重級別。
|
嚴重級別 |
描述 |
|
0-9 |
返回不太嚴重的狀態(tài)信息或報表錯誤的信息性消息。 數(shù)據(jù)庫引擎 不會引起嚴重級別為 0 到 9 的系統(tǒng)錯誤。 |
|
10 |
返回不太嚴重的狀態(tài)信息或報表錯誤的信息性消息。 由于兼容性原因， 數(shù)據(jù)庫引擎 在將錯誤信息返回到調(diào)用應(yīng)用程序前將嚴重性級別從 10 轉(zhuǎn)換為 0。 |
|
11-16 |
指示可由用戶糾正的錯誤。 |
|
11 |
指示給定的對象或?qū)嶓w不存在。 |
|
12 |
特殊嚴重性，用于因特殊查詢提示而不使用鎖定的查詢。 在某些情況下，因為沒有用鎖保證一致性，由這些語句所執(zhí)行的讀取操作會產(chǎn)生不一致的數(shù)據(jù)。 |
|
13 |
指示事務(wù)死鎖錯誤。 |
|
14 |
指示安全性相關(guān)錯誤，如權(quán)限被拒絕。 |
|
15 |
指示 Transact-SQL?命令中的語法錯誤。 |
|
16 |
指示可由用戶糾正的常規(guī)錯誤。 |
|
17-19 |
指示無法由用戶糾正的軟件錯誤。 請將問題通知系統(tǒng)管理員。 |
|
17 |
指示語句導致 SQL Server?用盡資源（如數(shù)據(jù)庫的內(nèi)存、鎖或磁盤空間）或超出了系統(tǒng)管理員設(shè)置的某些限制。 |
|
18 |
指示 數(shù)據(jù)庫引擎 軟件中有問題，但可完成執(zhí)行語句，并且可維護到 數(shù)據(jù)庫引擎 實例的連接。 每當出現(xiàn)嚴重級別為 18 的消息時均應(yīng)通知系統(tǒng)管理員。 |
|
19 |
指示超出了不可配置的 數(shù)據(jù)庫引擎 限制并且當前批處理已終止。 嚴重級別為 19 或更高的錯誤消息將停止執(zhí)行當前的批處理。 嚴重級別為 19 的錯誤很少，必須由系統(tǒng)管理員或主要支持提供商更正。 當引發(fā)嚴重級別為 19 的消息時，請與系統(tǒng)管理員聯(lián)系。 嚴重級別從 19 到 25 的錯誤消息均寫入錯誤日志。 |
|
20-24 |
指示系統(tǒng)問題并且是致命錯誤，這意味著正在執(zhí)行某語句或批處理的 數(shù)據(jù)庫引擎 任務(wù)已停止運行。 此任務(wù)記錄了所發(fā)生事件的有關(guān)信息，然后終止。 在大多數(shù)情況下，應(yīng)用程序與 數(shù)據(jù)庫引擎 實例的連接也可能終止。 如果發(fā)生這種情況，該問題可能使應(yīng)用程序無法重新連接。 此范圍內(nèi)的錯誤消息可以影響同一數(shù)據(jù)庫中所有正在訪問數(shù)據(jù)的進程，并可能指示數(shù)據(jù)庫或?qū)ο笠褤p壞。 嚴重級別從 19 到 24 的錯誤消息均寫入錯誤日志。 |
|
20 |
指示語句遇到了問題。 由于該問題只影響了當前任務(wù)，數(shù)據(jù)庫本身未必已經(jīng)損壞。 |
|
21 |
指示遇到了影響當前數(shù)據(jù)庫中所有任務(wù)的問題，但數(shù)據(jù)庫本身未必已經(jīng)損壞。 |
|
22 |
指示消息中所指定的表或索引因軟件或硬件問題而損壞。 很少發(fā)生嚴重級別為 22 的錯誤。 如果發(fā)生這種錯誤，請運行 DBCC CHECKDB 以確定數(shù)據(jù)庫中的其他對象是否也已損壞。 這種問題可能只是出現(xiàn)在緩存中而不存在于磁盤本身。 如果發(fā)生此錯誤，請重新啟動 數(shù)據(jù)庫引擎 實例更正此問題。 若要繼續(xù)工作，則必須重新連接到 數(shù)據(jù)庫引擎實例；否則，請使用 DBCC 修復該問題。 在某些情況下，可能需要還原數(shù)據(jù)庫。 如果重新啟動 數(shù)據(jù)庫引擎 的實例不能解決此問題，那么問題就是出在磁盤上。 有時，銷毀錯誤消息中指定的對象可以解決此問題。例如，如果消息報告 數(shù)據(jù)庫引擎 的實例在非聚集索引中發(fā)現(xiàn)了長度為 0 的行，則請刪除該索引并重建。 |
|
23 |
指示整個數(shù)據(jù)庫的完整性因硬件或軟件問題而出現(xiàn)問題。 很少發(fā)生嚴重級別為 23 的錯誤。 如果發(fā)生這種錯誤，請運行 DBCC CHECKDB 以確定損壞的程度。 這種問題可能只是出現(xiàn)在緩存中而未出現(xiàn)在磁盤本身。 如果發(fā)生此錯誤，請重新啟動 數(shù)據(jù)庫引擎 實例更正此問題。 若要繼續(xù)工作，則必須重新連接到 數(shù)據(jù)庫引擎實例；否則，請使用 DBCC 修復該問題。 在某些情況下，可能需要還原數(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é)
發(fā)現(xiàn)問題
一個作業(yè)報錯，報錯信息如下，從錯誤信息根本看不出為什么出錯，手工運行作業(yè)又成功了。一時不清楚什么原因?qū)е伦鳂I(yè)出錯。
Message
Executed as user: NT SERVICESQLSERVERAGENT. …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， 通過數(shù)據(jù)庫引擎錯誤嚴重性（Database Engine Error Severities），我們可以知道13意味著Indicates transaction deadlock errors. 也就是說出現(xiàn)死鎖，導致作業(yè)的會話成為了死鎖的犧牲品。不過也很奇怪，以前也遇到過作業(yè)由于出現(xiàn)死鎖，導致作業(yè)失敗的情況。都會在Message里面有提示，但是這個實例的版本SQL Server 2012 SP3（11.0.6020.0），出現(xiàn)死鎖，居然沒有提示相關(guān)死鎖信息。不清楚是Bug還是其它原因。
嚴重性級別
下表列出并說明 SQL Server 數(shù)據(jù)庫引擎所引起錯誤的嚴重級別。
|
嚴重級別 |
描述 |
|
0-9 |
返回不太嚴重的狀態(tài)信息或報表錯誤的信息性消息。 數(shù)據(jù)庫引擎 不會引起嚴重級別為 0 到 9 的系統(tǒng)錯誤。 |
|
10 |
返回不太嚴重的狀態(tài)信息或報表錯誤的信息性消息。 由于兼容性原因， 數(shù)據(jù)庫引擎 在將錯誤信息返回到調(diào)用應(yīng)用程序前將嚴重性級別從 10 轉(zhuǎn)換為 0。 |
|
11-16 |
指示可由用戶糾正的錯誤。 |
|
11 |
指示給定的對象或?qū)嶓w不存在。 |
|
12 |
特殊嚴重性，用于因特殊查詢提示而不使用鎖定的查詢。 在某些情況下，因為沒有用鎖保證一致性，由這些語句所執(zhí)行的讀取操作會產(chǎn)生不一致的數(shù)據(jù)。 |
|
13 |
指示事務(wù)死鎖錯誤。 |
|
14 |
指示安全性相關(guān)錯誤，如權(quán)限被拒絕。 |
|
15 |
指示 Transact-SQL?命令中的語法錯誤。 |
|
16 |
指示可由用戶糾正的常規(guī)錯誤。 |
|
17-19 |
指示無法由用戶糾正的軟件錯誤。 請將問題通知系統(tǒng)管理員。 |
|
17 |
指示語句導致 SQL Server?用盡資源（如數(shù)據(jù)庫的內(nèi)存、鎖或磁盤空間）或超出了系統(tǒng)管理員設(shè)置的某些限制。 |
|
18 |
指示 數(shù)據(jù)庫引擎 軟件中有問題，但可完成執(zhí)行語句，并且可維護到 數(shù)據(jù)庫引擎 實例的連接。 每當出現(xiàn)嚴重級別為 18 的消息時均應(yīng)通知系統(tǒng)管理員。 |
|
19 |
指示超出了不可配置的 數(shù)據(jù)庫引擎 限制并且當前批處理已終止。 嚴重級別為 19 或更高的錯誤消息將停止執(zhí)行當前的批處理。 嚴重級別為 19 的錯誤很少，必須由系統(tǒng)管理員或主要支持提供商更正。 當引發(fā)嚴重級別為 19 的消息時，請與系統(tǒng)管理員聯(lián)系。 嚴重級別從 19 到 25 的錯誤消息均寫入錯誤日志。 |
|
20-24 |
指示系統(tǒng)問題并且是致命錯誤，這意味著正在執(zhí)行某語句或批處理的 數(shù)據(jù)庫引擎 任務(wù)已停止運行。 此任務(wù)記錄了所發(fā)生事件的有關(guān)信息，然后終止。 在大多數(shù)情況下，應(yīng)用程序與 數(shù)據(jù)庫引擎 實例的連接也可能終止。 如果發(fā)生這種情況，該問題可能使應(yīng)用程序無法重新連接。 此范圍內(nèi)的錯誤消息可以影響同一數(shù)據(jù)庫中所有正在訪問數(shù)據(jù)的進程，并可能指示數(shù)據(jù)庫或?qū)ο笠褤p壞。 嚴重級別從 19 到 24 的錯誤消息均寫入錯誤日志。 |
|
20 |
指示語句遇到了問題。 由于該問題只影響了當前任務(wù)，數(shù)據(jù)庫本身未必已經(jīng)損壞。 |
|
21 |
指示遇到了影響當前數(shù)據(jù)庫中所有任務(wù)的問題，但數(shù)據(jù)庫本身未必已經(jīng)損壞。 |
|
22 |
指示消息中所指定的表或索引因軟件或硬件問題而損壞。 很少發(fā)生嚴重級別為 22 的錯誤。 如果發(fā)生這種錯誤，請運行 DBCC CHECKDB 以確定數(shù)據(jù)庫中的其他對象是否也已損壞。 這種問題可能只是出現(xiàn)在緩存中而不存在于磁盤本身。 如果發(fā)生此錯誤，請重新啟動 數(shù)據(jù)庫引擎 實例更正此問題。 若要繼續(xù)工作，則必須重新連接到 數(shù)據(jù)庫引擎實例；否則，請使用 DBCC 修復該問題。 在某些情況下，可能需要還原數(shù)據(jù)庫。 如果重新啟動 數(shù)據(jù)庫引擎 的實例不能解決此問題，那么問題就是出在磁盤上。 有時，銷毀錯誤消息中指定的對象可以解決此問題。例如，如果消息報告 數(shù)據(jù)庫引擎 的實例在非聚集索引中發(fā)現(xiàn)了長度為 0 的行，則請刪除該索引并重建。 |
|
23 |
指示整個數(shù)據(jù)庫的完整性因硬件或軟件問題而出現(xiàn)問題。 很少發(fā)生嚴重級別為 23 的錯誤。 如果發(fā)生這種錯誤，請運行 DBCC CHECKDB 以確定損壞的程度。 這種問題可能只是出現(xiàn)在緩存中而未出現(xiàn)在磁盤本身。 如果發(fā)生此錯誤，請重新啟動 數(shù)據(jù)庫引擎 實例更正此問題。 若要繼續(xù)工作，則必須重新連接到 數(shù)據(jù)庫引擎實例；否則，請使用 DBCC 修復該問題。 在某些情況下，可能需要還原數(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é)
以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對的支持。
相關(guān)推薦
- SQL開發(fā)知識：sqlserver/mysql按天、按小時、按分鐘統(tǒng)計連續(xù)時間段數(shù)據(jù)
- MongoDB 數(shù)據(jù)庫基礎(chǔ) 之 聚合group的操作指南
- MongoDB 數(shù)據(jù)庫基礎(chǔ) 之 全文檢索講解
- MongoDB數(shù)據(jù)庫基礎(chǔ) 常用命令匯總
- MongoDB 數(shù)據(jù)庫基礎(chǔ) 之 mongodb內(nèi)存管理相關(guān)總結(jié)
- mongodb數(shù)據(jù)庫基礎(chǔ) 之 mongodb 快速入門大全
- 教你如何給MongoDB數(shù)據(jù)庫添加分片副本集
- MongoDB數(shù)據(jù)庫基礎(chǔ) 裝 基本操作詳解【服務(wù)端啟動，客戶端連接，CRUD操作】
- 詳解 MongoDB數(shù)據(jù)庫 設(shè)計方法以及技巧范例
- MongoDB數(shù)據(jù)庫基礎(chǔ) 裝 高級查詢操作詳解（多條件查詢、正則匹配查詢等）
相關(guān)下載
熱門閱覽
- 1SQL開發(fā)知識：MyBatis SQL xml處理小于號與大于號正確的格式
- 2SQL基礎(chǔ)：SQL?Server的全文搜索功能
- 3SQL開發(fā)知識：SQL中Truncate的用法
- 4數(shù)據(jù)庫恢復之 delete誤刪數(shù)據(jù)使用SCN號恢復的詳細方希
- 5SQL開發(fā)知識：SQL Server數(shù)據(jù)庫查找表名或列名中包含空格的表和列
- 6SQL異常：教你sqlserver連接錯誤之SQL評估期已過的問題解決方法
- 7SQL開發(fā)知識：SQL Server執(zhí)行動態(tài)SQL的正確方法
- 8數(shù)據(jù)安全：SQL Server2019數(shù)據(jù)庫備份與還原腳本(批量備份)
- 9SQL基礎(chǔ)：SQLServer2019 數(shù)據(jù)庫的基本使用之圖形化界面操作的實現(xiàn)
- 10SQL開發(fā)知識：關(guān)于SQL Server數(shù)據(jù)庫觸發(fā)器詳解
- 11SQL開發(fā)知識：SQL Server Management Studio（SSMS）復制數(shù)據(jù)庫的方法
- 12SQL開發(fā)知識：SQL Server非動態(tài) SQL語句來對動態(tài)查詢進行執(zhí)行
最新排行
- 1SQL開發(fā)知識：SQL注入工具
- 2SQL開發(fā)知識：SQL 在自增列插入指定數(shù)據(jù)的操作方法
- 3Sql Server2012數(shù)據(jù)庫使用IP登錄服務(wù)器的配置教程
- 4SQL開發(fā)知識：Navicat導出.sql文件方法
- 5SQL開發(fā)知識：SQL Server表和索引存儲結(jié)構(gòu)
- 6SQL開發(fā)知識：Sql注入原理簡介
- 7SQL開發(fā)知識：SQL Server Management Studio（SSMS）復制數(shù)據(jù)庫的方法
- 8SQL開發(fā)知識：SQL Server執(zhí)行動態(tài)SQL的正確方法
- 9SQL開發(fā)知識：SQL Server Parameter Sniffing及其改進方法
- 10SQL開發(fā)知識：sql server2008調(diào)試存儲過程的步驟
- 11SQL開發(fā)知識：SQL Server非動態(tài) SQL語句來對動態(tài)查詢進行執(zhí)行
- 12一文帶你詳解SQL Server 2016數(shù)據(jù)庫快照代理過程
網(wǎng)友評論