Oracle高階複製

本文轉自：原文

在開始之前，需要簡單說明一下，目前公司有幾個專案都採用Oracle作為資料庫平臺，並且有的專案使用到了Oracle的資料庫複製技術，其中也遇到了一些問題，因此在這裡，我對Oracle的複製技術談一下我個人的理解，希望能夠對採用Oracle資料庫的專案組有所幫助。其中在文中使用到的 SQL指令碼都是經過檢驗可以執行的。
　　首先簡單介紹和資料庫複製有關的基本概念，然後探討Oracle資料複製技術中的幾個重要模型，最後介紹Oracle的資料複製管理器以及如何利用它來配置和維護複製環境。
　　在文章的開頭，我想首先簡單談一下複製的基本概念，也就是什麼是複製？複製簡單地說就是在由兩個或者多個資料庫系統構成的一個分散式資料庫環境中拷貝資料的過程。Oracle高階複製，也稱為對稱複製，第一次是在Oracle 7.1.6版本中出現的，在這之前的Oracle版本中，Oracle資料複製方法僅有隻讀快照形式的基本複製一種方法。隨著Oracle版本的每一次升級，資料複製的功能、管理以及速度等方面都得到了很大的改進和完善。目前，由於對分散式資料環境需求的不斷增長，越來越多的應用提出了資料複製的需求。
1.基本概念
1. 分散式資料庫技術
分散式資料庫技術是目前我們經常提及的分散式計算的一個重要組成部分，該技術允許資料在多個伺服器端共享。採用分散式資料庫技術，一個本地伺服器可以存取不同物理地點的遠端伺服器上的資料；也可以使所有的伺服器均可以持有資料的拷貝/複製，這樣分散式系統中的所有伺服器均可進行本地存取。
設計一個分散式計算解決方案首先需要考慮的問題就是應用的完整性、複雜性、效能和可用性以及響應時間等，同時還需要考慮的是對於不同的應用需求是採用實時存取遠端資料還是採用延遲存取遠端資料。這對於資料複製來講就是採取實時更新複製方案還是延遲資料複製方案。
2. 同步和非同步的概念
同步分發資料庫技術是一種實時遠端存取和實時更新資料的技術。這種技術可以保證應用的完整性降低了應用的複雜性，但是如果系統存在網路存取速度很慢這樣的問題，相應響應時間就會很慢。
非同步分發資料庫技術是一種延遲遠端存取和延遲傳播對資料更新的技術。這種技術具有很高的可用性和很短的響應時間。相比同步分發資料庫技術就顯得複雜一些，為了確保應用的完整性需要仔細考慮和設計。
對於實際的商業問題，必須權衡這兩種技術的利弊最終選擇最佳的解決方案，有些問題選用同步技術比較適合，也有一些問題採用非同步技術是比較好的解決方案，還有一些問題必須綜合這兩種技術。
3. 複製的概念
複製，顧名思義就是將資料庫中的資料拷貝到不同物理地點的資料庫中以支援分散式應用，它是整個分散式計算解決方案的一個重要組成部分。上面介紹了同步和非同步的概念，這裡針對複製也存在同步複製和非同步複製的問題。
同步複製，複製資料在任何時間在任何複製節點均保持一致。如果複製環境中的任何一個節點的複製資料發生了更新操作，這種變化會立刻反映到其他所有的複製節點。這種技術適用於那些對於實時性要求較高的商業應用中。
非同步複製，所有複製節點的資料在一定時間內是不同步的。如果複製環境中的其中的一個節點的複製資料發生了更新操作，這種改變將在不同的事務中被傳播和應用到其他所有複製節點。這些不同的事務間可以間隔幾秒，幾分種，幾小時，也可以是幾天之後。複製節點之間的資料臨時是不同步的，但傳播最終將保證所有複製節點間的資料一致。
4. 更新衝突
在非同步複製環境中，對於所有應用最關鍵的就是要確保資料的一致性。我們來看下面這種情況會有什麼後果發生呢？在同一時間對同一個表的同一行資料的同一列在兩個不同的地點作更新。這種情況就會發生稱之為更新衝突的錯誤。為保證資料的一致性，更新衝突必須被檢測到並且處理以確保在不同地點的資料元素保持同樣的值。更新衝突可以通過限制"所有權" 到單一節點或者將更新某個特定資料元素的權利限制到某一具體節點的方法來避免。
2.Oracle資料複製應用模型
為確保實際應用資料的一致性，必須在非同步複製應用模型中考慮衝突避免或者衝突檢測和消除的方法。例如，對於一個實際商業應用，首先必須在邏輯上了解該商業應用採取的衝突避免方法和在某個節點有那些資料以及這些資料中那些是可更新的，而那些又是不可更新的。在下面的這一部分中，我們首先將詳細討論兩種常用的衝突避免方法：主站點所有權模型和動態所有權模型。然後，討論共享所有權模型以及這種模型引起的衝突檢測和處理問題，最後，討論針對Fail-over的複製配置，這種複製方案同時考慮了衝突避免和衝突檢測與消除兩種情況。
1. 主站點所有權
主站點所有權，非同步複製資料被一個單一節點"所有"，這些要複製的資料僅能被該節點更新，其他節點向擁有該資料的主節點訂閱（subscribe）資料，這意味著他們在本地系統上只能夠存取這些複製資料的只讀拷貝。下面是一些這樣的例子。
（1） 決策支援系統（DSS）的聯機事務處理資料的解除安裝。來自一個或者多個OLTP系統的資料可以被解除安裝到一個獨立的區域性DSS中，用於只讀分析
（2） 中央資訊的分發。產品資訊，如價格列表等在總部節點上維護，然後將這些資訊複製到遠端銷售辦事處的只讀產品目錄系統中
（3） 遠端資訊的集中。許多遠端節點上的產品目錄資料複製到總部節點，這裡總部節點只需要有資料只讀的許可權
一個主節點擁有一個表的完全所有權，而其他節點只能訂閱這個表的只讀拷貝。也可以是多個主節點擁有同一個表的截然不同子集或者劃分，而另一些節點則訂閱這些子集或者劃分的只讀拷貝。如，一個分佈的產品目錄系統可以讓不同的銷售辦事處擁有一個表的屬於自己的一個"水平"部分，如在客戶（CUSTOMERS）表, 訂單（ORDERS）表和目錄（ITEMS）這些表中含有每個銷售辦事處為之服務的客戶和產品資訊。中心總部節點可以通過訂閱每個辦事處擁有的資料來保持一個完整的所有產品和客戶資訊的只讀拷貝。
2. 動態所有權
動態所有權，非同步更新將複製資料從一個節點移到另一個節點，而在該過程中，必須保證在同一時刻只有一個特定的節點可以對資料進行更新。一個典型實際應用就是"海關訂單處理系統"，訂單處理的典型步驟是，報關→同意→裝運→開單→收單→入帳等。應用模型可以執行其中的任何步驟，但必須保證各個不同模組的同一個資料應該在一個綜合資料庫中。在該系統中，當且僅當訂單的狀態表明前一個步驟已經完成時，下一個應用模組才可以執行更新訂單資料的操作。例如，"裝運" 應用模組僅能在"報關"並且得到"同意"後才能被執行。 (Delphi中的DEMO程式中提供了一個簡化版本演示程式)
通過使用動態所有權複製模型，可以將一個系統分佈在多個節點和資料庫上，也就是說應用模型可以建立在不同的系統上。我們還是來看上面的例子，"報關"和" 批准"這兩部分可以執行在一個系統上，"裝運"在另一個系統上，"開單"和"收單"等又可在一個系統上。在這個分散式系統中，資料可以被複制到不同的節點上，這些節點對複製的資料只要具有隻讀的許可權即可。如，利用複製，"報關"節點可以監視已經報關的訂單處理過程。
前面討論的主節點所有權和動態所有權複製模型具有一個共同的特徵：在任何一個給定的時間點，只允許一個節點有更新資料的權利，而其餘節點對於複製的資料拷貝僅有隻讀許可權。然而，還存在這樣的情況，允許多個節點可以更新同一個資料，在極端情況下可以是在同一時刻，這就是所說的共享所有權。
3. 共享所有權
共享所有權使用非同步複製，這對於主節點和動態所有權模型來講存在一些限制。在共享所有權情況下，整個系統可以存在暫時的不一致，同時必須使用衝突檢測和消除。共享所有權模型相對於前面兩種模型具有一些新的特點。

