ITPUB论坛-中国最专业的IT技术社区

 
 注册
热搜:
楼主: richto

邀请高手测试一款机械式全自动SQL优化工具

[复制链接]
论坛徽章:
486
秀才
日期:2015-09-09 10:33:01秀才
日期:2015-11-23 10:03:12秀才
日期:2015-11-23 10:03:12状元
日期:2015-11-23 10:04:09举人
日期:2015-11-23 10:04:09秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21
31#
发表于 2018-1-9 22:48 | 只看该作者
刚刚发了个 MOS 的Bug 8357294,帖子被审核了。这个BUG讲的就是PLSQL中的静态SQL无法利用ACS,目前尚未有解决办法。
用绑定变量的动态SQL同样有这问题,只有用动态SQL的REF CURSOR可以避开,当然它也就无法享受到游标缓存的好处了。

使用道具 举报

回复
认证徽章
论坛徽章:
8
2009新春纪念徽章
日期:2009-01-04 14:52:28祖国60周年纪念徽章
日期:2009-10-09 08:28:002010新春纪念徽章
日期:2010-03-01 11:07:24ITPUB9周年纪念徽章
日期:2010-10-08 09:32:25ITPUB十周年纪念徽章
日期:2011-11-01 16:23:262013年新春福章
日期:2013-02-25 14:51:24沸羊羊
日期:2015-03-04 14:51:522015年新春福章
日期:2015-03-06 11:57:31
32#
发表于 2018-1-10 11:48 | 只看该作者
newkid 发表于 2018-1-9 22:44
来自MOS的官方说法:

1、非常感谢,收集并提供了这么多有价值的资料;
2、ACS从产生以来确实存在不少的问题,以至于今天还在不断完善中,因为,这项技术相对复杂,涉及方方面面太多的因素;
3、对软解析和软软解析,个人认为两者之间的差别在于,软软解析在服务进程的空间内缓存了相关cursor的地址等信息,一旦需要不必查找,而是直接获取,而软解析则需要查找,因此,从原理上讲,ACS对软软解析也应该有效,当然,这是在抛开各种ACS相关bugs的前提下,否则,这是ACS很大的一个缺憾,也可以说是个bug,这将导致ACS威力大减,因为,很多场景中,软软解析发生的几率还是很高的,ssession_cache_cursors默认值也有几十个。

使用道具 举报

回复
论坛徽章:
20
ITPUB元老
日期:2005-02-28 12:57:002012新春纪念徽章
日期:2012-02-13 15:10:582012新春纪念徽章
日期:2012-02-13 15:10:582012新春纪念徽章
日期:2012-02-13 15:10:582012新春纪念徽章
日期:2012-02-13 15:10:58马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:142012新春纪念徽章
日期:2012-02-13 15:10:58
33#
 楼主| 发表于 2018-1-10 12:37 | 只看该作者
本帖最后由 richto 于 2018-1-12 10:44 编辑
sqysl 发表于 2018-1-9 13:49
在众多SQL调优方法中,hints应该排在最后,即使在生产库上。如果仅就两位列出的三个方法来讲,应用顺序应 ...

Don't forget we are talking SQL tuning, not SQL optimization. SQL tuning is the technique to tune a bad performance SQL.  Create a new index for one bad SQL may affect other SQL statements, So, you have to do stress test again, I don't think it is worth it to do so for a big production database.
Rewrite SQL and hints both are isolated tuning events. But Rewrite SQL is becoming difficult to predict in today's Oracle SQL optimizer. Hints is more easy to predict and some hidden query plans are not easy to be discovered by syntax rewrite.   

使用道具 举报

回复
认证徽章
论坛徽章:
8
2009新春纪念徽章
日期:2009-01-04 14:52:28祖国60周年纪念徽章
日期:2009-10-09 08:28:002010新春纪念徽章
日期:2010-03-01 11:07:24ITPUB9周年纪念徽章
日期:2010-10-08 09:32:25ITPUB十周年纪念徽章
日期:2011-11-01 16:23:262013年新春福章
日期:2013-02-25 14:51:24沸羊羊
日期:2015-03-04 14:51:522015年新春福章
日期:2015-03-06 11:57:31
34#
发表于 2018-1-10 13:29 | 只看该作者
richto 发表于 2018-1-10 12:37
Don't forget we are talking SQL tuning, not SQL optimization. SQL tuning is the technique to tune  ...

1、关于SQL调优和SQL优化,各人理解不同,个人认为SQL调优更注重过程,而SQL优化更强调结果;
2、你说到索引可能会影响到其他SQL,需要提前压力测试,理论上这点认可,但现实中,在全面分析准备的前提下,新建索引一般不会对其他SQL造成不良影响,可在生产库上用什么方式调优没风险呢?no risks,no gains。index虽有一定风险,但其优势也很明显,无需改代码,操作简单,不失灵活性和自适应性,关键是index很多时候是无可替代的,包括hint在内,这是将index排在三者之首的原因;
3、rewrite对已经部署的生产库有局限,暂且不提。hint可以隔离对其他SQL的影响,这点认可,但hint安全的同时,在线操作相对复杂,关键失去了灵活性和未来的自适应性,这也是将hint排在最后的原因。

