表级触发器不支持ddl语句

This article portrays the different utilization of database DDL Triggers for the Tables with a counting mail alert on schema composition using DDL (Data Definition Language) standard. Using that efficient method we can keep close eyes on monitoring schema changes in any database of SQL Server. We’ll also see how we could monitor these movements and send an alert email to persons responsible to inform about this change.

本文通过使用DDL （数据定义语言）标准的架构组成的计数邮件警报描绘了表的数据库DDL触发器的不同利用。 使用这种高效的方法，我们可以密切关注监视任何SQL Server数据库中的架构更改。 我们还将看到我们如何监视这些运动并将警报电子邮件发送给负责此变化的人员。

Microsoft SQL Server supports using very fundamental elements as SQL Triggers like DDL, DML and Logon Triggers. Table schema changes can be shrouded in DDL type Trigger. Next, we will examine in detail monitoring the blueprint changes and alert for the Tables. Most commonly organizations observe and alert on the database construction changes of the Table with the help of the Database Administrator group.

Microsoft SQL Server支持使用非常基本的元素作为SQL触发器，例如DDL，DML和登录触发器。 表模式更改可以用DDL类型Trigger覆盖。 接下来，我们将详细研究监视蓝图更改并为表格发出警报。 最常见的组织是在数据库管理员组的帮助下观察表的数据库结构变化并发出警报。

In a typical production environment, schema changes can be linked with a particular sprint or release if there should arise an occurrence of some little fixes, the schema changes could be sent to a database. Subsequently, we have to screen a few more occasions on the database of which the changes are on a valid path and have been approved by an approved individual or not?

在典型的生产环境中，如果应该发生一些小的修复，则可以将模式更改与特定的sprint或发行版链接起来，可以将模式更改发送到数据库。 随后，我们必须在数据库中筛选出几次更改处于有效路径上并且已经获得批准的个人批准的场合？

DDL triggers are the convenient option to monitor and track changes on SQL Server objects or to send an alert of suspicious actions or requests from the connected authorized Cadent. It’s quite useful to obtain point by point adjustability to figure out the answers of the following “who”, “what”, “when”, “where”, and “how”?

DDL触发器是监视和跟踪SQL Server对象上的更改或发送有关可疑操作或来自连接的授权Cadent的请求的警报的便捷选项。 获得逐点可调整性以找出以下“谁”，“什么”，“何时”，“何处”和“如何”的答案非常有用。

With the exception of the Development database server, schema changes have to be checked on QA, Stage and Production environment as well. The following scenarios will be explained in detail:

除开发数据库服务器外，还必须在质量检查，阶段和生产环境中检查模式更改。 将详细解释以下情况：

• Track Schema Changes Event
  跟踪架构更改事件
• Monitor Schema changes by Role
  按角色监视架构更改
• Alert on Schema changes
  架构更改警报

跟踪架构更改事件 (Track Schema changes Event)

EVENTDATA () is an inbuilt function of DDL trigger in SQL Server, which will return the Transaction event details with numerous fields in XML format.

EVENTDATA（）是SQL Server中DDL触发器的内置函数，它将以XML格式返回包含大量字段的Transaction事件详细信息。

• EventType (Create Table, Alter Table, Drop Table, etc…)
  EventType （创建表，更改表，删除表等）
• PostTime (Event trigger time)
  PostTime （事件触发时间）
• SPID (SQL Server session ID)
  SPID （SQL Server会话ID）
• ServerName (SQL Server instance name)
  ServerName （SQL Server实例名称）
• LoginName (SQL Server Login name)
  LoginName （SQL Server登录名）
• UserName (username for login, by default dbo schema as username)
  用户名 （用于登录的用户名，默认情况下为dbo模式作为用户名）
• DatabaseName (name of database where DDL Trigger was executed)
  DatabaseName （执行DDL触发器的数据库的名称）
