sql server事务复制和镜像共存性的测试

were

事务复制的发布库同时也是镜像的主库，测试的目的是当镜像发生故障转移时，事务复制关系是否能同时自动转移。
环境：JOEPCSQLJOEC,DB_TEST1,DB_TEST2_VM三台机都是Win2008_R2_SP1+SQLServer2008_R2_SP1.
        JOEPC,DB_TEST1都是物理机，DB_TEST2_VM是建立在DB_TEST1上的虚拟机。
关系说明：JOEPCSQLJOEC是镜像关系的主体，是事务复制关系的发布者，
              DB_TEST1是镜像关系的见证者，是事务复制的分发者和订阅者，
              DB_TEST2_VM是镜像关系的镜像端。
1. 首先在JOEPCSQLJOE上创建测试库和表。
USE TESTGOCREATE TABLE dbo.tb_Test( ID INT NOT NULL, VAL NVARCHAR(20) )GOALTER TABLE [dbo].[tb_Test] ADD CONSTRAINT PK_tbTest_ID PRIMARY KEY  CLUSTERED(        [ID] ASC)GOINSERT 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 事务复制建立JOEPCSQLJOE与DB_TEST1事务复制关系。
3. 参考工作组模式下SQL Server 2008 R2 数据库镜像建立JOEPCSQLJOE为主体，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.基本配置完成。测试验证一下，把JOEPCSQLJOE的SQLSERVER服务停掉，看一下镜像和复制关系能否转移。
   6.1 镜像关系成功转移过来了。
         
  6.2 事务复制关系开始时遇到一个错误：“进程无法在“DB_TEST2_VM”上执行“sp_replcmds”。 (源: MSSQL_REPL，错误号: MSSQL_REPL20011)”。
       这个错误是个权限问题，执行sp_replcmds需要sysAdmin权限，于是把TEST库的所有者改成SA。在DB_TEST2_VM上执行：
USE TESTGOEXEC 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”中把JOEPCSQLJOE的SQLSERVER停掉了。
   所以只有当JOEPCSQLJOE的SQLSERVER联机，重新构成镜像关系后，所做的修改才会从分发库传播到订阅库。
    于是启动JOEPCSQLJOE的SQLSERVER，果不其然，数据同步过去了。

总结：
      1. 镜像主体库，可以同时做事务复制的发布库，并且能实现故障自动转移。
      2. 我想要给一个7*24的关键库，用事务复制做读写分离，并且用“具有自动故障转移的高安全性模式”做热备。测试的结果有些鸡肋。
         当镜像关系中，有一个伙伴离线，故障自动转移后所做数据修改不会传播到订阅端。那么读写分离的只读库的数据也严重滞后，而不可用。