使用道具 举报

回复
论坛徽章:
51
SQL数据库编程大师
日期:2013-12-06 13:59:43SQL大赛参与纪念
日期:2013-12-06 14:03:45SQL极客
日期:2013-12-09 14:13:35ITPUB社区OCM联盟徽章
日期:2014-12-30 09:12:25SQL数据库编程大师
日期:2016-01-13 10:30:43SQL大赛参与纪念
日期:2016-01-13 10:32:19双子座
日期:2016-02-26 14:50:25乌索普
日期:2018-03-02 09:19:33
35#
发表于 2018-1-10 15:15 | 只看该作者
我想提一下,实际sql的调优不会是这么简单两三个表的关联性,而是面对至少5个表之上并且还带自定义函数的条件,这种调优不是执行计划的问题了,有可能是改写SQL逻辑或者涉及到更底层结构和对象的问题了(比如在线定义分区)
不要说为啥这样写,你碰到的实际情况就是这样,不是所有程序员都是sql高手

使用道具 举报

回复
论坛徽章:
486
秀才
日期:2015-09-09 10:33:01秀才
日期:2015-11-23 10:03:12秀才
日期:2015-11-23 10:03:12状元
日期:2015-11-23 10:04:09举人
日期:2015-11-23 10:04:09秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21
36#
发表于 2018-1-10 23:26 | 只看该作者
sqysl 发表于 2018-1-10 11:48
1、非常感谢,收集并提供了这么多有价值的资料;
2、ACS从产生以来确实存在不少的问题,以至于今天还在 ...

缓存的游标是在PGA里面的。ACS是在SQL引擎实现的,一旦游标被缓存,它就指向一个固定的计划(cursor child number),这个就无能为力了,所以从原理上讲,它对软软解析是不可能有效的。除非把ACS的动作在PLSQL引擎又实现一遍,从已打开的游标中再进行选择,但是如你所言,这个技术比较复杂,多个变量的组合数是很可观的,这么做就会增加很多开销,和软软解析的初衷完全违背,所以这本来就是不可调和的需求矛盾。

使用道具 举报

回复
论坛徽章:
486
秀才
日期:2015-09-09 10:33:01秀才
日期:2015-11-23 10:03:12秀才
日期:2015-11-23 10:03:12状元
日期:2015-11-23 10:04:09举人
日期:2015-11-23 10:04:09秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21
37#
发表于 2018-1-10 23:42 | 只看该作者
增加索引的风险是被其他计划误用,以及增加DML开销。前者可以通过设置invisible index解决。后者可以根据业务性质来确定,如果都是小事务的OLTP确实影响不大。但是如果简单增加索引能够解决问题,那只能说明是运气好。有时候收集一下stats, 直方图也能解决问题,那也是运气好。

使用道具 举报

回复
论坛徽章:
486
秀才
日期:2015-09-09 10:33:01秀才
日期:2015-11-23 10:03:12秀才
日期:2015-11-23 10:03:12状元
日期:2015-11-23 10:04:09举人
日期:2015-11-23 10:04:09秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21
38#
发表于 2018-1-11 00:07 | 只看该作者
关于不同SQL变种的相同计划,还有个问题要请教杜兄。
比方说在调优的时候,一个 index hint 起到良好的效果,而另外一组用了 leading, use_nl, index 三种,得到计划也是一样的。于是工具只留下了前一种。但是这个SQL发布到PRODUCTION的时候,才发现这个index hint不足以生成那个执行路径,实际上得用后面那个,在PRODUCTION上才管用。
你是如何处理这种情形的呢?

使用道具 举报

回复
招聘 : Java研发
论坛徽章:
113
SQL数据库编程大师
日期:2013-12-06 13:59:43萤石
日期:2013-12-06 15:50:21ITPUB元老
日期:2007-09-25 17:05:532015年新春福章
日期:2015-03-06 11:57:31喜羊羊
日期:2015-03-04 14:49:39马上有房
日期:2015-01-22 17:30:45马上有房
日期:2014-12-17 14:39:38马上有对象
日期:2014-11-14 15:54:42itpub13周年纪念徽章
日期:2014-10-08 15:22:43itpub13周年纪念徽章
日期:2014-10-08 15:22:43
39#
发表于 2018-1-11 13:22 | 只看该作者
就佩服懂hint的,

使用道具 举报

回复
论坛徽章:
486
秀才
日期:2015-09-09 10:33:01秀才
日期:2015-11-23 10:03:12秀才
日期:2015-11-23 10:03:12状元
日期:2015-11-23 10:04:09举人
日期:2015-11-23 10:04:09秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21秀才
日期:2016-01-06 14:10:21
40#
发表于 2018-1-12 00:12 | 只看该作者
piliskys 发表于 2018-1-11 13:22
就佩服懂hint的,

他实际上解析了SQL的语法,这个也很不容易。

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档 |
  | | |
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 网站律师 隐私政策 知识产权声明
 北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表