Oracle性能问题诊断一例

WBOY
WBOYオリジナル
2016-06-07 17:20:22986ブラウズ

今天一打开数据库,我还什么事情都没做,就发现硬盘灯狂转。这是为啥?初步判定是Oracle的计划任务在运行,但是哪个在运行,还不

今天一打开数据库,我还什么事情都没做,就发现硬盘灯狂转。这是为啥?初步判定是Oracle的计划任务在运行,但是哪个在运行,还不知道。

所以,第一步先判断后台在跑什么东西:
select * from v$session_longops where sofar totalwork

从这个可以了解到大部分信息,包括:
1、session信息:sid,serial#
2、执行内容:target_desc
3、执行进度:sofar/totalwork
4、开始时间:start_time
5、执行用户:username
6、sql信息:sql_id,sql_address,sql_hash_value

根据以上内容,其实我就已经可以强制停止这个的sql了,但是还得找出这个源头,也就是“责任人”--谁执行了这个sql。

于是,第二个步骤就是根据上面的第五点:执行用户,去找该用户下对应的计划任务或job:

1、job:
select * from user_jobs
2、计划任务:
select * from user_scheduler_jobs;

从这里我知道了发起人及具体发起的那个执行点。
接下来的事情就简单了,先确认下这个定时处理的是什么内容,如果没有用或对当前环境无关紧要,则关闭job或计划任务:
exec dbms_job.broken(21,true);

exec dbms_scheduler.disable('AUTO_SPACE_ADVISOR_JOB');--这是例子

当然,有时候不是直接关闭就行了,,还得看下为何会产生这么大的磁盘扫描。这个时候就要去看sql的执行计划,搞清原因,然后对其优化。这次我本地产生这个问题的原因其实很简单,因为导入dmp的时候没有指定索引,索引后台处理的时候都是走的全表扫描,导致出现这个情况。

最后,关闭之后,还有做一件事情,就是把正在执行的过程停止掉:
alter system kill session 'sid,serial#'

linux

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。