有这样一个业务场景:两台服务器每天夜里定时用事务复制做同步。发布者服务器用的是简单恢复模式,而白天恰巧要做备份。如此,便会激发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),如下图
通过这个实验,得出了这个结论:
在事务复制模式下,如果事务没有被复制到订阅者,那么事务日志就不会被截断。