你要是全表复制的话,只需要在对应的article里面把表加上就可以了。重新初始化对应的publication

解决方案 »

  1.   

    我不是全表复制,发布里只有生产数据库中的部分表,且订阅端包含所有历史数据即要比生产数据库的数据多,所以应该不可以重新初始化对应的publication。
      

  2.   

    全表复制是只把需要的表全部复制而不是复制所需的列或者行的意思,如果不能初始化,那再加一个publication即可
      

  3.   

    那我每次加个表时都要加一个publication来实现岂不是很麻烦,长此以往就有好多publication了,有没有简便点的方法呢?另外,我在测试环境试了一下,直接将新表加到发布中数据也是能复制到订阅端的,但不知这样有没有潜在问题。
      

  4.   

    是的,原有的表加列是直接在发布端加就可以了,加的列会自动复制到订阅端我查了一下网上的资料,对于新加的表,一般有几种处理方式:
    1.在发布端建新表,然后重新初始化发布,生成新的快照;
    2.在发布端、订阅端都建新表,停日志读取代理,把新加的表加到订阅中,最后启用日志读取代理;
    3.建新的发布来发布新表。
    (参考:http://www.580top.com/html/201304/dba_2136.htm)但上面的方法都没有“直接将新表加到原有的发布上”来得简单,所以我怀疑我的做法是不是有什么潜在问题,但经测试又没有发现有什么问题。
    (注:我不是通过生成快照或初始化订阅来测试的。我是建了两个数据库,一个作为发布,一个作为订阅,发布的表在两个数据库中结构一样,然后通过向导建事务发布来实现的)
      

  5.   

    你是预先在订阅库建好表还是通过replication来生成的表?
      

  6.   

    预先在发布端、订阅端都建好表,然后再建复制实现数据同步。不是通过replication来生成的表,因为我们的现实环境是发布端与订阅端的数据不是一样的,比如发布端有最近1年的数据,而订阅端有所有年份的历史数据,所以不允许用发布端的表来生成订阅端的表。
      

  7.   

    这种方式我没试过,我都是通过replication产生的,发布最近一年的数据可以通过加where条件实现,设置article的时候有的
      

  8.   

    这种在article里面可以设置忽略delete操作,这样你的发布表即使删了数据也不会影响订阅表。不过你觉得麻烦的话可以按照自己的方式来做,但是最好预估一下一年之后会发生什么情况,环境在你那里,我也不知道怎么运作的
      

  9.   

    不能忽略delete,系统还需要正常的delete数据我试了一下,使用以下命令将新表加到原有发布中似乎也是可以的:
    exec sp_addarticle
    exec sp_refreshsubscriptions系统大概是这样的:
    系统以前是没有复制的,已经运行了多年了,现在运行是越来越慢,分析是数据多的原因,于是使用了复制:
    1.将当前数据库ProductionDB备份,然后恢复到历史数据库ProductionBak
    2.删除ProductionDB一年以前的数据
    3.建复制,ProductionDB作为发布端,ProductionBak作为订阅端
    4.以后每隔一段时间(不如一月或三月)删除ProductionDB一年以前的数据,删除步骤为:停掉操作ProductionDB的所有应用->停掉Log reader->删除ProductionDB一年以前的数据->启动Log reader->Ok
    这样ProductionDB就只有最近一年的数据,提高了系统性能,而ProductionBak有历年的历史数据了。