知识大全 Oracle DG 逻辑Standby创建说明

Posted 2022-07-14 数据库

篇首语：“善与恶皆为上帝的成见。”蛇如是说。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全 Oracle DG 逻辑Standby创建说明相关的知识，希望对你有一定的参考价值。

Oracle DG 逻辑Standby创建说明 以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

　　一逻辑Standby的准备工作

　　确认操作的对象和语句是否能被逻辑Standby支持

　　由于逻辑Standby是通过SQL应用来保持与Primary数据库的同步 SQL应用与REDO应用是有很大的区别 REDO应用实际上是在物理Standby端进行RECOVER SQL应用则是分析重做日志文件中的REDO信息并将其转换为SQL语句在逻辑Standby端执行因此需要注意以下几点

　　（）并非所有的数据类型都能被逻辑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 NVARCHAR RAW TIMESTAMP

　　TIMESTAMP WITH LOCAL TIMEZONE TIMESTAMP WITH TIMEZONE VARCHAR and VARCHAR

　　说明下列类型在获取Standby支持时需要注意兼容性

　　CLOB 需要Primary数据库的兼容级别运行于或更高

　　含LOB字段的索引组织表（IOT）需要Primary数据库的兼容级别运行于或更高

　　不含LOB字段的索引组织表（IOT）需要Primary数据库的兼容级别运行于或更高

　　不支持的数据类型有

　　BFILE Encrypted Columns ROWID UROWID XMLType 对象类型 VARRAYS 嵌套表自定义类型

　　也可以通过查询DBA_LOGSTDBY_UNSUPPORTED来确定主数据库中是否含有不支持的对象

　　SQL> select * from dba_logstdby_unsupported;

　　注意该视图的ATTRIBUTES列显示对象不被SQL应用支持的原因

　　（）并非所有的存储类型都能被逻辑Standby支持

　　逻辑Standby能够支持簇表（Cluster Tables）索引组织表（Index Organized Tables）堆组织表（Heap Organized Tables）但不支持段压缩（Segment Compression）存储类型

　　（）并非所有的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

　　说明元数据直接理解成对象的物理定义举例来说对于某表而言元数据就是表结构或表的存储属性等

　　（）并非所有的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端执行由于数目较多此处不再一一列举感兴趣的话请查阅官方文档

　　（）并非所有的DML操作都能在逻辑Standby端实面SQL应用

　　维护逻辑Standby与Primary的数据库同步是通过SQL应用实现 SQL应用转换的SQL语句在执行时对于INSERT还好说对于UPDATE DELETE操作则必须能够唯一定位到数据库待更新的那条记录问题就在这里如果Primary库中表设置不当可能就无法确认唯一条件

　　你可能会说可以通过ROWID唯一嘛！千万要谨记啊逻辑Standby 为啥叫逻辑Standby 就是因为它只是逻辑上与Primary数据库相同物理上可能与Primary数据库存在相当大差异一定要认识到逻辑Standby的物理结构与Primary是不相同的（即使初始逻辑Standby是通过Primary的备份创建）

　　因此想通过ROWID更新显然是不好使的当然也就不能再将其作为唯一条件下面来看这个问题

　　确保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来主动维护

　　二逻辑Standby创建时的操作步骤

　　创建物理Standby

　　创建逻辑Standby数据库的第一步就是先创建一个物理Standby数据库然后再将其转换成逻辑Standby数据库在将其转换为逻辑Standby前可以随时启动REDO应用不过一旦决定将其转换为逻辑Standby 就必须先停止该物理Standby的REDO应用以避免提前应用含LogMiner字典的REDO数据造成转换为逻辑Standby后 SQL应用时LogMiner字典数据不足而影响到逻辑Standby与Primary的正常同步

　　设置Primary数据库

　　在创建物理Standby数据库时曾经设置过相关数量的初始化参数用于Primary数据库与物理Standby的角色切换对于逻辑Standby的角色切换那些参数同样好使

　　不过注意如果希望Primary数据库能够正常切换为逻辑Standby角色那么DBA在配置环境时还需要设置相应的LOG_ARCHIVE_DEST_n初始化参数并注意该参数的VALID_FOR属性值需要更改成STANDBY_LOGFILES STANDBY_ROLE

　　完成对初始化参数的配置后必须在Primary数据库端生成LogMiner字典信息例如

