發現嚴重級別為 16 的損壞時，DBCC CHECKDB 未發送警報

我已經設置了從 Brent Ozar 網站獲得的警報。

EXEC msdb.dbo.sp_add_alert 
 @name=N'Severity 016',
 @message_id=0,
 @severity=16,
 @enabled=1,
 @delay_between_responses=60,
 @include_event_description_in=1,
 @job_id=N'00000000-0000-0000-0000-000000000000';
GO

我想在執行 DBCC CheckDB 並發現損壞的數據庫時使用它來發出警報，但它沒有發送警報。警報按預期工作。我收到其他 16 級事件的警報。

這是我在已知損壞的數據庫上執行 CheckDB 但沒有收到警報時在螢幕上看到的消息：

Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 885578193, index ID 0, partition ID 72057594042974208, alloc unit ID 72057594049396736 (type In-row data), page (1:8096). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 133129 and -4.
Msg 8928, Level 16, State 2, Line 1
Object ID 885578193, index ID 0, partition ID 72057594042974208, alloc unit ID 72057594049396736 (type In-row data): Page (1:8096) could not be processed.  See other errors for details.
CHECKDB found 0 allocation errors and 2 consistency errors in table 'Corrupt_Tbl' (object ID 885578193).
CHECKDB found 0 allocation errors and 2 consistency errors in database 'CorruptionTest'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (CorruptionTest).

當 CheckDB 發現此類錯誤損壞時，如何確保我會收到警報？

只需使用 DBCC CHECKDB 添加代理作業並在此處啟用帶有郵件通知的警報。此外，如果你能寫下這份工作的錯誤日誌，那就太好了。

Erin Stellato 有一篇關於配置 DBCC CHECKDB 的好文章

代理警報基於發送到 Windows 事件日誌的消息。代理每 20 秒讀取一次事件日誌，並將新消息與您配置的警報相匹配。即，為了觸發代理警報，我們需要在事件日誌中有一個與我們創建的警報匹配的條目。

假設您（r 應用程序）在表上執行 SELECT 時遇到了損壞。SQL Server 會將資訊寫入事件日誌，以便某些監視解決方案（如事件警報）可以擷取該資訊。可能是 833 或 834 錯誤。

但是，DBCC CHECKDB 是“故意”搜尋損壞的。這個想法是您在命令的輸出中查找錯誤，這就是為什麼您不會在事件日誌中收到可警告錯誤的原因。人們可以爭論這種設計，但它就是這樣。

最終結果是您無法使用代理警報來擷取 DBCC CHECKDB 命令發現的問題。您需要以這樣的方式執行命令，以便執行結果可以表明您從 DBCC CHECKDB 收到錯誤並發送電子郵件。幸運的是，支持在代理作業失敗時發送電子郵件。

至於你想如何實現這樣的工作，就看你自己了。您可以在針對相關數據庫執行 DBCC CHECKDB 的地方編寫自己的工作。或者您可以使用維護計劃。或者，像我們許多人一樣，使用 Ola Hallengren 的腳本。在這方面，Ola 的腳本沒有什麼神奇之處，您仍然必須將該作業配置為在失敗時發送電子郵件。不過，Ola 的維護解決方案還有很多其他優點。

引用自：https://dba.stackexchange.com/questions/297531