[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 人員最常見的就是一下面對問題直接就鑽入技術的窠臼中, 反而對真正問題沒有解決.

[Oracle News] 淘寶網的Platform

最新一期ORACLE雜誌選出 'Editor's Choice Awards 2008', 其中 'IT Manager of the Year'由淘寶網的IT經理(Hai Wang)獲選. 原來中國第一大的購物網站(只逛過奇摩和PCHOME的網友應該去逛逛淘寶網)也是透過ORACLE和JAVA所建置. RAC, Clusterware, Automatic storage management 等技術都使用在其 中. 淘寶網更用了 Oracle Datawarehouse 為競標者和賣家提供個人化的交易分析建議, 就個人使用經驗, 淘寶網這一點是奇摩和PCHOME所不及的.

值得一提的是Hai Wang本身也是 Oracle ACE成員(這是敝人終身追求的目標耶).

[Misc] Oracle 雜誌免費送, 還是寄到家喔

上Oracle網站(http://www.oracle.com/oramag/index.html), 登錄後即可免費收到每兩個月出版的雜誌. 也可以選擇收到數位版.內容有ORACLE近況, 技術專刊等等, Oracle的愛好者當然不能錯過.

[PL/SQL] PL/SQL 也可以很' 模組'

看過也寫過無數的PL/SQL code, 相對於我所接觸的其他語言(VB, Fortran), PL/SQL是最容易被輕忽而不做模組化的一種語言 (原因不清楚, 但我猜是PL/SQL 的 IDE不像其他語言的IDE成熟). 這也造成開發人員在接手其他人的舊程式時, 往往面對的是如意大麵(Pasta)似的程式碼, 如果連程式碼都看沒有, 更遑論後續的品質. 而改善品質, 大部分人會想到模組化, 本文就對PL/SQL的模組化, 提出一些想法和實際的作法供大家參考.

PL/SQL 模組化的三個作法:
1. 模組的公用度高 --> 將較常用的共用的程式包在同一個Package裡面, 以供其他程式呼叫.
2. 模組的公用度普通--> 如果Procedure(呼叫者)寫在 Package裡面, 則將共用的程式寫在
PACKAGE本身, 以供同一PACKAGE的其他程式呼叫. 當然若該FUNCTION宣告成Public,
則PACKAGE以外的程式亦可呼叫.
3. 模組的公用度低--> 是本文的重點, 就是若是該FUNCTION只有PROCEDURE本身會用用到.
那透過Sub-Function/Sub-Procedure 來完成, 會是更方便而且讓程式的層次分得更清楚.
以下就用實際程式來說明!



這樣子程式碼看起來是不是排列比較有邏輯而起維護性較高!

模組化不是一個口號而是可以落實的端看開發團隊如何運用囉!

[Oracle Career] 從開發人員到 DBA

傳統的觀念中, 一般然總認為DBA的優越感是高於開發人員的, 這裡有一些看法供各位參考.但其實兩者的工作有相同也有相異處, 了解這些異同也許可以解決一般常見DBA和開發人員間的衝突.

相異:
1. DBA 有較多重複性的工作(Daily Export, Daily alert log monitor,...)
2. DBA 常遇到緊急事件(Disk issue, Data file full,...)
3. 開發人員接近使用者, 直接面對開發人員的贊賞和責罵.
4. 開發人員必須面對USER對完成日期的壓力.
5. DBA相對較為技術導向, 開發人員則多往系統分析或管理階層發展.
6. DBA相對擁有較多ORACLE的資訊(從訓練或研討會等等)

相同
1. 一個資深的開發人員, 常常可以兼任 Application DBA的角色

• Application DBA 的角色

相關Schema(Table, View, Procedure, Trigger)改變/ SQL 調教

• System DBA 的角色

評估硬體環境/安裝 Oracle/規劃相關環境(Tablespace, DataFile,...)/資料庫建置/備份還原資料庫/維護使用者

在IT組織裡面, 適時將DBA和開發人員的角色做輪調有其必要性,因為IT最終呈現給使用者的是穩定且完整的系統, 對使用者而言, 兩個角色必須合作無間, 如何將兩個角色發揮最大的功用, 端視IT主管的功力!

參考文件:
Evolute from a Developer to DBA