一步一步學Streams(5) 第一部分 基礎之傳播程式(下)

５、ANYDATA佇列和使用者訊息

　　Streams 中ANYDATA佇列中可以存放不同型別的使用者訊息，以ANYDATA做為載體，應用就可以將不同型別的訊息放到一個佇列裡，應用也可以將其出隊(或訊息客戶端/使用者應用/apply程式)。

　　Streams 包括高階佇列(Advanced Queuing)的特性，支援訊息佇列的所有標準特性，包括queues, publish and subscribe, content-based routing, internet propagation, transformations, and gateways to other messaging subsystems。

　　使用靜態函式Convert data_type幾乎可以將所有型別都打包為ANYDATA，

６、快取訊息(Buffered Messaging)和Streams客戶端

　　快取訊息支援使用者從buffered queue中入隊和出隊訊息。傳播程式能夠在buffered queue中傳送快取訊息。使用快取訊息替換磁碟中的佇列表能夠提高效能。

　　下面簡要描述一下快取訊息與streams客戶端之間的互動：

• 與capture程式：被capture程式捕獲入隊的快取訊息只能被apply程式出隊。
• 與propagation程式：只要符合其傳播規則，propagagion程式能夠傳播源佇列中所有訊息。這些訊息即可儲存於buffered queue，也可以儲存於queue table。
• 與apply程式：apply程式能夠出隊並應用buffered queue中的訊息。要出隊buffered queue中被capture程式入隊的訊息，apply程式必須配置apply_captured引數值為true。要出隊buffered queue中被使用者應用入隊的訊息，apply程式必須配置apply_captured引數值為false。
• 與訊息客戶端：不被支援。

７、佇列與RAC

　　Streams 同樣支援RAC環境的資料庫。不過注意RAC環境中一個buffered queue只能在一個例項中，這是因為buffered queue是與系統sga相關聯的。

　　Streams 程式和job支援主例項和次例項對queue tables做描述，如果你應用這種描述，則當主例項不可用時，次例項可暫時接管這部分queue tables，直到主例項恢復服務，你可以通過DBMS_AQ_ADM.ALTER_QUEUE_TABLE過程指定主例項和次例項。

　　Capture 程式和apply程式在佇列屬主例項上啟動，propagation程式稍有不同，如果佇列屬主例項不可用，則其屬主自動轉換到叢集中的其它例項上。佇列到佇列的傳播會自動連線目標佇列的屬主例項。

　　佇列到dblink的傳播不會使用服務，因此為保證傳播任務連線到正確的例項，需要手工配置源資料庫到目標資料庫的資料庫鏈。

８、Commit-Time佇列

　　你可以控制User-Enqueued Messages在佇列中瀏覽和出隊的順序。訊息在佇列中的順序基於其佇列表，因此你可以在建立佇列表時為訊息指定好順序。實際上，佇列中的順序是由DBMS_AQADM.CREATE_QUEUE_TABLE過程的sort_list引數控制的。10gR2引入了一種commit-time佇列。Commit-time佇列中的訊息按照scn排序。

　　Commit-time 的順序是為佇列表指定的，使用這種佇列表的佇列就被稱為：commit-time佇列，如果DBMS_AQADM.CREATE_QUEUE_TABLE過程的sort_list引數指定為comiit_time，則佇列表使用commit-time順序。對於10gR2，DBMS_STREAMS_ADM.SET_UP_QUEUE的sort_list引數預設值就是commit_time，之前版本預設值為enq_time。

９、Streams分段與傳播架構

　　本節描述buffered queues,propagation jobs和secure queues，以及它們在Streams中如何工作。另外，本節還將描述transactional queues如何處理捕獲訊息和User-Enqueued Messages，以及傳播捕獲訊息所需的Streams資料字典的內容。

A 、Streams pool

　　Streams pool 也是SGA中的一部分。用來存放Buffered queue訊息以及capture程式/apply程式所需的記憶體。一般streams pool初始化會在下列幾種操作發生時：

• 訊息入隊。Data Pump export/import。
• Capture 程式啟動
• Apply 程式啟動

　　Streams pool 的大小有以下幾種設定方式(注意順序，如此排列也是有道理的)：

• BY SGA_TARGET ：指設定SGA_TARGET初始化引數為非0值，這樣系統會根據需要自動調整SGA記憶體區的分配。
• BY USER ：指設定STREAMS_POOL_SIZE初始化引數為非0值(SGA_TARGET值為0)，這樣ORACLE啟動時就會分配你指定的大小給Streams pool。提示：建議不小於200M。
• BY DEFAULT ：如果SGA_TARGET和STREAMS_POOL_SIZE兩引數值均為0，則streams在初始化時會自動從buffer cache中擷取10%的記憶體為Streams_pool_size引數的值。

提示：如果Streams pool未初始化，則觸發ORA-00832錯誤，要解決此類問題，首先要確保SGA中有足夠的空閒記憶體，如果必要，重新設定SGA_MAX_SIZE初始化引數增加SGA大小，然後修改SGA_TARGET或STREAMS_POOL_SIZE初始化引數的值。

B 、Buffered queues

