分区truncate操作的介绍

本文介绍了Oracle数据库中分区表的管理技巧,包括如何通过TRUNCATE操作快速回收空间,并维护全局索引的有效性。讨论了不同命令选项的影响及工业环境中遇到的实际案例。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

oracle技术资料  分区truncate操作的介绍 

        ① 马上回收空间:

  alter table table_name truncate partition partition_name drop storage;

  ② 同时维护全局索引:

  alter table table_name drop partition partition_name update global indexes;

  ㈡ 对全局索引的作用

  大分区表truncate partition后,需要对全局索引进行维护,否则,global index会变成unusable

  问题介绍:

  ① 在drop partition时,为了维护global索引,要加update indexes或是update global indexes条件

  请问,大家研究过这两个条件的区别吗?

  答: UPDATE GLOBAL INDEXES只维护全局索引

  UPDATE INDEXES同时维护全局和本地索引

  对于DROP/TRUNCATE PARTITION而言 ,二者没有太大的区别

  对于MERGE和SPLIT PARTITION,你就可以看到二者的区别了

  虽然index是变得valid了,但是index的空间没有释放

  因为该操作不等于REBUILD,只是在进行DDL的时候,同步维护索引信息而已

  工业环境的案例介绍:

  ② 我今天对分区表的一个分区做了TRUNCATE,这个分区有一个普通唯一索引和本地索引,

  TRUNCATRE的时候没有用UPDATE GLOBAL INDEXES 那个命令,结果导致报:

  ORA-01502: index BILL.IDX_CHARGE_D_591_0712_SID or partition of such index is in unusable state

  这是因为,truncate partition不加update global indexes,会导致全局索引失效(unusable)。

  然后,我只好:

  alter index bill.IDX_CHARGE_D_591_0712_SID parallel 10 nologging rebuild 来整个的重建,13亿记录的大表

  后来接着晚上有人继续插入这个表的时候,告诉我慢的要命,本来一个小时至少可以跑完400万条记录,现在3个小时了才跑130万

  我马上想到会不会是本地索引问题,因为我听说虽然分区交换或者TRUNCATE对局部索引没影响,

  但是实际上是有问题的,还是重建的好:

  alter index bill.UNQ_RRATING_CHARGE_D_591_0712 rebuild partition PART_20

  把这个刚才我TRUNCATE的分区的涉及到的局部索引重新建了一下

  结果立马见效果了,10分钟跑了200万条记录,600万条记录在20分钟全部跑好!比以前同期跑的还快一点

  半夜被叫起来干活了

  奇怪,如下写法怎么半天都执行不好

  alter table bill.recur_rating_charge_d_591_0712 truncate partition PART_21 update global indexes ;

  select count(*) from bill.recur_rating_charge_d_591_0712 partition(PART_21)

  数据始终不变

  但是我看v$session_longops看到这个SID很快就做好事了,

  而我看表分区记录始终在

  我晕,只好采用老办法,杀掉会话后,

  alter table bill.RECUR_RATING_CHARGE_d_591_0712 truncate partition PART_20不加update global indexes

  然后分别维护了普通索引和局部索引,这次加NOLOGGING和PARALLEL 8 ,也很快,3亿的大表,维护普通索引只花了200秒

  alter index bill.IDX_CHARGE_D_591_0712_SID rebuild parallel 8 nologging ;

  alter index bill.UNQ_RRATING_CHARGE_D_591_0712 rebuild partition PART_21 parallel 8 nologging;

  猜测原因:

  truncate partition PART_20后,这个分区的和这个分区上的本地索引的统计信息是不会更新也不会丢失

  当我往这个分区插入数据的时候,执行计划是根据错误的统计信息生成的,所以会很慢

  当我rebuild index partition PART_20 后,会导致这个索引的统计信息丢失,

  而我的执行计划就有可能改变了,所以我的插入变快了

  总结:

  当你truncate后应该立即对这个分区做分析cascade => true(增加对索引的统计信息),

  同时rebuild global index 并分析global index才对

  ㈢ 空间释放问题

  其实空间等都已经释放了,但数据字典没有被更新,

  例如你查dba_segments视图,发现这个分区的bytes其实还为原来的大小

  我们可执行alter table **** allocate extent即可更新数据字典为正常状态

  例如针对范围分区如下操作:

  alter table *** modify partition PART_*** allocate extent;

  