• SchemaName (schema name of the table)
  SchemaName （表的模式名称）
• ObjectName (Name of the table)
  ObjectName （表名）
• ObjectType (Object types. such as Table, view, procedure, etc…)
  ObjectType （对象类型，例如表格，视图，过程等）
• TSQLCommand (Schema deployment Query which is executed by user)
  TSQLCommand （由用户执行的架构部署查询）
• SetOptions (SET Option which are applied while Creating table or Modify it)
  SetOptions （在创建表或修改表时应用的SET选项）
• CommandText (Create, Alter or Drop object command)
  CommandText （创建，更改或删除对象命令）

To monitor the schema pattern changes for Tables, Trigger event information has to be put some place(table) and checked by someone for the required activities. DDL trigger will be categorized at Database Level. Secondarily the necessity to convey this trigger on what database this DDL Trigger should be sent. Seen at large, an additional database can exist on the server for some research or examination purposes. So, we don’t have to convey this event method on those databases.

要监视表的模式模式更改，必须将触发器事件信息放在某个地方（表），并由某人检查所需的活动。 DDL触发器将在数据库级别分类。 其次，必须在应发送此DDL触发器的数据库上传达此触发器。 从总体上看，服务器上可以存在一个附加数据库，用于某些研究或检查目的。 因此，我们不必在那些数据库上传达此事件方法。

With the intention to monitor the progressions on Dev and QA Environment, schema changes event information ought to be put away someplace in the table. We have placed away event data in the event_data table which is situated in the master database. On the off possibility that off-base schema changes associated with the Table in the database, at that point Database Administrator will be required to deal with this table and determine the root cause to follow who and when rolled out these improvements.

为了监视Dev和QA Environment上的进度，模式更改事件信息应放在表中的某个位置。 我们已将事件数据放置在主数据库中的event_data表中。 如果与数据库中的表相关联的基础架构发生更改的可能性极小，那么此时将需要数据库管理员来处理此表并确定根本原因，以跟踪谁以及何时推出这些改进。

In this model, we will include one DDL Trigger for a DDL operation for a Table. On adding a new table, we will scrutinize the event data which will be embedded in the referenced table (event_data).

在此模型中，我们将为表的DDL操作包含一个DDL触发器。 在添加新表时，我们将检查将嵌入在引用表（event_data）中的事件数据。

DDL Trigger:

DDL触发器：

CREATE TRIGGER alert_table
ON DATABASE
FOR CREATE_TABLE, DROP_TABLE, ALTER_TABLE
AS
BEGININSERT INTO master.dbo.event_data(in_)--Inserting data into table in XML formatSELECT EVENTDATA();
END
GO

Table Script:

表脚本：

CREATE TABLE tbl_roles(role_id INT PRIMARY KEY IDENTITY(1,1), role_name VARCHAR(128));

Subsequent to Creating or Altering the table, the operation was efficiently finished. What’s more, currently we can check event_data table to get the most recent event_data data. We can see here that each detail of the above transaction has been included in XML design.

创建或更改表之后，该操作已有效完成。 此外，目前我们可以检查event_data表以获取最新的event_data数据。 我们在这里可以看到上述事务的每个细节都已包含在XML设计中。

<EVENT_INSTANCE><EventType>CREATE_TABLE</EventType><PostTime>2019-09-04T10:30:50.403</PostTime><SPID>60</SPID><ServerName>JERRY\jignesh</ServerName><LoginName>jerry</LoginName><UserName>dbo</UserName><DatabaseName>auth</DatabaseName><SchemaName>dbo</SchemaName><ObjectName>tbl_roles</ObjectName><ObjectType>TABLE</ObjectType><TSQLCommand><SetOptions ANSI_NULLS="ON" ANSI_NULL_DEFAULT="ON" ANSI_PADDING="ON" QUOTED_IDENTIFIER="ON" ENCRYPTED="FALSE" /><CommandText>CREATE TABLE tbl_roles(role_id INT PRIMARY KEY IDENTITY(1,1), role_name VARCHAR(128))</CommandText></TSQLCommand>
</EVENT_INSTANCE>