例如，對於前面我們討論的那個採用具有水平劃分主節點複製方案來的分散式"訂單處理系統"的例子。採用共享所有權模型，每個銷售辦事處都有庫表中不同的水平劃分，該庫表含有每一個辦事處為之服務的一些訂單資訊和與消費者有關的顧客資訊。每一個銷售辦事處只輸入與自己有關的顧客訂單情況，而不管其餘顧客資訊。
然而，在實際商業應用中，這個模型不是最佳的選擇。例如，這種情況，一個零售集團在一個大城市中可以有好幾個商場。顧客可能經常去離他們住的最近的那個商場，但是偶爾也可能到其他商場去購物。這時，如果多家商場執行更新同一個顧客和其訂單資料的資訊，更新衝突就會發生。所以在這種情況下必須要採用衝突檢測和消除方案。
Oracle高階複製支援同時既考慮衝突避免又考慮衝突檢測和消除的複製模型。Oracle高階複製之所以又稱為對稱複製，其原因之一就是支援對稱複製模型，也就是可以在任何地方更新，即所有的複製節點都可以進行更新處理。為了避免衝突，一種方法就是將應用設計為將更新限制在一些特定的節點。對於共享所有權，Oracle提供了自動衝突檢測和消除方案。
4. 備用資料庫（Fail-Over）
非同步複製通過將一個主系統資料複製到另一系統，可以起到對主系統的崩潰提供保護的作用，這也就是所說的Fail-Over系統，如果主系統出現問題，業務依舊可以通過複製資料庫進行。
Oracle高階複製支援這種Fail-Over配置。同時，Oracle也針對Fail-Over提供了另外兩個可選的解決方案：Oracle並行伺服器和備用資料庫配置。使用者可以根據吞吐量、可用性、事務損失的可能性和其他一些如資料一致性、方法的侷限性等參考指標來權衡選擇合適的Fail-Over 方案。
3.Oracle 高階複製配置
Oracle高階複製即可支援基於整個表的複製也可支援基於部分表的複製兩種複製方案。這兩種複製方案主要是通過Oracle的兩種複製機制來完成的，即多主複製和可更新快照複製，同時還可以將這兩種複製機制結合起來以滿足不斷變化的業務需求。
1. 多主複製
多主複製方案支援全表在各個主節點間的對稱複製，允許所有主節點對主表都有更新操作的權利。任何一個主節點上的複製表的更新都會被傳播並被直接應用到其他所有主表。一個主節點出現問題，不會對其他主節點之間變化的傳播造成影響。
多主複製採用一種稱為"延遲遠端過程呼叫（deferred remote procedure calls RPCs)"的機制作為主要的傳播和應用變化的機制。各節點之間變化的傳播，既可以以基於事件的方式立即傳播，也可以在某個特定的時間點，如在網路空閒時（如晚上）傳播。在傳播變化時，如果其中的一個遠端系統沒有準備好，傳播變化的延遲遠端過程呼叫（RPCs）就會儲存在其本地佇列中，等到系統準備好以後再執行。
2. 可更新快照
Oracle將最早Oracle 7上的只讀快照機制擴充套件為一種允許快照可更新的對稱複製機制。快照更新的傳播方式和如何應用到快照主節點採用了和多主複製一樣的延遲遠端過程呼叫機制。
對於快照的定義，既可以是包含一個主表的完全拷貝，也可以是為滿足基於值的選擇標準的主表中行的子集。快照在主節點的重新整理是按照一定的時間間隔或使用者單獨請求進行的。最後一次重新整理後主表的任何變化也同樣被傳播並應用到快照。多個快照的重新整理是在一個一致的事務中完成的，這就確保了資料和引用的完整性。
3. 混合配置
可以將多主複製和可更新快照複製結合在一起，構成一種新的混合配置，這種配置可以完成對全表或者子表的複製。例如下面這種應用就是一個典型的混合配置方案，一個系統具有兩個位於不同地理區域的中心節點，這兩個不同的地理區域下面還有一些分支機構，兩個中心節點可以彼此看做是自己的備份節點。採用多主複製方法在兩個中心站點之間複製資料，同時採用只讀或者可更新快照複製方法在每個區域範圍中的主節點之間複製全表或者子表。這種配置的一個顯著好處就是當其中的一箇中心節點發生問題時，這些快照的主節點可以被重新定義到另一個執行良好的中心節點，從而提高了系統的可靠性。
4. 其他複製機制
Oracle除了前面討論的三種複製機制以外，還提供了另外兩種複製機制：過程級複製和同步複製。
（1）過程級複製：這種複製方案主要應用在存在大量資料更新以及採取批處理方式運算元據時需要複製資料的情況。例如，下面這個應用，一個以年為單位管理客戶訂單的公司，對於老的訂單資料不再需要線上儲存，而需要解除安裝到某儲存介質中。這時，如果在多個節點間複製每一獨立的行級變化效率將是非常低的。對於這種情況，可以直接在每個複製節點執行一個過程來直接進行這種更新操作。Oracle高階複製提供的分散式模式管理功能（將在下面詳細討論）可以非常方便地在多個節點上設定和維護過程級複製的遠端過程。
（2） 同步複製：一個採用同步複製方案的表發生變化時，Oracle會確保這種變化能夠成功地作用在本地表和其他節點的複製表，如果失敗則整個事務會被成功回滾。同步複製在網路的穩定性比較高的情況下是可行的，可以保證複製節點之間的複製資料一直保持同步。
4.Oracle管理工具
很顯然，有效的管理工具對於成功的分散式應用是非常關鍵的，如果沒有能力去操作它，再專業的複製功能也不能發揮很好的作用。Oracle高階複製提供了幾個功能強大的管理工具，諸如複製目錄，分散式模式管理以及其他的一些Oracle 複製管理工具。
1. 複製目錄
複製目錄是一個包含定義複製環境原資料的一個單一綜合庫。複製目錄本身也被複制到多個節點以確保高可用性和授權使用者可以簡單地實現本地存取管理。
複製目錄定義了被複制的資料庫物件，複製的節點以及用於複製的機制。資料庫物件有需要複製的庫表和其他一些相關的物件，如索引，檢視，過程，觸發器和同義詞等等。這些原資料是開放的，使用者可以通過標準SQL語句進行檢索和查詢。
2. 分散式模式管理
Oracle高階複製的分散式模式管理功能允許在一個控制點就可進行復制環境的定義和改變。對複製環境的任何改變，都將自動複製並且應用這些資料定義語言（DDL）命令到其他複製環境節點，同時也利用資料庫觸發器和複製相關過程自動生成複製所需要的一些支援物件。
分散式模式管理在一個被稱為主定義節點的地方進行控制。它自動將DDL推向其他所有主節點並且也允許快照節點"拉"回並且執行這些DDL命令。由於主定義節點使用並且維護著整個複製目錄，該複製目錄本身也被複制到其他節點，所以該主定義節點一旦出現問題，就必須用其他節點來代替。分散式模式管理可以通過一個圖形使用者介面管理工具（GUI）來配置。
3. Oracle複製管理器
Oracle複製管理器是Oracle提供的一個圖形介面的複製管理工具，通過該工具可以配置，定時和通過一個節點來管理整個的複製環境。該管理工具可以單獨執行也可以在Oracle企業管理器中通過一個applet來啟用。
採用Oracle複製管理器，用於複製的物件組可以通過一些滑鼠操作非常簡單地定義。複製組可以包含表和其他相關的物件，如觸發器，儲存過程，索引，檢視，同義詞以及序列等。Oracle除了可以複製每個複製組的全部拷貝以外，還可以選擇複製資料的子集。複製組的配置可以在任何時候修改，這種變化將自動應用到其他所有的複製節點。
一旦定義了物件組，可以通過Oracle複製管理器，簡單進行拖拉操作，就可自動部署複製組到一個新的節點。這些快照節點既可以是隻讀的也可以是可更新的。複製節點配置完成以後，使用者可以配置定時以使複製環境中的變化傳播到其他節點，當然也可以選擇採用同步複製。
4. 選擇衝突解決方案
如果選擇採用一種可以在任何地方更新的複製方案，Oracle複製管理器提供了幾個內建的衝突解決方案，諸如"最近時間戳"和"站點優先"等來解決潛在的衝突。對於不同的表可以選擇不同的方法，甚至可以對一個表中的不同列選擇不同的衝突消除方案。使用者對於一些特殊的商業需求也可以建立自己的衝突解決方案。

