用Oracle并行查詢發揮多CPU的威力

2024-08-29 13:57:33

字體：大中小

來源：轉載

供稿：網友

正在看的ORACLE教程是:用Oracle并行查詢發揮多CPU的威力。參數

　　讓我們進一步看看CPU的數量是如何影響這些參數的。

　　參數fast_start_parallel_rollback

　　Oracle并行機制中一個令人興奮之處是在系統崩潰時調用并行回滾得能力。當Oracle數據庫發生少有的崩潰時，Oracle能自動檢測未完成的事務并回滾到起始狀態。這被稱為并行熱啟動，而Oracle使用基于cpu_count的fast_start_parallel_rollback參數來決定未完成事務的秉性程度。

　　并行數據操縱語言（DML）恢復能夠在Oracle數據庫崩潰后極大地加快其重新啟動的速度。此參數的默認值是系統CPU數量的兩倍，但是一些DBA們認為應該將這個值設置為cpu_count的四倍。

　　參數parallel_max_servers_parameter

　　Oracle一個顯著的加強是自動決定OPQ并行的程度。由于Oracle清楚服務器中CPU的數量，它會自動分配合適的子進程的數量來提升并行查詢的響應時間。當然，會有其它的外部因素，比如表的劃分以及磁盤輸入/輸出子系統的布局等，但是根據cpu_count來設置parallel_max_servers參數將給Oracle一個合理的依據來選擇并行的程度。

　　由于Oracle的并行操作嚴重依賴服務器上CPU的數量，parallel_max_servers會被設置成服務器上CPU的數量。如果在一臺服務器上運行多個實例，則默認值太大了，會導致過度的頁面交換和嚴重的CPU負擔。并行的程度還依賴于目標表中分區的數量，因此parallel_max_servers應該設置成足夠大以允許Oracle為每個查詢選擇最佳數量的并行子查詢。

　　參數log_buffer

　　參數log_buffer定義了供即刻寫入redo日志信息的保留RAM的數量，這個參數受cpu_count的影響。Oracle推薦log_buffer最大為cpu_count乘以500KB或128KB。CPU的數量對于log_buffer來說非常重要，因為Oracle會生成多日志寫入（LGWR）進程來異步釋放redo信息。

　　log_buffer是Oracle中最易誤解的的RAM參數之一，通常存在下面幾個配置錯誤：

log_buffer被設置得太高（例如，大于1MB），這回引起性能問題，因為大容量的結果會使得寫入同步進行（例如，日志同步等待事件非常高）。

log_buffer在一個單獨的服務器中安裝更多的CPU成為目前的一個趨勢。使用對稱多處理服務器（SMP）的情況下，一個Oracle服務器擁有8個、16個或32個CPU以及幾吉比特RAM的SGA都不足為奇。

　　Oracle跟上了硬件發展的步伐，提供了很多面向多CPU的功能。從Oracle8i開始，Oracle在每個數據庫函數中都實現了并行性，包括SQL訪問（全表檢索）、并行數據操作和并行恢復。對于Oracle專業版的挑戰是為用戶的數據庫配置盡可能多的CPU。

　　在Oracle環境中實現并行性最好的方法之一是使用Oracle并行查詢（OPQ）。我將討論OPQ是如何工作的和怎樣用它來提升大的全表檢索的響應時間以及調用并行事務回滾等等。

　　使用OPQ

　　當在Oracle中進行一次合法的、大型的全表檢索時，OPQ能夠極大地提高響應時間。通過OPQ，Oracle將表劃分成如圖A所示的邏輯塊。

　　圖 A

　　由OPQ劃分的表

　　一旦表被劃分成塊，Oracle啟用并行的子查詢（有時稱為雜務進程），每個子查詢同時讀取一個大型表中的一塊。所有子查詢完畢以后，Oracle將結果會傳給并行查詢調度器，它會重新安排數據，如果需要則進行排序，并且將結果傳遞給最終用戶。OPQ具有無限的伸縮性，因此，以前需要花費幾分鐘的全表檢索現在的響應時間卻不到1秒。

　　OPQ嚴重依賴于處理器的數量，通過并行運行之所以可以極大地提升全表檢索的性能，其前提就是使用了N-1個并行進程（N=Oracle服務器上CPU的數量）。

　　必須注意非常重要的一點，即Oracle9i能夠自動檢測外部環境，包括服務器上CPU的數量。在安裝時，Oracle9i會檢查服務器上CPU的數量，設置一個名為cpu_count的參數，并使用cpu_count作為默認的初始化輸入參數。這些初始化參數會影響到Oracle對內部查詢的處理。

　　下面就是Orale在安裝時根據cpu_count而設置的一些參數：

fast_start_parallel_rollback

parallel_max_servers

log_buffer

db_block_lru_latches

[NextPage]
不是db_block_size的倍數。在的Oracle9i中，log_buffer應該是2048字節的倍數。

　　參數db_block_lru_latches

　　LRU鎖的數量是在Oracle數據庫內部用來管理數據庫緩沖的，這嚴重依賴于服務器上CPU的數量。

　　很多聰明的Oracle9i的DBA使用多沖數據緩沖（例如db_32k_cache_size），他們推薦將這個未公開聲明的參數重設置為默認的最大值。db_block_lru_latches參數在Oracle8i中使用得很多，但是在Oracle9i中變成了一個未公開聲明的參數，因為Oracle現在根據數據庫擁有的CPU數量設置了一個合理的默認值。

　　db_block_lru_latches默認被設置為服務器上cpu_count的一半（例如服務器上只有一個Oracle數據庫）。Oracle推薦db_block_lru_latches千萬不要超過cpu_count的兩倍或三倍，或db_block_buffers的五十分之一。

　　如果使用多緩沖池則這種計算方法有一個問題，因為不能控制分配給每個數據緩沖池的鎖的數量。如果db_writers參數大于1，則默認值或許顯得太小。

　　加強服務器

　　Oracle數據庫總是在提升性能，根據外部服務器環境檢測cpu_count和基本參數設置的能力對于Oracle軟件來說是一個重要的加強。

　　隨著更多的Oracle系統轉移到SMP上來，當客戶要采取增強措施并將眾多的數據庫轉移到擁有32個或64個CPU的巨大服務器上來的時候，這些參數顯得愈發重要。

上一篇：oracle快速刪除重復的記錄

下一篇：Oracle SQL性能優化系列學習一