Oracle DG 邏輯Standby建立說明

一、邏輯Standby的準備工作

1、確認操作的對象和語句是否能被邏輯Standby支援

由於邏輯Standby是通過SQL應用來保持與Primary資料庫的同步。SQL應用與REDO應用是有很大的區別，REDO應用實際上是在物理Standby端進行RECOVER；SQL應用則是分析重做記錄檔中的REDO資訊，並將其轉換為SQL語句，在邏輯Standby端執行，因此，需要注意以下幾點：

（1）並非所有的資料類型都能被邏輯Standby支援，

邏輯Standby支援的資料類型有：

BINARY_DOUBLE、BINARY_FLOAT、BLOB、CHAR、CLOB and NCLOB、 DATE、INTERVAL YEAR TO MONTH、INTERVAL DAY TO SECOND、  LONG、LONG RAW、NCHAR、NUMBER、NVARCHAR2、RAW、TIMESTAMP、

TIMESTAMP WITH LOCAL TIMEZONE、TIMESTAMP WITH TIMEZONE、VARCHAR2 and VARCHAR

說明：下列類型在擷取Standby支援時需要注意相容性：

CLOB，需要Primary資料庫的相容層級運行於10.1或更高。

含LOB欄位的索引組織表（IOT），需要Primary資料庫的相容層級運行於10.2或更高。

不含LOB欄位的索引組織表（IOT），需要Primary資料庫的相容層級運行於10.1或更高。

不支援的資料類型有：

BFILE、Encrypted Columns、ROWID, UROWID、XMLType、物件類型、VARRAYS、巢狀表格、自訂類型。

也可以通過查詢DBA_LOGSTDBY_UNSUPPORTED來確定主要資料庫中是否含有不支援的對象

SQL> select * from dba_logstdby_unsupported;

注意：該視圖的ATTRIBUTES列，顯示對象不被SQL應用支援的原因。

（2）並非所有的儲存類型都能被邏輯Standby支援。

邏輯Standby能夠支援簇表（Cluster Tables）、索引組織表（Index-Organized Tables）、堆組織表（Heap-Organized Tables），但不支援段壓縮（Segment Compression）儲存類型。

（3）並非所有的PL/SQL包都能被SQL應用支援。

通常那些不會修改系統中繼資料（Metadata）的Package在實際應用時不會有問題，如DBMS_OUTPUT、DBMS_RANDOM、DBMS_METADATA之類的包。

那些可能修改系統中繼資料的Package不會被SQL應用支援，即使它們在Primary執行過，並且被成功傳輸到邏輯Standby端，也不會執行。如DBMS_JAVA、DBMS_REGISTRY、DBMS_ALERT、DBMS_SPACE_ADMIN、DBMS_REFRESH、DBMS_REDEFINITION、DBMS_SCHEDULER及DBMS_AQ等。只有DBMS_JOB例外，Primary資料庫的jobs會被複製到邏輯Standby，不過在邏輯Standby資料庫不會執行這些job。

說明：中繼資料，直接理解成對象的物理定義。舉例來說，對於某表而言，中繼資料就是表結構，或表的儲存屬性等。

（4）並非所有的SQL語句都能在邏輯Standby端執行。

在預設情況下，下列SQL語句在邏輯Standby端會被SQL應用自動跳過：

ALTER DATABASE。

ALTER MATERIALIZED VIEW。

ALTER MATERIALIZED VIEW LOG。

ALTER SESSION。

ALTER SYSTEM。

CREATE CONTROL FILE。

CREATE DATABASE。

CREATE DATABASE LINK。

CREATE PFILE FROM SPFILE。

CREATE MATERIALIZED VIEW。

CREATE MATERIALIZED VIEW LOG。

CREATE SCHEMA AUTHORIZATION。

CREATE SPFILE FROM PFILE。

DROP DATABASE LINK。

DROP MATERIALIZED VIEW。

DROP MATERIALIZED VIEW LOG。

EXPLAIN。

LOCK TABLE。

SET CONSTRAINTS。

SET ROLE。

SET TRANSACTION。

另外，由於SQL語句非常靈活，即使是那些能被SQL應用支援的DDL語句，可能在附加了某些特別的參數後，也不會在邏輯Standby端執行，由於數目較多，此處不再一一列舉，感興趣的話請查閱官方文檔。

（5）並非所有的DML操作都能在邏輯Standby端實面SQL應用。

維護邏輯Standby與Primary的資料庫同步是通過SQL應用實現，SQL應用轉換的SQL語句在執行時，對於INSERT還好說，對於UPDATE、DELETE操作則必須能夠唯一定位到資料庫待更新的那條記錄。問題就在這裡，如果Primary庫中表設定不當，可能就無法確認唯一條件。

你可能會說可以通過ROWID唯一嘛！千萬要謹記啊，邏輯Standby，為啥叫邏輯Standby，就是因為它只是邏輯上與Primary資料庫相同，物理上可能與Primary資料庫存在相當大差異。一定要認識到，邏輯Standby的物理結構與Primary是不相同的（即使初始邏輯Standby是通過Primary的備份建立）。

因此想通過ROWID更新顯然是不好使的，當然也就不能再將其作為唯一條件。下面來看這個問題。見

Oracle DG 邏輯Standby的相關視圖管理

Oracle 10g rac Standby 歸檔日誌自動刪除指令碼

Oracle Standby庫的ORA-01274問題

DataGuard 之物理Standby 的監控與管理

1 2 3 下一頁