我一直在努力了解SSIS中的检查点功能。对于这个实现，我包含了以下配置:
-
我执行了4个execute-sql-task，顺序与优先级约束相关:第三个execute-sql-task将在第一次尝试中失败，因此我将修复错误并重新运行包以观察Checkpoint特性行为
-
对于包，transactionoption:Supported，对于每个execute-sql-task, transactionoption:Supported
-
在包属性上设置检查点配置如下:
- CheckPointFileName:文件路径
- CheckPointUsage: ifExists
- SaveCheckPoints:真
- 为每个execute-sql-task设置属性:
- FailPackageonFailure:真正的
在此配置下，对于第一次运行的package，前2个任务在sqlserver上执行更新表，第3个任务失败，第4个任务根本没有启动，因为它的优先级约束任务具有precedence-constraint:success;检查点文件被创建，我修复了错误并重新运行包。这一次，只有任务3和任务4一起执行，并对数据库进行更新;这清楚地显示了Checkpoint的预期行为。
然而，然后我对TransactionOption:Required for the 4 tasks中的每一个做了一个改变，并且包TransactionOption:Supported;我执行了两次包来观察Checkpoint行为。在这里，我观察到—尽管任务1和任务2在第一次运行中成功，但它们在第二次运行中与任务3和任务4一起再次执行，并对表进行了更新。我相信，使用检查点配置，包必须从失败的任务开始(并执行以下未执行的任务);
好吧，简单地说，我关心的是，这两种情况之间的区别是什么?场景01 ----
A) Package TransactionOption:supported——B)每个执行-sql-tasks事务:支持——C)检查点:已配置
场景02——A) Package TransactionOption:supported——B)每个Execute-sql-tasks Transaction:required——C) checkpoint: configured.
谁能帮我理解一下这个场景?感谢您给予的宝贵支持。阅读微软关于检查点的文档，有以下说明。
在同一个包中使用检查点和事务可能会导致意想不到的结果。例如，当包失败并从检查点重新启动时，包可能会重复已经成功提交的事务。
检查点功能还有其他限制，比如不支持For Each Loops。数据流将完全重新运行，检查点不捕获数据流中间状态。
Checkpoint是一个有局限性的好工具;它不是包状态重启的灵丹妙药。