背景：
周六某应用在搭建报表库，通过数据泵从上游导出dmp文件，然后在报表库，使用数据泵进行初始化导入，后续将采用ogg进行增量同步。上游数据库大概有3~4T。该应用当天凌晨开始导数，大概在早上9点半左右出现告警，报错信息为ora-257，从报错信息不难看出，归档目录空间存在瓶颈，查看归档目录使用情况，发现1.5TB的FRA磁盘组，只剩余1GB空闲空间，所有的空间都被当天归档日志所占用。应急的方法要么扩存储空间，要么清理归档。在了解清楚应用的情况后，选择清理归档方式。
其实生产上也有配置归档清理策略（每小时调用1次清理脚本，清除expired归档文件，保留最近2天归档），但对于短时间内，大量导数或跑批，产生大量日志，会存在清理不及时现象，最终导致归档空间爆满，数据库挂起。而采用手工清理或调小归档清理保留周期，对于重点应用或旧应用，存在一定风险。如果手工清理掉的归档（在最近一次全备之后），且没有备份这部分归档，这时数据库出现故障需要恢复，将无法做到完全恢复，这一点应用需要与DBA沟通好方案。
言归正传，对于一些新建应用或是新建容灾库，在使用数据泵初始化大量数据时，到底有没一些避坑的方法？答案是肯定有的。
Oracle 12c之后，对数据泵加了不少功能，今天要介绍的就是transform选项，该选项有很多值，其中跟归档有关的是disable_archive_logging，而且可以细粒度到表或索引，有一点需要注意的是，如果您的数据库是开启了force logging，那么这个参数将失效。以下是官方手册的参数说明。
通过以下两个示例，带大家感受一下这个参数对导入的耗时及归档空间的影响。实验环境是虚机4C8G，RedHat 7.6 x86，上面运行了Oracle 19.6、MySQL、达梦三种类型数据库
，测试表的记录数约5千万，带2个索引，容量大概在11GB左右。
先备份一下数据库，没开启压缩，大概6.9GB（大概用时1分半钟）
查看数据库是否强制记日志以及是否归档模式
查看数据库归档路径
查看闪回区的空间使用情况，目前全为0
# 导入测试一（开启disable_archive_logging参数）
1）删除原表
2）查看par参数文件（注意红框内容）
3）执行导入操作，耗时3分37秒
4）查看闪回区使用情况，发现全为0
# 导入测试二（去掉disable_archive_logging参数）
1）删除原表
2）查看par参数文件
3）执行导入操作，耗时10分51秒
4）查看闪回区使用情况，可以发现有19个归档文件，占闪回空间的87.69%
通过上面案例对比，导数效率及归档空间使用上，有很大的差异。相信大家能get到在什么样的场景下，使用那种方法会更加合适我们。另外，参数的使用也需要注意它的使用范围，对现有的数据库架构、备份恢复、性能等有何影响，这些都是我们需要理清楚的，切忌道听途说，没经过任何验证，就抱着试试看的心态就直接在生产上操作。希望共勉。
