我目前正在使用SSIS进行一些流程，脚本和直接数据导入。大多数数据清理和转换都发生在我从SSIS执行SQL任务调用的存储过程中。对于大多数sprocs，如果由于任何原因失败，我真的不关心回滚任何交易。我的SSIS错误处理基本上消除了任何临时数据，然后将错误记录到表中。 （此时人类需要修复基础数据问题）
我的问题围绕着begin tran，end tran。是否有任何情况下存储过程可能会失败，然后不让调用SSIS进程知道？我正在寻找硬件故障，锁定超时等等。
我希望尽可能避免使用事务并依赖我的SSIS错误处理。
思想？
答案 0 :(得分：1)
如果存储过程没有更新或插入任何记录，我会想到（并且事务也无济于事）。这不会是失败，但它可能需要用于SSIS包。您可能希望返回受影响的行数并在之后检查。
我们也对某些导入执行此操作，其中与上次导入相比明显偏离的数字表示存在数据问题。因此，如果我们通常从导入B中的客户端A获得100,000条记录而我们获得5000条记录，那么SSIS包将失败，直到人们可以查看它并看到文件是坏的或者他们是否意外地意味着减少他们的劳动力或客户列表。
顺便提一下，我们分为两个表（一个包含未更改的原始数据和一个用于清理的表。如果您想轻松查看数据问题，SSIS包的失败不应该回滚。您可以告诉它们如果数据从一开始就是错误的，或者它以某种方式丢失或修复错误的清理过程。有时记录错误的地方不是错误实际发生的地方，很高兴看到数据看起来没有变化并且在更改过程之后。有时候你有糟糕的数据，是的（大多数时候都好）但有时候你有一个错误。拥有这两个表可以让你看到它们中的哪一个。
您可以将所有过程作为最后一步插入到日志记录表中，并确保在执行下一步之前记录在那里，如果您担心丢失一些不会冒泡回包的执行。