In this example, we have legitimately sent out XML in the table. Be that as it may, in an appropriate method for checking that XML ought to be extracted in the Column arrangement of the table. For the same, underneath XML command can support us with getting the required column of event_data only.

在此示例中，我们合法地在表中发送了XML。 不管怎样，在一种适当的方法中，应该检查是否应在表的Column安排中提取XML。 同样，在XML命令下方可以支持我们仅获取所需的event_data列。

@xml.value('EventType[1]', 'VARCHAR(128)') AS 'Event Type'

Here, @xml is a EVENTDATA() value in a trigger

在这里，@ xml是触发器中的EVENTDATA（）值

按角色监视架构更改 (Monitor Schema changes by Role)

At the time when Multiple Developers have to deal with a Project and they have to do changes in a database architecture, it will be difficult for a Database Engineer to observe and restrict the users to apply made changes on database. With this as an understanding, we will make use of Trigger to scrutinize changes in the schema in any database of SQL Server and Insert Record in the table, in such a way we can monitor the history of Schema changes made Over a polling time.

当多个开发人员必须处理一个项目并且必须在数据库体系结构中进行更改时，数据库工程师很难观察并限制用户将所做的更改应用于数据库。 以此为基础，我们将使用触发器来检查SQL Server的任何数据库中的架构更改以及表中的插入记录，从而可以监视在轮询时间内进行的架构更改的历史记录。

You will get appreciably more data from DDL eventa over the database, yet using custom metrics on the Trigger with the support of logged-in user’s role in SQL Server. We can also limit it. For illustration, the user-defined role and numerous systems will subsist in the SQL Server; however, as a characteristic of organization policy, database owners can determine or modify as they were.

您将通过数据库从DDL eventa中获得明显更多的数据，但是在触发器上使用自定义指标并在SQL Server中登录用户角色的支持下。 我们也可以限制它。 为了说明起见，用户定义的角色和许多系统将存在于SQL Server中。 但是，作为组织策略的特征，数据库所有者可以照原样确定或修改。

This model of strategy can be designed in DDL Trigger and the owner of an engagement can monitor it as well. It can even tell you the best way to utilizing the metrics to differentiate unapproved or unauthorized changes to database objects (tables).

可以在DDL触发器中设计这种策略模型，并且约定的所有者也可以对其进行监视。 它甚至可以告诉您利用这些指标区分未经批准或未经授权对数据库对象（表）所做的更改的最佳方法。

select IS_MEMBER('db_owner')

IS_MEMBER() is an in-built function in SQL Server to find that a particular user is a element of specified role or not. We used to keep watch on the user is a member of ‘db_owner’ or not. We can assess the role of a designated user and choose to authorize deliberate changes at the database level with below example.

IS_MEMBER（）是SQL Server中的内置函数，用于查找特定用户是否为指定角色的元素。 我们过去经常监视用户是否是'db_owner'的成员。 我们可以通过以下示例评估指定用户的角色，并选择授权在数据库级别进行有意更改。

CREATE TRIGGER alert_table
ON database
FOR CREATE_TABLE, DROP_TABLE, ALTER_TABLE
AS
BEGINIF IS_MEMBER ('db_owner') = 0BEGINPRINT 'Please contact your Database Administrator' INSERT INTO master.dbo.event_data(in_)SELECT EVENTDATA();ROLLBACK TRANSACTION;END
END
GO

We have applied a condition to restrict particular users which are not members of ‘db_owner’. Only those members or users can CREATE or ALTER the Table schema, who are existing with that role. On the off chance that the user does not exist or are not from that role; at that point logged-in will get a message which we categorized in the trigger for the same and that Event Data will get embedded in the table, on which Database Administrator will be able to keep close eyes. Indeed, even condition-based object access can be applied for too, in IF clause if it is necessary.

