加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 百科 > 正文

oracle故障处理之删除大表空间hang住

发布时间:2020-12-12 16:45:58 所属栏目:百科 来源:网络整理
导读:背景 问题说明 环境:linux 6.X 数据库:oracle 11.2.0.4 (PSU为2016年6月份的) 问题说明: S_T_RTNRP_STATUS_2017是分区表,每天一个分区,且一共使用了2.5TB的空间,现在需要进行空间清理,操作步骤是先对表进行truncate,然后删除表,后对相应的表空间的

背景

问题说明

环境:linux 6.X

数据库:oracle 11.2.0.4 (PSU为2016年6月份的)

问题说明:

S_T_RTNRP_STATUS_2017是分区表,每天一个分区,且一共使用了2.5TB的空间,现在需要进行空间清理,操作步骤是先对表进行truncate,然后删除表,后对相应的表空间的每个数据文件进行resize成1g,在进行删除表空间语句

drop tablespace SMART_NRRPSTA_2017 including contents and datafiles。

但是,从2018.11.14 20:00一直到15日10:00,表空间没有删除,且数据字典中都能够查询得到数据文件,hang住。

如下:

?

处理过程

1)????? 初步怀疑(以为是上次遗留问题)

初步怀疑是ASM进程问题,因为之前我删除过一个大的表空间,是在业务期,业务用户在查询大的报表,IO开销很严重,中途暂停,表空间没有清理干净,后面再进行删除,表空间删除了,但是ASM磁盘组中数据文件有的没有进行删除,初步怀疑是上次遗留问题,认为是上次没有释放的ASM进程阻塞表空间的删除。

查看阻塞的等待事件:

?

查看等待事件中,运行时间很长的是class slave wait这类等待事件,查看有关这类事件的进程号,以及信息:

ps -ef |grep 41751

ps -ef |grep 68563

ps -ef |grep 25232

ps -ef |grep 34478

ps -ef |grep 12445

ps -ef |grep 34699

ps -ef |grep 25217

ps -ef |grep 68559

ps -ef |grep 62666

ps -ef |grep 20972

ps -ef |grep 11554

ps -ef |grep 68590

看到的全是ora_o开头的进程,查询相关资料,百度到的盖国强老师的论坛:账号里面的资料,说的大部分是Oracle ora_o进程 100% CPU占用的案例,但是事实的ora_o进程并没有占用很高的CPU,也没有进程阻塞,官方也没有对其进程进行详细说明。

?

后面我还是把相关进程杀掉(由于生产环境,不敢全部杀死,也不敢直接执行kil -9 操作系统命令,先在数据库层杀一个看看,发现杀掉后,系统自动启动一个新的进程,后面才全部执行)

alter system kill session '504,53407';

alter system kill session '599,61619';

alter system kill session '498,38267';

alter system kill session '366,62377';

alter system kill session '401,27591';

alter system kill session '446,5345 ';

alter system kill session '230,11603';

alter system kill session '81,26169? ';

alter system kill session '468,16725';

alter system kill session '686,48001';

alter system kill session '384,40041';

等了一会儿,发现drop tablespace语句仍然是无进展,一样的hang住,在support上查询,怀疑是BUG也发现情况不符合。

2)????? 柳暗花明

开始怀疑不是上一次遗留的问题,怀疑是其他进程导致表空间删除hang住。

进行AWR,生成的时间是删除hang住那段时间:

DB time如下

?

发现DB time/(DB time+Elapsed)时间比例并不是特别高,

查看TOP 10等待事件

?

占用第一个的是TT等待事件,查看整个会话的等待事件:

select event,count(1) from gv$session group by event order by 2;

?

查看具体的TT - contention等待事件:

?

突然想起来了,自己搭建的一套OEM监控数据库,其中sysman用户登录,sys用户监控磁盘组,这两个会话阻塞导致drop tablespace hang住。

3)????? 处理措施

停止RAC两个节点的OEM agent

如下图:

?

停止后,查看alert日志:

?

成功删除了表空间并释放了磁盘组的空间。

4)????? 总结

1、? 遇到问题要根据实际情况解决。

2、? 感谢阿里的周卫丰周大牛帮我一起解决故障(虽然是小问题)。

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读