SQL Server：如何在不阻塞触发触发器的事务的情况下获得触发器的响应能力？

Question

在今天的一个线程中，我希望在插入记录时立即执行代码，而不是求助于轮询。

触发器是强大的工具，但也是放置真实代码的危险场所，因为如果代码缓慢或阻塞，事务就会阻塞，这可能会成为一个真正的问题。

就我而言，轮询是不可行的。我真的需要我的代码在记录出现时立即执行。Windows 应用程序正在向表中插入数据。我没有应用程序的来源，无法更改它。我可以完全访问 SQL Server。

但是将严肃的代码放入触发器中确实是一种不好的做法。

所以问题就变成了：与触发器一样响应的触发器的替代方案是什么？（或者几乎和响应一样......延迟 1-5 秒就可以了，但是 30 秒的轮询周期确实令人不快。要运行的代码需要 0-3 秒才能完成。）

约束：

• 我只能访问数据库，不能访问应用程序
• SQL Server 2005 和 2008
• 可行的。我们不希望发明一些疯狂的东西，添加大量基础设施或大型新系统。我们有一个应用程序。它与 SQL Server 对话。添加更多层概率是不可能的。
• 实现另一个服务器应用程序（如 msg 队列服务器等）对于这个项目是不可行的。这东西一天只会开一到十五次。

手头的工具（不全面）： - .NET - Python - C#

如果可能的话，希望避免使用 xp_cmdshell。

Answer 1

您也许可以使用服务代理，但正如您所说的那样，这可能有点矫枉过正。

或者，如果您不想为此需要安装/管理额外的服务，您可以使用xp_cmdshell或基于 CLR 的触发器在需要时进行外部调用，以异步启动所需进程的程序（因此，外部调用触发器的事务）并立即返回。与简单地将一些复杂的代码放在触发器中相比，我会对此更加谨慎——至少，使用触发器，任何优秀的 SQL Server DBA 人员都可以在您不在时支持代码，而不是需要一些其他特定的编程经验.

当您说轮询根本不是一种选择，因为“最多 30 秒”的延迟是不可接受的，您是否有理由不能更频繁地进行轮询？如果关注的是轮询会给服务器带来的负载，那么有一些方法可以使轮询保持非常轻量级。无论您需要触发器（或其他东西）来决定在插入行时是否需要操作 - 如果您在触发器中做出此决定并简单地将其记录在一个简单的状态表中，那么您可以轮询每个几秒钟或几秒钟等待该状态标记被更新（一个数据库每秒命中一次以每隔几秒（甚至每秒，或更频繁）执行一次简单的查找，除非您正在使用一些通过查询向您收费的云数据库服务）。同样，这远非理想，xp_cmdshell 选项。

无论你做什么，都要小心确保过程中的失败被适当地标记。当您从主事务中提取额外的处理时，您不能依靠现有的异常处理来告诉您由于某种原因它失败了——因此，您可能不知道您有一个日益严重的数据一致性问题。这里触发器的主要优点是，通过保持在同一个事务中，您知道您的数据保持一致，因为如果另一半失败，则不会提交另一半。