新闻中心 >> 新闻中心详情

一次逻辑导入空间暴涨问题分析

发布时间:2019-08-08作者:阅读次数: 分享到:


某客户一套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的快,但空间消耗也会更大。


服务热线:400-711-8011
Copyright ©2005-2018 杭州美创科技有限公司. All Rights Reserved. 浙ICP备12021012号-1