【正文】 deal_log39。 and alert_type = 39。alert_type39。 and log_time = TO_DATE(39。2010080239。, 39。YYYYMMDD39。) and log_time TO_DATE(39。2010080339。, 39。YYYYMMDD39。) + 16. 總結和建議通過以上生產(chǎn)中的優(yōu)化案例描述，大家對前面總結的優(yōu)化思路樹模型應該有了較深刻的認識。本案例中，在使用未改寫SQL進行優(yōu)化并達到目的后，并沒有就此結束研究。在人為增加了大量數(shù)據(jù)的情況下，發(fā)現(xiàn)系統(tǒng)暴露出許多新的問題，最后依賴改造SQL的方法來實現(xiàn)優(yōu)化的目的。依次進行了為count(*)語句加上not null關鍵字，改造中間表為真實臨時表，去掉大量不必要的重做數(shù)據(jù)的刪除語句，用分析函數(shù)及merge語句改造普通SQL，構造分區(qū)表加上分區(qū)字段等工作。如果數(shù)據(jù)庫某些任務原本運行的很好，忽然變慢了，我們可以通過對數(shù)據(jù)庫整體做性能優(yōu)化分析，這樣可以迅速定位到真正的瓶徑所在，從而解決問題。本文介紹了AWR的方法，由于篇幅所限僅僅只是說明了一下思路，希望能拋磚引玉，開啟大家的興趣之門。通過以上的探討知道，其實優(yōu)化還是有規(guī)律可循的，只要深入學習理解ORACLE體系結構和各個相關知識點，腦海中時刻有優(yōu)化的思路模型樹做為指導，當然，我所提及的兩棵樹模型是我自己所想的，限于水平，只是起到拋磚引玉，給大家做參考，大家可以自己思考，將自己的思想和技能融合進去，將優(yōu)化模型的認識完善，希望在大家的共同努力下，將數(shù)據(jù)庫調優(yōu)工作做到最好！另外，相比優(yōu)化而言，數(shù)據(jù)庫設計其實顯的更有重要，好的系統(tǒng)是設計出來的而不是優(yōu)化出來的，設計中也是有規(guī)律可遵循的，也有模型可以建立，我會考慮后續(xù)在設計方面建立出一套設計思路模型，并不斷完善和改進。限于篇幅本文很多內容不能深入展開探討，許多方法只能說個思路，具體細節(jié)有興趣朋友可以通過相關文檔去深入學習了解。數(shù)據(jù)庫應用部署的好壞會對ERP應用起到舉足輕重的影響，結合優(yōu)化數(shù)據(jù)庫的項目經(jīng)驗及對相關數(shù)據(jù)庫知識的學習探索，我總結了如下一些數(shù)據(jù)庫管理應用中的建議給公司做參考，考慮不周和理解錯誤之處請批評指正。 要有ORACLE優(yōu)化意識開發(fā)人員和維護人員要掌握基本的查看執(zhí)行計劃的方法，不斷加強優(yōu)化意識！理解ORACLE是如何基于CBO模式進行工作的。如果開發(fā)人員和維護人員有了優(yōu)化意識和相關知識，就能自己發(fā)現(xiàn)和避免前面提到的表和索引未分析導致執(zhí)行計劃不正確的問題。很多人根本缺乏這樣的意識，在語句執(zhí)行慢的時候，就只做簡單的等待而不是去觀察為什么慢。其實有的時候，比如plsql developer工具一個簡單的F8就可以查看執(zhí)行計劃是什么，從而得知有無走索引和是否用到分區(qū)；通過查看一個簡單的v$session_wait視圖就可以知道系統(tǒng)在等什么，通過觀察v$sql視圖的execute字段我們就可以知道數(shù)據(jù)庫是否沒有使用綁定變量。其實這些并不太難，關鍵是要有這個想法！公司開發(fā)設計維護人員人人都有這樣的意識，一定能大大提高工作效率！[4] 優(yōu)化有步驟可遵循本文全篇都在描述優(yōu)化的思路及步驟，并引進了優(yōu)化思路模型樹的概念，后續(xù)我會在公司中和大家一起分享這些優(yōu)化的思考方法，希望和我交流過的同事都能理解和領會我在文中描述的內容，在遇到數(shù)據(jù)庫性能問題的時候，能參考本文的思路總結，優(yōu)化能做到有章可循，提高工作效率！ 要做大基準測試大家還記得我在進行改寫SQL優(yōu)化時做的準備工作吧，把所有表的數(shù)據(jù)量翻4番，數(shù)據(jù)量增大后原來沒注意到的性能問題全部暴露出來了，接著做了四次修改SQL的優(yōu)化后，才真正的改進了這個遷移程序的性能。[5]這個案例非常典型，告訴了我們這樣一個道理，測試環(huán)境中的應用要真正部署到生產(chǎn)，必須模擬生產(chǎn)的大數(shù)據(jù)量，進行大基準測試，甚至要超過生產(chǎn)真正的數(shù)據(jù)量！如果只是簡單的幾個用戶，少量的數(shù)據(jù)，你將永遠也發(fā)現(xiàn)不了潛在的各種問題，這點尤其重要！ 避免重復發(fā)明輪子 我發(fā)現(xiàn)不少人花了很大的精力開發(fā)了一個數(shù)據(jù)庫本身就已經(jīng)提供的功能，比如為了控制用戶的連接數(shù)有人寫了一個代碼監(jiān)控v$session中連接數(shù)量，達到某個值后強行將其kill實現(xiàn)，其實ORACLE中的profile早已提供了這樣的功能，而且使用起來相單簡單安全！還有開發(fā)人員編寫了大量代碼實現(xiàn)了sequence序列的功能，這樣不止麻煩，還會遇到并發(fā)帶來的各種問題，而且性能也將因為用不到cache等功能而大打折扣。在本文中中我們了解到oracle已經(jīng)用全局臨時表實現(xiàn)了開發(fā)人員構造的中間表實現(xiàn)的功能，而且在利用上ORACLE全局臨時表后，代碼大大減少的同時，性能還顯著提升了！此外還有非常重要的一點就是利用上ORACLE自帶功能，這些功能也可以隨著數(shù)據(jù)庫的版本升級而自動升級并更加強大。 力求使用簡單方法只要深入學習，開發(fā)人員就會發(fā)現(xiàn)，原來ORACLE已經(jīng)提供了許多很好的方法，完全可以替代那些我們費盡心思編寫，卻往往效率低下的sql語句。比如中提到的全局臨時表替代普通表以及中提到的用分析函數(shù)和merge語句替代普通SQL就非常典型，還有start with connect by 的樹形查詢語句等，這些功能用普通SQL實現(xiàn)非常煩瑣，且性能往往很糟。認真學習ORACLE各種SQL語法后就會發(fā)現(xiàn)，善于利用諸如decode, case when, insert all, with 子句，分析函數(shù)，merge, union等各種命令，加上良好的構造思路，我們可以把一個原本需要在過程中通過復雜邏輯實現(xiàn)的應用用單條sql來完成，帶來成就感的同時帶來了性能上的提升！[7]這里我引用Thomas Kyte曾說過的ORACLE優(yōu)化哲學：“盡量用一條SQL完成工作；如果無法用一條SQL實現(xiàn)則考慮PL/SQL；PL/SQL無法實現(xiàn)考慮用JAVA；JAVA無法實現(xiàn)考慮用C；C無法實現(xiàn)考慮放棄該任務?！彼f的很有道理，現(xiàn)實中我曾經(jīng)多次比較過單條SQL和過程實現(xiàn)相同邏輯后的代價的差別，每次都是單條SQL性能要高的多。 設計非常重要一般來說好的數(shù)據(jù)庫是設計出來的而并非在后期調優(yōu)得到的，不良設計會導致系統(tǒng)性能產(chǎn)生很大的瓶徑，反之，良好的設計能很好地提高系統(tǒng)性能。例如在剛開始我們就是花了大力氣改造了源表的表結構，將普通表改造為分區(qū)表，然后使用分區(qū)進行查詢，這種優(yōu)化設計最終大大提高了查詢速度。再舉索引的例子，索引雖然能提高查詢效率，卻對DML等更新語句有著負面作用，所以我們應該盡量在產(chǎn)品設計之前就規(guī)劃好索引，考慮要建什么類型的索引，建多少個索引等等，而不是在交付給客戶使用時才開始考慮，把大量調優(yōu)工作當成是用戶測試的一部分是不對的！[8]在中，我們就是將中間表改造為臨時表的同時，將該表索引控制為一個，從而提高插入的性能。我們還可以舉很多例子，比如某些應用是固定對某兩張表進行查詢更新的，我們就可以考慮建簇表，讓相關聯(lián)兩表的記錄處在同一數(shù)據(jù)塊上，從而大大提高了檢索的速度。再比如說RAC環(huán)境中，我們應該在設計初期就考慮對應用進行規(guī)劃，盡量設計將不同類型的業(yè)務分別部署到兩個不同的節(jié)點上，這樣可以有效避免CACHE的爭用等等。此外從大的層面來看，設計初期充分考慮讀寫分離，充分考慮將不同用戶進行垂直分割、將數(shù)據(jù)庫根據(jù)功能不同進行水平分割等等方案，也將對數(shù)據(jù)庫伸縮擴展性帶來很大的好處，一旦交付使用后再考慮改造將極其困難！當然設計是離不開對業(yè)務的理解的，最完美的解決方案是前期數(shù)據(jù)庫設計的時候，由對業(yè)務及業(yè)務發(fā)展趨勢非常精通的業(yè)務專家和數(shù)據(jù)庫專家進行相互配合，這樣的組合就能設計出相對完美的數(shù)據(jù)庫系統(tǒng)。[9]7. 結束語本文是基于日常工作中涉及到的性能調優(yōu)的工作總結，系統(tǒng)調優(yōu)是一個持續(xù)的過程，從剛開始的架構到系統(tǒng)結構設計，從連接數(shù)據(jù)庫的方式到寫SQL腳本，每一步都跟系統(tǒng)優(yōu)化息息相關。性能優(yōu)化要了解數(shù)據(jù)庫的體系結構，所以剛開始花了一定的篇幅描述了數(shù)據(jù)庫系統(tǒng)的體系結構，建立了優(yōu)化模型樹，從整體優(yōu)化到局部優(yōu)化，從存儲到CPU到并行結構，從改不改寫SQL本文都從實例進行分析描寫。本文主要是基于日常維護的ERP系統(tǒng)的一個子系統(tǒng)物流管理系統(tǒng)進行分析的，有些觀點比較片面，這也是本篇論文的不足之處。參考文獻[1] 譚懷遠.《oracle 10g性能分析和優(yōu)化思路》.北京：電子工業(yè)出版社，2010.[2] 李丙洋.《三思筆記之一步步學ORACLE》.北京：中國水利水電出版社，2010.[3] 梁敬彬 《劍破冰山oracle開發(fā)藝術》.北京：電子工業(yè)出版社，2010年.[4] 蓋國強.《DBA手記數(shù)據(jù)庫診斷案例和性能優(yōu)化實戰(zhàn)》.北京：電子工業(yè)出版社，2001.[5] ORACLE Database Concepts 10g Release 2 (), B1422002,October 2005.[6] ORACLE Database Administrators Guide 10g Release 2 (),B1423102, May 2006.[7] Thomas Kyte, Expert ORACLE Database Architecture. [8] 梁敬彬 《oracle優(yōu)化模型的思路探討》[9] 劉云生 李國徽 《主動實時數(shù)據(jù)庫事務的優(yōu)先級分派》計算機學報 致謝本篇論文是本人在實習公司從事系統(tǒng)維護過程所寫的，在編寫論文的過程中，有一些觀點是和同事討論而得出的。感謝在編寫論文中ITPUB的梁敬彬老師給我的論文做一些技術指導和論文原始的錯誤觀點做了修正，和分享了他在做電信項目過程系統(tǒng)優(yōu)化經(jīng)驗。感謝我的指導老師王秋芬老師對我的論文提出了修改意見，讓我的論文條理更清晰，格式更規(guī)范。