Oracle性能问题诊断一例

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了Oracle性能问题诊断一例，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1500字，纯文字阅读大概需要3分钟。

内容图文

今天一打开数据库，我还什么事情都没做，就发现硬盘灯狂转。这是为啥？初步判定是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#'

内容总结

以上是互联网集市为您收集整理的Oracle性能问题诊断一例全部内容，希望文章能够帮你解决Oracle性能问题诊断一例所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---