锁定老帖子 主题:记一次oracle sql调优过程
精华帖 (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语句的条件部分发出来? |
|
返回顶楼 | |
发表时间:2010-01-29
强强爱妍妍 写道 可否把v$sql_text的最终执行的sql语句的条件部分发出来?
select SQL_TEXT , SQL_ID from v$sqltext where SQL_TEXT like '%KEY_WORD%'; :KEY_WORD是你想要查询的sql的关键字,例如特定的表名 |
|
返回顶楼 | |
发表时间: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的结果集,谢谢. |
|
返回顶楼 | |
发表时间:2010-02-04
Oracle调优类问题发在itpub上,几分钟内会有大牛来解决。
我发现很多开发和DBA,一有性能问题,很喜欢质疑数据库本身的能力,好像这样才显得有本事,假设Oracle,MS等设计的优化器都靠不住似的,实际以我的经验来看,它们出错的几率低到完全不必考虑。就好像本楼这个问题,date被隐形转换导致全表扫描,其实这在优化器看来是正常的不是么。和电脑不同,人总是想当然的以为什么什么就该这样,而电脑始终按实际情况办事。 80%的性能问题是因为糟糕的SQL,所以有问题应该更着眼于应用程序设计和SQL,PROC这些是否合理,也能更快速的解决问题 |
|
返回顶楼 | |
发表时间:2010-02-04
yongdi2 写道 Oracle调优类问题发在itpub上,几分钟内会有大牛来解决。
我发现很多开发和DBA,一有性能问题,很喜欢质疑数据库本身的能力,好像这样才显得有本事,假设Oracle,MS等设计的优化器都靠不住似的,实际以我的经验来看,它们出错的几率低到完全不必考虑。就好像本楼这个问题,date被隐形转换导致全表扫描,其实这在优化器看来是正常的不是么。和电脑不同,人总是想当然的以为什么什么就该这样,而电脑始终按实际情况办事。 80%的性能问题是因为糟糕的SQL,所以有问题应该更着眼于应用程序设计和SQL,PROC这些是否合理,也能更快速的解决问题 同意楼上的观点 CBO“正确地”输出了执行计划,而我缺“错误地”理解。 我之前也写过blog阐述过和你类似的观点 但是即便是记录过问题,却仍然出现了定势思维,这就是我记录这次调优过程的原因,提醒自己。 |
|
返回顶楼 | |