5. 實時管理
通過Oracle的複製管理器，複製環境中任何地方發生的錯誤均可以非常快速和簡單地分離出來並且改正。通過一個單一的節點，使用者就可以看到每個節點的延遲事務佇列，也可以重新定時或者強制立即執行事務。另外，使用者也可以利用Oracle企業管理器的事件管理功能來對複製環境進行監視，該事件管理器提供了對多個站點間的複製狀態的主動監視功能，另外還提供了可以定義自動改正的選項等。
5.主要配置引數說明示例
Oracle高階複製，也稱為對稱複製。和Oracle的其他功能不同，Oracle的高階複製不是即插即用的，使用者必須深刻理解它們是如何工作的以及各種複製方案的優缺點。深刻理解複製的基本概念可以幫助你設計一個可靠的複製環境。
接下來主要介紹搭建Oracle高階複製環境時需要設定的一些系統引數。需要提醒注意的是，這裡所給出的這些系統引數的具體配置數值只能保證可以成功的搭建出一個相對較好的高階複製環境，但並未對這些引數的優化配置進行進一步的深入探討。
現在我們正式開始。假設有兩個節點，節點名分別為RLDBA和XJTU。
資料庫名 Rldba Xjtu
資料庫域名 Hr_group World
資料庫SID Rep.world Xjtu.world
Listener埠號 1521 1521
伺服器IP地址 192.168.110.221 192.168.110.130

