[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語句，該建的索引還是要建立，
--//感覺這樣才是比較合適的選擇，達到理想的優化效果。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/267265/viewspace-2672969/，如需轉載，請註明出處，否則將追究法律責任。