直接載入和並行-02

dotaddjj發表於2011-10-28

還是繼上次說說並行parallel,首先並行原理是:oracle建立一個程式用於協調並行服務程式之間的資訊和任務分配,把一個任務分割成很多小任務分配給並行服務程式,並行程式同時處理各自分配任務,直到任務全部結束,最後協調程式負責將各程式任務合併為最終執行結果返回給使用者。

並行在OLAP用的比較多,OLAP系統表一般為大表,OLTP上的表很多都以索引訪問為主,不過一切都要看實際業務情況,一般如果有多cpu,操作的物件很大開啟並行是可以明顯提高效率的。

一個查詢的parallel

Alter table tt01 parallel 2;

SQL> select count(*) from tt01 order by object_id;

COUNT(*)

----------

48545

執行計劃

----------------------------------------------------------

Plan hash value: 1845497878

--------------------------------------------------------------------------------

--------------------------------

| Id | Operation Cost (%CPU) Bytes

SELECT STATEMENT, GOAL = ALL_ROWS 90 48545 4514685

PX COORDINATOR

PX SEND QC (ORDER) SYS :TQ10001 90 48545 4514685

SORT ORDER BY 90 48545 4514685

PX RECEIVE 86 48545 4514685

PX SEND RANGE SYS :TQ10000 86 48545 4514685

PX BLOCK ITERATOR 86 48545 4514685

TABLE ACCESS FULL ASHUANG TT01 86 48545 4514685

下面的執行計劃摘自一位網友的blog(哎,英文不好)

1)並行服務程式對tt01表進行全表掃描。

2)並行服務程式以ITERATOR(迭代)方式訪問資料塊,也就是並行協調程式分給每個並行服務程式一個資料片,在這個資料片上,並行服務程式順序地訪問每個資料塊(Iterator),所有的並行服務程式將掃描的資料塊傳給另一組並行服務程式(父程式)用於做Hash Group操作。

3)並行服務父程式對子程式傳遞過來的資料做Hash Group操作。

4)並行服務程式(子程式)將處理完的資料傳送出去。

5)並行服務程式(父程式)接收到處理過的資料。

6)合併處理過的資料,按照隨即的順序發給並行協調程式(QCQuery Conordinator)。

7)並行協調程式將處理結果發給使用者。

Alter table tt01 parallel 2開啟了兩個並行度

select count(*) from tt01 order by object_id;

此時在執行並行查詢前在v$session檢視中可以比較一下

select * from v$session where username=’ASHUANG’ and status=’ACTIVE’發現執行後多了兩個session 不過某種情況可能出現4個並行程式,檢視資料發現存在父程式和子程式概念,有時候需要對sql進行額外的處理比如排序等,並行協調程式又會呼叫n個並行服務程式(父程式)用於處理剛開始分配n的程式處理(子程式)的資料,而並行服務程式之間資料交流叫做互動操作,單個並行服務之間叫做並行的內部操作。所以有時候並行服務程式是並行度的兩倍。

並行執行等待事件:

在做並行執行時也會遇到所謂的等待事件:PX Deq Creditsend blkd,檢視v$session_wait等檢視或者statspack awr報表可以看到。

PX Deq Creditsend blkd等待事件緣由:

當並行服務程式向並行協調程式QC(也可能是上一層的並行服務程式)傳送訊息時,同一時間只有一個並行服務程式可以向上層程式傳送訊息,這時候如果有其他的並行服務程式也要傳送訊息,就只能等待了。 知道獲得一個傳送訊息的信用資訊(Credit),這時候會觸發這個等待事件,這個等待事件的超時時間為2秒鐘。而對於事件的處理就是適當降低並行度!

上面展示了一個並行查詢(不過不能使用於dblink),同樣並行dml和並行ddl都是可以的。

並行ddl

Create table tt parallel 2 as select * from dba_objects

Alter table tt parallel 2

Create index index_tt on tt(object_id) parallel 2

….

如果想檢視具體的並行執行時可以去檢視udump下的trace檔案,而使用tkprof工具則可以很清楚的檢視這個過程

Alter session set events ‘10046 trace name context forever,level 12’;

Create table tt parallel 2 as select * from dba_objects

Alter session set events ‘10046 trace name context off’;

設定10046跟蹤sql然後tkprof檢視trace

索引 表的並行等都是並行協調程式建立並行程式讓其任務分配給各程式然後集合處理彙總。

並行dml

需要在使用並行的session級別設定一下alter session enable parallel dml

SQL> insert /*+parallel(tt02 2)*/ into tt02 select * from v$sysstat;

已建立347行。

執行計劃

----------------------------------------------------------

ERROR:

ORA-12838: 無法在並行模式下修改之後讀/修改物件

SP2-0612: 生成 AUTOTRACE EXPLAIN 報告時出錯

貌似出現了一個錯誤,把所有的session都提交了,暫時還沒理清為什麼!

並行執行的幾個引數:

parallel_min_servers:資料庫啟動時預先分配的並行程式數

parallel_max_servers: 資料庫的最大分配的並行程式數

parallel_adaptive_multi_user=true|false: 10G R2預設是true 能根據sql執行時系統的負載情況動態調整sql並行度。

Parallel_min_percent:申請並行服務程式的百分比,例如我們申請一個20的程式,而系統此時程式無法滿足,會按照這個引數20*parallel_min_percent個並行程式,如果還是無法滿足則報錯ora-12827

預設的並行度的計算跟cpu個數,rac例項和parallel_threads_per_cpu有關,而對於分割槽表一般採用分割槽數的併發程式處理,但是也並不是任何情況都並行,一般在服務程式資料充足

,硬體和實際業務情況同時考慮下采取並行,不然可能會適得其反,比如單cpu

[@more@]

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/25362835/viewspace-1056019/,如需轉載,請註明出處,否則將追究法律責任。

相關文章