复杂SQL性能优化的剖析(二)(r11笔记第37天)
昨天的一篇文章复杂SQL性能优化的剖析(一)(r11笔记第36天) 分析了一个SQL语句导致的性能问题,问题也算暂时告一段落,因为这个语句的执行频率是10分钟左右,所以优化后(大概是2秒左右,需要下周再次确认)的提升很大。
对于优化是一个持续的改进,我们碰到的问题,最终的原因可能五花八门,但是正如柯南所说,真相只有一个。我把这个问题和前几天处理的一个问题结合起来,前几天处理了一个紧急问题,也是有一个SQL语句的执行计划发生改变,这个语句的业务比较关键,触发频率是每分钟一次,如果一旦出现延迟,就是一个连锁反应。目前语句的执行效率其实不大理想,每次平均要25秒左右。对于我来说,这个结果其实是不可接受的。这么说的一个原因是据我所知,在另外一个统计库中,执行同样的语句只需要1秒钟。所以对于这个问题我还是充满信息的。
语句其实也蛮长,但是还得列出来。
select to_char(t2.servertime,'yyyy-mm-dd hh24:mi:ss') as servertime,t2.deviceid,t2.gamechannel,
t2.system,t2.device,t2.resolution,t2.dt,t2.appkey from (
select r1.servertime,r1.deviceid,r1.appkey from
(select min(servertime) as servertime,deviceid,appkey from sdk_start where dt=:1 group by deviceid,appkey) r1
left join
(select deviceid,appkey from h1_active_dev) r2
on(r1.deviceid=r2.deviceid and r1.appkey=r2.appkey)
where r2.deviceid is null
) t1
left join
(select servertime,deviceid,gamechannel,system,device,resolution,dt,appkey from sdk_start where dt=:2 ) t2
on(t1.appkey=t2.appkey and t1.deviceid=t2.deviceid and t1.servertime=t2.servertime)
主要的思路就是在表sdk_start中进行初步的过滤,得到每个设备最早的信息记录,然后和另外一个总表h1_active_dev去匹配(左外连接),得到这些信息之后再来和sdk_start重新关联,得到尽可能详细的信息。两个表的数据量都是千万级。
有了参考的标准,优化也有了一定的方向和章法可依据。
按照目前的执行情况,是对h1_active_dev做了全表扫描,是优化器认为目前最高效的方式。我认真比对了两套环境,数据量相仿,索引信息也是相似的,执行计划却大大不同。
其中的一个不同之处是sdk_start在当前执行效率较差的环境中,尽管是分区区,但是只有一个默认分区pmax,但是我注意到一个情况,同样的环境,另外一个逻辑相似(表名不同)的语句,表也没有分区,执行效率也很高,也是1秒左右。所以目前我只能推断表分区规范后能够提升执行效率,但是具体情况还得测试一下才能论证。
所以目前我更倾向于理解是执行计划的差别,目前的情况如下:
统计库1的执行效率较差,统计库2的执行效率要高。
统计库1中的SQL执行效率如下:
Enter value for 1: 87m3rru3sy2jt
PLAN_HASH_VALUE AVG_ET_SECS
--------------- -----------
3721561291 25.965
统计库2中的执行情况如下,存在两个子执行计划,但是效率都不错。
Enter value for 1: 87m3rru3sy2jt
PLAN_HASH_VALUE AVG_ET_SECS
--------------- -----------
690487836 .087
3721561291 .989
我们就可以在执行计划的深入分析之外大胆做一个尝试,把统计库2 的执行计划抓取出来,替换统计库1的执行计划,也算是偷天换日。这个工作做起来其实也不麻烦,有了SQLT这个工具,其实就容易得多。SQLT可参考使用sqlt手工创建sql_profile(r4笔记第37天)
但是很快做了尝试发现问题远没自己想得那么简单,因为替换之后我可以明显看到SQL的执行效率下降了,原本需要25秒,现在需要至少2分钟左右。对于1分钟执行频率的语句来说影响会被放大,导致SQL执行效率越来越差,有点多米诺骨牌的味道。
所以在2分钟的尝试中,我得出了一个初步结论,单纯替换执行计划是粗放的。因为对SQL Profile有备份,所以马上进行了恢复,恢复为原来的执行计划。
那么可以有一个很直观的感觉,那就是表的分区的影响,会把语句的性能瓶颈问题放大。
这个表有4千多万的数据,目前只有一个默认分区,看来也是一个遗留问题,要把数据再次重新分布,真不是一件简单的事情,而且sdk_start这个表的逻辑比较特别,只需要保留近2周左右的数据即可(按照日期进行分区),所以就牵扯到一个数据清理的问题,目前来看申请维护时间也有些不太合适。所以在线重定义又派上用场了。
我使用如下的语句生成了批量的分区语句,把近1个月的分区先补充出来,剩下的统统都放到默认分区,最后直接truncate pmax分区即可完成数据的清理工作。
select 'PARTITION P_'||to_char((trunc(sysdate)-30+level),'yyyymmdd')||' VALUES LESS THAN (TO_DATE('||chr(39)||(trunc(sysdate)-30+level+1)||chr(39)||', '||chr(39)||'YYYY-MM-DD HH24:MI:SS'||chr(39)||')) '
||'TABLESPACE CMBI_MIN_DATA ,' from dual connect by level<30;
这个语句生成的分区补充信息类似下面的形式:
PARTITION P_20161208 VALUES LESS THAN (TO_DATE('2016-12-09 00:00:00', 'YYYY-MM-DD HH24:MI:SS')) TABLESPACE CMBI_MIN_DATA ,
PARTITION P_20161209 VALUES LESS THAN (TO_DATE('2016-12-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')) TABLESPACE CMBI_MIN_DATA ,
PARTITION P_20161210 VALUES LESS THAN (TO_DATE('2016-12-11 00:00:00', 'YYYY-MM-DD HH24:MI:SS')) TABLESPACE CMBI_MIN_DATA ,
我们创建了表SDK_START_BAK,索引和权限也保持和原来的一致。
因为sdk_start没有主键,所以我使用rowid的方式来完成在线重定义的过程。
判断是否可以做在线重定义。
exec DBMS_REDEFINITION.CAN_REDEF_TABLE('MBI','SDK_START',2);
开始在线重定义的过程。
exec DBMS_REDEFINITION.START_REDEF_TABLE('MBI','SDK_START','SDK_START_BAK',NULL,2);
在线重定义的这个过程蛮有意思,本质上就是物化视图的prebuilt复制,给表sdk_start_bak加上了物化视图的壳,完成数据同步之后脱壳(删除物化视图)。可以看到在线重定义的过程中会创建一个sdk_start_bak的物化视图。
OWNER MVIEW_NAME QUERY_LEN UP RE REFRESH_MODE REFRESH_METHOD BUILD_MODE
---------- --------------- ---------- -- -- ------------ ---------------- ----------
MBI SDK_START_BAK 551 N DEMAND FAST PREBUILT
整个过程也是有条不紊,先复制数据,然后创建索引。CREATE INDEX "MBI"."IDX_SDK_START_SDA_NEW" ON "MBI"."SDK_START_BAK" ("SERVERTIME", "DEVICEID", "APP
KEY") LOCAL 。。。。
表sdk_start的数据量有4千多万,整个数据复制持续了5分钟左右。
为了保持数据的同步过程,减少GAP,可以使用如下的方式尽可能减少数据的差别。这个过程就有些类似物化视图的快速刷新。
execute dbms_redefinition.sync_interim_table ('MBI','SDK_START','SDK_START_BAK');
最后是收尾阶段,完成数据字典信息的替换。
exec DBMS_REDEFINITION.FINISH_REDEF_TABLE('MBI','SDK_START','SDK_START_BAK');
最后完成在线重定义之后,清理默认分区即可。
整个过程其实熟练掌握,走下来还是比较流畅的。
但是再次查看执行计划,发现执行效率没有任何改变,这个时候我们不要气馁,因为这个问题经过之前的分析,其实有更好的执行计划,那就是统计库2中的执行计划,我们再次偷天换日,替换执行计划。
可以很明显看到语句的性能有了飞速的提高。2秒钟即可完成。
其实对于这个问题有3点总结:
- 首先一个好的执行计划是基于准确的数据统计信息的基础上。有些场景下Oracle分析的执行计划可能不是最优的,我们可以在这个基础上做一些改变。
- 我们使用了分区的方式其实可以大大提高数据筛查的范围,原来需要扫描100个分区的工作量,现在只相当于扫描了1个分区。这个提高,如果使用得当,比指数级还高。
- 对于执行计划的在线替换,SQLT是一个好工具,CoE提供的这个工具还是有很强大的功能,替换稳定执行计划只是SQLT功能的冰山一角。
最后还是开头所说的那句话:优化是一个持续的改进,我们碰到的问题,最终的原因可能五花八门,但是正如柯南所说,真相只有一个。
- FFMPEG指令
- Gitlab删库事件回顾,备份手段还停留在“原始社会”?
- ASM 翻译系列第三十二弹:自制数据抽取小工具
- WordPress集成SendCloud邮件代发,规避SMTP泄漏网站主机真实IP的风险
- ASM 翻译系列第三十三弹:REQUIRED_MIRROR_FREE_MB的含义
- 放弃Python转向Go语言:这9大理由就够了 !(附代码)
- CCKiller:Linux轻量级CC攻击防御工具,秒级检查、自动拉黑和释放
- 利用HSTS安全协议柔性解决全站HTTPS的兼容性问题
- Nginx内容替换模块http_substitutions_filter_module及实用案例分享
- libmemcached编译安装报错解决记录
- 解决网站静态缓存后WP-PostViews插件不计数的问题
- Haproxy安装部署文档及多配置文件管理方案
- ASM 翻译系列第三十四弹:ASM磁盘组重要属性介绍
- 博客集成Hitokoto·一言经典语句功能
- JavaScript 教程
- JavaScript 编辑工具
- JavaScript 与HTML
- JavaScript 与Java
- JavaScript 数据结构
- JavaScript 基本数据类型
- JavaScript 特殊数据类型
- JavaScript 运算符
- JavaScript typeof 运算符
- JavaScript 表达式
- JavaScript 类型转换
- JavaScript 基本语法
- JavaScript 注释
- Javascript 基本处理流程
- Javascript 选择结构
- Javascript if 语句
- Javascript if 语句的嵌套
- Javascript switch 语句
- Javascript 循环结构
- Javascript 循环结构实例
- Javascript 跳转语句
- Javascript 控制语句总结
- Javascript 函数介绍
- Javascript 函数的定义
- Javascript 函数调用
- Javascript 几种特殊的函数
- JavaScript 内置函数简介
- Javascript eval() 函数
- Javascript isFinite() 函数
- Javascript isNaN() 函数
- parseInt() 与 parseFloat()
- escape() 与 unescape()
- Javascript 字符串介绍
- Javascript length属性
- javascript 字符串函数
- Javascript 日期对象简介
- Javascript 日期对象用途
- Date 对象属性和方法
- Javascript 数组是什么
- Javascript 创建数组
- Javascript 数组赋值与取值
- Javascript 数组属性和方法