問題の説明：
CMDの数に取引。CMDを実行した後にもトリガを実行することができます。私は、トランザクションと加入者のトリガーの間の取引と取引間の順序を実行し、CMDとCMDとの間で、クリアCMDと思います。
シモンズ： - サブスクライバここ出版社、ディストリビューター、特定の詳細を無視して、唯一の構造は、パブリッシャとして簡略化されて詳細に検討していません
結論：
1）
取引については、
;それぞれのcmdは、第1の加入者を更新するために、cmdを実行し、その後、加入者は、実行後にトリガ物事の一連のを待って、完全なCMDをアンロックされたロック
完了後CMD、CMDを実行する前に、すなわち、リニアアクチュエータ。
各トランザクションのために、
それは、リニアアクチュエータで次のトランザクションを実行する前に取引が完了したことを発表した後、
ツールの利用も見てみよう
sys.dm_tran_locks、レプリケーションモニタ、最適化のヒント、フリップフロップ、WAITFOR
質問を探ります：
1）
取引の場合のみCMD、CMDおよび実行シーケンストリガ加入
TestTriggerとTestTriggerDst 2つのテーブルを含むSourceExam用のパブリッシャデータベース、。いいえトリガーありません。
DstExamのための加入者データベースは、テーブルTestTriggerとTestTriggerDstが含まれています。次のようにTestTriggerは、テーブルの上にトリガーが含まれ、およびNOT FOR REPLICATIONオプションを開くことはありません
出版社は、取引時に加入者にタッチトリガーを発行し、次のステートメントを実行することができますしてみましょう
出版社はまた、そのlastwaittypeを待っていることはWAITFORであり、データXロックとページ以上の長期保有のIXロックデータラインがわかります。説明ライト・トランザクションが完了していません。
而此时用优化器提示with (nolock)来做SELECT操作，会发现，Subscriber表里的数据已经被更新。说明写事务内容本身已经做完了。
等到WAITFOR的时间结束后，用上述查看锁的语句发现，写事务已经消失，说明写完成了。
所以，我们大胆推断：
对于单个cmd的处理，先上锁、执行对Subscriber的更新，然后等Subscriber产生的一连串事情都运行完后，才解锁、完成。
2）
在一个transaction有多个cmd的情况下，cmd和cmd之间的运行顺序
Subscriber的TestTrigger表上的触发器改为如下
同时，Publisher也设置一个触发器，内容为更改TestTriggerDst的数据。然后，发布一个能激发Publisher和Subscriber触发器的事务。这样，复制监视器里会显示：
然后可以看到，这回事务发布失败，可看到下述复制监视器里的消息。说明第一个cmd的删除执行之后，才执行第二个cmd
这说明，第一个cmd的触发器要运行完毕，才能运行第二个cmd。可大胆猜想：
第一个cmd宣告运行完后，第二个cmd才能运行
另外，发生错误后，在Subscriber处发现TestTriggerDst依然存在。这是因为一个执行不成功的transaction会被回滚。
3）
在有多个transaction的情况下，transaction和transaction之间的运行顺序
Subscriber的TestTrigger表上的触发器改为如下
同时，利用GO语句或BEGIN TRANSACTION语句分别发送两个事务，事务A用于触动Subscriber的触发器，事务B则执行对TestTriggerDst的修改。然后，根据上述sys.dm_tran_locks的查询代码，可以判断第一个事务还在处理中；此时查询事务B修改的那个表，看事务B是否已执行。结果发现，在事务A未宣告完成期间，事务B不会得到执行，所以，我们大胆推断：
第一个transaction宣告运行完毕后，第二个transaction才开始运行