技术人生系列·我和数据中心的故事（第十三期）-风险预警11g容易被忽略的导入性能问题

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

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

老K提示：

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

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

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

如图所示，表 A6 比较大，有超过 500 万条记录（而且这里老 K 还在 A6 表上建了索引，在导入时还需要维护 A6 表的索引，其他表则没有索引），而其他所有的表占用空间加起来也不过 300M 大小而已。 在 10g 的日志中， A6 表的日志记录写在了最后一行，而在 11g 的日志中则出现在了第四行 。  

正常来说，使用数据泵导入 / 导出多个表时，会在导入 / 导出完成时在日志中打出相应表的信息，如果这里 A6 表作为一个大表，却相较于其他表先完成导入操作，我们就可以怀疑分区表和非分区表同时导入时， 11g 数据泵的机制是存在问题的，特别是在对比了 10g 的导入情况后。

上面梳理出疑惑，我们应该怎么去验证呢？如果我们是正在执行导入 / 导出的操作，我们可以 attach 到导入 / 导出任务中进行实时观察；而如果是导入 / 导出已经完成了，那我们就需要从数据库的历史性能视图中去寻找答案了（这里我们主要针对 11g 数据库进行验证） 。

首先，我们先来通过 v$active_session_history 视图来查看导入的整体情况：

这里使用 v$active_session_history 视图来核查，每秒做一次采样发现，导入期间，数据库确实启动了 6 个并行进程（ worker ），其中 DW00 进程采样次数最多，但是各进程的最早采样到的时间和最后采样到的时间相差无几，都是从 12:36 左右到 12:51; 显然， 这个过程中有部分 worker 进程是空闲的 ；

那么，是不是分区表导入存在问题呢？

我们先来分析分区表（以 A1 为例）的导入过程：

通过上面结果，我们能看到一个特征，就 A1 表而言，其各个分区的导入散落在不同的 DW 进程上，但是从采样的最大最小时间上看，没有重合时间区域，也就是说，在目前 DATAPUMP 启动了 6 个并行来导入 4 个表的时候，看起来分区表 A1 表并没有做到多个分区并行导入，同样我们核查 A2 、 A3 表的导入情况：

得出结论如下：导入时，虽然并行度是 6 ，只导入 4 个表（含分区表）的情况下， 所有的表的多个分区间没有并行地导入 ，至少有个两个 DW 进程是空闲的（实时 attach 到导入进程监控时更是一目了然）。

此类情况是不是与我们以往的经验相违背呢？

知识点：

1.数据泵导入时，并行主要是通过多个进程分别导入不同的表来提高导入速度的，而不同的分区作为不同的 segment 一般也被当做不同的表来处理；

2.数据泵导入时，默认使用的是 insert append 的方式，也就是说在导入时会持有对象的表锁；

本次的导入好像就是与第一条有所不符，导入时在存在空闲进程的情况下，同一个表的不同分区并没有做到并行，那是为什么呢？我们需要注意到我们在前面提到的几个导入特征，其中一个就是，我们使用了content=data_only ;   使用这个参数就意味着，当前数据库中已经有了该分区表的定义，只是将数据导入到已存在的表中去，在数据库中已经存在分区表的定义而需要向其中导入数据时，则可能会遇到的一种情况是，数据库中分区表的定义与 DUMP 文件中分区表的定义不一致（比如分区键不一致），导致 DUMP 文件中的分区无法与数据库中的已有分区一一对应，而无法做到一一对应就意味着，如果启动多个 WORKER 同时导入一个表的不同分区，不同 WORKER 就有可能会同时向一个目标分区中执行 insert append 操作，前面提到， insert append 操作会持有行锁，这样最后会出现导入 worker 间的互相阻塞的情况，而且有可能形成死锁，所以 oracle 较新的版本中，在导入已存在分区表时（使用了参数 content=data_only等 ），同一表的多个分区是顺序导入的（虽然有可能是通过不同的 worker 来执行） 。

那么 10g 数据库的导入是不是也是这样呢？我们用同样方法来测试观察，可以发现 10g 数据库的导入也是如此，那么客户在 10g 、 11g 环境中导入的数据、表的定义、导入命令，都没有变化，看起来并行 +metadata_only 并不是问题所在，那么真正的问题在哪里呢？我再次回到最开始的问题：

在 10g 的日志中， A6 表的日志记录写在了最后一行，而在 11g 的日志中则出现在了第四行，也就是说，在 10g 中， A6 表是最后完成的，而在 11g 中 A6 表却在 A1 、 A2 、 A3 表的大部分分区完成前已经完成了，是 A1 、 A2 、 A3 表的导入进程在等待什么吗？

还是要回到 v$active_session_history 视图上来 :

可以看到， A6 导入时间大约从 12:36 持续到 12:49 ，包含索引维护

而在此期间其他活动的会话中，各分区表只导入了一个分区（即各表导入的第一个分区），而且各 WORKER 在导入完第一个分区后（ 12:37:32~12:42:17 ）并没有异常等待，而是处于空闲状态。

我们再回顾一下各个表的导入情况：

可以看到，各个表在导完第一个分区后，出现长时间的停顿，一直等到非分区表导入完，才继续后续的分区导入；

结合各 worker 的状态及各表导入的时间状态以及前面的结论我们可以确认一点：

在分区表和非分区表同时导入，而且是数据库中表定义已经存在（使用 content=metadata_only等参数 ）时，分区表需要逐个导入无法使用并行，而在所有分区表分别导完第一个分区后，需要等待所有的非分区表导入完成，才能继续后面的分区表的分区导入，进而影响导入进度。

而以上问题在 10g 数据泵中不存在，宇宙行客户所遇到的问题正是这个问题，升级后多花费的时间也基本上就是单个非分区表导入的时间。以上问题已经提交的 ORACLE 官方并确认为11g导入的调度机制问题，目前正在开发解决中。

我们可以做什么：

当我们需要追求导入的效率时：

1.导入分区表时尽量避免使用 content=data_only 或 table_exists_action=appen/truncate 的方式，如果已有表的数据量不大，而且 dump 中表的结构也与已存表的结构一致，我们不妨先存留已有表的数据，再使用 table_exists_action=replace 的方式；

2.如果导入分区表无法避免使用 content=data_only 或 table_exists_action=appen/truncate ，那么我们建议分区表和非分区表分开导入 。