　　SQL> EXECUTE DBMS_LOGSTDBY BUILD;

　　提示本步必须执行并且执行本步操作时准逻辑Standby数据库要停止REDO应用

　　该过程专门用于生成记录的元数据信息到重做日志文件逻辑Standby未来正是通过这些元数据保持与Primary数据库的同步

　　提示该过程会自动启用Primary数据库的补充日志（Supplemental Logging）功能（如果未启用的话）

　　该过程需要等待当前所有事务完成后才能执行因此如果当前有较长的事务运行可能该过程的执行也需要多花一些等待时间

　　该过程是通过闪回查询的方式来获取数据字典的一致性因此Oracle初始化参数UNDO_RETENTION值不能太小建议设置为并且UNDO表空间也要有足够的空间

　　转换物理Standby为逻辑Standby

　　执行下列语句转换物理Standby为逻辑Standby

　　SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY DB_NAME;

　　注意 DB_NAME不是DB_UNIQUE_NAME 不同于物理Standby 逻辑Standby是一个全新的数据库因此建议你指定一个唯一的与Primary不同的数据库名另外如果当前准逻辑Standby使用SPFILE启动数据库那么执行该语句时Oracle会自动修改SPFILE中的相关信息如果使用PFILE启动数据库那么在下次执行SHUTDOWN的时候 Oracle会提示你去修改DB_NAME初始化参数的值

　　执行该语句前务必确保当前准逻辑Standby已经暂停了REDO应用另外转换是单向的即只能由物理Standby向逻辑Standby转换而不能由逻辑Standby转成物理Standby 这并不仅仅是因为DB_NAME发生了修改更主要的原因是逻辑Standby仅是数据与Primary一致其他如存储结构 SCN等甚至DBID都不相同

　　执行转换的过程中需要应用全部的与LogMiner字典相关的REDO数据这部分操作完全依赖于Primary数据库DBMS_LOGSTDBY BUILD的执行以及传输到Standby数据库端需要应用的数据量的规模而定如果Primary数据库执行DBMS_LOGSTDBY BUILD失败则转换操作也不会有结果这时候你恐怕不得不先cancel它解决Primary数据库的问题之后再尝试执行转换取消该操作与取消REDO应用一样当然实际上也正是取消REDO应用

　　重建逻辑Standby的密钥文件

　　主要是由于转换操作修改了数据库名因此密码文件也需要重建这个操作我们做得比较多这里就不详述了

　　[oracle@localhost dbs]$ orapwd file=/u /app/oracle/product/ /db_ /dbs/orapworcl password=admin

　　如果已经存在就不用创建了缺省情况下 win下口令文件的格式是pwdsid ora unix下的格式是orapwSID（大小写敏感）

　　调整逻辑Standby初始化参数

　　之所以要调整初始化参数一方面是由于此处我们的逻辑Standby是从物理Standby转换来的某些参数并不适合甚至可能造成错误如LOG_ARCHIVE_DEST_n参数的设置另一方面由于逻辑Standby默认是以OPEN READ WRITE模式打开有可能存在读写操作因此会读写本地Online Redologs并产生Archive Logs 务必需要注意本地的Archive Logs路径不要与接收自Primary数据库的重做日志文件路径冲突

　　当然归根结底是因为逻辑Standby是从物理Standby转换而来因此Standby的初始化参数就需要第二次调整（第一次是创建物理Standby）

　　修改初始化参数的方式有多种既可以通过ALTER SYSTEM命令也可以先生成PFILE并修改相关参数然后再根据修改过的PFILE生成SPFILE

　　打开逻辑Standby及应用REDO数据

　　由于逻辑Standby与Primary数据库事务并不一致其实质相当于进行了不完全恢复因此第一次打开时必须指定RESETLOGS子句如下

　　SQL> ALTER DATABASE OPEN RESETLOGS;

　　在逻辑Standby端启动SQL应用可以通过下列语句进行

　　SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

　　注意应用REDO数据时必须是在OPEN READ WRITE模式下这点与物理Standby有明显的区别

　　逻辑Standby也可以像物理Standby那样启用实时应用只需要在启动REDO应用时附加IMMEDIATE子句即可如

　　SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

　　如果想停止逻辑Standby数据库的SQL应用则可通过下列命令进行

cha138/Article/program/SQL/201404/30539