SQL Monitor是一個SQL Server監控工具。它可以監控SQL Servers的健康狀況和活動，并通過電子郵件為您發送監測結果和建議。使用SQL Monitor時，只要一出現問題，你將會通過郵件和用戶界面接收到警告，SQL Monitor會快速地做全局檢查，檢查單機，集群，服務區和數據庫的健康狀況和性能。使用SSRS或者用戶界面生成報告，得到全部的歷史數據，會讓你非常回溯到過去，快速地檢查到問題的原因。

點擊下載SQL Monitor正式版

您需要確保沒有人篡改您的生產數據庫，或者開發之外的任何數據庫。就算您不是一個神經質的人，也會想要知道數據庫是被停止了還是被刪除了。本文介紹了使用擴展事件和SQL Monitor檢查數據庫事件的內容。

您傾向于認為數據庫不可能突然“消失”，直到它發生。我仍然對開發團隊中有人意外刪除生產數據庫感到退縮。他在兩個單獨的SSMS查詢窗口中同時打開了登臺和生產，并感到困惑。之后，我對網絡路由器進行了設計，以確保需要訪問登臺服務器或生產服務器的任何人都必須在隔離的房間中使用熱臺工作站。它可以防止注意力不集中。

如何確保關鍵數據庫不會發生類似的事情？如果數據庫脫機或進入非聯機狀態，則很容易收到警報，而SQL Monitor的內置“數據庫不可用”警報將做到這一點。但是，我想要更多。我想知道是否創建、附加或啟動了新數據庫，或者現有數據庫是否已停止、分離或刪除。首先，我想在發生此類更改時收到警報，然后獲取所有這些數據庫事件的列表，這些事件是由誰執行的，發生了什么類型的更改，對哪個數據庫進行了更改，何時發生以及它們來自哪個客戶端應用程序。

聽起來很簡單，實際也很簡單：我們可以使用“擴展事件”事件會話輕松地進行設置，該會話檢測我們的數據庫級事件，然后使用SQL Monitor客戶指標來按計劃查詢事件數據。如果在過去半小時內發生的事件的數量或性質可能引起DBA焦慮，我們可以發出警報。

為什么要使用擴展事件和SQL Monitor？

有一整套數據庫級擴展事件，可跟蹤每個數據庫檢查點、頁面損壞、鏡像狀態、備份或恢復操作、批量復制、文件大小更改以及數據庫的創建、停止、啟動、刪除或更新，以用于服務器上的任何數據庫。

我們可以建立擴展的事件會話來收集所需的數據，它將為我們完成大部分工作。將SQL Monitor添加到組合中的一個好處是，通過事件會話，我們可以創建一個自定義監視器，該監視器將按時間表查詢收集到的事件數據，以查看是否在指定時間內引發了任何事件。我們可以為其設置警報，以及在圖形上繪制其值。

SQL Monitor還擅長關聯事件。例如，如果我們要檢查不屬于計劃流程的BCP活動，則可以創建一個事件會話以批量復制活動并為其編寫自定義指標。我們可以在時間線圖上顯示其輸出，并查找與其他指標的相關性，例如“可疑錯誤”、“權限更改”或“未經授權的配置更改”指標。

SQL Monitor或任何類似的外部監視過程（而不使用SQL Server自己的代理）的另一個重要優點是，外部系統不在數據庫用戶的范圍之內。除了關閉某些擴展事件之外，任何人都很難對其進行篡改。順便說一句，解決此問題的一種簡單方法是使用SQL Monitor跟蹤活動的擴展事件會話的數量，并在數量下降時發出警報。

如何使用擴展事件監視數據庫事件

在SQL Server Management Studio（SSMS）中，您可以在會話屬性屏幕或會話向導中查看這些擴展事件。

我只選擇了數據庫類別，然后我想要監視6個事件，database_attached、database_created、database_detached、database_dropped、database_started和database_stopped。

從安全角度來看，我也很想知道是否有人通過databases_bulk_copy_rows事件使用BCP復制數據，但是作為單獨的警報可能會更好。警報中還可以監視數據庫大小的變化（databases_data_file_size_changed），但最好還是單獨處理，您還想知道新的大小和增長量。

對于所有這些擴展事件，除了每個事件列的默認“有效負載”之外，我們還需要確定需要執行哪些其他操作。我們通過單擊“配置”選項卡來完成此操作。

我已經決定加入client_app_name、database_name、sql_text和username。我發現SQL文本是最有用的，但是擁有數據庫名稱非常方便。不是每個事件都發送數據庫名稱，而SQL Text操作可以可靠地提供詳細信息。

有了這些，我們將知道發生事件的數據庫的名稱、執行的DDL的文本、發出該事件的客戶端應用程序的名稱以及關聯的數據庫主體。換句話說，我們將確切地知道誰對哪些數據庫做了什么。

我們還需要確定是否將事件存儲在環形緩沖區或文件中。對于這種類型的事件，我希望使用環形緩沖區，因為事件將很少。我建議您保留大量有用的事件以進行法證工作。作為示例，我在以下腳本中指定了每種類型的六十個，但是您可以對其進行調整。如果我們要確保事件數據的持久性，那么很容易將XML文檔切成關系格式并將相關行存儲在表中。

創建事件會話

您可以如上所述從會話屬性窗口或“新建會話”向導中簡單地創建事件會話，但是我發現提取SQL腳本很有用，您可以從任何頁面的頂部獲取該腳本。

清單1：DatabaseEvents事件會話

對于使用擴展事件的任何監視，我們必須先創建并啟動會話，然后才能使用結果。這必須獨立于SQL Monitor中的自定義指標來完成，因此您必須記住在SQL Monitor工作之前必須同時執行這兩項。會話停止后，您將失去結果。

-- we start or stop the session in code or via SSMS
  ALTER EVENT SESSION DatabaseEvents ON SERVER STATE = START;

測試事件會話

這是一系列測試會話的批次。我添加了保護子句，以便在不按順序運行測試時可以避免錯誤。

清單2：測試DatabaseEvents事件會話

我們可以使用SSMS中的“觀看實時數據”直接查看數據：

通過右鍵單擊網格，它也很容易顯示其他事件列。

檢查結果：誰篡改了該數據庫？

我更喜歡使用SQL提取事件數據，因此我可以完全根據需要配置查詢。

清單3：查詢DatabaseEvents事件數據

如您所見，它向我們顯示了數據庫更改的時間、受影響的數據庫、進行更改的SQL Server主體以及進行更改的代碼。

這可能沒有看起來有用，因為要知道涉及哪個數據庫并不總是那么容易。有時，一個DatabaseId將不會與任何數據庫或其他數據庫相關，因為已從sys.databases表中刪除了已刪除的數據庫，并且ID很快被回收，因此，如果您嘗試從ID中查找數據庫的名稱，則很容易出錯或不存在，因為查找完成時，它可能與完全錯誤的數據庫有關。在這種情況下，TSQL是對受影響的數據庫的一個很好的指南，但是您可以獲得整個批處理，并且如果該批處理具有許多影響數據庫的不同操作，那么事情就會變得晦暗。

本教程內容較多，分為上下兩篇文章，想要了解本教程后續發展，請繼續關注我們網站，了解更多產品資訊~感興趣的朋友可以下載SQL Monitor試用版免費體驗~