基于同一主機配置Oracle11gDataGuard(logicalstandby)

Oracle Data Guard邏輯備庫是利用主庫的一個備份首先建立一個物理備庫，然后再將其轉換為邏輯備庫。這之后主庫將日志傳遞到備庫，

Oracle Data Guard邏輯備庫是利用主庫的一個備份首先建立一個物理備庫，然后再將其轉換為邏輯備庫。這之后主庫將日志傳遞到備庫，備庫利用logminer從主庫的日志中解析出主庫所執行過的SQL，在備庫上重新執行一遍，從而保證與主庫的數據在邏輯上保持一致。與物理備庫相對應的是，物理備庫使用的是redo apply，邏輯備庫使用的是sql apply。因此邏輯備庫僅僅保證數據與主庫是在邏輯上是一致的，從而邏輯備庫可以處于open狀態下并進行相應的DML操作。本文描述了創建邏輯備庫的注意事項以及給出了如何創建邏輯備庫。

相關參考:
Oracle Data Guard 重要配置參數
基于同一主機配置 Oracle 11g Data Guard

1、邏輯備庫的一些限制
對于邏輯備庫，存在很多限制，如對于一些特殊的些數據類型象object,nested table,rowid，對象類型，自定義的數據類型等不被支持，以及不
支持段壓縮，不支持一些特定的DDL語句等等一大堆的東西了。具體可以參考Oracle Data Guard Concepts and Administration。盡管如此，邏
輯備庫依舊有很多物理備庫所不具備的特點。下面僅僅列出邏輯備庫幾個重要關注的信息。

a、確定不被支持的schema
--對于Oracle數據庫自帶的相關schema會被跳過，因此不要基于這些schema來創建對象或測試，可使用下面的查詢來查看
SQL> SELECT OWNER FROM DBA_LOGSTDBY_SKIP WHERE STATEMENT_OPT = 'INTERNAL SCHEMA';

c、確定存在唯一性問題的對象
由于邏輯standby與原數據庫是邏輯相同，因此邏輯standby上的rowid并不等同于主庫上的rowid。關于rowid可參考：Oracle ROWID
對于主庫上的update,delete操作，Oracle通過主鍵和唯一索引/補充日志確保主庫與備庫所操作的對象為同一對象上的同一記錄
對于啟用了主鍵和唯一索引，補充日志的情形，每一條update語句如何去鑒別被更新的行呢？針對下面的情形在寫redo的時候會附加列值唯一信息
表存在主鍵，則主鍵值會隨同被更新列一起做為update語句的一部分
表無主鍵，存在非空的唯一索引/約束時，則最短的非空的唯一索引/約束會隨同被更新列做為update語句的一部分
表無主鍵，無唯一索引/約束，所有可定長度的列(除long,lob,long raw,object type,collection類型列)連同被更新列作為update語句的一部分
注，存在函數唯一索引的表能夠被實現SQL Apply，只要修改的行能夠被唯一鑒別，但該索引函數不能用作唯一性去鑒別更新的行
對于那些可由應用程序確保表上的行記錄唯一的，又不希望創建主鍵的情形，可以通過創建RELY約束，以避免維護主鍵所帶來的額外開銷
--可使用下面的方式為表添加RELY約束
SQL> ALTER TABLE tb_name ADD PRIMARY KEY (id, name) RELY DISABLE;

--數據字典DBA_LOGSTDBY_NOT_UNIQUE記錄了那些不存在主鍵以及唯一索引的表或者是說沒有足夠的信息能夠保證主庫與邏輯standby鎖定相同對象
SQL> SELECT owner, table_name FROM dba_logstdby_not_unique
2 WHERE (owner, table_name) NOT IN (SELECT DISTINCT owner, table_name FROM dba_logstdby_unsupported) AND bad_column = 'Y';

--查看主庫是否啟用補充日志，在主庫執行包dbms_logstdby.build后即開始啟用
SQL> select supplemental_log_data_pk,supplemental_log_data_ui from v$database;

2、邏輯備庫的幾個重要進程
邏輯備庫需要一系列的進程來完成日志的捕獲和應用工作。主要由兩個組件組成：挖掘引擎與應用引擎。也就是一個負責從重歸檔日志或備用日
志提取SQL語句集，一個負責將其SQL語句集應用到邏輯備庫。這兩個引擎的相關進程可以通過V$LOGSTDBY_PROCESS視圖中查詢獲得其相關信息。
挖掘引擎進程：
READER ： 進程從主庫傳過來的歸檔或者standby redo logfile中解析重做記錄(redo record)
PREPARER ：進程負責將READER進程解析到的重做記錄轉換為LCR(Logical change record)
可以有多個PREPARER進程。解析出來的LCR存放在shared pool的一個叫做LCR cache的區域中
BUILDER ：進程將LCR打包成事務，將多個LCR合成單個LCR，另外還負責管理LCR cache。如進行內存換頁，推進日志挖掘檢查點等

應用引擎進程：
ANALYZER ：該進程負責檢查一組LCR中包含的事務片段，過濾掉不需要應用的事務，檢查不同事務的依賴關系等
COORDINATOR ：該進程分配事務給APPLIER進程，監控事務依賴關系和協調提交順序
APPLIER : 可以有多個該進程，它負責將LCR應用到備庫

3、創建邏輯備庫

a、首先創建物理備庫
創建物理備庫的方法很多，對于Oracle 11g而言，可以直接從active database來創建，也可以基于10g 的RMAN使用duplicate方式來創建。
關于物理備庫的創建，此處不演示。
可以參考：基于同一主機配置 Oracle 11g Data Guard

b、 校驗主庫與物理備庫
--主庫: CNBO，，備庫: HKBO
--主庫上的信息
CNBO> select name,database_role,switchover_status from v$database;

NAME DATABASE_ROLE SWITCHOVER_STATUS
----------------- ---------------- ------------------------
CNBO PRIMARY TO STANDBY

--備庫上的信息
HKBO> select name,open_mode,database_role,protection_mode from v$database;

NAME OPEN_MODE DATABASE_ROLE PROTECTION_MODE
--------- -------------------- ---------------- --------------------
HKBO MOUNTED PHYSICAL STANDBY MAXIMUM PERFORMANCE

--SRL被apply的情形
HKBO> select sequence#, first_time, next_time,applied from v$archived_log where rownum<3 order by first_time desc;

SEQUENCE# FIRST_TIME NEXT_TIME APPLIED
---------- ------------------- ------------------- ---------------------------
7 2013/08/16 10:38:03 2013/08/16 10:46:11 YES
6 2013/08/16 10:38:00 2013/08/16 10:38:03 YES

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com