提交需求
*
*

*
*
*
立即提交
点击”立即提交”，表明我理解并同意 《美创科技隐私条款》
免费试用
400-811-3777

logo

    产品与服务
    解决方案
    技术支持
    合作发展
    关于美创
    申请试用
      热门阅读
      1

      2025中国互联网产业年会丨《中国互联网产业绿色算力发展倡议》正式发布

      2025-02-07

       2

      美创用户专访 | 精细化管理：医疗行业数据分类分级的策略与实践

      2025-01-10

       3

      容灾演练双月报｜美创助力某特大型通信基础设施央企顺利完成多个核心系统异地容灾演练

      2025-01-10

       4

      国家级｜美创、徐医附院共建项目入选工信部《2024年网络安全技术应用典型案例拟支持项目名单》

      2024-12-20

       5

      全球数据跨境流动合作倡议

      2024-11-22
      相关文章

      2025 IT 市场权威榜单发布｜美创 API 安全产品获新一代信息技术创新产品奖

      2025-04-29

      美创科技20周年庆典顺利举行

      2025-04-21

      美创20年｜那些年·那些事

      2025-04-17

      美创20年｜跨越与坚持

      2025-04-16

      20周年系列｜美创科技再度入围「年度高成长企业」系列榜单

      2025-04-09
      一次逻辑导入空间暴涨问题分析
      发布时间：2019-08-08 阅读次数： 457 次


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


      上一条：数据库的江湖情仇：事务篇
      下一条：CSS 2019丨美创科技两方案入选《FP50优秀网络安全解决方案白皮书》
      返回
      关注或联系美创
      官方订阅号 官方订阅号
      官方服务号 官方服务号
      第59号 第59号
      服务热线：400-811-3777
      商务合作：marketing@mchz.com.cn
      友情链接 中央网信办 公安部 工信部 CNCERT 中国信通院 中国软件测评中心 国家工业信息安全发展研究中心 赛迪研究院
      Copyright © 2024 杭州美创科技股份有限公司 All rights reserved.
      浙公网安备 33010502006954号 浙ICP备12021012号-1 网站地图 网站声明及隐私保护政策
      免费试用
      服务热线

      马上咨询

      400-811-3777

      回到顶部