很多人在SQL Server中配置DDL触发器时都会遇到一个常见困惑：明明创建了阻止DROP TABLE的触发器，却依然无法生效。核心问题在于：DDL触发器必须显式启用才能正常工作，创建后不启用就等于没用，这是导致线上操作事故的重要原因。
在SQL Server中，使用CREATE TRIGGER ... ON DATABASE FOR DROP_TABLE语法创建触发器后，默认处于禁用状态。许多线上事故的根源正是忽略了这个细节——"建完就以为万事大吉"，结果该响应的操作没有生效。检查是否启用非常简单：执行SELECT is_disabled FROM sys.triggers WHERE name = 'tr_block_drop'，返回1即为禁用。启用时必须指定作用域：ENABLE TRIGGER tr_block_drop ON DATABASE针对当前数据库，ENABLE TRIGGER tr_block_drop ON ALL SERVER则是全局级别，后者需谨慎使用。另外注意，服务器级触发器无法拦截用户数据库内的DROP TABLE操作，它只响应CREATE LOGIN、ALTER DATABASE这类跨库事件。
DDL触发器必须显式启用才生效
如上文所述，创建的DDL触发器默认处于非活动状态，即使语法完全正确，也不会对DROP TABLE等操作产生任何影响。因此，在创建后务必确认启用状态并正确激活，这是实现防护功能的第一步，也是必须完成的关键步骤。
必须用 EVENTDATA() 提取对象名，不能用 OBJECT_NAME()
在DDL触发器中，OBJECT_NAME()函数是不可靠的——表可能已经被删除或尚未创建，该函数会直接返回NULL。真正可靠的方案是使用EVENTDATA()返回的XML数据。
正确提取表名的方式：CAST(EVENTDATA() AS XML).value('(/EVENT_INSTANCE/ObjectName)[1]', 'sysname')。提取Schema名同理：CAST(EVENTDATA() AS XML).value('(/EVENT_INSTANCE/SchemaName)[1]', 'sysname')。
这里有一个关键点：必须用TRY...CATCH包裹解析逻辑。原因在于XML结构可能因版本调整而变化——如果SQL Server后续更新了字段名，触发器会报错并中断事务，反而阻断了正常的运维操作。常见错误包括XPath写成/ObjectNamee，或者遗漏[1]，导致判断完全失效，防护形同虚设。
RAISERROR 必须 ≥16 级且紧跟 ROLLBACK
在DDL触发器中，级别低于16的错误（例如RAISERROR('...', 10, 1)）仅作为警告，不会中断事务，DROP TABLE依然可以成功执行。必须使用RAISERROR('禁止删除表', 16, 1)或更高等级（16–25），才能强制SQL Server中断当前批处理并回滚操作。
紧随RAISERROR之后必须添加ROLLBACK命令，不能依赖事务自动终止，否则批处理可能继续执行后续语句，造成意外后果。另外，注意不要在触发器内使用PRINT或SELECT——这些语句不会中断事务，DROP操作仍会正常完成。
白名单不能只比对登录名，要绑定会话上下文
硬编码ORIGINAL_LOGIN() IN ('sa', 'dba_admin')是常见的安全漏洞：如果所有归档脚本都使用同一个账号运行，那么该账号就能畅通无阻地删除任何表。更安全的做法是结合PROGRAM_NAME()、HOST_NAME()或自定义上下文（如SET CONTEXT_INFO）进行联合校验。
举个例子：应用层在执行清理操作前先设置一个标识，比如SET CONTEXT_INFO 0x5472756E636174654A6F62，触发器中再通过CONTEXT_INFO()提取并验证。对于临时表的放行，不能仅依赖LIKE '%temp%'——攻击者可以创建user_temp_drop_me来绕过，应严格匹配系统临时表的命名规范（如以#或##开头）。
注意一个"坑"：TRUNCATE TABLE
DDL触发器无法拦截TRUNCATE TABLE操作，因为它遵循不同的执行流程，根本不会触发任何DDL触发器。这一特性最容易被忽略，必须依靠权限管控（例如REVOKE ALTER ON SCHEMA::dbo FROM [app_user]）或审计日志来提供补充防护。
