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

plantegg

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