KDB和Oracle的效能pk小記

在偶然的機會聽到了KDB,然後帶著好奇和新鮮感體驗了一把這個傳說中和Oracle 相似度達到99%的資料庫。
其中一部分的驅動力在於這個活動的獎品很豐厚，參加活動後可以拿到一個iwatch,確實是很划算的一個活動。
而對於KDB的認識，也是在對比調優中認識到的，其實結果還是大大超出我的預期。
首先來簡單說一下背景，我們一共十來個人，分成兩隊，紅隊和藍隊，然後紅隊調優Oracle,藍隊調優KDB,然後使用benchmark在同樣的加壓條件下的tpcc值作為參考來對比Oracle和KDB
乍一看Oracle這邊的人很佔便宜，至少調優的基準和方式方法感覺都是熟悉的，不用過多的花時間在熟悉KDB上面，而對於KDB這部分，其實我覺得還是佔有一定的優勢，因為兩隊都有專門的人來提供額外的資訊諮詢，原廠在這方面其實更有說服力，更有經驗，支援力度更大，這個調優的玄妙之處就在於我們除錯的Oracle系統是一個效能很差的一個環境，裡面其實還是埋了不少的機關，需要在有限的時間裡把tpcc的值跑上去。
所以分組之後大家簡單做了分工，最開始我的腦海中的調優思路是核心調優，引數調優，檔案調優，sql調優
結果一上來開始還是有些著急，其實大家的思路最後都是花更多的時間在資料庫引數調優上了。
我本來準備先檢視hugepage準備先檢視一下，看沒有調優的空間，結果一看aix的小機環境，配置不同，x86上的方式就不管用了，於是就果斷放棄了，這個部分還是要好好補補。
大家抓取效能瓶頸的時候基本大致的一致是sga的部分，結果一時忽略了其實undo的部分是個硬傷，結果回過頭來，調整的時候對方的tpcc已經遠遠領先我們了。這個時候我們所做的調優基本就是設定commit_write為nowait方式，然後調整sga_max_size,sga_target,然後一邊開始準備線上調整redo的大小，把原本的redo 50M的日誌檔案加大到百兆，
抓取的addm報告中更多的是sql語句的調優建議，所以暫時沒有深究。
所以第一階段和第二階段的調優對比效果還是不理想的。
這一輪下來，大家計程車氣也受到了影響，我們認真梳理了一下，在引數的調整上有幾個層次，
隱含引數
我發現在資料庫引數中埋了一個炸彈，就是把一個隱含引數給啟用了，引數是_fast_cursor_reexecute而這個引數的預設值是false,所以簡單評估之後就把這個值恢復了預設的值
在sga的調整上給了30G的sga，但是檢視記憶體元件的使用情況，shared pool被壓縮到了不到2G，在200多G的記憶體條件下，就把shared_pool的大小設定保持在10G以上，
pga的部分也進行了調整，把pga的大小進行為了一定的調整。
open_cursors的值太低，在1000個併發的條件下，當時的值是300，所以跑不上去，session_cached_cursors的值也比較低，做了小幅度的調整
audit_trail的部分是DB，其實這個部分暫時還沒有這個需求，在這種情況下審計部分的開銷就不必要了，果斷去除，設定為none
對於非同步io的設定,filesystemio_options設定為setall,嘗試啟用非同步io和direct io
還有一個坑就是sql_trace給開啟了，果斷禁用。
對於sql cursor的解析方式，大家還是建議改為similar，這部分也修改了。
在曹組系統級，大家把原有的CPU超執行緒設定給取消了。原來是4個，改為了預設的2個。
等大體這幾個部分完成之後，再去跑分，發現和KDB組的成績很接近了，一段時間還暫時超過了他們，這個時候才感覺到了一絲動力。
繼續調整，抓取的awr報告顯示還是存在一定的併發瓶頸，有一些row lock contention,在這個時候我檢視了相關的幾個表的ini_trans，還是原來的預設值，就簡單進行了調整，把ini_trans調大。
後面的部分，在這個基礎上再進行調優，大家就相對比較謹慎了，大家糾結比較多的一個地方就是redo的大小，甚至考慮要把它設定為一個極大的值，根據監控的情況，在過去的一個小時內redo切換次數在7次左右，還是可以進行小幅度的調整即可，不過後來大家大膽嘗試的把redo設定為一個極大的值，效果反而還是不夠理想，所以就果斷放棄了。後面的更多精力就沒有放在sql語句上，等到發現的時候時間已經不夠了，發現其中一個效能瓶頸在於一個slelect max(xxx) from xxx的查詢，其實完全可以在關注更多的細節，比如收集統計資訊，比如檢視index的設定情況，對面的KDB組還甚至考慮了對錶進行重新分割槽，這些細節的調整還是有很大的作用的，非常值得肯定。這些額外的細節和加分點也著實為KDB的tpcc貢獻了一部分分數。
最後Oracle和KDB的第三輪跑分結果比較相似，tpcc都在近9萬,KDB略微要高一些，浪潮團隊的之前的測試結果也基本和這個差不多，瞭解了KDB和其它資料庫的對比測試，跑分的差距還是很大的，KDB的效能還是很高。對於這次最佳化精力我的總結還是在粒度和細節上功夫下的不夠，在調優的方法和方式上，還是需要先從整體再到細節部分，不忽略每一個部分潛在的可能的效能問題。逐步深入，調優的改進之處就會更加有條理。
這種調優方式對我的感觸還是很大，因為這種對比pk的方式感受更加直觀，對我們分析問題和解決問題是一個非常真實的案例。沒有了基準和對比的參考，我們調優的幅度和動力就不會完全發揮出來。看來這種pk的方式可以多推廣推廣，也非常感謝浪潮本著開放的態度來組織這次活動，無論熟悉還是不熟悉KDB的朋友都會有一些認識和了解，因為時間關係，在叢集，容災，管理方式上還沒有進行深入的測試，不過相信結果應該也不賴，相信他們的技術團隊在這次活動之後，也經受了很大的壓力和考驗，可以好好休息一下了。再次感謝。