① 马上回收空间:

  alter table table_name truncate partition partition_name drop storage;

  ② 同时维护全局索引:

  alter table table_name drop partition partition_name update global indexes;

  ㈡ 对全局索引的作用

  大分区表truncate partition后,需要对全局索引进行维护,否则,global index会变成unusable

  问题介绍:

  ① 在drop partition时,为了维护global索引,要加update indexes或是update global indexes条件

  请问,大家研究过这两个条件的区别吗?

  答: UPDATE GLOBAL INDEXES只维护全局索引

  UPDATE INDEXES同时维护全局和本地索引

  对于DROP/TRUNCATE PARTITION而言 ,二者没有太大的区别

  对于MERGE和SPLIT PARTITION,你就可以看到二者的区别了

  虽然index是变得valid了,但是index的空间没有释放

  因为该操作不等于REBUILD,只是在进行DDL的时候,同步维护索引信息而已

  工业环境的案例介绍:

  ② 我今天对分区表的一个分区做了TRUNCATE,这个分区有一个普通唯一索引和本地索引,

  TRUNCATRE的时候没有用UPDATE GLOBAL INDEXES 那个命令,结果导致报:

  ORA-01502: index BILL.IDX_CHARGE_D_591_0712_SID or partition of such index is in unusable state

  这是因为,truncate partition不加update global indexes,会导致全局索引失效(unusable)。

  然后,我只好:

  alter index bill.IDX_CHARGE_D_591_0712_SID parallel 10 nologging rebuild 来整个的重建,13亿记录的大表

  后来接着晚上有人继续插入这个表的时候,告诉我慢的要命,本来一个小时至少可以跑完400万条记录,现在3个小时了才跑130万

  我马上想到会不会是本地索引问题,因为我听说虽然分区交换或者TRUNCATE对局部索引没影响,

  但是实际上是有问题的,还是重建的好:

  alter index bill.UNQ_RRATING_CHARGE_D_591_0712 rebuild partition PART_20

  把这个刚才我TRUNCATE的分区的涉及到的局部索引重新建了一下

  结果立马见效果了,10分钟跑了200万条记录,600万条记录在20分钟全部跑好!比以前同期跑的还快一点

  半夜被叫起来干活了

  奇怪,如下写法怎么半天都执行不好

  alter table bill.recur_rating_charge_d_591_0712 truncate partition PART_21 update global indexes ;

  select count(*) from bill.recur_rating_charge_d_591_0712 partition(PART_21)

  数据始终不变

  但是我看v$session_longops看到这个SID很快就做好事了,

  而我看表分区记录始终在

  我晕,只好采用老办法,杀掉会话后,

  alter table bill.RECUR_RATING_CHARGE_d_591_0712 truncate partition PART_20不加update global indexes

  然后分别维护了普通索引和局部索引,这次加NOLOGGING和PARALLEL 8 ,也很快,3亿的大表,维护普通索引只花了200秒

  alter index bill.IDX_CHARGE_D_591_0712_SID rebuild parallel 8 nologging ;

  alter index bill.UNQ_RRATING_CHARGE_D_591_0712 rebuild partition PART_21 parallel 8 nologging;

  猜测原因:

  truncate partition PART_20后,这个分区的和这个分区上的本地索引的统计信息是不会更新也不会丢失

  当我往这个分区插入数据的时候,执行计划是根据错误的统计信息生成的,所以会很慢

  当我rebuild index partition PART_20 后,会导致这个索引的统计信息丢失,

  而我的执行计划就有可能改变了,所以我的插入变快了

  总结:

  当你truncate后应该立即对这个分区做分析cascade => true(增加对索引的统计信息),

  同时rebuild global index 并分析global index才对

  ㈢ 空间释放问题

  其实空间等都已经释放了,但数据字典没有被更新,

  例如你查dba_segments视图,发现这个分区的bytes其实还为原来的大小

  我们可执行alter table **** allocate extent即可更新数据字典为正常状态

  例如针对范围分区如下操作:

  alter table *** modify partition PART_*** allocate extent;

From 阜和教育

为了设计一款能够有效聚合校园生活信息的APP,首先需要从用户的需求出发,详细分析目标用户群体的特点和需求,即XXXX生的日常生活和学习需求。在此基础上,定义APP的核心功能和服务范围,包括但不限于选课指南、考试资源、兼职信息、生活充值等服务。 参考资源链接:[校园生活APP:服务XXXX生的创新创业计划](https://wenku.youkuaiyun.com/doc/7ji9n8gsq2?spm=1055.2569.3001.10343) 接下来,进行市场调研,了解同类APP的现状、优缺点以及目标用户对此类APP的使用体验反馈。这一步骤将帮助我们确定产品的差异化特征,并据此制定出创新点和改进方向。 根据调研结果,设计APP的架构和用户界面。架构设计要考虑到数据的高效采集、存储、处理和展示,以及第三方平台的接口对接。用户界面设计则需要注重用户体验,确保操作简便、界面友好。 确定技术路线后,开始APP的开发工作。开发过程中,选择合适的开发工具和框架,如React Native或Flutter等跨平台开发框架,可以快速构建iOS和安卓双端应用。对于数据聚合,可以利用爬虫技术定时从校园网站、合作伙伴网站等来源抓取信息,并存储于服务器。开发中还应考虑到数据的安全性和隐私保护措施。 对于信息的更新及时性与准确性,可以设立后台管理系统,由专业团队负责日常的信息维护和更新,同时设置用户反馈机制,鼓励用户上报错误信息或提出建议。利用机器学习等技术优化信息分类和匹配准确性。 测试阶段,进行全面的系统测试、性能测试和用户测试,确保APP的稳定性和易用性。在APP上线后,进行持续的监控和迭代更新,根据用户反馈不断优化功能和提升服务质量。 总结来说,开发一款校园生活APP需要深入理解用户需求,合理规划产品功能,采用合适的开发技术和架构,并且注重后期的运营和维护。为了深入了解如何将这些步骤具体实现,建议参考《校园生活APP:服务XXXX生的创新创业计划》。这份文档不仅提供了产品规划的全面视角,还包括市场分析和运营策略,是解决当前问题的有力支持。 参考资源链接:[校园生活APP:服务XXXX生的创新创业计划](https://wenku.youkuaiyun.com/doc/7ji9n8gsq2?spm=1055.2569.3001.10343)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值