Chinaunix首页 | 论坛 | 博客
  • 博客访问: 317436
  • 博文数量: 91
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 1019
  • 用 户 组: 普通用户
  • 注册时间: 2016-09-22 09:50
个人简介

一个守望数据库的老菜鸟

文章分类

全部博文(91)

文章存档

2019年(12)

2018年(17)

2017年(38)

2016年(24)

我的朋友

分类: Oracle

2019-04-10 15:29:01

博客文章除注明转载外,均为原创。转载请注明出处。


接上文(Oracle sysaux表空间使用过大处理-1http://blog.chinaunix.net/uid-31396856-id-5819732.html)介绍另一种处理方法:

基本情况如下:
sysaux空间使用很大,检查相关对象,和awr设置

发现dbid=3737847129不是当前数据库,并且sysaux使用对象如下:

top segment对象发现分区表,都是属于dbid:3737847129的awr资料库数据。以WRH$_EVENT_HISTOGRAM,发现其分区键是dbid、snap-id进行分区的,因此可以考虑通过分区表的相关操作来解决。
分区裁剪:
alter table WRH$_EVENT_HISTOGRAM drop partition WRH$_EVENT_HISTOGRAM __3737847129_0 update indexes;
然后检查索引是否失效,如果失效需要重建索引。
进行构建分区裁剪脚本:

脚本如下:


然后检查索引状态:
select index_name,table_name,status from  user_indexes where status != 'VALID';
select index_name,partition_name,status  from user_ind_partitions where status = 'UNUSABLE';
如果有分区索引失效,则重建。
完成数据清理。

--the end.
阅读(3366) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册