如何将记录从一个 DB2 数据库移动到另一个 DB2 数据库？
How to move records from one DB2 database to another DB2 database?
我们希望定期清理（删除）生产数据库 (DB2) 中的记录，并将它们移动到存档数据库（也是具有相同模式的 DB2 数据库）。
为了完成这个故事，我们的数据库中有很多外键约束。
因此，如果 table B 中的记录 b 有一个外键来记录 table A 中的 a 并且我们要删除生产数据库中的记录 a 那么也必须在生产 B 中删除记录 b 并且两个记录都必须是在存档数据库中创建。
当然，没有数据丢失是非常重要的。这样我们就不可能删除生产数据库中的记录，而这些记录永远不会插入存档数据库中。
执行此操作的最佳方法是什么？
仅供参考，我已经检查过 https://www.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.admin.dm.doc/doc/r0024482.html，建议的解决方案有以下缺点。
- 加载实用程序、摄取实用程序 , Import utility : 仅解决在存档数据库中插入记录的部分。它没有涵盖完整的移动。
- Export utility : 仅涵盖导出数据的方法（可能由 Import 实用程序导入*.
- db2move, 恢复命令, db2relocatedb, ADMIN_COPY_SCHEMA, ADMIN_MOVE_TABLE and split mirror：如果您只想将满足特定条件的特定记录移动到存档数据库，则不是一个选项。
所以根据我的研究，目前最好的解决方案似乎是一种内部开发的脚本
- 正在以 IXF 格式导出要移动的记录
- 正在将那些导出的记录导入存档数据库
- 正在删除生产数据库中的那些记录
为了避免事务日志满错误，此脚本应分批执行此操作（例如 50000 条记录）
为了在第 3 步中没有外键约束错误：我们还必须确保在第 1 步中我们也将所有具有外键约束的记录导出到导出的记录以及所有具有外键约束的记录到这些记录 ...
有一些工具（例如 Optim Archive）可以更好地满足您没有意识到的需求。
在此期间 - 研究联邦和工具 asntdiff。
在存档数据库上，您可以定义到实时数据库的连接 (CREATE SERVER)。使用此定义，您可以为实时 tables (CREATE NICKNAME) 定义昵称。使用这些昵称，您可以将适当的数据加载到您的存档中 table。您可以使用自己喜欢的数据移动实用程序 - 加载、导入、插入等。
一旦加载，您可以通过使用适当的选择标准的Asntdiff工具来验证table s。 The -f option is great.
如果您对两个位置都存在数据感到满意，您可以删除实时数据库中的行。
对于您的外键关系 - 使用视图 SYSCAT.TABDEP 来查找此类依赖关系。您可以在存档数据库中将外键定义为 "not enforced"（或不定义它们）以避免在之前的过程中出错。
无论数据库如何，数据归档都是一个大而常见的话题。您可能还想查看 range partitioned tables 以获得更好的性能和控制。
询问 "best" 方法的问题用途有限，因为省略了评估标准。
有时技术人员和业务人员的评估标准不同。
有时客户公司的多项政策可以确定此类标准，因此了解当地政策和程序或模式至关重要。
通常 operational-requirements、security-requirements 和 licensing-requirements 会影响方法，除了 implementation-team 的技能水平和经验。
有时，公司会使用特定的标准化工具进行存档和删除，或者有时会受到 industry-sector 甚至 industry-specific 监管要求影响的特定模式。
由于 Whosebug 是一个面向编程的网站，像您这样的问题可以考虑 off-topic 因为您是在征求关于哪些 design-approach 可能的建议，同时省略了很多特定于您的 company/industry-sector 可能会影响解决方案模式。
影响该方法的一些典型要求或问题如下：
本地安全要求是否允许数据离开 Db2 环境？ （即存储在 Db2 表之外的磁盘上的数据）。有时这会限制导出或 load-from-file/pipe) 的使用。在 RDBMS 之外时，数据可能面临修改、检查或删除（无论是意外还是故意）的风险。
解决方案在出现运行时错误时的可重启性。这通常是一个关键要求。在不同的物理数据库（即使是相同的 RDBMS）之间复制数据时，有很多错误的可能性（网络错误、资源问题、并发问题、操作问题等）。解决方案是否必须保证在故障后从故障点恢复任何重新启动，或者必须进行清理并重新启动整个作业？答案决定设计。
如果两个数据库之间存在联合（或者如果可以在 Db2 许可条款中添加联合），那么这通常是推送或拉取内容的最简单实用的方法。本地表和远程表似乎在同一个逻辑数据库中，这简化了方法。数据永远不需要离开 RDBMS。这也简化了失败作业的可重启性。如果需要，它还允许数据保持加密状态。
如果 SQL-replication 或 Q-based-replication 已获得许可，则可以将其配置为智能同步源表和目标表，并在适当配置的情况下遵守 RI。这种方法需要大量的配置技巧。
如果生产数据库是 highly-available，如果归档数据库是 highly-available，and/or 那么解决方案必须遵循 HA 方法。有时这会阻止使用 LOAD，具体取决于 Db2 服务器的 operating-system 平台。
时间安排 windows 通常很重要。如果归档+删除作业必须保证在特定时间间隔内完全完成，这会影响设计模式。
如果最快推出是一项关键要求，那么 range-partitioning 通常是最佳选择。
我们希望定期清理（删除）生产数据库 (DB2) 中的记录，并将它们移动到存档数据库（也是具有相同模式的 DB2 数据库）。
为了完成这个故事，我们的数据库中有很多外键约束。 因此，如果 table B 中的记录 b 有一个外键来记录 table A 中的 a 并且我们要删除生产数据库中的记录 a 那么也必须在生产 B 中删除记录 b 并且两个记录都必须是在存档数据库中创建。
当然，没有数据丢失是非常重要的。这样我们就不可能删除生产数据库中的记录，而这些记录永远不会插入存档数据库中。
执行此操作的最佳方法是什么？
仅供参考，我已经检查过 https://www.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.admin.dm.doc/doc/r0024482.html，建议的解决方案有以下缺点。
- 加载实用程序、摄取实用程序 , Import utility : 仅解决在存档数据库中插入记录的部分。它没有涵盖完整的移动。
- Export utility : 仅涵盖导出数据的方法（可能由 Import 实用程序导入*.
- db2move, 恢复命令, db2relocatedb, ADMIN_COPY_SCHEMA, ADMIN_MOVE_TABLE and split mirror：如果您只想将满足特定条件的特定记录移动到存档数据库，则不是一个选项。
所以根据我的研究，目前最好的解决方案似乎是一种内部开发的脚本
- 正在以 IXF 格式导出要移动的记录
- 正在将那些导出的记录导入存档数据库
- 正在删除生产数据库中的那些记录
为了避免事务日志满错误，此脚本应分批执行此操作（例如 50000 条记录）
为了在第 3 步中没有外键约束错误：我们还必须确保在第 1 步中我们也将所有具有外键约束的记录导出到导出的记录以及所有具有外键约束的记录到这些记录 ...
有一些工具（例如 Optim Archive）可以更好地满足您没有意识到的需求。
在此期间 - 研究联邦和工具 asntdiff。
在存档数据库上，您可以定义到实时数据库的连接 (CREATE SERVER)。使用此定义，您可以为实时 tables (CREATE NICKNAME) 定义昵称。使用这些昵称，您可以将适当的数据加载到您的存档中 table。您可以使用自己喜欢的数据移动实用程序 - 加载、导入、插入等。
一旦加载，您可以通过使用适当的选择标准的Asntdiff工具来验证table s。 The -f option is great.
如果您对两个位置都存在数据感到满意，您可以删除实时数据库中的行。
对于您的外键关系 - 使用视图 SYSCAT.TABDEP 来查找此类依赖关系。您可以在存档数据库中将外键定义为 "not enforced"（或不定义它们）以避免在之前的过程中出错。
无论数据库如何，数据归档都是一个大而常见的话题。您可能还想查看 range partitioned tables 以获得更好的性能和控制。
询问 "best" 方法的问题用途有限，因为省略了评估标准。 有时技术人员和业务人员的评估标准不同。
有时客户公司的多项政策可以确定此类标准，因此了解当地政策和程序或模式至关重要。
通常 operational-requirements、security-requirements 和 licensing-requirements 会影响方法，除了 implementation-team 的技能水平和经验。
有时，公司会使用特定的标准化工具进行存档和删除，或者有时会受到 industry-sector 甚至 industry-specific 监管要求影响的特定模式。
由于 Whosebug 是一个面向编程的网站，像您这样的问题可以考虑 off-topic 因为您是在征求关于哪些 design-approach 可能的建议，同时省略了很多特定于您的 company/industry-sector 可能会影响解决方案模式。
影响该方法的一些典型要求或问题如下：
本地安全要求是否允许数据离开 Db2 环境？ （即存储在 Db2 表之外的磁盘上的数据）。有时这会限制导出或 load-from-file/pipe) 的使用。在 RDBMS 之外时，数据可能面临修改、检查或删除（无论是意外还是故意）的风险。
解决方案在出现运行时错误时的可重启性。这通常是一个关键要求。在不同的物理数据库（即使是相同的 RDBMS）之间复制数据时，有很多错误的可能性（网络错误、资源问题、并发问题、操作问题等）。解决方案是否必须保证在故障后从故障点恢复任何重新启动，或者必须进行清理并重新启动整个作业？答案决定设计。
如果两个数据库之间存在联合（或者如果可以在 Db2 许可条款中添加联合），那么这通常是推送或拉取内容的最简单实用的方法。本地表和远程表似乎在同一个逻辑数据库中，这简化了方法。数据永远不需要离开 RDBMS。这也简化了失败作业的可重启性。如果需要，它还允许数据保持加密状态。
如果 SQL-replication 或 Q-based-replication 已获得许可，则可以将其配置为智能同步源表和目标表，并在适当配置的情况下遵守 RI。这种方法需要大量的配置技巧。
如果生产数据库是 highly-available，如果归档数据库是 highly-available，and/or 那么解决方案必须遵循 HA 方法。有时这会阻止使用 LOAD，具体取决于 Db2 服务器的 operating-system 平台。
时间安排 windows 通常很重要。如果归档+删除作业必须保证在特定时间间隔内完全完成，这会影响设计模式。
如果最快推出是一项关键要求，那么 range-partitioning 通常是最佳选择。