两个具有不同名称且具有不同列名称的表之间的复制。是否可以创建这样的复制
我有一个要求,在两个具有不同名称且具有不同列名称的表之间创建复制。是否有可能创建这样的复制。
server A server B
---------- ----------
Table : Test Table : SUBS
-------------- ---------------
columns A,B,C Columns D,E,F,G,H
我想配置复制,以便将 A 列数据复制到 D 列,将 B 列数据复制到 E 列,将 C 列数据复制到 F 列
I have a requirement where i have create replication between two tables with different names and which have different column names. Is it possible to create such replication.
server A server B
---------- ----------
Table : Test Table : SUBS
-------------- ---------------
columns A,B,C Columns D,E,F,G,H
I want to configure replication so that column A data is replicated to column D, column B data is replicated to column E, column C data is replicated to column F
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
显然,答案是:“定义文章时,必须将
@vertical_partition
参数设置为 true,然后使用sp_articlecolumn
添加所需的列。 ”不过,我不得不问你为什么要这样做。在我看来,复制并不是在不同数据库之间移动数据的通用工具,而是用于保持两个相同数据库同步的通用工具。
其他集思广益的想法:
尝试在两个不同数据库之间保持数据同步可能是一个问题。可能存在各种微妙的问题,包括竞争条件、缺乏分布式事务(影响一致性和对故障的响应)、为处理没有分布式事务而创建的解决方法的问题等等。您是否可以创建一个链接服务器和一些视图,实际上使一个数据库中的数据可以从另一个数据库中实时访问?
请告诉我们更多有关您的要求以及为什么需要这样做的信息。
更新
如果您要采用手动更新路线,请注意您无法批量应用某个时间段的插入、更新和删除操作。您必须按顺序一次应用它们。如果您使用的是当前状态而不是中间数据操作,那么您可以一次执行所有行。我将向您展示 MERGE 示例,而不是历史回放示例。
您可能会发现推送整个表并在目标服务器上执行合并操作会更好。
如果您想要获得一致的时间点快照,我在第一个查询中添加的锁定提示非常重要。如果您不关心这一点,请去掉锁定提示。
如果您发现链接服务器上的更新速度很慢,请将整个表整体推送到远程服务器上的临时临时表,并完全在远程服务器上的脚本中执行 MERGE。
Apparently, the answer is: "When you define the article, you'll have to set the
@vertical_partition
parameter to true and then add the columns that you want withsp_articlecolumn
."However, I have to ask why you're doing this. Replication in my mind isn't a general tool for moving data around between unlike databases but for keeping two identical databases in sync.
Other brainstorm ideas:
Trying to keep data synchronized between two different databases can be a problem. There can be all sorts of subtle problems with race conditions, lack of distributed transactions (affecting consistency and response to failures), problems with the workarounds created to deal with not having distributed transactions, and so on and so forth. Can you instead create a linked server and some views that actually make the data in one database real-time accessed from the other?
Please tell us more about your requirements and why you need to do this.
Update
If you're going the manual update route note that you can't apply a time period's insert, update, and delete operations en masse. You have to apply them one at a time, in order. If you are instead working with current state rather than intermediate data operations, then you can do all rows at once. I will show you the MERGE example, not the history-playback one.
You may find it better to push the whole table and do the merge operation on the destination server.
The lock hints I put in on the first query are important if you're going to have a consistent point-in-time snapshot. If you don't care about that, then take the locking hints out.
If you find that updates across the linked server are slow, then push the entire table in one piece to a temporary staging table on the remote server, and do the MERGE in a script entirely on the remote server.