1. 實現資料庫複製的前提條件
q 資料庫支援高階複製功能：您可以用system身份登入資料庫，檢視v$option檢視，如果其中Advanced replication為TRUE，則支援高階複製功能；否則不支援。
q 資料庫初始化引數要求：
（1） db_domain = test.com.cn：指明資料庫的域名(預設的是WORLD)，這裡可以用您公司的域名。
（2） global_names = true：它要求資料庫連結(database link)和被連線的資料庫名稱一致。 現在全域性資料庫名：db_name+"."+db_domain
q 資料庫連線通暢：
執行$tnsping hr_svr與$tnsping xjtu，出現以下提示符：
Attempting to contact
(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.1.200)(PORT=1521)) OK（n毫秒）則表示資料庫連線通暢，可以準備複製。
2. 系統環境引數（init.ora檔案）設定（對於非預設值）
如果要搭建Oracle高階複製環境，必須在初始化檔案中設定下列引數，見表1所示。
引數名稱 推薦值 備註
processes 100 程式數，default=59如果程式數大於59資料庫將可能發生死鎖
shared_pool_size 30000000 至少30M，如果有很多的複製物件的話，則需要更多的空間
large_pool_size 500K
db_block_buffers 550K
compatible 8.0.5.0 該版本以上
db_file_multiblock_read_count 16
dml_locks 100
sequence_cache_entries 30
sequence_cache_hash_buckets 23
global_names TRUE
distributed_lock_timeout 300
distributed_transactions 10
Open_links 6 複製節點多的話，需要增加
Sort_area_size 1000000
db_name RLDBA
job_queue_processes 6 定義SNP程式的啟動個數為n。系統預設值為0，正常定義範圍為0～36，根據任務的多少，可以配置不同的數值。
job_queue_interval 60 定義系統每隔N秒喚醒該程式一次。系統預設值為60秒，正常範圍為1～3600秒。事實上，該程式執行完當前任務後，就進入睡眠狀態，睡眠一段時間後，由系統的總控負責將其喚醒。
parallel_max_servers 10 只適用於並行傳播
parallel_min_servers 2 只適用於並行傳播
PEPLICATION_DEPENDENCY_TRACKING TRUE 如果採用並行傳播，必須設定為TRUE
（表1：Oracle高階複製環境初始化引數設定）
表1中各個引數的推薦值認為目前的複製環境只有兩個節點，一個簡單的高階複製環境，如果節點較多，且複製關係複雜，需要複製的表也很多，則需要相應增大一些引數的值，這可以通過修改不同的引數試驗獲得。如果修改了以上這幾個引數，需要重新啟動資料庫以使引數生效。

