SQL Server 2005复制(一.可用性测试评估)

一、基本的功能测试：

DML操作同步：

1.有主键表的增/删/改数据同步（同步正常）

2.无主键表的增/删/改数据同步（无主键不能作同步复制，必须将每一张表加主键，否则无法配置到同步环境）

3.包含索引的表的增/删/改数据同步（同步正常）

4.包含触发器的表的增/删/改数据同步（如果A表包含有触发器，当增加记录时向B表插入数据，备库上会报错）

5.包含级连删除/修改数据的表的删/改数据同步 （同步正常）

6.包含大对象数据的表增/删/改数据同步（同步正常）

DDL操作同步：

１.增加表（不能同步新增加的表及数据，但不会报错）

２.删除表出错

（drop table dbo.test

消息3724，级别16，状态2，第1 行

无法对表' dbo.test ' 执行删除，因为它正用于复制。）

３.修改表名出错

（EXECUTE sp_rename N' dbo.test ', N'test1', 'OBJECT'

消息15051，级别11，状态1，过程sp_rename，第301 行

该表已为了复制而被发布，所以无法重命名。）

４.增加表索引 （不能同步索引，但不会报错）

５.删除表索引  （不能同步索引，但不会报错）

６.修改表索引  （不能同步索引，但不会报错）

7.增加表字段 （主DB增加字段会同步到复制DB

ALTER TABLE dbo.test ADD testcolumn NVARCHAR(20) null）

8.删除表字段 （同步正常）

9.修改表字段  （同步正常）

10.存储程序类同步（有时会报错，需要进一步跟踪原因）

二、稳定性及同步监控测试

1 .发布服务器断网,sql server服务关闭,重启动,关机的时候,对已经设置好的复制没有多大影响 。

  中断期间,分发和订阅都接收到没有复制的事务信息

2. 分发服务器断网,sql server服务关闭,重启动,关机的时候,对已经设置好的复制有一些影响。中断期间,发布服务器的事务排队堆积起来(如果设置了较长时间才删除过期订阅的选项, 繁忙发布数据库的事务日志可能会较快速膨胀), 订阅服务器会因为访问不到发布服务器，反复重试，我们可以设置重试次数和重试的时间间隔(最大的重试次数是9999, 如果每分钟重试一次,可以支持约6.9天不出错) 。

分发服务器sql server服务启动,网络接通以后,发布服务器上的堆积作业将按时间顺序作用到订阅机器上:  会需要一个比较长的时间(实际上是生成所有事务的insert,update,delete语句,在订阅服务器上去执行)

3 .订阅服务器断网,sql server服务关闭,重启动,关机的时候,对已经设置好的复制影响比较大,需要重新初试化

三、复制配置注意事项

1.如果想同步主DB上的非聚集索引，需要在主DB发布属性项目中对表点右键，选择设置所有表项目的属性，将复制非聚集索引设为true

2.主DB发布属性项目中增加新的对象后，需要重新初始化快照，才能将新的对象同步。增加新的对象不需要重新初始化订阅

3.可以个性化的新建复制DB上的索引，当建立后要注意重新初始化订阅后，需要重新建立这些主DB上不存在的索引

4.具体事务复制延迟的时间受网络，事务并发等因素的影响，局域网内的事务复制一般情况下延迟在3、4秒左右，第一次初始化的时间较长，可以利用备份文件初始化。所以对于实时性要求高的业务逻辑不能依赖于复制DB。

5.为了降低复制对主DB性能的影响，可以增加筛选仅复制需要的数据和字段；将订阅作为请求式的；独立分发服务器。

6. 通过使用事务复制或合并复制发布的表不能使用TRUNCATE TABLE语句，只能考虑使用DELETE 语句代替

四、复制DB的应用场景

关于复制数据库的使用，我设想了几种复制DB的应用场景：

(1.)作为开发人员日常查询只读数据库；

(2.)一般分析处理及统计数据的后台；

(3.)数据仓库和报表数据源；

(4.)可在复制DB上个性化的自定义一些索引针对某些应用的查询；

(5.)可以考虑将复制DB作为一些缓存数据或非实时性业务查询的数据源；

(6.)考虑利用复制DB改进每晚一些作业的处理。

(7.)可以考虑根据业务或用户的访问或者访问的实时性，将主数据库划分为多个分布式的数据库，这时复制作为实施分布式数据的一种方法，可以利用复制创建数据的副本

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/ssxw/archive/2009/04/23/4103491.aspx

转载于:https://www.cnblogs.com/safezone/articles/1496026.html