　　一個Buffered queue可能分成多個部分存在於Streams pool和磁碟。如果Streams pool size不是自動管理的話，建議至少為每個bufferd queue增加10m記憶體給Streams pool。Buffered queue能夠提高效能，不過如果包含buffered queue資訊的例項shutdown normal/abort的話，這部分資料就會丟失，例項恢復後，Streams會自動修復。

　　Buffered queue 中的訊息如果在一定時間內未出隊或無足夠記憶體空間存的話，就有可能被分隔成多份存入佇列表，從記憶體中分隔出來的訊息會儲存在AQ$_佇列名稱_p表中，至於這些訊息對應哪些propagation/apply程式的資訊，則儲存於AQ$_佇列名稱_d表中。

　　捕獲訊息總會存入buffered queue，不過user-enqueued LCR/non-LCR messages則可能不會存入buffered queue。對於user-enqueued message，入隊時操作指定訊息是存入buffered queue還是存入persistent queue。Persistent queue只會將訊息儲存在硬碟上。訊息究竟是儲存於buffered queue還是persitent queue要看BMS_AQ.ENOUEUE過程的enqueue_options引數的屬性delivery_mode的值，如果delivery_mode的值是PERSISTENT，則訊息存入persistent queue，如果該值是BUFFERED，則訊息存入buffered queue。

C 、Propagation Jobs

　　傳播任務內部還是使用DBMS_JOB來配置，因此這部分沒啥說的，大家應該都挺熟，下面說一下會建立傳播任務的幾個過程：

• DBMS_STREAMS_ADM . ADD_GLOBAL_PROPAGATION_RULES
• DBMS_STREAMS_ADM . ADD_SCHEMA_PROPAGATION_RULES
• DBMS_STREAMS_ADM . ADD_TABLE_PROPAGATION_RULES
• DBMS_STREAMS_ADM . ADD_SUBSET_PROPAGATION_RULE
• DBMS_PROPAGATION_ADM . CREATE_PROPAGATION

1).Propagation scheduling and Streams Propagations

　　傳播排程(Propagation scheduling)指定傳播任務傳播訊息的頻率。第一個queue-to-queue的傳播都會擁有各自的排程，不過queue-to-dblink的傳播共用同一個排程。

　　預設情況下排程有下列屬性：

• 開始時間為：sysdate
• Duration 為空，表示無限
• Next time 為空，表示上次傳播結束後，新傳播馬上開始
• Latency 為3秒，指queue清空後等待重新提交的最大等待時間。

2).Propagation job and RESTRICTED SESSION

　　當通過startup restrict語句進入受限模式連線時，傳播任務不會執行傳播，直到restricted session被disable。

　　當通過alter system enable restricted session語句進入受限模式連線時，正在執行的傳播任務會繼續執行直接到結束，不過新的傳播任務不會再啟動，直到restricted session被disable。

D 、Transactional and Nontransactional Queues

　　Transactional queue 就是user-enqueued messages分組打包到一個集合佇列被一個事務應用，apply程式是在應用User-Enqueued Messages組之後才提交。DBMS_STREAMS_ADM.SET_UP_QUEUE過程總會建立transactional queue。

　　Nontransactional queue 是指每個User-Enqueued Messages擁有不同的事務，apply程式應用完任意一個User-Enqueued Message後即執行提交。

　　基本上對於User-Enqueued Messages，Transactional/Nontransactional queue之間不同才顯的較為重要，因為apply程式應用捕獲訊息時都會是在事務模式(即以源庫執行的方式)下執行。

E 、Streams Data Dictionary for Propagations

　　源端資料庫的資料庫物件準備初始化的時候，Streams資料字典就會自動記錄資料庫中capture程式捕獲的修改。Streams資料字典實際上是源端資料庫主資料字典某些資訊的多版本複製，Streams資料字典對映源端物件編碼，物件的版本資訊以及內部列號為表名，列名和列型別，通過這種方式來保持捕獲訊息的最小化(因為數字通常比名字要小)。

　　為確保對映資訊可用於傳播，源庫中的streams資料字典對映資訊需要目標庫的評估規則，Oracle自動在需要複製的資料庫中維護多版本streams 資料字典。

　　Streams 資料字典資訊包括的佇列中的內部訊息可能不會被傳播，是否被傳播還是依賴於傳播的規則集。比如說當傳播碰到Streams資料字典資訊包含的表時，傳播規則先會評估部分資訊包括源庫名，表名以及表屬主等資訊，如果部分規則評估檢查通過，則這個表的資料字典資訊就會被複制。

　　當streams資料字典資訊複製到目標佇列，這部分就會成為streams資料字典資訊的一部分，做為附加值入隊到目標佇列。因此，傳播讀到目標佇列在directed networks配置環境中能夠直接傳送LCRs而不需要等待Streams資料字典，通過這種方式，源庫streams資料字典總能 正確 反映其關聯的資料庫物件的狀態 。

======================================

一步一步學Streams(4) 第一部分 基礎之傳播程式(上)

一步一步學Streams(3) 第一部分 基礎之捕獲程式

一步一步學Streams(2) 第一部分 架設一個單表複製環境

一步一步學Streams(1) 第一部分 基礎之概述篇

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