我们经常要从生产数据库（DB2）中清理（删除）记录，并将它们移动到存档数据库（也是具有相同模式的DB2数据库）。
要完成这个故事，我们的数据库中有很多外键约束。 因此，如果表B中的记录b具有在表A中记录a的外键，并且我们正在删除生产DB中的记录a，则必须在生产B中删除记录b，并且必须在归档DB中创建两个记录。
当然，没有数据丢失是非常重要的。因此，我们不可能删除生产数据库中的记录，而这些记录永远不会插入存档数据库中。
这样做的最佳方法是什么？
仅供参考我检查了https://www.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.admin.dm.doc/doc/r0024482.html，提议的解决方案有以下缺点。
基于我的研究，目前最好的解决方案似乎是一种内部开发的脚本
为了不导致任何事务日志完整错误，此脚本应批量执行此操作（例如，50000条记录）
为了在步骤3中没有外键约束错误：我们还必须确保在步骤1中我们还将具有外键约束的所有记录导出到导出的记录以及对这些记录具有外键约束的所有记录。 ..
答案 0 :(得分：1)
提出“最佳”方法的问题使用有限，因为省略了评估标准。 有时，技术人员和商务人士的评估标准不同。
有时客户公司的多项政策可以确定这些标准，因此对当地政策和程序或模式的认识至关重要。
除了实施团队的技能水平和经验之外，操作要求和安全要求以及许可要求通常会影响该方法。
有时，企业会有特定的标准化存档和删除工具，或者有时会受到行业部门或行业特定监管要求影响的特定模式。
由于stackoverflow是一个面向编程的网站，像你这样的问题可以被认为是偏离主题的，因为你在寻找可能的设计方法的建议，同时省略了许多特定于你的公司/行业的上下文很好地影响解决方案模式。
影响该方法的一些典型要求或问题如下：
本地安全要求是否允许数据离开Db2环境？ （即存储在Db2表外的磁盘上的数据）。有时，这会限制使用export或load-from-file / pipe）。在RDBMS之外，数据可能存在修改或检查或删除（无论是偶然的还是故意的）的风险。
在运行时错误的情况下解决方案的可重启性。这通常是一项至关重要的要求。在不同物理数据库之间复制数据时（即使是相同的RDBMS），存在许多错误可能性（网络错误，资源问题，并发问题，操作问题等）。解决方案是否必须保证故障后从故障点恢复任何重启，或者必须进行清理并重新启动整个作业？答案可以决定设计。
如果两个数据库之间存在联合（或者如果它可以在Db2许可条款中添加），那么这通常是推送或提取内容最简单的实用方法。本地和远程表似乎位于同一逻辑数据库中，这简化了方法。数据永远不需要离开RDBMS。这也简化了失败作业的可重启性。如果需要，它还允许数据保持加密状态。
如果SQL复制或基于Q的复制获得许可，则可以将其配置为智能地同步源表和目标表，并在适当配置时尊重RI。这种方法需要很高的配置技能。
如果生产数据库具有高可用性，并且/或者如果存档数据库具有高可用性，那么解决方案必须遵守HA方法。有时这会阻止使用LOAD，具体取决于Db2服务器的操作系统平台。
用于调度的计时窗口通常至关重要。如果档案+删除工作必须保证完全按照特定的时间间隔完成，这可能会影响设计模式。
如果最快推出是关键要求，则范围分区通常是最佳选择。
答案 1 :(得分：0)
有这样的工具（例如Optim Archive）可以更好地满足你没有意识到的要求。
在过渡期间 - 查看联盟和工具asntdiff。
在存档数据库中，您可以定义与实时数据库（CREATE SERVER）的连接。使用此定义，您可以为实时表（CREATE NICKNAME）定义昵称。使用这些昵称，您可以将适当的数据加载到存档表中。您可以使用自己喜欢的数据移动实用程序 - 加载，导入，插入等。
加载后，您可以使用具有适当选择条件的asntdiff工具验证表格。 The -f option is great
如果您对两个位置都存在数据感到满意，则可以删除实时数据库中的行。
对于外键关系 - 使用视图SYSCAT.TABDEP查找此类依赖项。您可以在归档数据库中将外键定义为“未强制执行”（或不定义它们），以避免在上一过程中出现错误。
无论数据库如何，数据归档都是一个很大的常见主题。您可能还需要查看range partitioned tables以获得更好的性能和控制权。