建站
咨詢
售后
建站咨詢
新聞中心
oracle 并行模式（parallel）
一般表數(shù)據(jù)量比較大（超過100萬）時，可以使用parallel強制啟動并行度來提升查詢速度
創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供寧陜網(wǎng)站建設、寧陜做網(wǎng)站、寧陜網(wǎng)站設計、寧陜網(wǎng)站制作等企業(yè)網(wǎng)站建設、網(wǎng)頁設計與制作、寧陜企業(yè)網(wǎng)站模板建站服務，10年寧陜做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡服務。
用法：/*+parallel(table_short_name,cash_number)*/
可以加到insert、delete、update、select的后面來使用
比如：select /*+paralle(t,32)*/ from table t;?table_short_name使用別名，Parallel后面的數(shù)字，越大，執(zhí)行效率越高，一般用8，10，12，16，32。不過，數(shù)值越大，占用的資源也會相對增大。如果在查詢where后的條件有加索引查詢效率會大大提高。
oracle 建索引怎么開啟并行？
建索引時，我們?yōu)榱私ㄋ饕欤瑫由喜⑿校由喜⑿兄螅肆兴饕蜁遣⑿辛恕ＴL問有并行度的索引時，CBO可能可能會考慮并行執(zhí)行，這可能會引發(fā)一些問題，如在服務器資源緊張的時候用并行會引起更加嚴重的爭用。當使用并行后，需要把并行度改回來。\x0d\x0aSQL drop table test purge;\x0d\x0aSQL create table test as select * from dba_objects;\x0d\x0aSQL create index ind_t_object_id on test(object_id) parallel 4 ;\x0d\x0aSQL select s.degree\x0d\x0afrom dba_indexes s\x0d\x0awhere s.index_name = upper('ind_t_object_id');\x0d\x0aDEGREE\x0d\x0a----------------------------------------\x0d\x0a4\x0d\x0a\x0d\x0aSQL alter index ind_t_object_id noparallel;\x0d\x0a\x0d\x0aSQL select s.degree\x0d\x0afrom dba_indexes s\x0d\x0awhere s.index_name = upper('ind_t_object_id');\x0d\x0aDEGREE\x0d\x0a----------------------------------------\x0d\x0a1
OracleRedo并行機制
Redo log 是用于恢復和一個高級特性的重要數(shù)據(jù) 一個redo條目包含了相應操作導致的數(shù)據(jù)庫變化的所有信息 所有redo條目最終都要被寫入redo文件中去 Redo log buffer是為了避免Redo文件IO導致性能瓶頸而在sga中分配出的一塊內存 一個redo條目首先在用戶內存(PGA)中產(chǎn)生 然后由oracle服務進程拷貝到log buffer中 當滿足一定條件時 再由LGWR進程寫入redo文件 由于log buffer是一塊 共享 內存 為了避免沖突 它是受到redo allocation latch保護的 每個服務進程需要先獲取到該latch才能分配redo buffer 因此在高并發(fā)且數(shù)據(jù)修改頻繁的oltp系統(tǒng)中 我們通常可以觀察到redo allocation latch的等待 Redo寫入redo buffer的整個過程如下
在PGA中生產(chǎn)Redo Enrey 服務進程獲取Redo Copy latch(存在多個 CPU_COUNT* ) 服務進程獲取redo allocation latch(僅 個) 分配log buffer 釋放redo allocation latch 將Redo Entry寫入Log Buffer 釋放Redo Copy latch;
shared strand
為了減少redo allocation latch等待 在oracle 中 引入了log buffer的并行機制 其基本原理就是 將log buffer劃分為多個小的buffer 這些小的buffer被成為strand(為了和之后出現(xiàn)的private strand區(qū)別 它們被稱之為shared strand) 每一個strand受到一個單獨redo allocation latch的保護 多個shared strand的出現(xiàn) 使原來序列化的redo buffer分配變成了并行的過程 從而減少了redo allocation latch等待
shared strand的初始數(shù)據(jù)量是由參數(shù)log_paralleli *** 控制的;在 g中 該參數(shù)成為隱含參數(shù) 并新增參數(shù)_log_paralleli *** _max控制shared strand的最大數(shù)量;_log_paralleli *** _dynamic則控制是否允許shared strand數(shù)量在_log_paralleli *** 和_log_paralleli *** _max之間動態(tài)變化
HELLODBA select??nam ksppinm val KSPPSTVL nam ksppdesc?????? ??from????sys x$ksppi nam ?????? ??????????sys x$ksppsv val?????? ??where nam indx = val indx?????? ?? AND?? nam ksppinm LIKE _% ?????? ??AND?? upper(nam ksppinm) LIKE %LOG_PARALLE% ;?????? KSPPINM????????????????????KSPPSTVL?? KSPPDESC???? ????_log_paralleli *** ?????????? ??????????Number of log buffer strands????_log_paralleli *** _max?????? ??????????Maximum number of log buffer strands????_log_paralleli *** _dynamic?? TRUE?????? Enable dynamic strands????
每一個shared strand的大小 = log_buffer/(shared strand數(shù)量) strand信息可以由表x$kcrfstrand查到(包含shared strand和后面介紹的private strand g以后存在)
HELLODBA select indx strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa != ;?????? ??????INDX STRAND_SIZE_KCRFA???? ???????????? ?????????? ???????????? ?????????? ?????? HELLODBA show parameter log_buffer?????? NAME???????????????????????????????? TYPE????????VALUE???? ????log_buffer?????????????????????????? integer???? ??
關于shared strand的數(shù)量設置 個cpu之內最大默認為 當系統(tǒng)中存在redo allocation latch等待時 每增加 個cpu可以考慮增加 個strand 最大不應該超過 并且_log_paralleli *** _max不允許大于cpu_count
注意 在 g中 參數(shù)_log_paralleli *** 被取消 shared strand數(shù)量由_log_paralleli *** _max _log_paralleli *** _dynamic和cpu_count控制
Private strand
為了進一步降低redo buffer沖突 在 g中引入了新的strand機制——Private strand Private strand不是從log buffer中劃分的 而是在shared pool中分配的一塊內存空間
HELLODBA select * from V$sgastat where name like %strand% ;POOL NAME BYTES shared pool private strands HELLODBA select indx strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa = ;INDX STRAND_SIZE_KCRFA
Private strand的引入為Oracle的Redo/Undo機制帶來很大的變化 每一個Private strand受到一個單獨的redo allocation latch保護 每個Private strand作為 私有的 strand只會服務于一個活動事務 獲取到了Private strand的用戶事務不是在PGA中而是在Private strand生成Redo 當flush private strand或者mit時 Private strand被批量寫入log文件中 如果新事務申請不到Private strand的redo allocation latch 則會繼續(xù)遵循舊的redo buffer機制 申請寫入shared strand中 事務是否使用Private strand 可以由x$ktcxb的字段ktcxbflg的新增的第 位鑒定
HELLODBA select decode(bitand(ktcxbflg ) ) used_private_strand count(*) from x$ktcxb where bitand(ksspaflg ) != and bitand(ktcxbflg ) != group by bitand(ktcxbflg );USED_PRIVATE_STRAND COUNT(*)
對于使用Private strand的事務 無需先申請Redo Copy Latch 也無需申請Shared Strand的redo allocation latch 而是flush或mit是批量寫入磁盤 因此減少了Redo Copy Latch和redo allocation latch申請/釋放次數(shù) 也減少了這些latch的等待 從而降低了CPU的負荷 過程如下
事務開始 申請Private strand的redo allocation latch (申請失敗則申請Shared Strand的redo allocation latch) 在Private strand中生產(chǎn)Redo Enrey Flush/Commit 申請Redo Copy Latch 服務進程將Redo Entry批量寫入Log File 釋放Redo Copy Latch 釋放Private strand的redo allocation latch
注意 對于未能獲取到Private strand的redo allocation latch的事務 在事務結束前 即使已經(jīng)有其它事務釋放了Private strand 也不會再申請Private strand了
每個Private strand的大小為 K g中 shared pool中的Private strands的大小就是活躍會話數(shù)乘以 K 而 g中 在shared pool中需要為每個Private strand額外分配 k的管理空間 即 數(shù)量* k
g:SQL select * from V$sgastat where name like %strand% ;POOL NAME BYTES shared pool private strands HELLODBA select trunc(value * KSPPSTVL / ) * * from (select value from v$parameter where name = transactions ) a (select val KSPPSTVL from sys x$ksppi nam sys x$ksppsv val where nam indx = val indx AND nam ksppinm = _log_private_paralleli *** _mul ) b;TRUNC(VALUE*KSPPSTVL/ )* * g:HELLODBA select * from V$sgastat where name like %strand% ;POOL NAME BYTES shared pool private strands HELLODBA select trunc(value * KSPPSTVL / ) * ( + ) * from (select value from v$parameter where name = transactions ) a (select val KSPPSTVL from sys x$ksppi nam sys x$ksppsv val where nam indx = val indx AND nam ksppinm = _log_private_paralleli *** _mul ) b;TRUNC(VALUE*KSPPSTVL/ )*( + )*
Private strand的數(shù)量受到 個方面的影響 logfile的大小和活躍事務數(shù)量
參數(shù)_log_private_mul指定了使用多少logfile空間預分配給Private strand 默認為 我們可以根據(jù)當前l(fā)ogfile的大小(要除去預分配給log buffer的空間)計算出這一約束條件下能夠預分配多少個Private strand
HELLODBA select bytes from v$log where status = CURRENT ;BYTES HELLODBA select trunc(((select bytes from v$log where status = CURRENT ) (select to_number(value) from v$parameter where name = log_buffer ))* (select to_number(val KSPPSTVL) from sys x$ksppi nam sys x$ksppsv val where nam indx = val indx AND nam ksppinm = _log_private_mul ) / / ) as calculated private strands from dual;calculated private strands HELLODBA select count( ) actual private strands from x$kcrfstrand where last_buf_kcrfa = ;actual private strands
當logfile切換后(和checkpoint一樣 切換之前必須要將所有Private strand的內容flush到logfile中 因此我們在alert log中可能會發(fā)現(xiàn)日志切換信息之前會有這樣的信息 Private strand flush not plete 這是可以被忽略的) 會重新根據(jù)切換后的logfile的大小計算對Private strand的限制
HELLODBA alter system switch logfile;System altered HELLODBA select bytes from v$log where status = CURRENT ;BYTES HELLODBA select trunc(((select bytes from v$log where status = CURRENT ) (select to_number(value) from v$parameter where name = log_buffer ))* (select to_number(val KSPPSTVL) from sys x$ksppi nam sys x$ksppsv val where nam indx = val indx AND nam ksppinm = _log_private_mul ) / / ) as calculated private strands from dual;calculated private strands HELLODBA select count( ) actual private strands from x$kcrfstrand where last_buf_kcrfa = ;actual private strands
參數(shù)_log_private_paralleli *** _mul用于推算活躍事務數(shù)量在最大事務數(shù)量中的百分比 默認為 Private strand的數(shù)量不能大于活躍事務的數(shù)量
HELLODBA show parameter transactionsNAME TYPE VALUE transactions integer transactions_per_rollback_segment integer HELLODBA select trunc((select to_number(value) from v$parameter where name = transactions ) * (select to_number(val KSPPSTVL) from sys x$ksppi nam sys x$ksppsv val where nam indx = val indx AND nam ksppinm = _log_private_paralleli *** _mul ) / ) as calculated private strands from dual;calculated private strands HELLODBA select count( ) actual private strands from x$kcrfstrand where last_buf_kcrfa = ;actual private strands
注 在預分配Private strand時 會選擇上述 個條件限制下最小一個數(shù)量 但相應的shared pool的內存分配和redo allocation latch的數(shù)量是按照活躍事務數(shù)預分配的
lishixinzhi/Article/program/Oracle/201311/17848
如何配置Oracle并行處理
Oracle試圖自動化系統(tǒng)配置來使并行操作的性能最大化。然而，仍然有許多手工調整的空間，我們可以調整數(shù)據(jù)庫，優(yōu)化SQL并行性能。
判斷并行度
合適的并行度DOP對于良好的并行性能很關鍵。Oracle會按如下方式設定DOP：
1、如果指定或請求了并行執(zhí)行，但是沒有指定DOP，默認DOP會設置為該系統(tǒng)上CPU內核數(shù)量的兩倍。對于RAC系統(tǒng)，DOP值會是整個集群內核數(shù)量的兩倍。默認值是由配置參數(shù)“PARALLEL_ THREADS_PER_CPU”控制的。
2、對于Oracle 11g R2之后的版本，如果“ PARALLEL_DEGREE_POLICY”被設置為“AUTO”，Oracle將根據(jù)被執(zhí)行的運行性質和涉及對象的大小自動調整DOP值。
3、如果“PARALLEL_ADAPTIVE_MULTI_USER”被設置為“TRUE”，Oracle將基于該系統(tǒng)的整個負載調整DOP。當系統(tǒng)承受更重的負載時，DOP值將會減少。
4、在Oracle 11g或者更高版本中，如果“PARALLEL_IO_CAP ”被設置為TRUE，Oracle將把DOP限制為IO子系統(tǒng)可以支持的值。這些IO子系統(tǒng)限制可以通過“DBMS_RESOURCE_ MANAGER.CALIBRATE_IO”存儲過程計算。
5、DOP可以被指定到表或者索引一級，可以通過在“CREATE TABLE”，“CREATE INDEX”，“ALTER TABLE”或者“ALTER INDEX”中使用“PARALLEL ”從句來實現(xiàn)。
6、“PARALLEL ”關鍵字可以被用來指定某個查詢中指定表的DOP。
7、不管任何其它設置，DOP不能超過“PARALLEL_MAX_SERVERS”可以支持的數(shù)量。對于大部分SQL語句，服務器數(shù)量需要是請求DOP的兩倍。
正如我們可以看到的，超過優(yōu)化點增減DOP會導致進一步性能提升的失敗。然而，超過最佳優(yōu)化限制強行增加DOP值會對整個系統(tǒng)性能帶來重大的負面影響。盡管被并行化的SQL可能不會隨著DOP的增加而降低，但是該系統(tǒng)的負載會持續(xù)增加，而且會引起其它并發(fā)運行的SQL要遭受響應時間降低的影響。
當我們達到最優(yōu)DOP點時(該系統(tǒng)中的值大約是8)，查詢時間的減少變的平緩了。然而，其它會話在等待CPU可用上花費的時間會持續(xù)增長。其它等待訪問CPU的會話將需要繼續(xù)等待，這會導致響應時間變慢。
oracle 并行怎么寫
并行概念
并行執(zhí)行（parallel execution）是Oracle企業(yè)版才有的特性（標準版中沒有這個特性），指能夠將一個大型串行任務（任何DML，或者一般的DDL）物理地劃分為多個較小的部分，這些較小的部分可以同時得到處理。
并行包括：
并行查詢：這是指能使用多個操作系統(tǒng)進程或線程來執(zhí)行一個查詢。Oracle會發(fā)現(xiàn)能并行執(zhí)行的操作（如全表掃描或大規(guī)模排序），并創(chuàng)建一個查詢計劃來實現(xiàn)）。
并行DML（PDML）：這在本質上與并行查詢很相似，但是PDML主要是使用并行處理來執(zhí)行修改（INSERT、UPDATE、DELETE和MERGE）。
并行DDL：并行DDL是指Oracle能并行地執(zhí)行大規(guī)模的DDL操作。例如，索引重建、創(chuàng)建一個新索引、數(shù)據(jù)加載以及大表的重組等都可以使用并行處理。
并行恢復：這是指數(shù)據(jù)庫能并行地執(zhí)行實例（甚至介質）恢復，以減少從故障恢復所需的時間。
過程并行化：這是指能并行地運行所開發(fā)的代碼。
何時使用并行
在應用并行執(zhí)行之前，需要保證以下兩點成立：
必須有一個非常大的任務，如對50GB數(shù)據(jù)進行全面掃描。
必須有足夠的可用資源（CPU、I/O、內存）。在并行全面掃描50GB數(shù)據(jù)之前，你要確保有足夠的空閑CPU（以容納并行進程），還要有足夠的I/O通道。
如果只有一個小任務（通常OLTP系統(tǒng)中執(zhí)行的查詢就是這種典型的小任務），或者你的可用資源不足（這也是OLTP系統(tǒng)中很典型的情況），其中CPU和I/O資源通常已經(jīng)得到最大限度的使用，那就根本不用考慮并行執(zhí)行。
如果一個任務只需要幾秒（或更短時間）就能串行地完成，引入并行執(zhí)行后，相關的管理開銷可能會讓整個過程花費更長的時間。
舉例如，寫一頁文檔若12個人來寫，需要開會分段等，可能并不如一個人來寫更快。而如果寫1200頁，12個人寫需要的時間只為原來的1/12，就算分配任務可能也就1/12，還是比一個人寫要快多了。
并行查詢
并行查詢允許將一個SQL SELECT語句劃分為多個較小的查詢，每個部分的查詢并發(fā)地運行，然后會將各個部分的結果組合起來，提供最終的答案。
在并行進程和掃描文件之間并不存在1對1映射，可以多個進程掃描同一個文件。
各個并行進程可稱為并行執(zhí)行服務器（parallel execution server），有時也稱為并行查詢（parallel
query，PQ）從屬進程。各個并行執(zhí)行服務器都是單獨的會話，就像是專業(yè)服務器進程一樣連接數(shù)據(jù)庫。每個并行執(zhí)行服務器分別負責掃描表中一個部分（各
個部分都不重疊），匯總其結果子集，將其輸出發(fā)回給協(xié)調服務器（即原始會話的服務器進程），它再將這些子結果匯總為最終答案。
在默認情況下，Oracle是不啟用并行查詢的。啟用并行查詢有多種方法，可以直接在查詢中使用一個提示，或者修改表要求考慮并行執(zhí)行路徑等。
【并行查詢方法】
1）暗示hints式，臨時有效
select /*+parallel(table_name num)*/ count(*) from table_name;
多表關聯(lián)時多表并行：
select /*+parallel(table_name1,num1) parallel(table_name2,num2)*/ count(*) from table_name1, table_name2;
2）alter table對象式，長期有效
alter table table_name parallel num;
3）alter session會話式，會話生命周期有效
alter session force parallel query parallel num;
4）并行DDL式，會話生命周期有效
alter session enable parallel dml;
對于前兩種方式，若省略num則Oracle將自動根據(jù)負載確定并行度。并行度要隨著系統(tǒng)上工作負載的增減而變化。如果有充足的空閑資源，并行度會
上升；如果可用資源有限，并行度則會下降。這樣就不會為機器強加一個固定的并行度。利用這種方法，允許Oracle動態(tài)地增加或減少查詢所需的并發(fā)資源
量。
【查看默認并行數(shù)】
1）確定會話SID
select sid from v$mystat where rownum = 1;
2）在其他會話中查詢
select sid,qcsid,server#,degree from v$px_session where qcsid = num;
一般而言，如果能訪問盡可能多的資源（CPU、內存和I/O），并行執(zhí)行就能最好地發(fā)揮作用。但這并不是說如果整個數(shù)據(jù)集都在一個磁盤上，就從并行
查詢得不到任何好處。不過如果整個數(shù)據(jù)集都在一個磁盤上，可能確實不如使用多個磁盤那樣能有更多收獲。即使使用一個磁盤，在響應時間上也可能可以得到一定
的速度提升。原因在于：給定的一個并行執(zhí)行服務器在統(tǒng)計行時并不讀取這些行，反之亦然。所以，與執(zhí)行串行相比，兩個并行執(zhí)行服務器可以在更短的時間內完成
所有行的統(tǒng)計。
數(shù)據(jù)分布在多個物理設備上可以提高I/O，如表分區(qū)、跨磁盤等。
在Oracle 11g Release2及以上版本中，引入了一項新功能來限制資源過度使用：并行語句排除（Parallel
Statement
Queuing,PSQ）。使用PSQ時，數(shù)據(jù)庫會限制并發(fā)執(zhí)行的并行查詢數(shù)，并把更多的并行請求放在一個執(zhí)行隊列中。CPU資源用盡時數(shù)據(jù)庫會阻止新的
請求變?yōu)榛顒訝顟B(tài)。這些請求并沒有失敗，它們只是會延遲開始，也就是說它們將排隊。資源可用時，數(shù)據(jù)庫就會開始執(zhí)行隊列中的查詢。
并行DML
Oracle文檔將并行DML（PDML）一詞的范圍限制為只包括INSERT、UPDATE、DELETE和MERGE（不像平常的DML那樣還
包括SELECT）。在PDML期間，Oracle可以使用多個并行執(zhí)行服務器來執(zhí)行INSERT、UPDATE、DELETE或MERGE，而不是只利
用一個串行進程。在一個有充足I/O帶寬的多CPU主機上，對于大規(guī)模的DML操作，可能會得到很大的速度提升。
不過，不能把PDML當成提高OLTP應用速度的一個特性。因為并行操作設計為要充分、完全地利用一臺機器上的所有資源。通過這種設計，一個用戶可
以完全使用機器上的所有磁盤、CPU和內存。在某些數(shù)據(jù)倉庫中（有大量數(shù)據(jù)，而用戶很少），這可能正是你想要的。而在一個OLTP系統(tǒng)中（大量用戶都在做
很短、很快的事務），可能就不能希望如此了，你不想讓用戶能夠完全占用機器資源。
類似于Oracle執(zhí)行的分布式查詢，PDML操作采用同樣的方式執(zhí)行，即每個并行執(zhí)行服務器相當于一個單獨數(shù)據(jù)庫實例中的一個進程。這些事務都結束后，會執(zhí)行一個相當于快速2PC的過程來提交這些單獨的獨立事務。這些事務要么都由PDML協(xié)調會話提交，要么無一提交。
由于PDML采用的一種偽分布式的實現(xiàn)，因此存在一些限制：
PDML操作期間不支持觸發(fā)器。這是一個很合理的限制，因為觸發(fā)器可能會向更新增加大量開銷，而你使用PDML的本來目的是為了更快一些，這兩方面是矛盾的，不能放在一起。
PDML期間，不支持某些聲明方式的引用完整性約束，因為表中的每一片（部分）會在單獨的會話中作為單獨的事務進行修改。例如，PDML操作不支持自引用完整性。如果真的支持自引用完整性，可能會出現(xiàn)死鎖和其他鎖定問題。
在提交或回滾之前，不能訪問用PDML修改的表。
PDML不支持高級復制（因為復制特性的實現(xiàn)要基于觸發(fā)器）。
不支持延遲約束（也就是說，采用延遲模式的約束）。
如果表是分區(qū)的，PDML只可能在有位圖索引或LOB列的表上執(zhí)行，而且并行度取決于分區(qū)數(shù)。在這種情況下，無法在分區(qū)內并行執(zhí)行一個操作，因為每個分區(qū)只有一個并行執(zhí)行服務器來處理。
執(zhí)行PDML時不支持分布式事務。
PDML不支持聚簇表。
并行DDL
從維護的觀點看，以及從管理的角度來說，并行DDL才是Oracle中并行執(zhí)行最突出的優(yōu)點。如果認為并行查詢主要是為最終用戶設計的，那么并行
DDL則是為DBA/開發(fā)人員設計的。如果沒有并行執(zhí)行，DBA將很難真正充分利用硬件的全部能力。但如果利用并行執(zhí)行，則完全可以做到。以下SQL
DDL命令允許“并行化”：
CREATE INDEX：多個并行執(zhí)行服務器可以掃描表、對數(shù)據(jù)排序，并把有序的段寫出到索引結構。
CREATE TABLE AS SELECT：執(zhí)行SELECT的查詢可以使用并行查詢來執(zhí)行，表加載本身可以并行完成。
ALTER INDEX REBUILD：索引結構可以并行重建。
ALTER TABLE MOVE：表可以并行移動。
ALTER TABLE SPLIT|COALESCE PARTITION：單個表分區(qū)可以并行地分解或合并。
ALTER INDEX SPLIT PARTITION：索引分區(qū)可以并行地分解。
前4個命令還適用于單個的表/索引分區(qū)，也就是說，可以并行地MOVE一個表的單個分區(qū)。
并行DDL和使用外部表的數(shù)據(jù)加載
利用并行DDL，再加上外部表，就能通過一個簡單的CREATE TABLE AS SELECT or INSERT /*+ APPEND
*/來實現(xiàn)并行直接路徑加載。不用再編寫腳本，不必再分解文件，也不用協(xié)調要運行的N個腳本。簡單地說，通過結合并行DDL和外部表，不僅提供了純粹的易
用性，而且全無性能損失。
并行DDL和區(qū)段截斷
并行DDL依賴于直接路徑操作。也就是說，數(shù)據(jù)不傳遞到緩沖區(qū)緩存以便以后寫出；而是由一個操作（如CREATE TABLE AS
SELECT）來創(chuàng)建新的區(qū)段，并直接寫入這些區(qū)段，數(shù)據(jù)直接從查詢寫到磁盤（放在這些新分配的區(qū)段中）。每個并行執(zhí)行服務器執(zhí)行自己的部分CREATE
TABLE AS SELECT工作，并且都會寫至自己的區(qū)段。INSERT /*+ APPEND
*/（直接路徑插入）會在一個段的HWM“之上“寫，每個并行執(zhí)行服務器再寫至其自己的一組區(qū)段，而不會與其他并行執(zhí)行服務器共享。因此，如果執(zhí)行一個并
行CREATE TABLE AS
SELECT，并使用4個并行執(zhí)行服務器來創(chuàng)建表，就至少有4個分區(qū)，可能還會更多。每個并行執(zhí)行服務器會分配其自己的區(qū)段，向其寫入，等填滿時，再分配
另一個新的區(qū)段，并行執(zhí)行服務器不會使用由其他并行執(zhí)行服務器非品牌的區(qū)段。
在數(shù)據(jù)倉庫環(huán)境中，執(zhí)行一個大規(guī)模的加載之后，這可能導致“過渡浪費“。假設你想加載1,010MB的數(shù)據(jù)（大約1GB），而且正在使用一個有
100MB區(qū)段的表空間，你決定使用10個并行執(zhí)行服務器來加載這個數(shù)據(jù)。每個并行執(zhí)行服務器先分配其自己的100MB區(qū)段（總共會有10個100MB的
區(qū)段），并在其中填入數(shù)據(jù)。由于每個并行執(zhí)行服務器都要加載101MB的數(shù)據(jù)，所以它會填滿第一個區(qū)段，然后再繼續(xù)分配另一個100MB的區(qū)段，但實際上
只會使用這個區(qū)段中1MB的空間。現(xiàn)在就有了20區(qū)段，其中10個是滿的，另外10個則不同，這10個區(qū)段中都各有1MB的數(shù)據(jù)，因此，總共會有
990MB的空間是”已分配但未使用的“。下一次加載是可以使用這個空間，但是對現(xiàn)在來說，你就有了990MB的死空間。此時區(qū)段截斷（extend
trimming）就能派上用場了。Oracle會試圖取每個并行執(zhí)行服務器的最后一個區(qū)段，并將其”截斷為“可能的最小大小。
區(qū)段截斷和字典管理表空間
如果使用傳統(tǒng)的字典管理表空間，Oracle可以把只包含1MB數(shù)據(jù)的各個100MB區(qū)段轉變或1MB的區(qū)段。遺憾的是，（在字典管理的表空間中）
這會留下10個不連續(xù)的99MB空閑區(qū)段，因為你的分配機制采用的是100MB區(qū)段，所以這990MB空間就會用不上！下一次分配100MB時，往往無法
使用現(xiàn)有的這些空間，因為現(xiàn)在的情況是：有99MB的空閑空間，接下來是1MB的已分配空間，然后又是99MB空閑空間，依此類推。
區(qū)段截斷和本地管理表空間
本地管理表空間有兩種類型：UNIFORM SIZE 和AUTOALLOCATE，UNIFORM
SIZE是指表空間中的每個區(qū)段大小總是完全相同；AUTOALLOCATE則表示Oracle會使用一種內部算法來確定每個區(qū)段應該是多大。這些方法都
能很好地解決上述問題，不過，這兩種方法的解決策略截然不同。
在字典管理的表空間中，如果請求一個100MB區(qū)段，倘若Oracle只找到了99MB的自由區(qū)段，請求還是會失敗。與字典管理表空間不同，有AUTOALLOCATE區(qū)段的本地管理表空間可以更為靈活。為了試圖使用所有空閑空間，它可以減小所請求的空間大小。
隨著使用并行直接路徑操作向表UNIFORM_TEST加載越來越多的數(shù)據(jù)，過一段時間后，空間利用情況會變得越來越糟糕。對此，我們可能希望使用
一個更小的統(tǒng)一區(qū)段大小，或者使用AUTOALLOCATE。一段時間后，AUTOALLOCATE也可能生成更多的區(qū)段，但是由于會發(fā)生區(qū)段截斷，所以
空間利用情況要好得多。
文章名稱：oracle如何開并行 oracle存儲過程并行
當前鏈接：http://www.ef60e0e.cn/article/hphedo.html
