背景
数据库分区表数据越来越大, 需要对过期话的数据进行迁移, 以及大的分区表需要进行数据的清理和删除, 达到释放磁盘空间的目的.
问题说明
环境: 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 开头的进程, 查询相关资料, 百度到的盖国强老师的论坛: http://www.eygle.com/archives/2012/06/oracle_o001_o00n_cpu.html 以及 MOS 账号里面的资料, 说的大部分是 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, 感谢阿里的周卫丰周大牛帮我一起解决故障 (虽然是小问题).
来源: https://www.cnblogs.com/hmwh/p/9964644.html