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