none
关于2008复制订阅的几个问题 RRS feed

  • 问题

  • 最近,在准备以复制订阅的形式,同步备份二十几个业务数据库,遇到几个问题,有人对这块熟悉么,请回复下

    1、以事务的形式实现订阅需开启完全恢复模式,但在这种情况下,如何管理事务日事,必竟服务器空间有限,开启后日志会非常大,如果清日志时如何保证订阅服务器上的数据已经同步了

    2、因为是在已经运行一段时间的业务库实施这项功能,发布服务器的数据量已经有一些了,这样就导致初始化订阅时,速度很慢,如何能提高这块的速度,具体操作方式是怎样的

    3、如果采用只在一台订阅服务器上,建立多个分库对应不同的发布服务器,对这台订阅服务器的性能是否会有很大影响,如果只有这么一台订阅服务器的话,如何确定这台服务器的硬件配置

    2011年9月5日 11:40

答案

  • 1. set sql job to backup log in schedule (like every 15 minutes).

    3. don't need multiple distributor. Hardware spec depends on work load, you can work with server vendor on it.



    2011年9月5日 15:21

全部回复

  • 第二个问题我已经找到办法了,原来可以手动初始化的

    2011年9月5日 13:27
  • 1. set sql job to backup log in schedule (like every 15 minutes).

    3. don't need multiple distributor. Hardware spec depends on work load, you can work with server vendor on it.



    2011年9月5日 15:21
  • 测试过程中还遇到4个问题,请释疑下:

    1、对于具有IDENTITY 属性列的表,订阅库必须针对这类别取消该属性或是set IDENTITY  on 么,有没有其它办法,因为打算拿订阅库作为一个备用库用,如果必须取消的话,是否有批量设定方式可以简化操作的

    2、对于具有触发器的表,必须删除触发器或是增加NOT FOR REPLICATION 选项么,有没有更快速的处理方式,而不需要针对每个触发器进行修改的

    3、如果因为升级的原因,增加了新表或是变更了表结构,订阅库是否需要同步升级,特别是新表是否有方法可以不用手动添加到发布项目里的

    4、使用业务库数据库副本搭建的订阅库,除了以上两点会影响到数据的同步,还有没其它地方需要注意的


    2011年9月6日 13:18
  • 1. no, but you have to use 'not for replication' for it when create table. 

    2. no quick way.

    3. have to add new tables to article, sql will not pick them automatically. Schema changes are replicated by default.

    2011年9月6日 13:29