国庆节假日的最后一天,客户反馈数据库运行较慢,pl/sql连接数据库登陆直接卡死,请求排查原因。因为是内网环境,不太方便查看,同事在接到请求后指导客户进行排查,排查了服务器空间、alter日志、等待事件延迟等信息,并未看到有效的信息反馈。
##通过以下命令来查看当前等待事件的延迟,通过以下发现延迟较高以为是存储性能出现故障,询问是否检查存储,得到的反馈是已经联系浪潮相关人员,存储正常
select * from ( select event, total_waits,total_timeouts,time_waited,average_wait from gv$system_event where time_waited > 0 order by time_waited desc ) where rownum <=10 ;
通过以下命令查看数据库相关等待事件,发现以下信息,这里发现数据库正在等待undo record,怀疑是数据库正在进行回滚操作
select event,count(*) from v$session_wait group by event order by 2
到这里后我就申请通过内网跳转到目标数据库服务器,并对当前数据库进行查询,发现数据库执行相关命令异常缓慢
#通过以下命令,发现数据库有80个进程,正在进行回滚,这里的80个进程和上面查询的db file sequential read等待事件的个数正好对应上。
select spid from v$process where pid in (select pid from v$fast_start_servers);
抓取了当前环境的ash报告,从这里也发现了当前数据库的db file sequential read在读取undo表空间
这里我也发现了db file sequential read、db file parallel write和wait for a undo record同时出现。
通过以上信息,我判断数据库此时正在执行并行回滚,对应的进程数为80,将数据库相关资源耗尽,这里我的思路就是将并行回滚设置为串行回滚,也就是修改参数fast_start_parallel_rollback=false,并重启数据库
alter system set fast_start_parallel_rollback=false scope=spfile; shutdown abort startup
重启数据库后,数据库虽然仍在回滚,但是数据库已经没有之前卡顿了,其他业务也能正常进行
标签:回滚,hang,数据库,db,file,event,select From: https://www.cnblogs.com/hanglinux/p/16776757.html