xTTS Oracle数据从大端到小端迁移

嗨，汤姆，

我们有一个大量的SAP Oracle数据库。对象计数。DB大小较小，约为500gb。但是表计数是75000的，索引是围绕95000和其他对象周围的10000每个。

当我们使用rman convert从源到目标进行TTS迁移时 (我们使用xTTS并使用Oracle Perl脚本)。此perl脚本调用RMAN进行备份和转换并应用于目标。

我们以full = y & transcable = always来导出元数据。这将在2小时内完成。

但是，此元数据的导入将永远运行。对于这种情况，需要12个小时。数据库上没有异常等待。我每秒看到5到6个表被导入。其次是index，它是每秒导入的4-5个index对象。

这是一个expdp和一个impdp命令。作为限制，我们没有使用并行，因为transportable_datafile参数在导入中不支持并行。我们确实需要在导入元数据部分上使用并行。但是impdp同时具有transportable_datafiles (12c功能) 和元数据，并且没有并行性。

你对此有什么建议吗？

谢谢
普拉萨纳

它通常不是数据文件，而是与每个对象关联的元数据。对象最常见的大块元数据是优化器统计信息。一旦开始在每一列上添加直方图，那可能是很多元数据。

要查看时间丢失的地方，您可以检查v $ active_session_history，或者您可以在导入过程中进行系统范围的跟踪，即

1) alter system set events = '永远10046跟踪名称上下文，级别8';
2) 运行impdp
3) alter system set events = '10046跟踪名称上下文关闭';

datapump本身也有一个trace = level参数

 level   Purpose
 ------- -----------------------------------------------
 10300   To trace the Shadow process (API) (expdp/impdp)
 20300   To trace Fixed table
 40300   To trace Process services
 80300   To trace Master Control Process
 100300  To trace File Manager
 200300  To trace Queue services
 400300  To trace Worker process(es)
 800300  To trace Data Package
 1000300 To trace Metadata Package
 1FF0300 To trace all components          (full tracing)

将创建几个跟踪文件 (因为datapump使用worker slave)，但这应该使您对原因有所了解。

如果确实是优化器统计信息，那么您可能会将导入它们推迟到数据文件传输之后。然后你可以做一些 (手动) 并行化。