生产故障:Oracle数据库意外宕机导致Undo损坏
浏览量: 次 发布日期:2023-09-17 11:49:34
生产故障:Oracle数据库意外宕机导致Undo损坏
IT数据库行业小学生,记录日常工作中数据库知识及一些故障案例,如有不对请指正,欢迎关注小编,小编微信xh870545795,CSDN:dba_notes
一、故障背景
客户一台运行在windows2008上的oracle 10.2.0.4 的单机数据库,由于近期在部署第三方监控系统,监控系统bug导致服务器cpu占用率达到100%,导致数据库服务异常停止,再次启动提示undo损坏,具体排查过程如下。
二、排查处理
1.故障现象
客户反馈数据库突然连不上,报错如下:
2.远程连接服务器排查
2.1 登录服务器发现oracle服务停止,服务器运行卡顿,查看资源利用情况如下
发现服务器cpu使用率达到100%,内存使用占比也相对较高,继续排查可疑进程:
发现java.exe这个进程不断终止和重启,占用cpu资源。经过和客户沟通杀掉了相关服务后,cpu使用恢复正常。
2.2重启数据库,启动报错如下
提示ORA-01092,实例终止,强制断开连接,查看alert日志,提示undo表空间有问题,进一步查看trc文件:
提示回滚段需要恢复,证实了是undo表空间的问题,数据库异常宕机,导致undo回滚段损坏。
2.3修复undo
修复undo最好的方法是完全恢复,不过如果没有备份,可以采用一种非常规的手段(利用Oracle的隐藏参数),如果此时undo包含未提交的事务,会造成一点点的数据丢失(一般都是可忍受的),如果没有未提交的事务,则不会有数据丢失。因为客户没有备份,所以采用非常规手段。
2.3.1 创建pfile,添加隐含参数,并启动数据库
修改initorcl.ora文件,加入
使用pfile启动数据库
查看一下当前的rollback segments
2.3.2 新建undo表空间替换有问题的undo
新建undo表空间
停库,修改pfile文件将undo表空间改为undotbs2
修改initorcl.ora文件
再次使用pfile启动数据库
删除损坏的undotbs1表空间:
停库并注释掉相关隐含参数:
修改initorcl.ora文件,注释或者删除参数:
通过pfile生成spfile启动数据库,处理完成