Oracle DG 逻辑Standby创建说明

由于逻辑Standby是通过SQL应用来保持与Primary数据库的同步。SQL应用与REDO应用是有很大的区别，REDO应用实际上是在物理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 的监控与管理