论坛首页 综合技术论坛

记一次oracle sql调优过程

浏览 18997 次
精华帖 (0) :: 良好帖 (2) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2010-01-28  
Spike 写道
LucasLee 写道
LZ似乎有一个大问题:
你不该对ibatis的逻辑sql调试,而应该以ibatis生成、oracle最终收到的(物理)SQL来调。
这个还是能得到的,ibatis应该提供这样的debug信息,或者用oracle相应的功能,监控收到的sql日志。


可能是我没描述清楚

我并没有用“逻辑sql”调试,
我这个人比较懒,向来是使用v$sql_text查看最终的执行地sql语句


可否把v$sql_text的最终执行的sql语句的条件部分发出来?
0 请登录后投票
   发表时间:2010-01-29  
强强爱妍妍 写道
可否把v$sql_text的最终执行的sql语句的条件部分发出来?


select SQL_TEXT , SQL_ID from v$sqltext
where SQL_TEXT  like '%KEY_WORD%';

:KEY_WORD是你想要查询的sql的关键字,例如特定的表名
0 请登录后投票
   发表时间:2010-01-30  
Spike 写道
强强爱妍妍 写道
可否把v$sql_text的最终执行的sql语句的条件部分发出来?


select SQL_TEXT , SQL_ID from v$sqltext
where SQL_TEXT  like '%KEY_WORD%';

:KEY_WORD是你想要查询的sql的关键字,例如特定的表名


我想要的是你这句sql的结果集,谢谢.
0 请登录后投票
   发表时间:2010-02-04  
Oracle调优类问题发在itpub上,几分钟内会有大牛来解决。
我发现很多开发和DBA,一有性能问题,很喜欢质疑数据库本身的能力,好像这样才显得有本事,假设Oracle,MS等设计的优化器都靠不住似的,实际以我的经验来看,它们出错的几率低到完全不必考虑。就好像本楼这个问题,date被隐形转换导致全表扫描,其实这在优化器看来是正常的不是么。和电脑不同,人总是想当然的以为什么什么就该这样,而电脑始终按实际情况办事。
80%的性能问题是因为糟糕的SQL,所以有问题应该更着眼于应用程序设计和SQL,PROC这些是否合理,也能更快速的解决问题
0 请登录后投票
   发表时间:2010-02-04  
yongdi2 写道
Oracle调优类问题发在itpub上,几分钟内会有大牛来解决。
我发现很多开发和DBA,一有性能问题,很喜欢质疑数据库本身的能力,好像这样才显得有本事,假设Oracle,MS等设计的优化器都靠不住似的,实际以我的经验来看,它们出错的几率低到完全不必考虑。就好像本楼这个问题,date被隐形转换导致全表扫描,其实这在优化器看来是正常的不是么。和电脑不同,人总是想当然的以为什么什么就该这样,而电脑始终按实际情况办事。
80%的性能问题是因为糟糕的SQL,所以有问题应该更着眼于应用程序设计和SQL,PROC这些是否合理,也能更快速的解决问题


同意楼上的观点
CBO“正确地”输出了执行计划,而我缺“错误地”理解。
我之前也写过blog阐述过和你类似的观点
但是即便是记录过问题,却仍然出现了定势思维,这就是我记录这次调优过程的原因,提醒自己。
0 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics