sql - 从事务中的 SQL 批处理中止错误中恢复？选择？

Question

我正在寻找一种方法来继续执行事务，尽管在插入低优先级数据时出现错误。看起来真正的嵌套事务可能是一个解决方案，但 SQL Server 2005/2008 不支持它们。另一种解决方案是有逻辑来确定错误是否严重，但这似乎也不可能。

以下是有关我的方案的更多详细信息:

使用 ADO.NET/C# 定期将数据插入到数据库中，虽然其中一些是至关重要的，但也可能会毫无问题地丢失一些数据。插入完成后，将对数据进行一些计算。 (重要的和非重要的)整个过程都在事务中，所以一切都保持同步。

目前，使用事务保存点，并对非重要插入期间发生的异常进行部分回滚。但是，这不适用于“批量中止”错误，它会自动回滚整个事务。我知道有些错误很严重，但是 SQL Server 将诸如失败的强制转换之类的事情视为批处理中止错误。 ( Info on batch errors ) 如果这些错误发生在低优先级数据上，我试图防止它们导致整个插入中断。

如果我所描述的内容是不可能的，我愿意考虑任何替代方法来实现数据完整性，但允许非重要插入失败。

谢谢你的帮助。

Answer 1

不幸的是，不能像您描述的那样完成(对嵌套事务的完全支持将是关键)。我能想到的几件事过去曾被用来解决这个问题:

最好的选择可能是将命令分成可以明确执行的重要/非重要命令，自然这将要求它们彼此不依赖于顺序

还可以使用基于消息传递的方法(参见 Service Broker )，您可以内联执行主要命令并将非主要命令推送到队列中以便稍后/单独执行。推送到队列将是批处理中的事务，但是当您从队列中弹出时命令的执行将是分开的。这也将要求它们不依赖于彼此的顺序。

如果依赖于顺序，您可以对所有内容使用消息传递方法，这将确保顺序并且每个操作可以有单独的消息，然后将它们分组在一起(通过对话组)将允许您按顺序将它们从队列中拉出并使用每种“类型”操作(即主要与非主要)的单独事务。如果所有分组消息都必须是单个自主操作，那么这将需要您进行一些特殊编码，但可以完成。

我什至不愿提及这个选项，因为这是一个糟糕的选项，但为了全面披露，我想如果你认为它合适，你可以自行考虑它(但它绝对不是一个适用于几乎任何场景的架构)。您可以使用 xp_cmdshell 调用命令行并为非关键任务执行 sqlcmd/osql - 此 sqlcmd 执行将与您正在执行的模块在单独的事务中，并且只需忽略 xp_cmdshell 故障应该允许主批处理继续。

这些是一些想法...