[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语句，该建的索引还是要建立，
--//感觉这样才是比较合适的选择，达到理想的优化效果。