最近跟踪了下GMCC一个系统的ORACLE性能问题,大致有这些方法

1、登录数据库
2、看CPU是否耗用过多,运行队列是否过多
vmstat  --CPU当时有100多个任务在队列中
3、看是否有CPU过高的进程
top/prstat  --系统CPU资源消耗100%,ORACLE进程占92%
4、检查oracle进程数量
ps -ef | grep ora | wc -l  --进程达430个左右
5、查询v$session_wait各进程等待事件
SQL>select sid,event,p1,p1text from v$session_wait;
select sid,event,p1,p1text from v$session_wait where event not like 'SQL%'
and (event = 'db file sequential read' or event = 'db file scattered read');
SELECT * FROM (select sid,username,elapsed_time,EXECUTIONS,SORTS,
  COMMAND_TYPE,DISK_READS,(ELAPSED_TIME/EXECUTIONS)/1000 AVG,sql_text FROM v$sqlarea,v$session
    where v$sqlarea.HASH_VALUE = v$session.SQL_HASH_VALUE
    and executions > 0 and username = 'TRSWCM'
  order BY AVG DESC )where ROWNUM<10 ;
  select
    p1 "File #",--与等待相关的数据文件的全部文件数量
    p2 "Block #",--P1中的数据文件的块数量
    p3 "Reason Code"--描述等待产生原因的代码
  from
    v$session_wait
  where
    event = 'buffer busy waits';
看到有比较多的db file scattered read及db file sequential read等待,看来全表扫描太多了
6、查询相关SQL
SELECT   sql_text
    FROM v$sqltext a
   WHERE a.hash_value = (SELECT sql_hash_value
                           FROM v$session b
                          WHERE b.SID = '&sid')
ORDER BY piece ASC
/
  SELECT a.username,a.machine,a.program,a.sid,a.serial#,
  a.status,c.piece,c.sql_text from v$session a,v$process b,
  v$sqltext c WHERE b.spid='ORCL' AND b.addr=a.paddr AND
  a.sql_address=c.address(+)order BY c.piece
查询前10条性能差的SQL
  SELECT * FROM (select PARSING_USER_ID,EXECUTIONS,SORTS,
  COMMAND_TYPE,DISK_READS,sql_text FROM v$sqlarea
  order BY disk_reads DESC )where ROWNUM<10 ;
SELECT * FROM (select sid,username,elapsed_time,EXECUTIONS,SORTS,
  COMMAND_TYPE,DISK_READS,sql_text FROM v$sqlarea,v$session
    where v$sqlarea.HASH_VALUE = v$session.SQL_HASH_VALUE
  order BY disk_reads DESC )where ROWNUM<10 ;
性能差的SQL太多了,看来平常开发都不太注意,或者有些外购件没办法调优,看来开发的兄弟有一阵要忙了。
7、对SQL进行分析,可以使用autotrace或者PLSQL的F5
PLSQL这一点不错,不用建一堆PLAN表,也不用设权限啥的,直接F5一键搞定,这一点比TOAD好不少
8、查询等待事件的名称、等待事件与时间的总和
select * from v$system_event;
9、查询导致等待的缓冲区的类型
select * from v$waitstat;
10、检查IO是否是瓶颈
sar -u 2 10 --对于用了盘阵的好像看不出来,不知道有什么其它的方法
查看占io较大的正在运行的session
  SELECT se.sid,se.serial#,pr.SPID,se.username,se.status,
  se.terminal,se.program,se.MODULE,、se.sql_address,st.event,st.
  p1text,si.physical_reads,
  si.block_changes FROM v$session se,v$session_wait st,
  v$sess_io si,v$process pr WHERE st.sid=se.sid AND st.
  sid=si.sid AND se.PADDR=pr.ADDR AND se.sid>6 AND st.
  wait_time=0 AND st.event NOT LIKE '%SQL%' ORDER BY physical_reads DESC
 
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值