我们已应用条件来限制不是'db_owner'成员的特定用户。 只有那些具有该角色的成员或用户才能创建或更改Table模式。 用户不存在或不在该角色中的可能性很小； 届时登录后将收到一条消息，我们将其归类为触发器，并且事件数据将嵌入到表中，数据库管理员将能够密切注意该表。 确实，即使必要，也可以在IF子句中甚至应用基于条件的对象访问。

In the same approach, we can inspect EVENT Data as beneath in XML position.

用相同的方法，我们可以在XML位置中检查事件数据如下。

<EVENT_INSTANCE><EventType>CREATE_TABLE</EventType><PostTime>2019-09-04T12:00:56.973</PostTime><SPID>57</SPID><ServerName>JERRY\jignesh</ServerName><LoginName>myel</LoginName><UserName>myel</UserName><DatabaseName>auth</DatabaseName><SchemaName>dbo</SchemaName><ObjectName>tbl_roles</ObjectName><ObjectType>TABLE</ObjectType><TSQLCommand><SetOptions ANSI_NULLS="ON" ANSI_NULL_DEFAULT="ON" ANSI_PADDING="ON" QUOTED_IDENTIFIER="ON" ENCRYPTED="FALSE" /><CommandText>CREATE TABLE tbl_roles(role_id INT PRIMARY KEY IDENTITY(1,1), role_name VARCHAR(128))</CommandText></TSQLCommand>
</EVENT_INSTANCE>

架构更改警报 (Alert on Schema changes)

The most substantial prerequisite is to get an alert at the point these changes start happening. We can set that up right away in SQL Monitor, using a custom metric. When you get a notification, you would then be able to analyse the facts of the event.

最重要的前提是要在这些更改开始发生时发出警报。 我们可以使用自定义指标立即在SQL Monitor中进行设置。 收到通知后，您便可以分析事件的事实。

How could we setup monitoring of Schema Changes in Any Database of SQL Server? How could we monitor these developments and send out an alert e-mail to respective persons to Inform about this change? Common practice by engineers is to install schema blindly to a database without going for a check in their changes, however, we are now handling this obstacle and instruct these people from uncontrollably taking shots from the hip.

我们如何在SQL Server的任何数据库中设置对架构更改的监视？ 我们如何监视这些发展并向相应人员发送警报电子邮件，以通知此更改？ 工程师的常规做法是在不检查其更改的情况下盲目地将模式安装到数据库，但是，我们现在正在处理这一障碍，并指示这些人不要随意控制臀部。

Information security and administrative acquiescence necessities have turned out to be increasingly rigorous. Thus, DBAs are assigned with the heavy task of giving an exact review trail of schema changes and review this data can often require weeks or long stretches of custom improvement.

事实证明，信息安全和管理默认需求变得越来越严格。 因此，分配给DBA繁重的任务是提供对模式更改的准确审查线索，并且审查此数据通常可能需要数周甚至很长时间的定制改进。

The DDL Trigger will drop a mail to concern people including schema changes event details in HTML format.

DDL触发器将发送一封邮件，以引起人们的关注，包括HTML格式的架构更改事件详细信息。

CODE: ALTER_trigger.sql

代码： ALTER_trigger.sql

结论： (Conclusion:)

DDL triggers help a lot to manage event information in favour of Policy and Security perspective as part of SQL Triggers. We can fabricate an SSRS report as well on event_data to keep consecutively running against and pulled information as required.

DDL触发器作为SQL触发器的一部分，有助于从策略和安全性角度来管理事件信息。 我们还可以在event_data上构造SSRS报告，以根据需要保持连续运行并提取信息。

目录 (Table of contents)

翻译自: https://www.sqlshack.com/database-level-ddl-trigger-over-the-table/

表级触发器不支持ddl语句