监控工具SQL Monitor教程：使用扩展事件和SQL Monitor检查数据库事件（上）

您需要确保没有人篡改您的生产数据库，或者开发之外的任何数据库。就算您不是一个神经质的人，也会想要知道数据库是被停止了还是被删除了。本文介绍了使用扩展事件和SQL Monitor检查数据库事件的内容。

SQL Monitor是一个SQL Server监控工具。它可以监控SQL Servers的健康状况和活动，并通过电子邮件为您发送监测结果和建议。使用SQL Monitor时，只要一出现问题，你将会通过邮件和用户界面接收到警告，SQL Monitor会快速地做全局检查，检查单机，集群，服务区和数据库的健康状况和性能。使用SSRS或者用户界面生成报告，得到全部的历史数据，会让你非常回溯到过去，快速地检查到问题的原因。

SQL Monitor正式版

您需要确保没有人篡改您的生产数据库，或者开发之外的任何数据库。就算您不是一个神经质的人，也会想要知道数据库是被停止了还是被删除了。本文介绍了使用扩展事件和SQL Monitor检查数据库事件的内容。

您倾向于认为数据库不可能突然“消失”，直到它发生。我仍然对开发团队中有人意外删除生产数据库感到退缩。他在两个单独的SSMS查询窗口中同时打开了登台和生产，并感到困惑。之后，我对网络路由器进行了设计，以确保需要访问登台服务器或生产服务器的任何人都必须在隔离的房间中使用热台工作站。它可以防止注意力不集中。

如何确保关键数据库不会发生类似的事情果数据库脱机或进入非联机状态，则很容易收到警报，而SQL Monitor的内置“数据库不可用”警报将做到这一点。但是，我想要更多。我想知道是否创建、附加或启动了新数据库，或者现有数据库是否已停止、分离或删除。首先，我想在发生此类更改时收到警报，然后获取所有这些数据库事件的列表，这些事件是由谁执行的，发生了什么类型的更改，对哪个数据库进行了更改，何时发生以及它们来自哪个客户端应用程序。

听起来很简单，实际也很简单：我们可以使用“扩展事件”事件会话轻松地进行设置，该会话检测我们的数据库级事件，然后使用SQL Monitor客户指标来按计划查询事件数据。如果在过去半小时内发生的事件的数量或性质可能引起DBA焦虑，我们可以发出警报。

为什么要使用扩展事件和SQL Monitor/strong>

有一整套数据库级扩展事件，可跟踪每个数据库检查点、页面损坏、镜像状态、备份或恢复操作、批量复制、文件大小更改以及数据库的创建、停止、启动、删除或更新，以用于服务器上的任何数据库。

我们可以建立扩展的事件会话来收集所需的数据，它将为我们完成大部分工作。将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中的“观看实时数据”直接查看数据：

通过右键单击网格，它也很容易显示其他事件列。

检查结果：谁篡改了该数据库/span>

我更喜欢使用SQL提取事件数据，因此我可以完全根据需要配置查询。

清单3：查询DatabaseEvents事件数据

如您所见，它向我们显示了数据库更改的时间、受影响的数据库、进行更改的SQL Server主体以及进行更改的代码。

这可能没有看起来有用，因为要知道涉及哪个数据库并不总是那么容易。有时，一个DatabaseId将不会与任何数据库或其他数据库相关，因为已从sys.databases表中删除了已删除的数据库，并且ID很快被回收，因此，如果您尝试从ID中查找数据库的名称，则很容易出错或不存在，因为查找完成时，它可能与完全错误的数据库有关。在这种情况下，TSQL是对受影响的数据库的一个很好的指南，但是您可以获得整个批处理，并且如果该批处理具有许多影响数据库的不同操作，那么事情就会变得晦暗。

本教程内容较多，分为上下两篇文章，想要了解本教程后续发展，请继续关注我们网站，了解更多产品资讯~感兴趣的朋友可以下载SQL Monitor试用版免费体验~

想要购买SQL Monitor正版授权，或了解更多产品信息请点击【咨询在线客服】

标签：

来源：慧都