將所有的SNAPSHOT 或者是JOB_QUEUE_KEEP_CONNECTIONS引數都刪除，因為Oracle以後已經不支援這些引數。

2.Net8引數檔案
(1)sqlnet.ora檔案設定
# SQLNET.ORA Network Configuration File: D:OracleOra81networkadminsqlnet.ora# Generated by Oracle configuration toolsSQLNET.AUTHENTICATION_SERVICES= (NTS) NAMES.DIRECTORY_PATH= (TNSNAMES, ONAMES, HOSTNAME)automatic_ipc=offnames.default_domain = worldname.default_zone = worldsqlnet.expire_time = 0DISABLE_OOB = ON

(2)tnsnames.ora檔案設定
RLDBA = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = hr_svr)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = rep.world) ) )XJTU = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = xjtu)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = xjtu.world) ) )
上面Host為各個複製節點的IP地址，如果複製節點很多，則全部加入到tnsnames.ora檔案中，本文作為用例中有兩個節點。
3.表空間
如果搭建Oracle高階的高階複製環境，額外需要加大一些表空間，表2是建議的初始表空間。
表空間 建議初始值 建議
SYSTEM 至少20M
ROLLBACK SEGMENTS 至少20M 建議回滾段的下一個區大小設定至少為100K。
TEMPORARY 至少10M
TOOLS 至少20M
( 表2：Oracle系統表空間大小設定 )
上面這些建議的設定是一種較小複製環境下的空間設定。如果要複製的表很多，每天的變化量很大，複製節點複雜，則需要相應增大表空間的大小，具體資料依據具體情況而定。
6.複製應用例項
上面我們對複製基本概念及複製引數的作了說明，接下來主要介紹一個Oracle快照複製的實際例子及其技術實現細節。
(1) 業務需求描述
在一個實際的資料庫應用中，如電信、人力資源管理等應用中通常都採用這樣一種解決方案，在一個行政區域內，如一個省或者一個市，在不同的地理位置架設數臺資料庫伺服器，這些不同地理位置的伺服器具有同樣的後臺資料庫。為了維護資料庫系統的一致性，對於整個行政區域應用的基本資料表應該保持一致，如果不考慮資料複製，想維護同樣的不衝突的程式碼表是很困難的。下面我們不考慮實際的業務應用，只從資料庫複製角度來說明Oracle快照複製的應用。
為了維護整個系統基本資料表的一致性，比如有這樣的業務需求，對RLDBA上的一些表採用統一維護，即在一臺伺服器上維護。而在其他位置（如資料庫 XJTU，使用者SNAP）可以直接使用這些表，也就是說在位置1具有對程式碼表插入、刪除和更新的能力，而在其他地方具有同步查詢應用的能力。
(2) 應用設計
針對上述的需求，現在提出了這樣一種解決方案，也就是採用Oracle的快照複製。具體業務實現方案設計如下：
在位置1的資料庫RLDBA維護所有的表，在其餘資料庫建立相對於位置1的所有表的快照。為了維護快照的方便，在位置2建立一個單獨的快照表空間和一個模式（schema），也可以稱為使用者（USER），系統中的其他使用者通過一個私有同義詞來存取這些快照。這裡私有同義詞相對公共同義詞要好，這是因為在位置1存在一個同樣的系統，它的表是通過公共同義詞來存取的。對於快照的重新整理，採用Oracle系統包DBMS_REFRESH進行，並將該重新整理過程的執行定時在每天早上2:00，這樣可以減少網路流量。對於快照的重新整理形式，由於對於表的維護不是很多而且表的資料量相對較少，所以在此選擇了完全重新整理，這樣就避免了管理快照日誌的麻煩。下面以一個節點2（XJTU）為例來說明具體的技術實現細節。
(3) 技術實現細節
除非特別說明，下面的SQL命令都是在資料庫XJTU的SYSETM使用者下執行的。

