重复行的数据库合并问题
我有DB1和DB2。我想将所有表数据从DB1导出到DB2。 DB2 中的某些表具有与 DB1 类似的行。由于 PK 约束，无论我在 SSIS 中使用什么方法，这都会引发错误。 如何即时忽略目标表中存在的行并继续与其他表一起复制。我需要立即运行整个数据库的过程。我有 100 个表，因此对每个表执行此操作是行不通的。我尝试在 SSIS (BI) 中使用传输 SQL Server 对象任务控件，但它没有给我处理我的情况的选项。
非常感谢任何帮助，而且并不紧急。
I have DB1 and DB2. I want to export all tables data from DB1 to DB2. Some of tables in DB2 have similar rows as DB1. This throws an error no matter what method I use in SSIS due to PK constraint.
How can I ignore rows that are present in destination tables on the fly and continue copying with others. I need to run the process for whole DB at once. I have 100's of tables so doing for each table will not work. I tried using Transfer SQL Server Objects Task control in SSIS (BI) but it does not give me option to deal with my case.
Any help is highly appreciated and it is little urgent.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以为此使用查找。
http://jahaines.blogspot.com /2009/09/ssis-only-inserting-rows-that-do-not.html
编辑：如果需要合并两个表中的数据，则使用合并组件合并两个数据源，然后在合并表后使用查找。如果合并的数据中有重复项，则可以在合并和查找之间使用排序组件，并勾选该框以删除重复项。但请注意，使用排序组件在资源使用方面是昂贵的。
实现此目的的另一种方法是将两个表中的所有数据放入接收 SQL 框上的单个临时表中。然后编写一个存储过程以仅将新行插入生产表中，最后截断临时表。我将从控制流中调用 SP 作为执行 SQL 任务。
就我个人而言，我会使用临时表方法，因为反复试验表明这对我来说更简单且最有效。不需要昂贵的排序和查找（查找并不昂贵），但 SP 中基于集合的工作是 SQL 引擎喜欢做的事情。
You can use a lookup for this.
http://jahaines.blogspot.com/2009/09/ssis-only-inserting-rows-that-do-not.html
Edit: if you need to merger data from two tables, then merge the two data sources using a merge component, then use a lookup after the merger table. If you have duplicates in the merged data, then you can use a sort component between the merge and the lookups and tick the box to remove duplicates. Beware though, that using a sort component is expensive in terms of resource usage.
Another way to accomplish this would be to put all the data from the two tables into a single staging table on the receiving SQL box. Then write a stored proc to insert only new rows into the production table, finally truncate the staging table. I'd call the SP from the control flow as an execute SQL task.
Personally, I'd use the staging table method as trial and error has show this to be simpler and most effective for me. No expensive sorts and lookups required (lookups aren't expensive), but the set based work in the SP is what the SQL engine loves to do.