事务复制和镜像共存性的测试
事务复制的发布库同时也是镜像的主库，测试的目的是当镜像发生故障转移时，事务复制关系是否能同时自动转移。
环境：JOEPC\SQLJOEC,DB_TEST1,DB_TEST2_VM三台机都是Win2008_R2_SP1+SQLServer2008_R2_SP1.
JOEPC,DB_TEST1都是物理机，DB_TEST2_VM是建立在DB_TEST1上的虚拟机。
关系说明：JOEPC\SQLJOEC是镜像关系的主体，是事务复制关系的发布者，
DB_TEST1是镜像关系的见证者，是事务复制的分发者和订阅者，
DB_TEST2_VM是镜像关系的镜像端。
1. 首先在JOEPC\SQLJOE上创建测试库和表。
USE TEST
GO
CREATE TABLE dbo.tb_Test
(
ID INT NOT NULL,
VAL NVARCHAR(20)
)
GO
ALTER TABLE [dbo].[tb_Test] ADD CONSTRAINT PK_tbTest_ID PRIMARY KEY CLUSTERED
(
[ID] ASC
)
GO
INSERT INTO dbo.tb_Test
( ID, VAL )
VALUES (1,N'A'),(2,N'B'),(3,N'C'),(4,N'D')
,(5,N'E'),(6,N'F'),(7,N'G'),(8,N'H');
GO
2. 参考工作组模式下SQL Server 2008 R2 事务复制建立JOEPC\SQLJOE与DB_TEST1事务复制关系。
3. 参考工作组模式下SQL Server 2008 R2 数据库镜像建立JOEPC\SQLJOE为主体，DB_TEST2_VM为镜像，DB_TEST1为见证的镜像关系。
在这里我遇到一个问题见证机总是连接不上，最后放弃用代码来实现，用镜像配置向导重新配置，成功。
4. 在分发服务器DB_TEST1上把镜像服务器DB_TEST2_VM加入到发布者。
这一步的目的：1.将镜像添加为发布者。2. 镜像成为发布者后与镜像主体使用同一个快照文件夹，同一个发布服务器。
5. 在分发服务器上执行以下代码。profile_id代表不同的配置文件，下面列出几个对应关系。
--查看代理配置文件
-- 1 = Snapshot Agent; 2 = Log Reader Agent; 3 = Distribution Agent; 4 = Merge Agent; 9 = Queue Reader Agent.
exec sp_help_agent_profile
--因为测试做的是事务复制,所以需要修改配置文件只包括Snapshot Agent,Log Reader Agent.
exec sp_add_agent_parameter @profile_id = 1, @parameter_name = N'-PublisherFailoverPartner',
@parameter_value = N'DB_TEST2_VM';
exec sp_add_agent_parameter @profile_id = 2, @parameter_name = N'-PublisherFailoverPartner',
@parameter_value = N'DB_TEST2_VM';
6.基本配置完成。测试验证一下，把JOEPC\SQLJOE的SQLSERVER服务停掉，看一下镜像和复制关系能否转移。
6.1 镜像关系成功转移过来了。
6.2 事务复制关系开始时遇到一个错误：“进程无法在“DB_TEST2_VM”上执行“sp_replcmds”。 (源: MSSQL_REPL，错误号: MSSQL_REPL20011)”。
这个错误是个权限问题，执行sp_replcmds需要sysAdmin权限，于是把TEST库的所有者改成SA。在DB_TEST2_VM上执行：
USE TEST
GO
EXEC sp_changedbowner 'SA','dbowner'
GO
OK,事务复制也正常了。不过还是插入两条数据看一下，能否同步到DB_TEST1下的订阅库TEST_Subscriber。
INSERT INTO dbo.tb_Test(ID,VAL) VALUES(9,N'I'),(10,N'J')
在DB_TEST1的订阅库TEST_Subscriber查询，发现数据没有同步过来。在日志读取代理的作业历史中找到“复制的事务正等待下一次日志备份或等待镜像伙伴更新”。
在MSDN上找到：
这个测试中镜像用的正是“具有自动故障转移的高安全性模式”，并且“步骤6”中把JOEPC\SQLJOE的SQLSERVER停掉了。
所以只有当JOEPC\SQLJOE的SQLSERVER联机，重新构成镜像关系后，所做的修改才会从分发库传播到订阅库。
于是启动JOEPC\SQLJOE的SQLSERVER，果不其然，数据同步过去了。
总结：
1. 镜像主体库，可以同时做事务复制的发布库，并且能实现故障自动转移。
2. 我想要给一个7*24的关键库，用事务复制做读写分离，并且用“具有自动故障转移的高安全性模式”做热备。测试的结果有些鸡肋。
当镜像关系中，有一个伙伴离线，故障自动转移后所做数据修改不会传播到订阅端。那么读写分离的只读库的数据也严重滞后，而不可用。
