Oracle10g R2 Logical Standby 的一些概念[摘錄]

        從Oracle9i開始支援邏輯Standby，透過logminer從日誌中挖掘出sql語句重新在備庫應用，來達到主備庫資料冗餘的目的。由於邏輯備庫在應用sql的同時是處於open狀態了，那麼除了可以利用其冗餘資料的特性來做冗災之外，考慮得更多的可能是利用其做為報表查詢庫，或者做為讀寫分離的一種解決方案來分擔整個系統的負載，可以充分利用做為備庫的主機和儲存資源。但是9i的邏輯備庫有很多不成熟的地方，實際使用的案例也不多。Oracle10g對於Data Guard在易用性和穩定性方面做出了不少的改進。本系列文章打算簡單介紹一下10gR2的邏輯備庫。

邏輯備庫的架構說起來十分的簡單，首先利用主庫的一個備份來建立邏輯備庫，然後主庫將日誌傳遞到備庫，備庫利用logminer從主庫的日誌中解析出主庫所執行過的SQL，然後重新跑一邊，從而使得主備庫的資料一致。由於Oracle的聯機日誌是半邏輯半物理結構，所以從日誌中解析出來的SQL，只是邏輯上和主庫上的等效，而不是完全相同的語句。比如主庫執行一條insert語句插入了10條記錄，在備庫解析出來將是10條insert語句，每條語句插入一條記錄。

邏輯備庫需要一系列的程式來完成日誌的捕獲和應用工作。

執行捕獲任務的程式主要有：

• READER程式從主庫傳過來的歸檔或者standby redo logfile中解析重做記錄(redo record)
• PREPARER程式負責將READER程式解析到的重做記錄轉換為LCR(Logical change record)。可以開啟多個PREPARER程式。解析出來的LCR存放在shared pool的一個叫做LCR cache的區域中。
• BUILDER程式將LCR打包成事務。另外還負責管理LCR cache, 執行重啟SQL Apply所需要的checkpoint(這個在後面的文章中會介紹)，以及過濾不需要資料等任務。

執行應用日誌的程式主要有：

• ANALYZER程式檢查一組LCR中包含的事務片段，過濾掉不需要應用的事務，檢查不同事務的依賴關係等
• COORDINATOR程式分配事務給APPLIER程式，監控事務依賴關係和協調排程，確認邏輯備庫的提交
• APPLIER程式將LCR應用到備庫，和COORDINATOR程式互動確認事務的依賴關係並提及事務。

上面提到的這些程式，都可以從V$LOGSTDBY_PROCESS檢視中獲得他們的資訊 ，

透過v$logstdby_stats檢視可以檢視邏輯備庫的一些統計資訊 。

            邏輯備庫只是對於主庫的一個邏輯意義上的資料冗餘，不像物理備庫能夠在block級別上和主庫保持一致。所以有其優點，也有其缺點。比如主庫的一個datafile損壞，可以從物理備庫複製對應的檔案過來然後recover datafile就可以恢復，邏輯備庫則無法實現這樣保護了。由於是SQL APPLY，對於一些資料型別也是有限制的。

不支援的資料型別

Oracle10gR2的logical standby已經能支援大多數的資料型別了，包括CLOB/BLOB/LONG等，但還是有幾種型別是不支援的。如果主庫中有使用到這些資料型別，則需要使用其他方式進行處理。

BFILE
Collections (including VARRAYS and nested tables)
Encrypted columns
Multimedia data types (including Spatial, Image, and Context)
ROWID, UROWID
User-defined types
XMLType

可以透過查詢DBA_LOGSTDBY_UNSUPPORTED檢視來檢視當前庫中是否有table包含了這些不支援的資料型別

摘錄自