[20200111]浅谈exadata oltp系统的优化.txt

[20200111]浅谈exadata oltp系统的优化.txt --//最近做exadata数据库优化，自己有许多感想。 --//链接：http://blog.itpub.net/267265/viewspace-2672368/=>[20201007]exadata存储索引.txt > @ sql_id 5yqm7qry03mcg SQL_ID        SQLTEXT ------------- ----------------------------------------------------------------------------------------------- 5yqm7qry03mcg WITH x AS (                           ... --/trunc                          )                     SELECT x.*,y.xtsj                      FROM x,emr_yzbczrz y WHERE x.yzbxh = y.yzbxh AND (y.czjs = 2 OR (y.czjs = 1 AND y.czlx = 5))                        and y.xtsj  >=to_date(:1,'yyyy-mm-dd hh24:mi:ss') and y.xtsj <=to_date(:2,'yyyy-mm-dd hh24:mi:ss') --//通过建立emr_yzbczrz表的xtsj索引，可以不走全表扫描，不利用exadata的存储索引。这样优化后对比： --//优化前： > @ d_buffer 5yqm7qry03mcg 60  EXECUTIONS1 BUFFER_GETS1 ELAPSED_TIME1 ROWS_PROCESSED1 ------------ ------------ ------------- ---------------        89722      4999857   44930492814         1435496 1 row selected. ... sleep 60 , waiting ....  EXECUTIONS2 BUFFER_GETS2 ELAPSED_TIME2 ROWS_PROCESSED2 ------------ ------------ ------------- ---------------        89724      8188024   44931515542         1435596 1 row selected. 总buffer_gets 每次buffer_gets 执行次数   总执行时间 每次执行时间 总处理记录数 平均处理记录数 ------------- --------------- -------- ------------ ------------ ------------ --------------       3188167       1594083.5        2      1022728       511364          100             50 1 row selected. --//建立索引后优化： > @ d_buffer 5yqm7qry03mcg 60  EXECUTIONS1 BUFFER_GETS1 ELAPSED_TIME1 ROWS_PROCESSED1 ------------ ------------ ------------- ---------------        89745     22989971   44942090061         1436189 1 row selected. ... sleep 60 , waiting ....  EXECUTIONS2 BUFFER_GETS2 ELAPSED_TIME2 ROWS_PROCESSED2 ------------ ------------ ------------- ---------------        89747     23066613   44942854509         1436302 1 row selected. 总buffer_gets 每次buffer_gets     执行次数   总执行时间 每次执行时间 总处理记录数 平均处理记录数 ------------- --------------- ------------ ------------ ------------ ------------ --------------         76642           38321            2       764448       382224          113           56.5 1 row selected. --//使用.38秒,仅仅节约一点点时间，像这种情况是建立索引还是不需要建立索引非常纠结。 --//做这样优化非常没有成就感,我大概节省了 (0.511-0.382)*67 = 8.643 秒，感觉跟没做没有什么区别。 --//但是with里面的内容没有优化，事后我继续优化，效果如下： > @ d_buffer 5yqm7qry03mcg 60 EXECUTIONS1 BUFFER_GETS1 ELAPSED_TIME1 ROWS_PROCESSED1 ----------- ------------ ------------- ---------------        2234     89241076     816675931           42511 1 row selected. ... sleep 60 , waiting .... EXECUTIONS2 BUFFER_GETS2 ELAPSED_TIME2 ROWS_PROCESSED2 ----------- ------------ ------------- ---------------        2235     89241783     816681538           42519 1 row selected. 总buffer_gets 每次buffer_gets   执行次数 总执行时间 每次执行时间 总处理记录数 平均处理记录数 ------------- --------------- ---------- ---------- ------------ ------------ --------------           707             707          1       5607         5607            8              8 1 row selected. --//达到这样的效果已经非常理想了。当然我仅仅在60秒抓取1次执行，处理记录数很小，仅仅8条记录。 --//不过也可以看出问题，exadata对于OLTP"毫无用处",就好像拿大炮打蚊子，也许说的有点过^_^。 --//我自己再次仔细阅读<性能神化，聊聊Exadata 的"七宗罪">,链接： --//http://blog.itpub.net/22034023/viewspace-2153518/ --//exadata可能并不适合OLTP系统，或者讲许多客户使用它，更多是掩盖自身软件应用设计的缺陷，至少我认为我们现在的应用就是这样。 --//当然好处就是至少我不会担心系统运行缓慢，整天忙于应付这些sql语句的优化问题。 --//对于"纯"OLTP类型数据库，也许应该不要考虑在exadata运行的假设，按照原有的模式优化sql语句，该建的索引还是要建立， --//感觉这样才是比较合适的选择，达到理想的优化效果。