禁用触发器上的火灾触发器
有一个安全触发器可以阻止生产数据库实例上的所有 SQL DDL 事件(ALTER/DROP/CREATE 等)。
对于部署,您需要执行DISABLE TRIGGER
,然后在完成后执行ENABLE TRIGGER
。
我希望在安全触发器禁用/启用时通知操作员 (EXEC sp_notify_operator ...
)。它们似乎不是 DDL 事件,我无法添加sys.triggers 上的 UPDATE/DELETE 触发器。有什么想法吗?
There's a safety trigger that blocks all SQL DDL events (ALTER/DROP/CREATE etc.) on a production database instance.
For deployments you'd do DISABLE TRIGGER
and then ENABLE TRIGGER
when done.
I'd like an Operator to be notified (EXEC sp_notify_operator ...
) when the safety trigger is DISABLED/ENABLED. They don't appear to be DDL events and I can't add an UPDATE/DELETE trigger on sys.triggers
either. Any ideas?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
由于从执行的 DDL 语句来看您已经受到“保护”,因此您可以添加另一个数据库触发器来查找调用过程来通知操作员的 DDL 事件。不过,您可能需要另一层管理——也许需要对通知进行排队——这样它就不会变得太垃圾。我可以想象正在推出的更改并收到 100 多封电子邮件通知......糟糕。
在我看来,这还有一个很好的副作用,即保持通知逻辑和 DDL 预防逻辑分离。
Since you're already "protected" so to speak from DDL statements being executed, you could add another database trigger looking for DDL events that calls a procedure to notify an operator. You might need another layer of management though - maybe something to queue the notifications - so that it doesn't become too spammy. I could envision changes being rolled out and receiving 100+ email notices...yuck.
In my opinion this also has the nice side effect of keeping notification logic and DDL prevention logic separated.