Oracle 本站推荐

ORACLE DataGuard Logical 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更新显然是不好使的，当然也就不能再将其作为唯一条件。下面来看这个问题。

2 确保Primary库中各表的行可被唯一标识
Oracle通过主键、唯一索引/约束的补充日志（Supplemental Logging）来确定待更新逻辑Standby数据库中的行。当数据库启用了补充日志，每一条UPDATE语句写REDO的时候会附加列值唯一信息，比如：
如果表定义了主键，则主键列会随同被更新列一起作为UPDATE语句的一部分，以便执行时区分哪些列应该被更新。
如果没有主键，则非空的唯一索引/约束会随同被更新列作为UPDATE语句的一部分，以便执行时区分哪些列应该被更新，如果该表有多个唯一索引/约束，则Oracle自动选择长度最短的那个，以降低生成的重做日志大小。
如果表既无主键，也没有定义唯一索引/约束，所有可定长度的列，连同被更新列同时作为UPDATE语句的一部分。更明确些，可定长度的列是指除LONG、LOB、LONG RAW、OBJECT TYPE、COLLECTION类型外的列。
Oracle 建议你为表创建一个主键或非空的唯一索引/约束，以尽可能确保SQL应用能够有效应用REDO数据，更新逻辑Standby数据库。

下列语句可以用来检查SQL应用能否唯一识别表列，并找出不被支持的表：
SQL> SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_NOT_UNIQUE WHERE (OWNER, TABLE_N
AME) NOT IN (SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED)
AND BAD_COLUMN = ‘Y’;

OWNER TABLE_NAME

TSMSY SRS$

提 示: 关于DBA_LOGSTDBY_NOT_UNIQUE, 该视图显示所有既没主键也没唯一索引的表。如果表中的列包括足够多的信息，通常也可支持在逻辑Standby端的更新，不被支持的表通常是由于列的定义包含了不支持的数据类型。

注意BAD_COLUMN列值，该列有两个值：
Y：表示该表中有采用大数据类型的字段，比如LONG、CLOB。如果表中除LOG列某些行记录完全匹配，则该表无法成功应用于逻辑Standby。Standby会尝试维护这些表，不过你必须保证应用不允许。
N：表示该表拥有足够的信息，能够支持在逻辑Standby的更新，不过仍然建议你为该表创建一个主键或者唯一索引/约束，以提高LOG应用效率。

假设在某张表中你可以确认数据是唯一的，但是基于效率方面的考虑，不想为其创建主键或唯一约束，怎么办呢？没关系，Oracle早想到了这一点，你可以创建一个DISABLE的Primary-Key Rely约束：

提 示: 关于Primary-Key Rely约束。
如果DBA能够确认表中的行是唯一的，那么可以为该表创建Rely的主键，Rely约束并不会造成系统维护主键的开销，如你对一个表创建了RELY约束，系统则会假定该表中的行是唯一的，这样能够提高SQL应用时的性能。但是需要注意，由于Rely的主键约束只是假定唯一，如果实际并不唯一的话，有可能会造成错误的更新哟。
创建Rely的主键约束非常简单，只要在标准的创建语句后加上RELY DISABLE即可，例如：
SQL> ALTER TABLE USER ADD PRIMARY KEY (ID) RELY DISABLE;
表已更改。

注 意: 创建了Rely约束后，Oracle会假定该列是唯一的（给DBA足够的信任），不过并不会对该列的值进行唯一性的验证，因此该列是否唯一只能由DBA来主动维护。


数据运维技术 » ORACLE DataGuard Logical Standby 详解之：（一）逻辑Standby的准备工作
分享到：

相关推荐