1. 在資料庫2（XJTU）上增加資料庫1（RLDBA）的services name,可以直接在tnsnames.ora檔案中增加資料庫1的services name，包括IP地址，SID以及埠號等。services name 命名為rep.world。

2. 建立一個用於連線資料庫1（RLDBA）的資料庫連線（dblink）

DROP PUBLIC DATABASE LINK rep.hr_group@rldba; //刪除Database linkCREATE PUBLIC DATABASE LINK rep.hr_group@rldba CONNECT TO rldba IDENTIFIED BY admin USING rldba; //Create Database linkselect * from cat@rep.hr_group@rldba; //Test the Database link
注：出於安全考慮，可以採用一個私有資料連線。
3. 建立一個名為snapshot_rldba的表空間來存放RLDBA快照，並建立一個和該表空間有關的名為Snap的使用者。
CREATE TABLESPACE "snapshot_rldba"LOGGING DATAFILE D:ORACLEORADATAORA8ISNAPSHOT_RLDBA.oraSIZE 30MDEFAULT STORAGE ( INITIAL 30K NEXT 15K MINEXTENTS 100 MAXEXTENTS UNLIMITED PCTINCREASE 0 ); //Create Table spaceCREATE USER snap IDENTIFIED BY snap DEFAULT TABLESPACE "snapshot_rldba"; //Create User in the table spaceGRANT CONNECT, RESOURCE TO snap; //grant role to the user

