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

有这样一个业务场景：两台服务器每天夜里定时用事务复制做同步。发布者服务器用的是简单恢复模式，而白天恰巧要做备份。如此，便会激发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），如下图

     

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

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