专栏首页杨建荣的学习笔记关于降低高水位线的尝试(r3笔记47天)

关于降低高水位线的尝试(r3笔记47天)

在前一段时间,生产环境中有几个很大的分区表,由于存在太多的碎片,导致表里的数据就几十条,但是查询的时候特别慢。很明显是高水位线导致的问题。 一般来说这类问题,使用备份->truncate->insert的方式比较保守,不适用于在线操作。 而在10g开始的一个新特性shrink算是一个比较理想的方案,按照新特性的预期,速度也是很快的,而且是在线操作。可以分批释放表中的冗余空间。 所以做了一个尝试,在生产系统中使用这个新特性来降低高水位线。 生产中的表pub_log,sub_log都是分区表,分区数不多,几十个左右。 首先使用shrink需要先设置表为enable rowmovement,这个操作会导致和这个表对应的包体失效。 可以使用shrink space compact先来压缩空间,然后在空闲时段使用shrink space来降低高水位线,但是shrink的操作对于基于函数的索引还是受限的。所以使用的时候需要考量一下。 需要降低高水位线的表是PUB_LOG,SUB_LOG,所在在简单准备之后,写了如下的脚本。

alter  session force parallel ddl parallel 8;  --设置了并行
alter table PUB_LOG enable row movement;   --启用row movement
alter table PUB_LOG shrink space compact;    --先压缩表的空间
alter table PUB_LOG shrink space;        --降低表的高水位线
alter index  PUB_LOG_PK shrink space compact;   --对索引也可以设置同样的操作。
alter index PUB_LOG_PK  shrink space; 
alter table PUB_LOG disable  row movement;  

alter table SUB_LOG enable row movement; 
alter  table SUB_LOG shrink space compact; 
alter table SUB_LOG shrink space  ; 
alter index SUB_LOG_PK shrink space compact; 
alter index SUB_LOG_PK  shrink space; 
alter index SUB_LOG_1IX shrink space compact; 
alter index  SUB_LOG_1IX shrink space ; 
alter table SUB_LOG disable row  movement; 

在测试环境中做测试的时候,时间还是很快的,在5分钟以内完成了所有的操作。 然后脚本提交给客户去运行,结果晚上就接到电话,说第一步操作 alter table PUB_LOG shrink space compact 执行了快3个小时,还没有执行完。客户最后kill了那个session. 在第二天查这个问题的时候发现,在shrink space compact的同时,有几个session正在执行update,delete操作,执行还是比较频繁的。 看来shrink的操作还是需要谨慎,在生产环境中可能涉及的操作场景更为复杂。最后评估之后还是转为truncate的方式了。 truncate的操作步骤比较老套,但是在操作的时候还是有不少的细节。 首先是备份 可以使用exp/expdp的方式,如果数据量不大,可以采用使用表级备份。 我先尝试了exp的方式,结果发现还是有一些问题,表里只有68条数据,但是exp的时候,用了1分钟左右。 Export terminated successfully without warnings. real 1m7.111s user 0m0.104s sys 0m0.065s 查看对应的索引情况,看来还是受到高水位线的影响。

INDEX_NAME             TABLESPACE  INDEX_TYPE  UNIQUENES  PAR  COLUMN_LIST                      TABLE_TYPE STATUS   NUM_ROWS LAST_ANAL  G
---------------------- ---------- ---------- --------- ---  ------------------------------ ---------- ------ ---------- ---------  -
PUB_LOG_PK               NORMAL      UNIQUE      YES  BUFFER_ID,PUB_TRX_ID,SOURCE_COMP_ID TABLE      N/A            15 23-OCT-14  N

select count(*)from pub_log 速度也是很慢的。 因为索引是buffer_id开头,最后间接的使用索引,速度一下子就快了很多。 select count(*)from trb1_pub_log where buffer_id in(select buffer_id from trb1_pub_log group by buffer_id); COUNT(*) ---------- 68 Elapsed: 00:00:00.17 最后转换为exp的方式,时间降低到5秒 time exp xxx/xxx tables=pub_log file=pub_log_bak.dmp query=\' where buffer_id in \(select buffer_id from pub_log group by buffer_id\)\' buffer=9102000 statistics=none grants=n indexes=n

