關於數據庫優化的討論可以說是壹個永恒的主題。高級Oracle優化人員通常會讓詢問性能問題的人對數據庫進行統計打包，發布數據庫配置等。其他人認為有必要抓住最慢的句子進行優化。但事實是，提問者可能根本不理解執行計劃，更不用說statspack了。我認為，數據庫優化首先應該從大的方面考慮:網絡、服務器硬件配置、操作系統配置、Oracle服務器配置、數據結構組織，然後進行具體調整。事實上，網絡、硬件等。不能更改，應用程序壹般不能修改。因此，我們應該重點關註數據庫配置和數據結構。首先，讓數據庫有壹個良好的配置，然後考慮優化壹些緩慢的語句。在優化我的用戶系統的過程中，我總結了壹些優化數據庫的基本而簡單的方法，這就是我的三軸，呵呵。但是，請註意，這些方法可能不是普遍使用的，其中壹些甚至可能有副作用，但它們通常對OLTP系統和基於成本的數據庫有效。試試它們。（註意:附件是Burleson編寫的用於報告數據庫性能等信息的腳本，本文中使用了該腳本。)
1.設置壹個合適的SGA
人們經常抱怨服務器硬件很好，但甲骨文就是慢。很可能是內存分配不合理造成的。（1）假設內存為512M，這通常是壹個小應用程序。建議Oracle的SGA約為240M，其中:* * * *共享池（SHARED_POOL_SIZE）可以根據實際的用戶和查詢數量在60M到80M之間設置。數據塊緩沖區可以大致分配到120M-150M。在8i下，需要設置DB_BLOCK_BUFFERS，DB_BLOCK_BUFFER*DB_BLOCK_SIZE等於數據塊緩沖區大小。9i以下的數據緩沖區可以直接用db_cache_size分配。
（2）假設內存為1G，Oracle的SGA可以考慮分配500M:*** *共享池從100M分配到150M，數據緩沖區從300M分配到400M。
（3）2G內存，SGA可以考慮分配1.2G，* * *共享300M到500M的內存池，並將其余內存分配給數據塊緩沖區。
（4）2G以上內存:* *享受300M到500M的池就夠了，多了幫助不大；（比提_雨天有壹個專題）數據緩沖區應該盡可能大，但我們必須註意兩個問題:壹是為操作系統和其他應用程序留下足夠的內存，二是對於32位操作系統，Oracle的SGA有1.75G的限制。壹些32位操作系統可以突破這壹限制。方法請看比提的傑作。
2.分析表和索引並更改優化模式。
Oracle的默認優化模式是CHOOSE。在這種情況下，如果不對表進行分析，通常會導致查詢掃描整個表而不是索引。這通常會導致過多的磁盤I/O，從而導致查詢速度變慢。如果不使用執行計劃穩定性，則應該分析表和索引，這可能會直接提高查詢速度。分析表命令可用於分析索引，分析索引命令可用於。對於小於1百萬的表，可以對整個表進行分析，對於非常大的表，可以按百分比進行分析，但百分比不能太低，否則生成的統計信息可能不準確。可以通過DBA_TABLES的LAST_ANALYZED列檢查表是否經過了分析或分析時間，索引可以通過DBA_INDEXES的LAST_ANALYZED列。
以下示例說明了分析前後的速度比較。（表CASE_GA_AJZLZ有大約350，000個數據和壹個主鍵）。首先，在SQLPLUS中打開自動查詢執行計劃功能。（第壹次執行\RDBMS\ADMIN\utlxplan.sql來創建表PLAN_TABLE）。
SQL & gt打開自動跟蹤
SQL & gt設置定時開啟
通過SET AUTOTRACE ON檢查語句的執行計劃，通過SET TIMING ON檢查語句的運行時間。
SQL & gtseleCT count（*）from CASE _ GA _ AJZLZ；
計數（*）
-
346639
耗時:00: 00: 21.38
執行計劃
0 SELECT語句優化器=選擇
1 0排序（聚合）
2 1‘CASE _ GA _ AJZLZ‘的表訪問（完整）
……………………
註意上面分析中的表訪問（FULL），它顯示該語句執行全表掃描。查詢耗時21.38秒。此時，尚未分析該表。讓我們分析下表:
SQL & gt分析表CASE_GA_AJZLZ計算機統計；
表已被分析。用時:00: 05: 357.63。然後進行查詢:
SQL & gtselect count（*）from CASE _ GA _ AJZLZ；
計數（*）
-
346639
經過時間:00: 00: 00.71
執行計劃
0 SELECT語句優化器= FIRST _ ROWS（Cost = 351 Card = 1）
1 0排序（聚合）
2 1“PK _ AJZLZ”（唯壹）的索引（快速全掃描）（成本=351
卡=346351）
…………………………
請註意，這個時間只花了0.71秒！感謝索引（快速全掃描）。通過分析表，查詢使用PK_AJZLZ索引，磁盤I/O大大減少，速度大大提高！假設用戶是GAXZUSR，以下實用語句可用於生成和分析用戶的所有表和索引:
SQL & gt設置頁面大小0
SQL & gtspool d:\ analyze _ tables . SQL；
SQL & gt選擇“分析表“||所有者| |“。“||表名| |‘
計算統計數據；from dba_tables，其中owner =‘GAXZUSR‘；
SQL & gt松開線
SQL & gtspool spool d:\ analyze _ indexes . SQL；
SQL & gt選擇“分析索引”||所有者| |“。”| | index _ name | |
計算統計數據；from dba_indexes其中owner =‘GAXZUSR‘；
SQL & gt松開線
SQL & gt@d:\analyze_tables.sql
SQL & gt@d:\analyze_indexes.sql
解釋:上面的語句生成了兩個sql文件，它們分別分析GAXZUSR的所有表和索引。如果需要按百分比分析表格，可以修改腳本。通過以上步驟，我們已經完成了對表和索引的分析，並可以測試速度的提高。建議定期運行上面的語句，尤其是當數據被大量更新時。
當然，通過dbms_stats分析表和索引更方便。但我還是習慣上面的方法，因為成功會直接表示。
此外，我們可以修改優化模式。Optimizer_mode值可以是RULE、CHOOSE、FIRST_ROWS和ALL_ROWS。對於OLTP系統，可以將其更改為FIRST_ROWS以要求查詢盡快返回結果。這樣，即使不進行分析，查詢性能也可以得到總體提高。但是，對表和索引的分析有助於找到最合適的執行計劃。
3.Set cursor_sharing=FORCE或類似內容。
這種方法在8i中才開始使用，oracle805不支持它。通過設置該參數，您可以強制* * *使用不同的單詞來享受語句解釋計劃。例如，* * *可以使用以下兩種語句:
SQL & gtSELECT * FROM MYTABLE其中NAME =‘Tom‘
SQL & gtSELECT * FROM MYTABLE其中NAME =‘Turner‘
這種方法可以大大減少緩沖區利用率低的問題，並避免重新解釋語句。通過該功能，可以在很大程度上解決硬解析導致的性能下降問題。個人感覺可以根據系統的實際情況來決定是否將這個參數改為FORCE。默認情況下，此參數是精確的。但必須註意的是，修改前必須給oracle打補丁，否則修改後ORACLE將占用100%的CPU而無法使用。對於ORACLE9i，可以將其設置為SIMILAR，這結合了FORCE和EXACT的優點。但是，請謹慎使用該功能，該參數也可能帶來很大的負面影響！
4.釘釘常用的小表和索引放在KEEP池的數據緩存中。
在內存中讀取數據的速度比在硬盤中快得多。據說內存讀取數據的速度是硬盤的14000倍！如果資源充裕，將整個表中頻繁掃描的常用小表固定到內存中當然更好。只需通過alter table表名緩存即可實現，在ORACLE8i之後可以使用ALTER TABLE表存儲（buffer _ pool keep）。壹般來說，您可以考慮將200個數據塊以內的表放在keep池中，這取決於內存大小等因素。關於如何找出哪些表或索引符合要求，您可以使用本文中提供的access.sql和access_report.sql。這兩個劇本是著名甲骨文專家伯利森寫的。您也可以在閱讀後根據實際情況調整腳本。對於索引，您可以通過更改索引名稱存儲（buffer _ poolKeep）將它們固定在KEEP池中。
在KEEP池中設置表需要壹些準備工作。您需要為ORACLE9i設置DB_KEEP_CACHE_SIZE，為8i設置buffer_pool_keep。在8i中，您需要修改db_block_lru_latches。默認情況下，該參數為1，並且不能使用buffer_pool_keep。此參數應小於2 * 3 * CPUs的數量，但大於1以設置DB_KEEP_CACHE_BUFFER。Buffer_pool_keep是從db_block_buffers分配的，因此它也比db_block_buffers小。設置這些參數後，您可以在內存中永久固定公共對象。
動詞 （verb的縮寫）設置優化程序最大權限
對於多表連接查詢，如果采用基於成本的優化（CBO），ORACLE將計算多種操作方案並選擇最佳方案。該參數用於設置oracle選擇最佳方案的數量。如果設置過大，計算最佳方案的過程將需要很長時間。Oracle805和8i默認為80000，8建議將其更改為2000。9i默認已經是2000了。
不及物動詞調整分揀參數
（1）SORT_AREA_SIZE:用於排序的默認SORT _ AREA _ SIZE為32K，通常有點小。壹般可以設置為1M（1048576）。這個參數不能設置得太大，因為每個連接都應該分配相同的排序內存。
（2）SORT _ multi block _ READ _ COUNT:增加該參數可以提高臨時表空間的排序性能。該參數的默認值為2，可以更改為32來比較排序查詢時間的變化。請註意，該參數的最大值取決於平臺。