[Performance Tune] Oracle SQL Tune Methodology

系統Performance不好, 不論是DBA主動設定KPI偵測或是使用者反應, 往往需要DBA和開發人員一起合作找出真因, 進一步解決. 但通常Perfrmance tune被侷限在SQL Tuning, DBA又常和開發人員雞同鴨講, DBA怪開發人員SQL亂下, 開發人員怪DBA亂調參數又不通知. 但是Tune 的手法何其多又複雜(Tune Memory, IO, Cost-base optimizer, execution plan,...), 網路上隨便都可以找到幾百頁的教材供大家參考. 再此將自已對TUNE的一些作法分享, 希望有幫助!!!

1. Tune 的階段, 從上而下的關係以及扮演階段的角色為何:
1-1. 商業功能的調整 (Business Function)
角色 : 系統分析師(System Analyst)
功能 : 從使用者的角度來分析功能的必要性, 從中尋求 Performance 調整的機會.
1-2. 流程和資料流設計的最佳化 (Process/Data Design)
角色 :系統設計師 (System Designer)
功能 : 從系統資訊流和Schema的設計的角度. 通常這一段的改善空間很大, 因為很多
應用程式設計都是急就章並沒有把Performance當作是 Design 的考量因子.
1-3. SQL語法的微調 (SQL Tune)
角色 : 程式設計師 (System Programmer)
功能 : 校調SQL包含 Execution plan, index access, join method 等等.
1-4. 記憶體和IO的微調 (Oracle Memory/IO)
角色 : 資料庫管理 : DBA
功能 : 系統層級的資料庫參數調整 (Buffer cache setting,...)以及透過系統
LEVEL的觀點去尋求改善機會. 例如 : Wait-Interface, Scability,....
1-5. 作業系統的微調 (Operating System)
角色 : 系統管理 (System Administrator)
功能 : 作業系統設定的調整
1-6. 網路的微調 (Network)
角色 : 網路管理 :Network Administrator )
功能 : 網路相關設定調整, 尤其在Web 3-Tier 的環境下, 會有此需求.

2. Tune 的階段, 彼此間的影響性:
2-1. 越上層, performance 改善的空間越大. 從使用者需求(也就是商業功能)著眼,
常發現開發人員被要求 tune 一個performance 差的程式, tune了老半天才發
現該程式的使用率很低或者對使用者而言, 該功能只是Nice-To-Have的功能.
這個Tune的需求當然以停掉程式, 效果最好也沒有後續1-2~1-6的問題.
2-2. 越上層,要做Performance改善的成本會越高. 流程和資料流的設計的改變, 影響
個層面相對大, 例如為了Tune Performance, 改變了某的欄位存放的位置, 影響
的是所有存取此欄位的SQL都要做變更和重新測試,相對而言成本當然很高.
2-3. 上層的改變會影響到下層 (當然要看系統的設計是否考慮到層次(Tier)的劃分,
層次規劃越完整, 相關改變的影響會越小).
2-4. 越下層的階段, 若有Performance的問題, 通常影響層面不會是單一應用程式
而會是較全面性的影響. 網路有問題通成會是全面性的影響.單一SQL語法的問題,
影響層面有限.

基本上所有的Tune需求應該都要根據第一點的順序,併同時間考慮第二點提到的相依性問題,
思考出一個步驟後再進行, 才不會捨本逐末, 事倍功半!!!
IT 人員最常見的就是一下面對問題直接就鑽入技術的窠臼中, 反而對真正問題沒有解決.