[探究]事务日志截断是否会影响事务复制？

有这样一个业务场景：两台服务器每天夜里定时用事务复制做同步。发布者服务器用的是简单恢复模式，而白天恰巧要做备份。如此，便会激发CHECKPOINT、截断事务日志。这是否会影响夜里做事务复制呢？

我对这个问题的探究结果为：

在事务复制模式下，如果事务没有被复制到订阅者，那么事务日志就不会被截断。就是说，根本不会发生截断。

为了探究这个问题，我做了一个小实验，如下。

Step 1 建立一个数据库SRC，设为Simple恢复模式。并建立表Test_Truncate

      --创建数据库

      USE  master

      CREATE  DATABASE  SRC

      GO

      ALTER  DATABASE  SRC  SET  RECOVERY  SIMPLE ;

      GO

      - -创建数据表

      USE  SRC

      CREATE  TABLE  Test_Truncate (

                        id  INT  IDENTITY (  1 , 1  ),

                        num  INT  ,

                       CONSTRAINT  PK_id  PRIMARY  KEY  ( id  )

      )

      --插入一条数据

      INSERT  INTO  Test_Truncate  VALUES ( 0  )

Step 2 建立一个发布，并在本机建立数据库DST来作为订阅者数据库，然后建立订阅。要保证订阅者已被初始化，但是分发代理是Run on demand模式。并且在复制监视器里停掉Log Reader。这样，分发代理和Log Reader代理会被禁用。

Step 3 扩大活动区间：生成大量事务，然后运行DBCC LOGINFO。

      --生成大量事务以扩大日志的活动区间

      DBCC  LOGINFO

      DECLARE  @i  INT  =  0

      WHILE ( @i  <  10000  )

      BEGIN

                        UPDATE  Test_Truncate  SET  num  =  num  +  1

                        SET  @i  =  @i  +  1

      END

      DBCC  LOGINFO

     DBCC LOGINFO的运行结果表明，活动区间已被扩大：

     

     这一步发现，事务日志的活动区间已被非常大，充满了大量虚拟日志文件。

     

Step 4 尝试截断事务日志：运行CHECKPOINT，再运行DBCC LOGINFO

     DBCC LOGINFO的结果为：

         

     这一步发现，事务日志的活动区间没有变化。

Step 5 运行Log Reader，但不开启分发代理。然后运行CHECKPOINT，再运行DBCC LOGINFO

     DBCC LOGINFO的结果为：

     

     这一步发现，事务日志的活动区间没有变化。

Step 6 运行分发代理。然后运行CHECKPOINT，再运行DBCC LOGINFO

     DBCC LOGINFO结果如下

     这一步发现，事务日志的活动区间变小了，只剩下了一个活动虚拟日志文件（其Status为2），如下图

     

通过这个实验，得出了这个结论：

     在事务复制模式下，如果事务没有被复制到订阅者，那么事务日志就不会被截断。