【正文】 peer_id, decode(action, 39。, 0, 1) ne_state from dcc_sys_log dsl, dcc_ne_log dnl where = and (( = 39。) or ( = 39。)) and log_type = 39。)) ne_disconnect_info where = (+)原先至少需要掃描2次！現(xiàn)在根據(jù)KEEP結(jié)合DENSE_RANK的方式，將表掃描從2次變?yōu)榱?次，具體代碼改寫如下：SELECT ,CASE WHEN IS NOT NULL AND str IN (39。) THEN 39。 END ne_stateFROM (SELECT peer_id,MIN(action||cause) KEEP(DENSE_RANK LAST ORDER BY log_time) str FROM dcc_sys_log dsl WHERE log_type = 39。 and cause like 39。 and alert_type = 39。, 39。, 39。 and deal_log = 39。 and log_time = TO_DATE(39。) and log_time TO_DATE(39。) + 1)union (select peer_id 對端標(biāo)識, origin_host 源域名, dest_host 目標(biāo)域名, alert_type 告警類型, log_time 告警時間, cause 告警內(nèi)容, deal_log 處理狀態(tài), deal_staff 處理人, deal_time 處理時間, remark 備注 from dcc_ne_log where result_code = 39。 and deal_log = 39。 and log_time = TO_DATE(39。) and log_time TO_DATE(39。) + 1)union (select peer_id 對端標(biāo)識, null 源域名, null 目標(biāo)域名, alert_type 告警類型, log_time 告警時間, cause 告警內(nèi)容, deal_log 處理狀態(tài), deal_staff 處理人, deal_time 處理時間, remark 備注 from dcc_sys_log where action = 39。 and deal_log = 39。 and log_time = TO_DATE(39。) and log_time TO_DATE(39。) + 1)很明顯，此處的UNION ALL 完全可以用OR 來改造，等價改寫，減少表掃描次數(shù)。對端被關(guān)閉%39。deal_log39。2010080239。2010080339。parser失敗%39。SRTimeout%39。alert_type39。YYYYMMDD39。YYYYMMDD39。依次進(jìn)行了為count(*)語句加上not null關(guān)鍵字，改造中間表為真實(shí)臨時表，去掉大量不必要的重做數(shù)據(jù)的刪除語句，用分析函數(shù)及merge語句改造普通SQL，構(gòu)造分區(qū)表加上分區(qū)字段等工作。限于篇幅本文很多內(nèi)容不能深入展開探討，許多方法只能說個思路，具體細(xì)節(jié)有興趣朋友可以通過相關(guān)文檔去深入學(xué)習(xí)了解。很多人根本缺乏這樣的意識，在語句執(zhí)行慢的時候，就只做簡單的等待而不是去觀察為什么慢。在本文中中我們了解到oracle已經(jīng)用全局臨時表實(shí)現(xiàn)了開發(fā)人員構(gòu)造的中間表實(shí)現(xiàn)的功能，而且在利用上ORACLE全局臨時表后，代碼大大減少的同時，性能還顯著提升了！此外還有非常重要的一點(diǎn)就是利用上ORACLE自帶功能，這些功能也可以隨著數(shù)據(jù)庫的版本升級而自動升級并更加強(qiáng)大?！彼f的很有道理，現(xiàn)實(shí)中我曾經(jīng)多次比較過單條SQL和過程實(shí)現(xiàn)相同邏輯后的代價的差別，每次都是單條SQL性能要高的多。我們還可以舉很多例子，比如某些應(yīng)用是固定對某兩張表進(jìn)行查詢更新的，我們就可以考慮建簇表，讓相關(guān)聯(lián)兩表的記錄處在同一數(shù)據(jù)塊上，從而大大提高了檢索的速度。性能優(yōu)化要了解數(shù)據(jù)庫的體系結(jié)構(gòu)，所以剛開始花了一定的篇幅描述了數(shù)據(jù)庫系統(tǒng)的體系結(jié)構(gòu)，建立了優(yōu)化模型樹，從整體優(yōu)化到局部優(yōu)化，從存儲到CPU到并行結(jié)構(gòu)，從改不改寫SQL本文都從實(shí)例進(jìn)行分析描寫。感謝我的指導(dǎo)老師王秋芬老師對我的論文提出了修改意見，讓我的論文條理更清晰，格式更規(guī)范。參考文獻(xiàn)[1] 譚懷遠(yuǎn).《oracle 10g性能分析和優(yōu)化思路》.北京：電子工業(yè)出版社，2010.[2] 李丙洋.《三思筆記之一步步學(xué)ORACLE》.北京：中國水利水電出版社，2010.[3] 梁敬彬 《劍破冰山oracle開發(fā)藝術(shù)》.北京：電子工業(yè)出版社，2010年.[4] 蓋國強(qiáng).《DBA手記數(shù)據(jù)庫診斷案例和性能優(yōu)化實(shí)戰(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í)時數(shù)據(jù)庫事務(wù)的優(yōu)先級分派》計算機(jī)學(xué)報 致謝本篇論文是本人在實(shí)習(xí)公司從事系統(tǒng)維護(hù)過程所寫的，在編寫論文的過程中，有一些觀點(diǎn)是和同事討論而得出的。此外從大的層面來看，設(shè)計初期充分考慮讀寫分離，充分考慮將不同用戶進(jìn)行垂直分割、將數(shù)據(jù)庫根據(jù)功能不同進(jìn)行水平分割等等方案，也將對數(shù)據(jù)庫伸縮擴(kuò)展性帶來很大的好處，一旦交付使用后再考慮改造將極其困難！當(dāng)然設(shè)計是離不開對業(yè)務(wù)的理解的，最完美的解決方案是前期數(shù)據(jù)庫設(shè)計的時候，由對業(yè)務(wù)及業(yè)務(wù)發(fā)展趨勢非常精通的業(yè)務(wù)專家和數(shù)據(jù)庫專家進(jìn)行相互配合，這樣的組合就能設(shè)計出相對完美的數(shù)據(jù)庫系統(tǒng)。例如在剛開始我們就是花了大力氣改造了源表的表結(jié)構(gòu)，將普通表改造為分區(qū)表，然后使用分區(qū)進(jìn)行查詢，這種優(yōu)化設(shè)計最終大大提高了查詢速度。比如中提到的全局臨時表替代普通表以及中提到的用分析函數(shù)和merge語句替代普通SQL就非常典型，還有start with connect by 的樹形查詢語句等，這些功能用普通SQL實(shí)現(xiàn)非常煩瑣，且性能往往很糟。其實(shí)這些并不太難，關(guān)鍵是要有這個想法！公司開發(fā)設(shè)計維護(hù)人員人人都有這樣的意識，一定能大大提高工作效率！[4] 優(yōu)化有步驟可遵循本文全篇都在描述優(yōu)化的思路及步驟，并引進(jìn)了優(yōu)化思路模型樹的概念，后續(xù)我會在公司中和大家一起分享這些優(yōu)化的思考方法，希望和我交流過的同事都能理解和領(lǐng)會我在文中描述的內(nèi)容，在遇到數(shù)據(jù)庫性能問題的時候，能參考本文的思路總結(jié)，優(yōu)化能做到有章可循，提高工作效率！ 要做大基準(zhǔn)測試大家還記得我在進(jìn)行改寫SQL優(yōu)化時做的準(zhǔn)備工作吧，把所有表的數(shù)據(jù)量翻4番，數(shù)據(jù)量增大后原來沒注意到的性能問題全部暴露出來了，接著做了四次修改SQL的優(yōu)化后，才真正的改進(jìn)了這個遷移程序的性能。 要有ORACLE優(yōu)化意識開發(fā)人員和維護(hù)人員要掌握基本的查看執(zhí)行計劃的方法，不斷加強(qiáng)優(yōu)化意識！理解ORACLE是如何基于CBO模式進(jìn)行工作的。本文介紹了AWR的方法，由于篇幅所限僅僅只是說明了一下思路，希望能拋磚引玉，開啟大家的興趣之門。本案例中，在使用未改寫SQL進(jìn)行優(yōu)化并達(dá)到目的后，并沒有就此結(jié)束研究。2010080339。2010080239。deal_log39。DIA