real 0m5.064s user 0m0.039s sys 0m0.037s 到这一步其实也基本告一段落了,如果有些分区表含有lob字段,导出速度也还是会慢不少。 再次进行调整,发现使用表级备份还是不错的。 create table tmp_bak_pub_log nologging as select * from pub_log where buffer_id in (select buffer_id from pub_log group by buffer_id) ; Elapsed: 00:00:01.69 create table tmp_bak_sub_log nologging as select * from sub_log where queue_id in (select queue_id from sub_log group by queue_id) ; --sub_log含有lob字段,exp也还是慢不少,使用表级备份就快多了。 Elapsed: 00:00:00.58 备份完成之后,就是truncate truncate table pub_log reuse storage; truncate table sub_log reuse storage; 最后insert即可。 insert into pub_log select *from tmp_bak_pub_log; commit; insert into sub_log select *from tmp_bak_sub_log; commit; 总体来说,对于新特性的使用还是要做大量的测试,需要谨慎和保守,对于一些看似简单的操作也可以精工出细活。

本文分享自微信公众号 - 杨建荣的学习笔记(jianrong-notes),作者:r3笔记47天

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2014-11-06

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 最近在读的一些文章

    我犯下的代价惨痛的错误使我改变了看问题的角度,从“我知道我是对的”变成了“我怎么知道我是对的”。这些错误让我养成了谦逊的习惯,我需要用谦逊平衡我的勇敢。—《原则...

    jeanron100
  • 对IMP-00013问题的思考(r3笔记第71天)

    对于IMP的问题或者是各类ORA问题,如果碰到的时候使用oerr是一个很不错的参考方案。比如对于ora错误12041的解释如下。 > oerr ora 1204...

    jeanron100
  • 学习Oracle和MySQL推荐的几本书

    已经很多次收到后台网友的留言或者私信了,对于学习Oracle和MySQL,他们都有类似的疑问,我就索性放在一起来回答下。 简单来说,官方文档是最好的...

    jeanron100
  • 给你一份详细的 Spring Boot 知识清单

    在过去两三年的Spring生态圈,最让人兴奋的莫过于Spring Boot框架。或许从命名上就能看出这个框架的设计初衷:快速的启动Spring应用。因而Spri...

    程序员宝库
  • 给你一份详细的 Spring Boot 知识清单

    在过去两三年的Spring生态圈,最让人兴奋的莫过于Spring Boot框架。或许从命名上就能看出这个框架的设计初衷:快速的启动Spring应用。因而Spri...

    纯洁的微笑
  • 生产服务器宕机了,线上业务挂掉了!你的 Promtheus 怎么又不报警了呢?

    警报是监控系统中必不可少的一块, 当然了, 也是最难搞的一块. 我们乍一想, 警报似乎很简单一件事:

    iMike
  • 给你一份超详细 Spring Boot 知识清单

    在过去两三年的Spring生态圈,最让人兴奋的莫过于Spring Boot框架。或许从命名上就能看出这个框架的设计初衷:快速的启动Spring应用。因而Spri...

    Java技术栈
  • 【我爱设计模式】备忘录 - Ajax响应缓存

    备忘录模式,是我最喜欢使用的几个设计模式之一,实用性很强,我已经多次运用在项目中。

    神仙朱
  • Java 语言基础(常用设计原则和设计模式,常用 Java 8~11 新特性)

    RendaZhang
  • Python —— 一个『拉勾网』的小爬虫

    本文将展示一个 Python 爬虫,其目标网站是『拉勾网』;题图是其运行的结果,这个爬虫通过指定『关键字』抓取所有相关职位的『任职要求』,过滤条件有『城市』、...

    小小科

扫码关注云+社区

领取腾讯云代金券