4. 執行下面的指令碼檔案snapsql.sql來生成建立rldba資料庫上rldba使用者表的快照指令碼：
注意如果所需生成快照的表中含有型別為long的列，"select *"在這裡就不會起作用，上面的這個SQL指令碼就不能自動建立生成所需快照的指令碼，必須通過在select列表中顯式地新增long型列名來建立表的快照。下面是一個例子，假如我們要建立快照依賴的表T_YGJBXX中有一個列ZP型別為long，就需要單獨寫出如下的建立快照的指令碼：
CREATE SNAPSHOT T_YGJBXX PCTFREE 10 PCTUSED 40TABLESPACE "snapcost_rldba "STORAGE (INITIAL 40960 NEXT 57344 PCTINCREASE 0 )USING INDEX REFRESH WITH PRIMERY KEYFOR UPDATEAS select YGID, GZBH, FZJRLB, ZP, SXZY, XCSZY from T_YGJBXX@rep.hr_group@rldba; //Create snapshot
EXECUTE DBMS_SNAPSHOT.REFRESH (snap.T_YGJBXX )
執行指令碼檔案create_snapshot.sql後，就在模式snap中建立了所需要的快照。下一步就是考慮該如何重新整理快照。對於快照的重新整理，可以通過一些桌面DBA工具來重新整理快照也可以通過系統包dbms_snapshot.refresh來重新整理一個快照：
建立或選擇實現資料庫複製的使用者和物件，給使用者賦權，資料庫物件必須有主關鍵字，如果資料庫物件沒有主關鍵字，可以執行以下SQL命令新增：
alter table dept add (constraint dept_deptno_pk primary key (deptno))；

5. 建立一個定時重新整理過程來定時重新整理快照：
--sp_snapshot_refresh.sql CREATE OR REPLACE PROCEDURE sp_snapshot_refresh ISBEGINDBMS_REFRESH.MAKE ( NAME=> T_YGJBXX , LIST=>snap. T_YGJBXX, NEXT_DATE=>TRUNC (SYSDATE+1)+2/24, INTERVAL=>(SYSDATE+1), IMPLICIT_DESTROY=>FALSE, LAX=>TRUE);END sp_snapshot_refresh; --建立了一個定時任務來每天早晨2:00定時重新整理快照
EXECUTE sp_snapshot_refresh; //Execute the procedure
SELECT JOB, WHAT FROM DBA_JOBS; //查詢剛剛加入的這個任務
CREATE SYNONYM system.T_YGJBXX FOR snap.T_YGJBXX;//在使用者system下建立快照的私有同義詞
GRANT SELECT ON dm_gy_rydm TO system;//以snap使用者向system使用者授與快照可以select的許可權。

6. 同樣的步驟在其它位置建立位置1（rldba）的錶快照和定時重新整理任務。這樣就可實現在位置1統一維護程式碼表，在位置2和其它位置使用該表的目的。如下面的SQL語句，在位置2（xjtu）使用者snap瀏覽在位置1（rldba）中的程式碼表。
SELECT * FROM T_YGJBXX;
(4) 日常維護及注意事項
無論任何時候只要出現網路連線問題，重新整理就會失敗。這些錯誤資訊可以在alert.log檔案中找到。下面簡單介紹一下對這種問題的處理辦法：
1．首先在任務佇列中找到重新整理快照的任務編號
SELECT JOB,　what FROM DBA_JOBS;
2．刪除該任務
EXECUTE DBMS_JOB.REMOVE (JOBNO)；
3．刪除快照組
EXECUTE DBMS_REFRESH.DESTROY (tax_dmb_grp)；
4．重新建立快照組並且重新定時任務來定時重新整理快照
EXECUTE sp_snapshot_refresh(snap.T_YGJBXX)
5．快照監視
SELECT NAME, TO_CHAR(last_refresh,DD-MON-YY HH:MM:SS) FROM DBA_SNAPSHOTS;

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