问题描述
这个问题更多的是征求意见，而不是实际问题。
我的任务是将大型仓库数据库从一个数据中心中的一组硬件迁移到另一个数据中心中的一组新硬件。不包括temp，undo，system，sysaux和仅索引的表空间，实例的大小约为6.5tb。
一些相关主题/约束/参数:
-数据中心之间的网络连接受到限制，这排除了几种方法。我们不能使用datapump的network_link功能在接收端使用impdp发起迁移。只是太慢了。网络带宽的不足也排除了使用金门的奢侈。
-网络带宽的缺乏使我们走上了使用可移动存储设备并将数据从一个数据中心物理传输到另一个数据中心的道路。我们选择的设备具有处理整个数据库实例的能力。源系统没有足够的SAN存储容量来在本地创建导出文件-可移动存储也使我们摆脱了这个问题。
-两个数据中心中的主机硬件 (特别是芯片组和endanness) 不同。源数据中心中的主机是bigendian，而新数据中心中的主机是littleendian。这表明我们将datapump作为一个整体解决方案，因为datapump将处理端序转换。
-数据库中的一个架构约占要迁移的数据的50%，并且该架构中的一个分区表的大小超过1tb。
-- 源系统中的表空间不是可传输的表空间。另外，在源系统中，磁盘作为原始分区呈现给数据库，而不是在文件系统中，因此复制文件无论如何都不是一种选择。
-源实例中有33个表空间，其中包含要迁移的数据 (省略了仅索引的表空间，因为对于索引，仅导出了元数据)。
因此，这为您提供了我们面临的迁移工作的高级概述。根据上面提供的信息，我非常感谢您对如何最好地使用datapump导出和导入来执行迁移的想法和意见。
因此，我想我的问题与您对datapump处理非常大的导出文件的信心有关。我最初的想法是，执行单个完整的数据库导出，而不是将迁移分解成碎片 (也许是通过表空间) 可能是一个很大的问题。但是，这样做将消除许多障碍和复杂性 (例如如何处理表空间间的依赖关系，必须在导入数据表空间之前导入用户帐户 (然后必须处理所有其他因素，例如特权，角色，物化视图，触发器，序列等)。
执行完整数据库导出的想法让我有点紧张，因为这相当于把所有的鸡蛋都放在一个篮子里。如果在出口过程中 (甚至在进口过程中) 出了问题，那么重新开始将浪费大量宝贵的时间。
因此，首先，您是否认为给定足够的空间，datapump可以在单个完整数据库导出中导出整个数据库？
其次，如果您对使用单个完整数据库导出有疑虑，您将如何将迁移分解成碎片？我在这里看到两个选项: 1) 逐个模式 (或多个模式组)，以及2) 逐个表空间。
回想一下，尽管数据库实例中的单个架构约占数据的一半，因此其导出文件本身将非常大。还要注意，几个表空间的大小超过1T (实际上，1t表空间之一仅包含单个表的分区)。
任何建议和/或想法将不胜感激。
谢谢。
我的任务是将大型仓库数据库从一个数据中心中的一组硬件迁移到另一个数据中心中的一组新硬件。不包括temp，undo，system，sysaux和仅索引的表空间，实例的大小约为6.5tb。
一些相关主题/约束/参数:
-数据中心之间的网络连接受到限制，这排除了几种方法。我们不能使用datapump的network_link功能在接收端使用impdp发起迁移。只是太慢了。网络带宽的不足也排除了使用金门的奢侈。
-网络带宽的缺乏使我们走上了使用可移动存储设备并将数据从一个数据中心物理传输到另一个数据中心的道路。我们选择的设备具有处理整个数据库实例的能力。源系统没有足够的SAN存储容量来在本地创建导出文件-可移动存储也使我们摆脱了这个问题。
-两个数据中心中的主机硬件 (特别是芯片组和endanness) 不同。源数据中心中的主机是bigendian，而新数据中心中的主机是littleendian。这表明我们将datapump作为一个整体解决方案，因为datapump将处理端序转换。
-数据库中的一个架构约占要迁移的数据的50%，并且该架构中的一个分区表的大小超过1tb。
-- 源系统中的表空间不是可传输的表空间。另外，在源系统中，磁盘作为原始分区呈现给数据库，而不是在文件系统中，因此复制文件无论如何都不是一种选择。
-源实例中有33个表空间，其中包含要迁移的数据 (省略了仅索引的表空间，因为对于索引，仅导出了元数据)。
因此，这为您提供了我们面临的迁移工作的高级概述。根据上面提供的信息，我非常感谢您对如何最好地使用datapump导出和导入来执行迁移的想法和意见。
因此，我想我的问题与您对datapump处理非常大的导出文件的信心有关。我最初的想法是，执行单个完整的数据库导出，而不是将迁移分解成碎片 (也许是通过表空间) 可能是一个很大的问题。但是，这样做将消除许多障碍和复杂性 (例如如何处理表空间间的依赖关系，必须在导入数据表空间之前导入用户帐户 (然后必须处理所有其他因素，例如特权，角色，物化视图，触发器，序列等)。
执行完整数据库导出的想法让我有点紧张，因为这相当于把所有的鸡蛋都放在一个篮子里。如果在出口过程中 (甚至在进口过程中) 出了问题，那么重新开始将浪费大量宝贵的时间。
因此，首先，您是否认为给定足够的空间，datapump可以在单个完整数据库导出中导出整个数据库？
其次，如果您对使用单个完整数据库导出有疑虑，您将如何将迁移分解成碎片？我在这里看到两个选项: 1) 逐个模式 (或多个模式组)，以及2) 逐个表空间。
回想一下，尽管数据库实例中的单个架构约占数据的一半，因此其导出文件本身将非常大。还要注意，几个表空间的大小超过1T (实际上，1t表空间之一仅包含单个表的分区)。
任何建议和/或想法将不胜感激。
谢谢。
专家解答
看起来您已经调查了迁移数据的选项。
如果可能的话，我会选择将迁移分成几部分。
一次迁移可能需要应用程序长时间的停机时间。零敲碎打可能意味着更多的中断。但是每个都应该更小，更多。
如果您发现出于任何原因需要恢复到当前服务器，这也会使事情变得不那么痛苦。如果在新系统上使用一两天后，您想将所有6.5 TB移回...会痛的!
假设没有跨模式依赖关系，逐个模式是一个很好的方法。
从最小/最小影响模式开始，您可以快速验证所有内容在新系统上的正常运行。
您还提到您已经对表格进行了分区。假设:
他们被日期分割了
和
旧分区是只读的 (实际上，如果没有完全强制执行)
还有另一种方法可以解决:
分别复制所有旧的，不变的分区。一旦将所有这些都加载到新系统中，希望您只剩下少量复制。因此，当您进行实时切换时，需要传输的数据集要小得多。
这使您可以在当前系统仍然有效的情况下完成大部分数据传输。如果出现任何问题，请给您足够的时间来重新运行导入。并且您需要一个较小的中断窗口来完成迁移。
祝你好运!
====
附录:
也可以查看跨平台tablepspace迁移。这听起来是你需求的完美匹配
MOS注意: 2471245.1-V4使用跨平台增量备份减少可传输表空间停机时间
如果可能的话，我会选择将迁移分成几部分。
一次迁移可能需要应用程序长时间的停机时间。零敲碎打可能意味着更多的中断。但是每个都应该更小，更多。
如果您发现出于任何原因需要恢复到当前服务器，这也会使事情变得不那么痛苦。如果在新系统上使用一两天后，您想将所有6.5 TB移回...会痛的!
假设没有跨模式依赖关系，逐个模式是一个很好的方法。
从最小/最小影响模式开始，您可以快速验证所有内容在新系统上的正常运行。
您还提到您已经对表格进行了分区。假设:
他们被日期分割了
和
旧分区是只读的 (实际上，如果没有完全强制执行)
还有另一种方法可以解决:
分别复制所有旧的，不变的分区。一旦将所有这些都加载到新系统中，希望您只剩下少量复制。因此，当您进行实时切换时，需要传输的数据集要小得多。
这使您可以在当前系统仍然有效的情况下完成大部分数据传输。如果出现任何问题，请给您足够的时间来重新运行导入。并且您需要一个较小的中断窗口来完成迁移。
祝你好运!
====
附录:
也可以查看跨平台tablepspace迁移。这听起来是你需求的完美匹配
MOS注意: 2471245.1-V4使用跨平台增量备份减少可传输表空间停机时间
文章转载自ASKTOM，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
