某客户一套11g RAC从AIX平台迁移到X86平台，全库数据量约为2.6T。此次测试迁移采用逻辑导入导出方法，在测试过程中没有出现任何报错，但目标端的数据量剧增，达到4.8T。老司机眉头一皱，觉得此事并不简单。逻辑迁移做了不下上百次，空间暴涨如此之大也还是头一回碰见，既然撞见了就必须要查明原因。

生产环境是AIX 7.1 11.2.0.3 RAC ASM，目标环境是Linux CentOS 6.8 11.2.0.4 RAC ASM。排查发现，生产库数据主要集中在一个用户，该用户在生产端数据量达2.2T，目标端达4.7T，于是我们把注意力放在了这个用户上，究竟是什么原因使得该用户迁移前后发生如此巨大的变化，让我们来一探究竟。

笔者主要从表空间定义，数据库参数和表结构定义三个方面去排查此次故障。

01

表空间定义

表空间定义是最容易让人怀疑的，目标端的表空间是在导入前人为创建的，那么会不会是生产端做了表空间级别的压缩，这里我选取了最大的表空间进行验证。

生产结果：

目标结果：

从表空间结构定义上不难看出，目标端与生产端并没有区别，这个猜测被否决。

02

数据库参数

数据库的大版本并未发生改变，从原来的11.2.0.3升级到11.2.0.4，参数并不会有太大变化，唯一涉及的就是导入初始化分配空间的参数延迟段创建：deferred_segment_creation。延迟段创建，顾名思义，就是表格创建的时候如果没有数据插入的情况下，就不会分配空间。所以这里只需要确认生产上该参数是否设置为false以及设置时间是否在对象创建之前即可。

生产端：

目标端：

从生产端告警日志发现：延迟段创建参数是2016年置为false的，而数据量巨大的用户2016年还未被创建，所以延迟段创建这个参数并不是此次空间暴涨的原因。

03

表结构定义

只剩下最后一个怀疑对象了，生产端随机选取了一张大表与目标端比对，表结构定义也没啥变化。

三种排查思路都被否决，问题分析一度陷入了僵局。接下来究竟该该何去何从。

作为一名资深DBA，怎么能轻易被困难折服~回到原点，从头开始。这时，对象类型的统计引起了我的注意。

以此为突破口，进一步统计业务用户的TABLE PARTITION类型对象的空间占用大小。

生产端：

目标端：

这里我发现SUMMARY_140_2_P3这张表导入导出前后变化量非常大，进一步排查：

再进一步排查：

此时问题已经很明显了，Oracle对于分区表空分区的分配大小上存在差异。在mos上搜索initial extent size in partition table

参考文档：Initial Extent Size of a Partition Changed to 8MB from 64KB After Upgrade to 11.2.0.2 or Later (Doc ID 1295484.1)

生产版本是11.2.0.3怎么会还是64KB呢，难道调整过版本参数，最后一步确认猜想：

此时问题已经柳暗花明，由于生产的版本参数还是11.2.0.0 创建对象分配extent size还是原来的64KB，而目标端为11.2.0.4初始化以为8M，当大量空分区创建时会导致空间暴涨。

对此，解决办法有两种：

方法一：修改隐含参数，将分区表和分区索引调回默认的64KB

alter system set "_partition_large_extents"=false scope=spfile sid='*'; 

alter system set "_index_partition_large_extents"=false scope=spfile sid='*'; 

方法二：还原延迟段创建

alter system set  DEFERRED_SEGMENT_CREATION=false sid='*';

至此，此次逻辑导入空间暴涨问题已基本解决。

数据库版本11.2.0.2之前的创建对象分配extent size是64KB，11.2.0.2之后的创建对象分配extent size是8M，这意味着，同样的数据量导入时，创建对象分配extent size是8M的导入时间会比创建对象分配extent size是64KB的快，但空间消耗也会更大。