风险预警·11g容易被忽略的导入性能问题

前言

        某大型国有银行一套关键系统 10g 升级到 11g ，老 K 负责升级后第一天早上的运行保障；在升级前甲方客户已经先后做了各种测试，以保证升级后不会存在任何性能问题。然而，事与愿违，老 K 刚到现场，客户应用团队就已经反馈到客户说批量慢了一段时间，根据应用日志与现场负责协助升级的友商 DBA 的核查，初步定位问题为升级后使用的存储变慢导致的导出缓慢，拖慢了批量的执行时间。对于这一结论，客户在调动存储相关工程师进行核查的同时，还存在疑惑，于是老 K 便开始参与这一问题的追查；现在问题就可以描述为： oracle从10g升级到11g后，导入操作变慢。

0 1 开始思考

   因为是升级前后导入的效率变化，于是老K首先将生产系统分别在10g和11g的环境下导入的日志来进行对比，主要核对导入的时间点后再进一步查看相关时间点数据库的状态。然而，在看过两个日志后，老K就有了自己的疑惑，于是，我就启动自己的虚拟机，开始自己的验证探索之旅。

上面两图是我在自己的虚拟机上直接测试导入得到的导入日志文件，细心的你在看完下图之后，是否也发现了一些疑惑呢？老K提示：

老K提示：

1.导入时启用了并行（并行为6，大于表的个数）

2.导入时使用了content=data_only（说明数据库中原来已经有了表的定义）

3.导入的表中存在分区表（A1，A2，A3共计24个分区）和非分区表（A6