Oracle 並行查詢 parallel Query____Oracle

Oracle 並行查詢 parallel Query

81    53,5297 P_Base_Day_I_NewTaredUser 2009-06-25 17:28:56 2009-06-25 18:24:21 55 insert 成功 base
82    53,5300 P_BASE_DAY_I_NEWTAREDUSER_test 2009-06-25 17:29:31 2009-06-25 17:54:21 24 insert 成功 base

 

這是兩個同樣的過程 訪問6千萬的資料進行inner join 統計 前個花了55分鐘 後一個花了24分鐘

insert /*+parallel(t_newtraed_test,4) */ into  t_newtraed_test 
  select  b.addtime,0,b.username,sysdate,0,c.lotid,0,c.playid,0,0,sysdate
  from
  (
       select  username,min(addtime) as addtime 
       from
       (
              select /*+ PARALLEL(x, 5) PARALLEL(z, 5)*/ x.F_username as username ,x.f_addtime as addtime
              from T_Gather_ProUser x
              INNER JOIN t_gather_project z ON x.f_projectid = z.f_id and x.f_lotteryid=z.f_lotteryid
 ....

 

對錶可以

ALTER TABLE BA.P_ADMIN   PARALLEL ( DEGREE Default INSTANCES Default );

這個由ORACLE 自己決定

可經常報 ORA-12801: 並行查詢服務器 P029 中發出錯誤訊號
ORA-00018: 超出最大會話數

由此可見 它開了太多的會話數。

 

 

 

下面些資料可供參考

由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

參數    

    讓我們進一步看看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不是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的巨大伺服器上來的時候，這些參數顯得愈發重要。