SqlServer Bug:复制架构更改参数(replicate_ddl)无效

最近测试可更新订阅的架构更改问题,发现了一个 bug。

在复制中,当在发布数据库对发布数据库进行架构更改时,结构自动同步到订阅中(这就是
复制架构更改)。由于某些原因,对某个表增加字段时,不需要同步到订阅。在发布属性中,有一个选项可以控制不同步架构更改。如下图:

只有将 复制架构更改 的值改为 false ,更改结构则不同步,更改实时生效。

也可以脚本来更改该参数:

EXEC sp_changepublication
@publication = N'publication',
@property = N'replicate_ddl',
@value = 0
GO

EXEC sp_changepublication
@publication = N'publication',
@property = N'replicate_ddl',
@value = 1
GO

但是在 Microsoft SQL Server 2008 R2 (RTM) 中,该参数更改有问题。当把参数改为
False 时,架构更改是不会同步了;但是再把参数改回
True
时,发现结构更改也还是不同步。怀疑是bug,没有找到相关文档说明这个问题,于是自己下载
Microsoft? SQL Server? 2008 R2 Service Pack 3 更新试试看。安装SP3 后,正常了!~也许这个功能用的比较少吧,没有找到该问题的问题和修复文档,既然 sp3 有修复,那说明官方已经确认修复了。

时间: 2024-10-13 18:39:26

SqlServer Bug:复制架构更改参数(replicate_ddl)无效的相关文章

SqlServer 禁止架构更改的复制中手动修复使在发布和订阅中分别增加字段同步

由于之前的需要,禁止了复制架构更改,以至在发布中添加一个字段,并不会同步到订阅中,而现在又在订阅中添加了一个同名字段,怎么使这发布和订阅的两个字段建立同步关系呢? 下面就测试更改:此次发布类型为事务复制的可更新订阅,其他类型的发布没有测试. 首先建立事务复制的可更新订阅,建立好之后. 在发布创建一张测试表: CREATE TABLE [dbo].[DemoTab]( [Guid] [uniqueidentifier] NOT NULL, [SID] [varbinary](85) NOT NUL

SQLServer 可更新订阅数据在线架构更改(增加字段)方案

之前一直查找冲突发布和订阅数据不一致的原因,后来发现多少数据库升级引起,因为一直以来都是在发布数据库增加字段,订阅也会自动同步.在此时如果订阅队列有数据,这些数据将丢失.参考上一篇说明:SQLServer 可更新订阅数据冲突的一个原因 .当在发布数据库增加一个字段时,系统同步存储过程和触发器都会重新生成,这会导致仍在队列中的数据无法正常同步.订阅队列中的命令将因"同步"后消失,代理有可能出错,但也会自动回复正常!~ 这周测试了一些方法,最终算是确定一个方案可行的,虽然麻烦和耗时. 首先

SqlServer 更改复制代理配置文件参数及两种冲突策略设置

原文:SqlServer 更改复制代理配置文件参数及两种冲突策略设置 由于经常需要同步测试并更改代理配置文件属性,所以总结成脚本,方便测试. 可更新订阅的冲突策略有两种情况:一是在发布中冲突,即订阅数据到发布时冲突:二是在订阅冲突,发布数据到订阅时冲突. 队列读取器设置的是:发布到订阅的冲突策略 代理配置参数位置: 里面的参数是需要更改的,未显示的参数,则是没有添加到配置文件的.但是取消上面的勾选是可以看到还有那些配置参数. 使用复制代理配置文件参考:https://msdn.microsoft

SqlServer删除复制监视器中无效的发布名称

原文:SqlServer删除复制监视器中无效的发布名称 在服务器复制监视器中有一个发布名称,因为该发布订阅已经删除. ReportServerTempDB只有一个发布,已无效,打算删除. --直接删除表记录 select * from dbo.MSsnapshot_agents where publisher_db='ReportServerTempDB' --直接删除表记录 DELETE FROM distribution.DBO.MSlogreader_agents WHERE publis

MySQL的复制架构与优化

###########原理###########1.主服务器将更新的数据的sql语句(例如,insert,update,delete等)写入到  二进制文件中(由log-bin选项开启).此二进制文件由一个索引文件跟踪维护.  2.从服务器连接(使用I/O线程连接)主服务器,将自己最后一次更新的位置通知  主服务器.然后,主服务器将把从'从服务器'得知的位置开始之后的所有更新发  送给'从服务器'(使用Binlog Dump线程来发送),而后'从服务器'再次使用I/O  线程读取由Binlog

关系型数据库之MariDB 10.0.10多主一从的架构及多线程复制架构

一.MySQL 5.6 以后出现的GTID:GTID概念: 1.GTID是一个由服务器的UUID和事务序号组成的唯一事务序号      例如: UUID:N          1122-3322-1122:1           1122-3322-1122:2 2.GTID会被当做唯每一个事务的首部,将会自动生成并存到二进制日志中3.GTID可以用来追踪主从之间的事务传输.4.GTID主要应用于HA的功能.在多主模型中,标示某一个事务是来源于哪个特定的主服务器.5.从服务器不会修改或者添加新的

搭建MySQL的主从、半同步、主主复制架构

复制其最终目的是让一台服务器的数据和另外的服务器的数据保持同步,已达到数据冗余或者服务的负载均衡.一台主服务器可以连接多台从服务器,并且从服务器也可以反过来作为主服务器.主从服务器可以位于不同的网络拓扑中,由于mysql的强大复制功能,其复制目标可以是所有的数据库,也可以是某些数据库,甚至是某个数据库中的某些表进行复制. MySQL支持的两种复制方案:基于语句复制,基于行复制基于语句复制基于行复制,这两种复制方式都是通过记录主服务器的二进制日志中任何有可能导致数据库内数据发生改变的SQL语句到中

MSSQL报错:参数数据类型 text 对于 replace 函数的参数 1 无效的解决办法

Ms - sql 数据库批量替换字符串 MSSQL报错:参数数据类型 text 对于 replace 函数的参数 1 无效的解决办法 update ContentInfo set spcContent=replace(cast(spcContent as varchar(max)),'http://www.buy5188.com/','http://www.epowerchina.com.cn/')

转载-Mysql主主复制架构配置

Mysql主主复制架构配置 转载:原始出处 http://luoweiro.blog.51cto.com/2186161/658550MySQL主主复制结构区别于主从复制结构.在主主复制结构中,两台服务器的任何一台上面的数据库存发生了改变都会同步到另一台服务器上,这样两台服务器互为主从,并且都能向外提供服务. 这就比使用主从复制具有更好的性能.接下来我将使用两个同样的服务器来实现这个效果:具体Mysql的安装我就省略了,在上一篇的Mysql的主从架构的配置中有详细介绍server1_mysql: