優(yōu)化數據庫大幅度提高Oracle的性能
低碳指數：在這里為了方便計算和直觀，我們以Intel至強X7500處理器的TDP為標準計算能耗（TDP=130W/h=2.167W/m=0.036W/s）。另外根據中國林業(yè)局的數據，一棵樹一天吸收二氧化碳量為5.023kg，每一度電產生0.785公斤二氧化碳。
如果按照本文方法優(yōu)化后數據庫執(zhí)行時間由5分35秒縮減到0.71秒，也就是單位時間少99.7%的能量消耗。那么在一天里將減少3.101kw電能消耗，約合2.434kg二氧化碳排放，按我們的計算是一天減少0.48棵樹二氧化碳吸收量。
數據庫優(yōu)化的討論可以說是一個永恒的主題。資深的Oracle優(yōu)化人員通常會要求提出性能問題的人對數據庫做一個statspack，貼出數據庫配置等等。還有的人認為要抓出執(zhí)行最慢的語句來進行優(yōu)化。但實際情況是，提出疑問的人很可能根本不懂執(zhí)行計劃，更不要說statspack了。而我認為，數據庫優(yōu)化，應該首先從大的方面考慮：網絡、服務器硬件配置、操作系統(tǒng)配置、Oracle服務器配置、數據結構組織、然后才是具體的調整。實際上網絡、硬件等往往無法決定更換，應用程序一般也無法修改，因此應該著重從數據庫配置、數據結構上來下手，首先讓數據庫有一個良好的配置，然后再考慮具體優(yōu)化某些過慢的語句。我在給我的用戶系統(tǒng)進行優(yōu)化的過程中，總結了一些基本的，簡單易行的辦法來優(yōu)化數據庫，算是我的三板斧，呵呵。不過請注意，這些不一定普遍使用，甚至有的會有副作用，但是對OLTP系統(tǒng)、基于成本的數據庫往往行之有效，不妨試試。（注：附件是Burleson寫的用來報告數據庫性能等信息的腳本，本文用到）
一．設置合適的SGA
常常有人抱怨服務器硬件很好，但是Oracle就是很慢。很可能是內存分配不合理造成的。(1)假設內存有512M，這通常是小型應用。建議Oracle的SGA大約240M，其中：共享池（SHARED_POOL_SIZE）可以設置60M到80M，根據實際的用戶數、查詢等來定。數據塊緩沖區(qū)可以大致分配120M-150M，8i下需要設置DB_BLOCK_BUFFERS，DB_BLOCK_BUFFER*DB_BLOCK_SIZE等于數據塊緩沖區(qū)大小。9i 下的數據緩沖區(qū)可以用db_cache_size來直接分配。
(2)假設內存有1G，Oracle 的SGA可以考慮分配500M：共享池分配100M到150M，數據緩沖區(qū)分配300M到400M。
(3)內存2G，SGA可以考慮分配1.2G，共享池300M到500M，剩下的給數據塊緩沖區(qū)。
(4)內存2G以上：共享池300M到500M就足夠啦，再多也沒有太大幫助；(Biti_rainy有專述)數據緩沖區(qū)是盡可能的大，但是一定要注意兩個問題：一是要給操作系統(tǒng)和其他應用留夠內存，二是對于32位的操作系統(tǒng)，Oracle的SGA有1.75G的限制。有的32位操作系統(tǒng)上可以突破這個限制，方法還請看Biti的大作吧。
二．分析表和索引，更改優(yōu)化模式
Oracle默認優(yōu)化模式是CHOOSE，在這種情況下，如果表沒有經過分析，經常導致查詢使用全表掃描，而不使用索引。這通常導致磁盤I/O太多，而導致查詢很慢。如果沒有使用執(zhí)行計劃穩(wěn)定性，則應該把表和索引都分析一下，這樣可能直接會使查詢速度大幅提升。分析表命令可以用ANALYZE TABLE 分析索引可以用ANALYZE INDEX命令。對于少于100萬的表，可以考慮分析整個表，對于很大的表，可以按百分比來分析，但是百分比不能過低，否則生成的統(tǒng)計信息可能不準確?？梢酝ㄟ^DBA_TABLES的LAST_ANALYZED列來查看表是否經過分析或分析時間，索引可以通過DBA_INDEXES的LAST_ANALYZED列。
下面通過例子來說明分析前后的速度對比。（表CASE_GA_AJZLZ大約有35萬數據，有主鍵）首先在SQLPLUS中打開自動查詢執(zhí)行計劃功能。(第一次要執(zhí)行\(zhòng)RDBMS\ADMIN\utlxplan.sql來創(chuàng)建PLAN_TABLE這個表)
SQL> SET AUTOTRACE ON SQL>SET TIMING ON |
通過SET AUTOTRACE ON 來查看語句的執(zhí)行計劃，通過SET TIMING ON 來查看語句運行時間。
SQL> select count(*) from CASE_GA_AJZLZ; COUNT(*) ---------- 346639 已用時間: 00: 00: 21.38 Execution Plan 0 SELECT STATEMENT Optimizer=CHOOSE 1 0 SORT (AGGREGATE) 2 1 TABLE ACCESS (FULL) OF 'CASE_GA_AJZLZ' …………………… |
請注意上面分析中的TABLE ACCESS(FULL)，這說明該語句執(zhí)行了全表掃描。而且查詢使用了21.38秒。這時表還沒有經過分析。下面我們來對該表進行分析：
SQL> analyze table CASE_GA_AJZLZ compute statistics; |
表已分析。已用時間: 00: 05: 357.63。然后再來查詢：
SQL> select count(*) from CASE_GA_AJZLZ; COUNT(*) ---------- 346639 已用時間: 00: 00: 00.71 Execution Plan 0 SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=351 Card=1) 1 0 SORT (AGGREGATE) 2 1 INDEX (FAST FULL SCAN) OF 'PK_AJZLZ' (UNIQUE) (Cost=351 Card=346351) ………………………… |
請注意，這次時間僅僅用了0.71秒！這要歸功于INDEX(FAST FULL SCAN)。通過分析表，查詢使用了PK_AJZLZ索引，磁盤I/O大幅減少，速度也大幅提升！下面的實用語句可以用來生成分析某個用戶的所有表和索引，假設用戶是GAXZUSR：
SQL> set pagesize 0 SQL> spool d:\analyze_tables.sql; SQL> select 'analyze table '||owner||'.'||table_name||' compute statistics;' from dba_tables where owner='GAXZUSR'; SQL> spool off SQL> spool spool d:\analyze_indexes.sql; SQL> select 'analyze index '||owner||'.'||index_name||' compute statistics;' from dba_indexes where owner='GAXZUSR'; SQL> spool off SQL> @d:\analyze_tables.sql SQL> @d:\analyze_indexes.sql |
解釋：上面的語句生成了兩個sql文件，分別分析全部的GAXZUSR的表和索引。如果需要按照百分比來分析表，可以修改一下腳本。通過上面的步驟，我們就完成了對表和索引的分析，可以測試一下速度的改進啦。建議定期運行上面的語句，尤其是數據經過大量更新。
當然，也可以通過dbms_stats來分析表和索引，更方便一些。但是我仍然習慣上面的方法，因為成功與否會直接提示出來。
另外，我們可以將優(yōu)化模式進行修改。optimizer_mode值可以是RULE、CHOOSE、FIRST_ROWS和ALL_ROWS。對于OLTP系統(tǒng)，可以改成FIRST_ROWS，來要求查詢盡快返回結果。這樣即使不用分析，在一般情況下也可以提高查詢性能。但是表和索引經過分析后有助于找到最合適的執(zhí)行計劃。
三．設置cursor_sharing=FORCE 或SIMILAR
這種方法是8i才開始有的，oracle805不支持。通過設置該參數，可以強制共享只有文字不同的語句解釋計劃。例如下面兩條語句可以共享：
SQL> SELECT * FROM MYTABLE WHERE NAME='tom' SQL> SELECT * FROM MYTABLE WHERE NAME='turner' |
四．將常用的小表、索引釘在數據緩存KEEP池中
內存上數據讀取速度遠遠比硬盤中讀取要快，據稱，內存中數據讀的速度是硬盤的14000倍！如果資源比較豐富，把常用的小的、而且經常進行全表掃描的表給釘內存中，當然是在好不過了?？梢院唵蔚耐ㄟ^ALTER TABLE tablename CACHE來實現，在ORACLE8i之后可以使用ALTER TABLE table STORAGE(BUFFER_POOL KEEP)。一般來說，可以考慮把200數據塊之內的表放在keep池中，當然要根據內存大小等因素來定。關于如何查出那些表或索引符合條件，可以使用本文提供的access.sql和access_report.sql。這兩個腳本是著名的Oracle專家 Burleson寫的，你也可以在讀懂了情況下根據實際情況調整一下腳本。對于索引，可以通過ALTER INDEX indexname STORAGE(BUFFER_POOL KEEP)來釘在KEEP池中。
將表定在KEEP池中需要做一些準備工作。對于ORACLE9i 需要設置DB_KEEP_CACHE_SIZE，對于8i，需要設置buffer_pool_keep。在8i中，還要修改db_block_lru_latches，該參數默認是1，無法使用buffer_pool_keep。該參數應該比2*3*CPU數量少，但是要大于1，才能設置DB_KEEP_CACHE_BUFFER。buffer_pool_keep從db_block_buffers中分配，因此也要小于db_block_buffers。設置好這些參數后，就可以把常用對象永久釘在內存里。
五．設置optimizer_max_permutations
對于多表連接查詢，如果采用基于成本優(yōu)化(CBO)，ORACLE會計算出很多種運行方案，從中選擇出最優(yōu)方案。這個參數就是設置oracle究竟從多少種方案來選擇最優(yōu)。如果設置太大，那么計算最優(yōu)方案過程也是時間比較長的。Oracle805和8i默認是80000，8建議改成2000。對于9i，已經默認是2000了。
六．調整排序參數
(1) SORT_AREA_SIZE:默認的用來排序的SORT_AREA_SIZE大小是32K，通常顯得有點小，一般可以考慮設置成1M（1048576）。這個參數不能設置過大，因為每個連接都要分配同樣的排序內存。
(2) SORT_MULTIBLOCK_READ_COUNT:增大這個參數可以提高臨時表空間排序性能，該參數默認是2，可以改成32來對比一下排序查詢時間變化。注意，這個參數的最大值與平臺有關系。
【編輯推薦】
