注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

lazydba

hello

 
 
 

日志

 
 

甲骨文performance tuning tools  

2006-12-01 18:30:40|  分类: all about databa |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
SQL_TRACE还有10046真是个好东西,方便,高效。
想trace自己的session时,可以
alter session set sql_trace true, alter session set events '10046 trace name context forever, level 12'
想关掉的话,可以
alter session set sql_trace false, alter session set events '10046 trace off'
想trace别人的session时,可以
exec dbms_system.set_ev(sid, serial#, 10046, 12, '');
不要忘了及时关掉trace,
exec dbms_system.set_ev(sid, serial#, 10046, 0, '');
sid, serial#可以从V$session查,
select sid, serial# from v$session where sid = xxx;
trace后会生成一个文件,放在user_dump_dest里,可以通过
show parameter user_dump_dest查到,前提是要有访问trace 文件的权限。
拿到trace文件后,可以
tkprof trace_file report_file
grep total report_file
这样就可以看到某个session时间到底花在哪里,如果代码真有什么问题,就可以比较快找到。
?
不过,如果一个session跑很长时间,你通过不断修改代码,调整数据库参数等等,不断打开和关掉trace的话,
ms所有的trace信息都是输出到同一个文件的,就是说各次trace的信息都堆到一起了。
如果先把某个session的trace文件删掉,然后再开起trace,那么,trace文件死活都不会出现了,
不知道有没有方法可以解决这个问题。
?
当然,statspack也很好用的。运行2次statspack.snap,然后 @ ?/rdbms/admin/spreport就可以产生一份报表了,关键是要能看懂报表。tom建议2次snap的时间间隔为15-30分钟。
?
dbms_profiler在解决sql performance问题的作用ms不大。
一把钥匙开一把锁?
?

  评论这张
 
阅读(54)| 评论(2)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017