北京北排建设公司招标网站,做网站公司分为国内还是国外,专业的企业智能建站制造厂家,旅游网站制作文献1. SQL Apply架构概述
SQL Apply使用一组后台进程来应用来自主数据库的更改到逻辑备数据库。 在日志挖掘和应用处理中涉及到的不同的进程和它们的功能如下#xff1a;
在日志挖掘过程中#xff1a; 1#xff09;READER进程从归档redo日志文件或备redo日志文件中读取redo记…1. SQL Apply架构概述
SQL Apply使用一组后台进程来应用来自主数据库的更改到逻辑备数据库。 在日志挖掘和应用处理中涉及到的不同的进程和它们的功能如下
在日志挖掘过程中 1READER进程从归档redo日志文件或备redo日志文件中读取redo记录 2PREPARER进程转换redo记录中包含的数据块更改到逻辑更改记录LCRsLogical Change Records。可以为一个指定的redo日志文件激活多个PREPARER进程。LCRs存放在SGAsystem global area中称为LCR缓存。 3BUILDER进程将LCRs组合成事务和执行其他任务比如在LCR缓存中进行内存管理重启与SQL Apply相关的检查点和滤除无用的更改。
在应用过程中 1ANALYZER进程确认不同事务之间的依赖关系。 2COORDINATOR进程LSP分配事务给不同的应用器然后在事务间进行协调来确保遵循事务之间的依赖关系。 3APPLIER进程在协调进程的监督下应用事务到逻辑备数据库。 1.1. SQL Apply考虑的各种因素
1.1.1. 事务大小考虑
SQL Apply将事务分成两类小事务和大事务。
每种类别的定义如下 1小事务—SQL Apply一旦遇到redo日志文件中的事务提交记录就会启动应用属于小事务的LCRs。 2大事务—SQL Apply将大事务分割成更小的事务块transcation chunks然后在看到redo日志文件中的大事务提交记录之前启动应用事务块。这样可以减轻LCR缓存的内存压力和减少整体故障切换的时间。 例如如果不将大事务分割成小块事务SQL*Loader导入1千万行每行100 bytes那么LCR缓存将会使用1G的内存。如果分配给LCR缓存的内存小于1G就会导致从LCR缓存中移出页面pageout。 降了内存方面的考虑如果SQL Apply直到遇到事务的COMMIT记录才开始应用SQL*Loader导入1千万行的相关的更改它会阻滞角色的转换。在事务提交后发起的正常切换或故障切换不能完成直到SQL Apply已经应用事务到逻辑备数据库为止。 虽然使用了事务块当处理修改多于8百万行的事务时SQL Apply的性能可能会降低。对于多于8百万行的事务SQL Apply使用临时段来存放处理事务的部分内部元数据。确保在临时段中分配更多的空间让SQL Apply能成功地处理多于8百万行的事务。
所有事务开始时会分类成小事务。取决于LCR缓存的可用内存容量和属于事务的LCR消耗的内存容量SQL Apply决定什么时候重新将事务分类为大事务。 1.1.2. 页出pageout考虑
当LCR缓存的内存耗尽时需要释放空间来让SQL Apply来继续进行就会发生页出pageout。
例如假设分配给LCR缓存的内存是100MBSQL Apply遇到一条INSERT到表的一个LONG列的大小为300MB的事务。在这种情况下日志挖掘组件页出第一部分LONG数据来读取后面部分的列更改。在一个调优好的逻辑备数据库中页出活动偶尔会发生不会影响系统 的整体吞吐量。
参考“自定义逻辑备数据库”章节关于如何识别有问题的页出和执行纠正操作。 1.1.3. 重启考虑
对逻辑备数据库的更改不会成为持久的直到从redo日志文件中挖掘到事务的提交记录和应用到逻辑备数据库为止。
因此每次SQL Apply停止时不管是因为用户的指令还是系统故障的结果SQL Apply必须进行回溯重新挖掘最早的没有提交的事务。
在事务只做了少量的工作但打开了很长一段时间的情况下从一开始重启SQL Apply可能会付出过高的代价因为SQL Apply必须重新挖掘大量的归档redo日志文件只为了读取一部分没有提交的数据的redo数据。为了减轻这种情况SQL Apply定期地对旧的未提交的数据执行检查点操作。检查点进行时的SCN反映在视图V$LOGSTDBY_PROGRESS的列RESTART_SCN中。在进行重启时SQL Apply从大于列RESETART_SCN的值的SCN时产生的redo记录开始挖掘。重启时不需要的归档redo日志文件会自动被SQL Apply删除。
某些负载例如大的DDL事务并行的DML语句PDML和直接路径导入阻止RESTART_SCN在负载的持续时间里向前推进。 1.1.4. DML Apply考虑
SQL Apply在应用影响逻辑备数据库的吞吐量和延迟的DML事务时有以下特性 1在主数据库上做批量更新或删除时一条语句会导致多行被修改这时在逻辑备数据库上则作为单独的行修改来应用。因为对于每个维护的表必须有唯一的索引或主键。 2在主数据库上执行的直接路径插入在逻辑备数据库上使用传统的INSERT语句来应用。 3并行的DMLPDML事务在逻辑备数据库上不是并行地执行。 1.1.5. DDL Apply考虑
SQL Apply在应用影响逻辑备数据库的吞吐量和延迟的DDL事务时有以下特性 1DDL事务在逻辑备数据库上是串行地应用。因此在主数据库上并行应用的DDL事务是一次一个地在逻辑备数据库上应用。 2CREATE TABLE AS SELECTCTAS语句如此执行以致DML操作CATS语句的一部分在逻辑备数据库上受到抑制。作为CTAS语句的一部分插入到新创建的表的行从redo日志文件中挖掘出来和使用INSERT语句应用到逻辑备数据库。 3SQL Appy重新发出在主数据库上执行的DDL确保作为DDL操作目标的相同对象上的相同的事务中发生的DML不会在逻辑备数据库上复制SQL Apply reissues the DDL that was performed at the primary database, and ensures that DMLs that occur within the same transaction on the same object that is the target of the DDL operation are not replicated at the logical standby database。因此以下两个情况会导致主备数据库相互偏离 a. DDL包含从主数据库的状态获取的非文字的值。这样的DDL的一个例子是 ALTER TABLE hr.employees ADD (start_date date default sysdate); 由于SQL Apply在逻辑备数据库重新发出相同的DDL函数sysdate() 在逻辑备数据库重新取值。因此列start_date使用与主数据库不同的缺省值来创建。 b. DDL激发在目标表上定义的DML触发器。由于触发的DMLs发生在与DDL相同的事务上操作的表也是DDL的目标这些触发的DML不会在逻辑备数据库上复制。 例如假设创建一个如下的表 create table HR.TEMP_EMPLOYEES ( emp_id number primary key, first_name varchar2(64), last_name varchar2(64), modify_date timestamp);
假设在表上创建一个触发器使得任何时候表进行更新时列modify_date也更新来反映更改的时间 CREATE OR REPLACE TRIGGER TRG_TEST_MOD_DT BEFORE UPDATE ON HR.TEST_EMPLOYEES REFERENCING NEW AS NEW_ROW FOR EACH ROW BEGIN :NEW_ROW.MODIFY_DATE: SYSTIMESTAMP; END; /
表在一般的DML/DDL负载下可以正确地维护。但如果使用缺省值往表里增加一列ADD COLUMN DDL操作会激发更新触发器更改表中所有行的MODIFY_DATE列为新的时间戳。这些对MODIFY_DATE列的更改不会复制到逻辑备数据库上。接下来对表的DML操作会停止SQL Apply因为记录在redo流中的MODIFY_DATE列数据与存在于逻辑备数据库上的数据不匹配。 1.1.6. 密码验证函数
检查密码复杂度的密码验证函数必须在SYS模式中创建。
因为SQL Apply不会复制SYS模式中创建的对象这些密码验证函数不会复制到逻辑备数据库。必须在逻辑备数据库上手动创建密码验证函数然后与合适的profile关联。 2控制用户对表的访问
SQL语句ALTER DATABASE GUARD在逻辑备数据库上控制用户对表的访问。
缺省情况下在逻辑备数据库上database guard设置为ALL。
ALTER DATABASE GUARD语句允许以下关键字 1ALL 指定ALL来阻止除SYS外的所有用户对逻辑备数据库的任何数据进行更改。 2STANDBY 指定STANDBY来阻止除SYS之外的所有用户对通过SQL Apply维护的任何表或序列进行DML和DDL更改。 3NONE 指定NONE来对数据库的所有数据使用典型的保护措施。
例如使用以下语句来启用用户更改不是SQL Apply维护的表。 SQL ALTER DATABASE GUARD STANDBY;
特权用户可以分别使用ALTER SESSION DISABLE GUARD和ALTER SESSION ENABLE GUARD语句为当前会话临时关闭和打开database guard。这个语句替代了DBMS_LOGSTDBY.GUARD_BYPASS PL/SQL存储过程在Oracle 9i中执行相同的功能。当你想临时禁用database guard来对数据库进行更改时语句ALTER SESSION [ENABLE|DISABLE] GUARD很有用。
注在database guard禁用时不要让主数据库和逻辑备数据库偏离。 3监控逻辑备数据库
3.1. 监控SQL Apply的进度
SQL Apply可以在六个进度状态中的任何一个初始化SQL Apply等待字典日志导入LogMiner字典应用redo数据等待归档缺口gap得到解决和空闲。
下图显示了这些状态的流动
3.1.1初始化状态
当使用ALTER DATABASE START LOGICAL STANDBY APPLY语句启动SQL APPLY时它会进入到initializing状态。
查询V$LOGSTDBY_STATE视图来确认SQL Apply的当前状态。 SQL SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;
SESSION_ID STATE
---------- -------------
1 INITIALIZING列SESSION_ID显示SQL Apply创建的持久的LogMiner会话用来挖掘主数据库产生的归档redo日志文件。 3.1.2等待字典日志
SQL Apply第一次启动时它需要导入redo日志文件中记录的LogMiner字典。SQL Apply停留在WAITING FOR DICTIONARY LOGS状态直到它已经接收到导入LogMiner字典所要求的所有的redo数据。 3.1.3导入字典状态
Loading dictionary的状态会持续一会。导入一个大数据库的LogMiner字典会花很长的时间。当导入字典时查询视图V$LOGSTDBY_STATE会返回以下输出 SQL SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;
SESSION_ID STATE
---------- ------------------
1 LOADING DICTIONARY只有COORDINATOR进程和挖掘进程启动直到LogMiner字典完全导入为止。因此此时如果查询视图V$LOGSSTDBY_PROCESS将会看不到任何APPLIER进程。 SQL SELECT SID, SERIAL#, SPID, TYPE FROM V$LOGSTDBY_PROCESS;
SID SERIAL# SPID TYPE
------ --------- --------- ---------------------
47 3 11438 COORDINATOR
50 7 11334 READER
45 1 11336 BUILDER
44 2 11338 PREPARER
43 2 11340 PREPARER可以通过查询视图V$LOGMNR_DICTIONARY_LOAD来获取关于导入字典进度更详细的信息。导入字典分3个阶段进行 1挖掘相关的归档redo日志文件或备redo日志文件来收集与导入LogMiner字典相关的redo更改 2这些更改被处理和导入到数据库中的阶段表 3发出一序列的DDL语句导入LogMiner字典表。 SQL SELECT PERCENT_DONE, COMMAND FROM V$LOGMNR_DICTIONARY_LOAD WHERE SESSION_ID (SELECT SESSION_ID FROM V$LOGSTDBY_STATE);
PERCENT_DONE COMMAND
------------- -------------------------------
40 alter table SYSTEM.LOGMNR_CCOL$ exchange partition P101 with table SYS.LOGMNRLT_101_CCOL$ excluding indexes without validation如果PERCENT_DONE或COMMAND列很长一段时间没有变化查询视图V$SESSION_LONGOPS来监控有问题的DDL事务的进度。 3.1.4应用状态
在这个状态中SQL Apply已经成功导入LogMiner字典的初始快照和正在应用redo数据到逻辑备数据库。
查询视图V$LOGSTDBY_PROGRESS取得关于SQL Apply进度的详细信息 SQL ALTER SESSION SET NLS_DATE_FORMAT ‘DD-MON-YYYY HH24:MI:SS’; SQL SELECT APPLIED_TIME, APPLIED_SCN, MINING_TIME, MINING_SCN FROM V$LOGSTDBY_PROGRESS;
APPLIED_TIME APPLIED_SCN MINING_TIME MINING_SCN
-------------------- ----------- -------------------- -----------
10-JAN-2005 12:00:05 346791023 10-JAN-2005 12:10:05 3468810134主数据库的所有在APPLIED_SCN或APPLIED_TIME之前的提交的事务都已经应用到逻辑备数据库。挖掘引擎已经处理了所有在MINING_SCN和MINING_TIME之前产生的redo记录。在稳定的状态下MINING_SCN和MINING_TIME总是在APPLIED_SCN和APPLIED_TIME的前面。 3.1.5等待gap状态
这个状态发生在当SQL Apply已经挖掘和应用所有可用的redo记录在等待新的日志文件或缺失的日志文件来通过RFS进程归档的时候。 SQL SELECT STATUS FROM V$LOGSTDBY_PROCESS WHERE TYPE ‘READER’;
STATUS
------------------------------------------------------------------------
ORA-16240: waiting for log file (thread# 1, sequence# 99)3.1.6空闲状态
一旦SQL Apply已经应用完主数据库产生的所有redo它就进入到这个状态。 SQL SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;
SESSION_ID STATE
---------- -----------------
1 IDLE3.2. 自动删除日志文件
外来的归档日志包含从主数据库传输来的redo。
有两种方式来存储外来的归档日志 1快速恢复区域 2在快速恢复区域以外的目录
存储在快速恢复区域的外来归档日志由SQL Apply管理。包含在日志中的所有redo记录已经应用到逻辑备数据库后它们会保留一段由参数DB_FLASHBACK_RETENTION_TARGET指定的时间或如果参数DB_FLASHBACK_RETENTION_TARGET没有指定则保留1440分钟。不可以撤销自动管理存放在快速恢复区域中的外来归档日志。
不是存储在快速恢复区域的外来归档日志缺省由SQL Apply管理。在自动管理下在日志包含的所有redo记录已经应用到逻辑备数据库后不是存储在快速恢复区域的外来归档日志保留一段由参数LOG_AUTO_DEL_RETENTION_TARGET指定的时间。可以执行以下PL/SQL存储过程取消自动管理不是存储在快速恢复区域中的外来归档日志。 SQL EXECUTE DBMS_LOGSTDBY.APPLY_SET(‘LOG_AUTO_DELETE’, ‘FALSE’);
注使用DBMS_LOGSTDBY.APPLY_SET存储过程来设置这个参数如果不明确指定参数LOG_AUTO_DEL_RETENTION_TARGET它缺省为逻辑备数据库设置的参数DB_FLASHBACK_RETENTION_TARGET的值或者在DB_FLASHBACK_RETENTION_TARGET参数没有设置时为1440分钟。
如果撤消缺省的自动日志删除功能定期执行以下步骤来发现和删除SQL Apply不再需要的归档redo日志文件 1执行以下PL/SQL语句来清除不需要的元数据的逻辑备会话 SQL EXECUTE DBMS_LOGSTDBY.PURGE_SESSION; 这条语句也更新视图DBA_LOGMNR_PURGED_LOG。
2查询视图DBA_LOGMNR_PURGED_LOG来列出可以删除的归档redo日志文件 SQL SELECT * FROM DBA_LOGMNR_PURGED_LOG;
FILE_NAME
------------------------------------
/boston/arc_dest/arc_1_40_509538672.log
/boston/arc_dest/arc_1_41_509538672.log
/boston/arc_dest/arc_1_42_509538672.log
/boston/arc_dest/arc_1_43_509538672.log
/boston/arc_dest/arc_1_44_509538672.log
/boston/arc_dest/arc_1_45_509538672.log
/boston/arc_dest/arc_1_46_509538672.log
/boston/arc_dest/arc_1_47_509538672.log3使用操作系统的命令来删除查询列出的归档redo日志文件。 4自定义逻辑备数据库
4.1.在视图DBA_LOGSTDBY_EVENTS中自定义事件记录
视图DBA_LOGSTDBY_EVENTS可以视为一个循环的日志日志包含最近的发生在SQL Apply环境中有用的事件。 缺省情况下最后的10,000个事件会记录在事件视图中。可以调用存储过程DBMS_LOGSTDBY.APPLY_SET更改记录的事件数量。例如可以执行以下语句来确保最后的100,000事件会被记录。 SQL EXECUTE DBMS_LOGSTDBY.APPLY_SET (‘MAX_EVENTS_RECORDED’, ‘100000’);
引起SQL Apply停止的错误会一直记录在DBA_LOGSTDBY_EVENTS视图中除非SYSTEM表空间没有足够的空间。这些事件也会存放到alert告警文件中文本包含关键字LOGSTDBY。当查询视图时通过EVENT_TIMECOMMIT_SCN和CURRENT_SCN排序来选择这些列。这样排序确保关闭故障显示在视图的最后。
下面的示例显示DBMS_LOGSTDBY子程序指定记录到视图中的事件。
示例1确认DDL语句是否已经应用 例如执行以下语句来记录应用DDL事务到DBA_LOGSTDBY_EVENTS视图中。 SQL EXECUTE DBMS_LOGSTDBY.APPLY_SET (‘RECORD_APPLIED_DDL’, ‘TRUE’);
示例2检查视图DBA_LOGSTDBY_EVENTS来确认逻辑备数据库不支持的操作 执行以下语句来捕获运行在主数据库上的逻辑备数据库不支持的事务信息 SQL ALTER DATABASE STOP LOGICAL STANDBY APPLY; SQL EXEC DBMS_LOGSTDBY.APPLY_SET(‘RECORD_UNSUPPORTED_OPERATIONS’, ‘TRUE’); SQL ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
然后检查DBA_LOGSTDBY_EVENTS视图来查看不支持的操作。一般情况下在不支持的表上的操作会被SQL Apply安静地忽略。然而在滚动升级过程当备数据库在更高的版本挖掘更低版本的主数据库产生的redo时如果在主数据库执行不支持的操作逻辑备数据库可能不是你想执行正常切换的数据库。Oracle Data Guard在视图DBA_LOGSTDBY_EVENTS中为每个表记录至少一条不支持的操作。 4.2. 使用DBMS_LOGSTDBY.SKIP来阻止更改特定的模式对象
缺省情况下主数据库上所有支持的表都会复制到逻辑备数据库。
可以通过指定规则来略过应用特定的表的修改从而更改缺省的行为。例如为了忽略表HR.EMPLOYEES的更改可以指定规则来阻止应用DML和DDL更改到特定的表。例如 1停止SQL Apply SQL ALTER DATABASE STOP LOGICAL STANDBY APPLY;
2注册SKIP规则 SQL EXECUTE DBMS_LOGSTDBY.SKIP (stmt ‘DML’, schema_name ‘HR’, object_name ‘EMPLOYEES’); SQL EXECUTE DBMS_LOGSTDBY.SKIP (stmt ‘SCHEMA_DDL’, schema_name ‘HR’, object_name ‘EMPLOYEES’);
3启动SQL Apply SQL ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 4.3. 为DDL语句设置Skip Handler
可以创建一个存储过程来拦截某些DDL语句和使用不同的语句替换原始的DDL语句。
例如如果逻辑备数据库的文件系统结构与主数据库的不同可以写一个DBMS_LOGSTDBY.SKIP存储过程来使用文件规范透明地处理DDL事务。
下面的步骤可以处理主备数据库之间不同的文件系统结构只要为文件参数字符串使用特定的命名惯例。 1创建SKIP存储过程来处理表空间DDL事务
CREATE OR REPLACE PROCEDURE SYS.HANDLE_TBS_DDL (OLD_STMT IN VARCHAR2,STMT_TYP IN VARCHAR2,SCHEMA IN VARCHAR2,NAME IN VARCHAR2,XIDUSN IN NUMBER,XIDSLT IN NUMBER,XIDSQN IN NUMBER,ACTION OUT NUMBER,NEW_STMT OUT VARCHAR2
) AS
BEGIN-- All primary file specification that contains a directory-- /usr/orcl/primary/dbs-- should go to /usr/orcl/stdby directory specificationNEW_STMT : REPLACE(OLD_STMT,/usr/orcl/primary/dbs,/usr/orcl/stdby);ACTION : DBMS_LOGSTDBY.SKIP_ACTION_REPLACE;
EXCEPTIONWHEN OTHERS THENACTION : DBMS_LOGSTDBY.SKIP_ACTION_ERROR;NEW_STMT : NULL;
END HANDLE_TBS_DDL;c. 停止SQL Apply SQL ALTER DATABASE STOP LOGICAL STANDBY APPLY;
d. 注册SKIP存储过程 SQL EXECUTE DBMS_LOGSTDBY.SKIP (stmt ‘TABLESPACE’, proc_name ‘sys.handle_tbs_ddl’);
e. 停止SQL Apply: SQL ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 4.4. 修改逻辑备数据库
逻辑备数据库可以用来做报告活动即使在SQL语句正在应用的时候。
在逻辑备数据库中Database guard控制用户对表的访问语句ALTER SESSION DISABLE GUARD用来绕过database guard允许在逻辑备数据库中修改表。
注为了使用逻辑备数据库来存放其他应用程序处理从主数据库复制过来的数据同时创建属于它们自己的其他表database guard必须设置为STANDBY。为了这些应用程序无缝地工作确保PRESERVE_COMMIT_ORDER参数设置为TRUESQL Apply的缺省设置。参考Oracle Database PL/SQL Packages and Types Reference关于在DBMS_LOGSTDBY PL/SQL包的参数PRESERVE_COMMIT_ORDER的信息 执行以下SQL语句来设置database guard为STANDBY SQL ALTER DATABASE GUARD STANDBY; 在这个设置中从主数据库复制的表被保护不允许用户更改但在备数据库上创建的表可以被运行在逻辑备数据库的应用程序更改。
缺省时逻辑备数据库以database guard设置为ALL来运行这是最有限制性的设置不允许任何用户对数据库执行更改。可以执行ALTER SESSION DISABLE GUARD来撤销database guard允许对逻辑备数据库更改。特权用户可以执行这个语句来为当前会话关闭database guard。
以下部分提供了一些示例。这些部分中的讨论假设database guard设置为ALL或STANDBY。 4.4.1. 在逻辑备数据库上执行DDL
可以增加约束到SQL Apply维护的表。
缺省时当database guard设置为ALL或STANDBY时只有具有SYS特权的账户可以修改数据库。如果以SYSDG,SYSTEM或其他特权账户登录不可以在逻辑备数据库上执行DDL语句除非先在会话中绕过database guard。
下面的示例显示如何停止SQL Apply绕过database guard在逻辑备数据库上执行SQL语句然后重新启用guard。在这个示例中探测索引soundex index被增加到姓氏列SCOTT.EMP来加速部分匹配查询。探测索引在主数据库上可能被禁止维护。
SQL ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered.
SQL ALTER SESSION DISABLE GUARD; PL/SQL procedure successfully completed.
SQL CREATE INDEX EMP_SOUNDEX ON SCOTT.EMP(SOUNDEX(ENAME)); Table altered.
SQL ALTER SESSION ENABLE GUARD; PL/SQL procedure successfully completed.
SQL ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered.
SQL SELECT ENAME,MGR FROM SCOTT.EMP WHERE SOUNDEX(ENAME) SOUNDEX(‘CLARKE’);
ENAME MGR
---------- ----------
CLARK 7839Oracle建议当绕过database guard启用时不要在SQL Apply维护的表上执行DML操作。这样做会影响主备数据库的偏离让逻辑备数据库不可能被维护。 4.4.2. 修改不是SQL Apply维护的表
有时报告应用程序必须收集统计结果和临时存储它们或跟踪报告运行的次数。虽然应用程序的主要目的是执行报告活动应用程序也许需要在逻辑备数据库上执行DML插入更新和删除操作。它可能需要创建或删除表。可以设置database guard来允许报告操作更改数据只要数据不是由SQL Apply正在维护。
分两个步骤来实现对不是SQL Apply维护的表进行更改 1在逻辑备数据库上执行存储过程DBMS_LOGSTDBY.SKIP指定一组应用程序可以写数据的表。忽略的表不会被SQL Apply维护。 2设置database guard只保护备表。
在下面的示例中假设报告写的表也在主数据库上。
示例停止SQL Apply忽略需要修改的表重新启动SQL Apply。报告应用程序写到模式HR的对象TESTEMP%。这些表不再由SQL Apply维护。
SQL ALTER DATABASE STOP LOGICAL STANDBY APPLY; Database altered.
SQL EXECUTE DBMS_LOGSTDBY.SKIP(stmt ‘SCHEMA_DDL’,schema_name ‘HR’, object_name ‘TESTEMP%’); PL/SQL procedure successfully completed.
SQL EXECUTE DBMS_LOGSTDBY.SKIP(‘DML’,‘HR’,‘TESTEMP%’); PL/SQL procedure successfully completed.
SQL ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Database altered.
一旦SQL Apply启动它需要为增加到skip规则的新指定的表更新备数据库上的元数据。
在SQL Apply有机会更新元数据之前尝试更改新忽略的表会失败。执行以下查询可以确认SQL Apply是否已经成功将刚增加的SKIP规则考虑在内 SQL SELECT VALUE FROM SYSTEM.LOGSTDBY$PARAMETERS WHERE NAME ‘GUARD_STANDBY’;
VALUE
---------------
Ready当VALUE值显示为Ready时SQL Apply已经成功为略过的表更新所有相关的元数据可以安全地修改表。 4.5. 在逻辑备数据库上增加或重建表
一般情况下使用DBMS_LOGSTDBY.INSTANTIATE_TABLE存储过程在无法恢复的操作后重建表。
也可以使用这个存储过程来为之前跳过的表启用SQL Apply。
在创建表前必须满足“确保主数据库的表行可以被唯一区别”章节描述的要求。然后可以使用以下步骤来重建表HR.EMPLOYEES和恢复SQL Apply。指令假设已经存在一个定义来访问主数据库的链接BOSTON。
1停止SQL Apply SQL ALTER DATABASE STOP LOGICAL STANDBY APPLY;
2查询视图DBA_LOGSTDBY_SKIP确保有问题的表没有操作正在被忽略 SQL SELECT * FROM DBA_LOGSTDBY_SKIP;
ERROR STATEMENT_OPT OWNER NAME
----- ------------ ----- -----------
N SCHEMA_DDL HR EMPLOYEES
N DML HR EMPLOYEES
N SCHEMA_DDL OE TEST_ORDER
N DML OE TEST_ORDER因为在逻辑备数据库上已经有SKIP规则与想重建的表相关联必须首先删除这些规则。可以调用DBMS_LOGSTDBY.UNSKIP存储过程来完成。例如 SQL EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt ‘DML’, schema_name ‘HR’, object_name ‘EMPLOYEES’); SQL EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt ‘SCHEMA_DDL’, schema_name ‘HR’, object_name ‘EMPLOYEES’);
3 在逻辑备数据库使用它所有的数据来重建表HR.EMPLOYEES。例如 SQL EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE(schema_name ‘HR’, table_name ‘EMPLOYEES’, dblink ‘BOSTON’);
4启动SQL Apply SQL ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
为了确保新实例化的表和数据库的其余数据有一个一致性的视图在查询表之前等待SQL Apply追上主数据库。可以执行以下步骤来确认 1在主数据库上确认当前的SCN SQL SELECT CURRENT_SCN FROM V$DATABASEBOSTON;
CURRENT_SCN
---------------------
3451627882确保SQL Apply已经应用所有在CURRENT_SCN之前提交的事务 SQL SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS;
APPLIED_SCN
--------------------------
345161345当查询返回的APPLIED_SCN大于前面查询中返回的CURRENT_SCN时可以安全地查询新重建的表。 5管理逻辑备数据库环境下特定的负载
5.1. 导入可传输的表空间到主数据库
可传输的表空间可以导入到主数据库。
执行以下步骤 1禁用database guard设置从而可以修改逻辑备数据库 SQL ALTER DATABASE GUARD STANDBY;
2在逻辑备数据库导入表空间。
3启用database guard设置 SQL ALTER DATABASE GUARD ALL;
4在主数据库导入表空间。 5.2. 使用物化视图
逻辑备数据库自动跳过与物化视图有关的DDL语句。
例如逻辑备数据库跳过下面的语句 1CREATEALTER或DROP MATERIALIZED VIEW 2CREATEALTER或DROP MATERIALIZED VIEW LOG
在逻辑备数据库已经创建之后在主数据库上创建修改或删除的新的物化视图不会在逻辑备数据库上创建。然而在逻辑备数据库创建之前在主数据库上创建的物化视图存在于逻辑备数据库上。
逻辑备数据库支持本地创建和维护新的物化视图除了其他种类的辅助数据结构之外。例如OLTP系统为了更新性能会频繁地使用高度标准化normalized的表但这些会导致复杂决策支持查询的响应时间缓慢。为了在逻辑备数据库上有更高效的查询支持非标准化denormalize复制的数据的物化视图可以被创建如下在执行以下语句前以SYS用户连接 SQL ALTER SESSION DISABLE GUARD;
SQL CREATE MATERIALIZED VIEW LOG ON SCOTT.EMP WITH ROWID (EMPNO, ENAME, MGR, DEPTNO) INCLUDING NEW VALUES;
SQL CREATE MATERIALIZED VIEW LOG ON SCOTT.DEPT WITH ROWID (DEPTNO, DNAME) INCLUDING NEW VALUES;
SQL CREATE MATERIALIZED VIEW SCOTT.MANAGED_BY REFRESH ON DEMAND ENABLE QUERY REWRITE AS SELECT E.ENAME, M.ENAME AS MANAGER FROM SCOTT.EMP E, SCOTT.EMP M WHERE E.MGRM.EMPNO;
SQL CREATE MATERIALIZED VIEW SCOTT.IN_DEPT REFRESH FAST ON COMMIT ENABLE QUERY REWRITE AS SELECT E.ROWID AS ERID, D.ROWID AS DRID, E.ENAME, D.DNAME FROM SCOTT.EMP E, SCOTT.DEPT D WHERE E.DEPTNOD.DEPTNO;
在逻辑备数据库上 1ON-COMMIT物化视图会在事务提交发生时在逻辑备数据库上自动刷新。 2ON-DEMAND物化视图不会自动刷新必须执行DBMS_MVIEW.REFRESH存储过程来刷新。
例如执行以下命令来刷新在前面示例中创建的ON-DEMAND物化视图 SQL ALTER SESSION DISABLE GUARD; SQL EXECUTE DBMS_MVIEW.REFRESH (LIST ‘SCOTT.MANAGED_BY’, METHOD ‘C’);
如果DBMS_SCHEDULER工作被使用来定期刷新ON-DEMAND物化视图database guard必须设置为STANDBY。不可能在PL/SQL块中使用ALTER SESSION DISABLE GUARD语句和让它生效。 5.3. 在逻辑备数据库上的触发器和约束如何处理
缺省情况下触发器和约束会在逻辑备数据库上自动启用和处理。
对于由SQL Apply维护的表的触发器和约束 1约束—–检查约束会在主数据库上估值不需要在逻辑备数据库上重新估值 2触发器—在主数据库上执行触发器的效果会记录和应用到备数据库上。
对于不是SQL Apply维护的表的触发器和约束 1约束会估值 2触发器会触发 5.4. 使用触发器来复制不支持的表
在表上创建的DML触发器的参数DBMS_DDL.SET_TRIGGER_FIRING_PROPERTY fire_once缺省时设置为TRUE。
触发器只有在表被用户进程修改时才触发。在SQL Apply进程中它们会自动被禁用因此SQL Apply进程修改表时不会触发。作为SQL Apply进程更改维护的表的结果存在两种方法来触发触发器 1设置触发器的参数fire_once为FALSE允许它在用户进程或SQL Apply进程的环境中触发 2设置apply_server_onl参数为TRUE导致触发器只有在SQL Apply进程的环境中触发在用户进程的环境中不触发。
fire_onceapply_server_only描述TRUEFLASE这是DML触发器缺省的属性设置。触发器只有在用户进程修改基础表时触发。FALSEFALSE触发器在用户进程和SQL Apply进程修改基础表的环境中触发。可以使用DBMS_LOGSTDBY.IS_APPLY_SERVER函数区分这两种环境。TRUE/FALSETRUE触发器只有在SQL Apply进程修改基础表时触发。触发器在用户进程修改基础表时不触发。因此属性apply_server_only覆写触发器的参数fire_once。
由于简单对象类型列而不支持的表可以通过创建在SQL Apply环境中触发的触发器来复制设置触发器的参数fire_once为FALSE或设置触发器的apply_server_only参数为TRUE。可以在主数据库上使用普通的DML触发器来flatten对象类型到可以支持的表。在逻辑备数据库上SQL Apply环境中触发的触发器重组对象类型以事务的方式更新不支持的表。
下面的示例显示具有简单对象类型的表如何使用触发器来复制。示例显示如何处理插入相同的规则可以应用到更新和删除。嵌套表和VARRAY也可以使用这种技术和标准化嵌套数据的循环的额外步骤来复制。
-- simple object type
create or replace type Person as object
(FirstName varchar2(50),LastName varchar2(50),BirthDate Date
)-- unsupported object table
create table employees
(IdNumber varchar2(10) ,Department varchar2(50),Info Person
)-- supported table populated via trigger
create table employees_transfer
(t_IdNumber varchar2(10),t_Department varchar2(50),t_FirstName varchar2(50),t_LastName varchar2(50),t_BirthDate Date
)--
-- create this trigger to flatten object table on the primary
-- this trigger will not fire on the standby
--
create or replace trigger flatten_employeesafter insert on employees for each row
declare
begininsert into employees_transfer(t_IdNumber, t_Department, t_FirstName, t_LastName, t_BirthDate)values
(:new.IdNumber, :new.Department, :new.Info.FirstName,:new.Info.LastName, :new.Info.BirthDate);
end--
-- Option#1 (Better Option: Create a trigger and
-- set its apply-server-only property to TRUE)
-- create this trigger at the logical standby database
-- to populate object table on the standby
-- this trigger only fires when apply replicates rows
-- to the standby
--
create or replace trigger reconstruct_employees_asoafter insert on employees_transfer for each row
begininsert into employees (IdNumber, Department, Info)values (:new.t_IdNumber, :new.t_Department,Person(:new.t_FirstName, :new.t_LastName, :new.t_BirthDate));
end
-- set this trigger to fire from the apply server
execute dbms_ddl.set_trigger_firing_property(trig_owner scott, trig_name reconstruct_employees_aso, property dbms_ddl.apply_server_only, setting TRUE);--
-- Option#2 (Create a trigger and set
-- its fire-once property to FALSE)
-- create this trigger at the logical standby database
-- to populate object table on the standby
-- this trigger will fire when apply replicates rows to -- the standby, but we will need to make sure we are
-- are executing inside a SQL Apply process by invoking
-- dbms_logstdby.is_apply_server function
--
create or replace trigger reconstruct_employees_nfoafter insert on employees_transfer for each row
beginif dbms_logstdby.is_apply_server() theninsert into employees (IdNumber, Department, Info)values (:new.t_IdNumber, :new.t_Department,Person(:new.t_FirstName, :new.t_LastName, :new.t_BirthDate));end if;
end
-- set this trigger to fire from the apply server
execute dbms_ddl.set_trigger_firing_property(trig_owner scott, trig_name reconstruct_employees_nfo, property dbms_ddl.fire_once, setting FALSE);5.5.在主数据库执行时间点恢复
当逻辑备数据库收到新的redo数据分支时SQL Apply自动处理新分支的redo数据。
对于逻辑备数据库如果备数据库没有应用超过新resetlogs SCN的redo数据超过redo数据新分支的起点不需要进行人工干预。
下表描述了如何让备数据库与主数据库分支同步。
如果备数据库…那么…执行这些步骤…没有应用超过新resetlogs SCN超过redo数据新分支起点的redo数据SQL Apply自动处理新分支的redo数据不需要人工干预。SQL Apply使用新分支的redo数据自动同步备数据库。已经应用超过新resetlogs SCN超过redo数据新分支起点的redo数据和闪回数据库已经在备数据库上启用备数据库恢复到redo数据新分支的未来1闪回逻辑备数据库到特定的时间点。 2重启SQL Apply来继续应用redo数据到新的resetlogs分支。已经应用超过新resetlogs SCN超过redo数据新分支起点的redo数据和闪回数据库没有在备数据库上启用主数据库与备数据库在指定的主数据库分支上偏离重建逻辑备数据库缺失从之前分支的redo数据末尾开始的归档redo日志文件SQL Apply不能继续直到找回缺失的日志文件找到和注册来自之前分支的缺失的归档redo日志文件5.6. 在逻辑备数据库上运行Oracle流捕获进程
可以在逻辑备数据库上运行Oracle流捕获进程Oracle Streams capture process来捕获存在于逻辑备数据库上的任何表的更改不管它是一个本地表还是正在从主数据库复制的一个被维护的表。
当捕获到被维护的表的更改时跟运行在主数据库上的Oracle流捕获进程相比存在额外的延迟。额外的延迟是由于在逻辑备数据库时Oracle流捕获进程必须等待更改从主数据库传输到逻辑备数据库和被SQL Apply应用。在大部分情况下如果运行实时应用不会超过几秒钟。
Oracle流捕获进程与创建它的数据库关联与数据库的角色无关。例如假设有一个主数据库名为Boston和一个逻辑备数据库名为London。不可以在角色转换时从一个数据库移动Oracle流捕获进程到其他数据库。例如如果在逻辑备数据库London上创建Oracle流捕获进程那么它一直在London上即使London作为角色转换操作的结果例如swichover或failover成为主数据库。为了让Oracle流捕获进程在角色转换后继续工作必须写一个角色转换触发器比如以下
create or replace trigger streams_aq_job_role_change1
after DB_ROLE_CHANGE on database
declare
cursor capture_aq_jobs isselect job_name, database_rolefrom dba_scheduler_job_roleswhere job_name like AQ_JOB%;
u capture_aq_jobs%ROWTYPE;
my_db_role varchar2(16);beginif (dbms_logstdby.db_is_logstdby() 1) then my_db_role : LOGICAL STANDBY;else my_db_role : PRIMARY;end if;open capture_aq_jobs;
loopfetch capture_aq_jobs into u;exit when capture_aq_jobs%NOTFOUND;if (u.database_role ! my_db_role) thendbms_scheduler.set_attribute(u.job_name,database_role, my_db_role);end if;
end loop;
close capture_aq_jobs;exceptionwhen others thenbeginraise;end;
end;6调优逻辑备数据库
6.1. 创建主键依赖约束
在主数据库上如果一个表不存在主键或唯一索引和你确定行是唯一的那么可以创建一个主键RELY约束。
在逻辑备数据库上在组成主键的列上创建索引。下面的查询产生一系列表这些表没有索引信息可以被逻辑备数据库使用来唯一识别行。通过在下面的表上创建索引性能可以显著地改善。
SQL SELECT OWNER, TABLE_NAME FROM DBA_TABLES WHERE OWNER NOT IN (SELECT OWNER FROM DBA_LOGSTDBY_SKIP WHERE STATEMENT_OPT ‘INTERNAL SCHEMA’) MINUS SELECT DISTINCT TABLE_OWNER, TABLE_NAME FROM DBA_INDEXES WHERE INDEX_TYPE NOT LIKE (‘FUNCTION-BASED%’) MINUS SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED;
可以在主数据库上增加一个主键依赖约束到表如下所示 1在主数据库增加主键依赖约束 SQL ALTER TABLE HR.TEST_EMPLOYEES ADD PRIMARY KEY (EMPNO) RELY DISABLE;
这确保列EMPNO用来唯一识别表HR.TEST_EMPLOYEES的行作为表上所做的任何更新的一部分补充地记录下来。
注意表HR.TEST_EMPLYEES在逻辑备数据库上依旧没有指定唯一索引。这可能会导致UPDATE语句在逻辑备数据库上去做全表扫描。可以在逻辑备数据库上通过增加唯一索引来补救。 参考章节“确保主数据库的表行可以被唯一区别”关于RELY约束的描述。
2停止SQL Apply SQL ALTER DATABASE STOP LOGICAL STANDBY APPLY;
3禁用guard从而可以修改逻辑备数据库上的被维护表 SQL ALTER SESSION DISABLE GUARD;
4在列EMPNO上增加唯一索引 SQL CREATE UNIQUE INDEX UI_TEST_EMP ON HR.TEST_EMPLOYEES (EMPNO);
5启用guard SQL ALTER SESSION ENABLE GUARD;
6启用SQL Apply SQL ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 6.2. 在逻辑备数据库上收集数据
在逻辑备数据库上使用STATS 包和视图 V$SYSSTAT 确认哪些表消耗大部分资源和表扫描。 6.3. 调整进程的数量
有3个参数可以被修改来控制分配给SQL Apply的进程数量MAX_SERVERSAPPLY_SERVERS和PREPARE_SERVERS。
下面的关系必须总是适用的 1APPLY_SERVERS REPARE_SERVERS MAX_SERVERS -3
因为SQL Apply总是分别为READERBUILDER和ANALYZER角色分配一个进程。
2缺省时MAX_SERVERS设置为9PREPARE_SERVERS设置为1和APPLY_SERVERS设置为5。
3Oracle建议通过DBMS_LOGSTDBY.APPLY_SET存储过程只更改MAX_SERVERS参数允许SQL Apply在PREPARE和APPLY进程之间合理地分配服务器进程。
4SQL Apply使用进程分配算法来为分配给SQL Apply的每20个服务器进程由MAX_SERVERS指定分配1个PREPARE_SERVER进程和限制PREPARE_SERVERS的数量为5。因此如果设置MAX_SERVERS为1和20之间的任意值SQL Apply分配1个服务器进程来担任PREPARER在满足前面描述的关系后分配剩余的进程为APPLIERS。相似地如果设置MAX_SERVERS的值在21和24之间SQL Apply分配2个服务器进程来担任PREPARERS在满足前面描述的关系后分配剩余的进程为APPLIERS。只要前面描述的关系满足时可以通过直接设置APPLY_SERVERS和PREPARE_SERVERS来覆盖内部的进程分配算法。 6.3.1调整APPLIER进程的数量
在调整APPLIER进程的数量之前应该确认这样做是否会帮助获得更高的吞吐量。
为了确认这个执行以下步骤 1执行以下查询检查APPLIER进程是否繁忙 SQL SELECT COUNT(*) AS IDLE_APPLIER FROM V$LOGSTDBY_PROCESS WHERE TYPE ‘APPLIER’ and status_code 16116;
IDLE_APPLIER
-------------------------
0一旦确认不存在空闲的APPLIER进程执行以下查询来确保如果选择调整APPLIERS进程的数量存在足够的可用工作来使用额外的APPLIER进程。 SQL SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME ‘txns applied’ OR NAME ‘distinct txns in queue’;
这两个统计数字存放准备被APPLIER进程应用的累积的事务总数和和已经被应用的事务数量。 如果数字distinct txns in queue – txns applied高于2倍的可用APPLIER进程数量增加APPLIER进程的数量可能会带来吞吐量的提升。
假设想调整APPLIER进程的数量从缺省的5到20同时保持PREPARER进程的数量为1。由于需要满足以下等式 APPLY_SERVERS REPARE_SERVERS MAX_SERVERS -3 必须首先设置MAX_SERVERS为24。一旦完成后就可以设置APPLY_SERVERS的数量为20如下所示 SQL EXECUTE DBMS_LOGSTDBY.APPLY_SET(‘MAX_SERVERS’, 24); SQL EXECUTE DBMS_LOGSTDBY.APPLY_SET(‘APPLY_SERVERS’, 20); 6.3.2调整PREPARER进程的数量
需要调整PREPARER进程的数量是比较少见的。在增加它们的数量前必须确保某些条件为真如下所示 1所有PREPARER进程很繁忙 2准备应用的事务数量比可用的APPLIER进程少 3存在空闲的APPLIER进程。
下面的步骤显示如何确认这些条件为真 1确认所有REPARER进程繁忙 SQL SELECT COUNT(*) AS IDLE_PREPARER FROM V$LOGSTDBY_PROCESS WHERE TYPE ‘PREPARER’ and status_code 16116;
IDLE_PREPARER
-------------
02确认准备应用的事务数量比可用的APPLIER进程少 SQL SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME ‘txns applied’ OR NAME ‘distinct txns in queue’;
NAME VALUE
--------------------- -------
txns applied 27892
distinct txns in queue 12896SQL SELECT COUNT(*) AS APPLIER_COUNT FROM V$LOGSTDBY_PROCESS WHERE TYPE ‘APPLIER’;
APPLIER_COUNT
-------------
20注执行查询几次来确保这不是瞬时的事件。
3确保存在空闲的APPLIER进程 SQL SELECT COUNT(*) AS IDLE_APPLIER FROM V$LOGSTDBY_PROCESS WHERE TYPE ‘APPLIER’ and status_code 16116;
IDLE_APPLIER
-------------------------
19在这个例子中为增加PREPARER进程数量的所有3个必要条件都满足。假设想保持APPLIER进程的数量为20和增加PREPARER进程的数量从缺省的1到3。由于需要满足以下等式 APPLY_SERVERS REPARE_SERVERS MAX_SERVERS -3 必须首先增加MAX_SERVERS从24到26来容纳增加的PREPARER进程。然后就可以增加PREPARER进程的数量如下所示 SQL EXECUTE DBMS_LOGSTDBY.APPLY_SET(‘MAX_SERVERS’, 26); SQL EXECUTE DBMS_LOGSTDBY.APPLY_SET(‘PREPARE_SERVERS’, 3); 6.4调整LCR(logical change records)缓存使用的内存
对于某些负载SQL Apply可能会使用大量的页出操作因此减少系统总体的吞吐量。增加分配给LCR缓存的内存可能会有所帮助。
执行以下步骤确认增加分配给LCR缓存的内存是否是有益的 1执行以下查询来获取页出活动的快照 SQL SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE ‘%page%’ OR NAME LIKE ‘%uptime%’ OR NAME LIKE ‘%idle%’;
NAME VALUE
---------------------------- --------------
coordinator uptime (seconds) 894856
bytes paged out 20000
pageout time (seconds) 2
system idle time (seconds) 100025分钟后再次执行查询 SQL SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE ‘%page%’ OR NAME LIKE ‘%uptime%’ OR NAME LIKE ‘%idle%’;
NAME VALUE
---------------------------- --------------
coordinator uptime (seconds) 895156
bytes paged out 1020000
pageout time (seconds) 100
system idle time (seconds) 10003计算标准化的页出活动。例如 Change in coordinator uptime © (895156 – 894856) 300 secs Amount of additional idle time (I) (1000 – 1000) 0 Change in time spent in pageout § (100 – 2) 98 secs Pageout time in comparison to uptime P/(C-I) 98/300 ~ 32.67%
理想情况下页出活动应该不要消耗多于5%的总运行时间。如果继续在持续的间隔里拍快照发现页出活动继续消耗相当部分的应用时间增加内存大小可能会提供某些好处。可以通过设置分配给LCR缓存的内存来增加分配给SQL Apply的内存这个示例中SGA设置为1GB SQL EXECUTE DBMS_LOGSTDBY.APPLY_SET(‘MAX_SGA’, 1024); PL/SQL procedure successfully completed 6.5. 调整事务如何在逻辑备数据库上应用
缺省时事务在逻辑备数据库上按照在主数据库上提交的精确的顺序被应用。
这种严格的提交事务的缺省顺序允许任何应用程序在逻辑备数据库上透明地运行。
然而许多应用程序在所有事务当中不需要如此严格的排序。这些应用程序不需要包含不重叠的行集的事务按照与主数据库上相同的提交顺序提交。这种较不严格的排序通常会在逻辑备数据库上带来更高的应用速度。执行以下步骤可以更改提交事务的缺省顺序 1停止SQL Apply: SQL ALTER DATABASE STOP LOGICAL STANDBY APPLY;
2执行以下命令允许事务不按照在主数据库上提交的顺序应用 SQL EXECUTE DBMS_LOGSTDBY.APPLY_SET(‘PRESERVE_COMMIT_ORDER’, ‘FALSE’);
3启动SQL Apply SQL ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
使用以下步骤更改回应用模式 1停止SQL Apply: SQL ALTER DATABASE STOP LOGICAL STANDBY APPLY;
2恢复参数PRESERVE_COMMIT_ORDER的缺省值 SQL EXECUTE DBMS_LOGSTDBY.APPLY_UNSET(‘PRESERVE_COMMIT_ORDER’);
3启动SQL Apply SQL ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
对于典型的在线事务处理OLTP负载不是缺省的模式对比缺省的模式可以提供50%或更高的吞吐量提升。 7逻辑备数据库环境下的备份和恢复
可以使用传统的可用方法来备份逻辑备数据库然后通过还原数据库备份和与备份结合在归档日志上执行介质恢复来恢复数据库。
下面的项目在逻辑备数据库的环境下是相关的。
创建和使用本地RMAN恢复目录时的考虑 如果计划创建RMAN恢复目录或执行任何修改恢复目录的RMAN活动必须在逻辑备数据库上设置GUARD为STANDBY。 如果本地恢复目录只保留在逻辑备数据库的控制文件中可以让GUARD设置为ALL。
控制文件备份的考虑 Oracle建议在实例化逻辑备数据数据库后立即备份控制文件。
时间点恢复考虑 当SQL Apply在时间点恢复后第一次启动时必须可以在本地系统上找到要求的归档日志或从主数据库上获取。使用V$LOGSTDBY_PROCESS视图来确认主数据库上是否有任何需要还原的归档日志。
表空间时间点恢复考虑 如果在逻辑备数据库上执行表空间的时间点恢复必须确保满足以下条件中的一个 1表空间不包含由SQL Apply进程正在维护的表或分区 2如果表空间包含由SQL Apply进程正在维护的表或分区那么使用DBMS_LOGSTDBY.INSTANTIATE_TABLE存储过程在逻辑备数据库上重新实例化所有包含在恢复表空间的维护的表或使用DBMS_LOGSTDBY.SKIP存储过程注册所有包含在恢复表空间的表在逻辑备数据库上从维护表列表中跳过这些表。 8主数据库执行Open Resetlogs语句后闪回数据库
如果在Oracle Data Guard环境的主数据库发生一个错误备数据库正在使用实时应用那么相同的错误也会应用到备数据库。如果闪回数据库已启用可以复原主数据库和备数据库到错误之前的状态。
为了这些做在主数据库上执行FLASHBACK DATABASE和OPEN RESETLOGS语句然后在重启Apply Service之前在备数据库上执行相应的FLASHBACK STANDBY DATABASE语句。如果闪回数据库没有启用那么在主数据库上执行时间点恢复之后需要重建备数据库。
8.1. 闪回逻辑备数据库到指定时间点
这些步骤描述如何闪回主数据库和使用OPEN RESETLOGS语句打开它后避免重建逻辑备数据库。
注如果SQL Apply检测到主数据库resetlogs操作的发生如果可能这么做而不需要闪回逻辑备数据库它会自动挖掘正确的redo分支。否则SQL Apply会停止和报错“ORA-1346: LogMiner processed redo beyond specified reset log scn”。在这个部分中假设SQL Apply已经停止和有这个报错。
1在主数据库上使用以下查询来获取主数据库在RESETLOGS操作发生前2个SCN的SCN值: SQL SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) AS FLASHBACK_SCN FROM V$DATABASE;
2在逻辑备数据库上确认闪回操作的目标SCN。 SQL SELECT DBMS_LOGSTDBY.MAP_PRIMARY_SCN (PRIMARY_SCN FLASHBACK_SCN) AS TARGET_SCN FROM DUAL;
3执行下面的SQL语句来闪回逻辑备数据库到指定的SCN然后使用RESETLOGS选项打开逻辑备数据库 SQL SHUTDOWN; SQL STARTUP MOUNT EXCLUSIVE; SQL FLASHBACK DATABASE TO SCN TARGET_SCN; SQL ALTER DATABASE OPEN RESETLOGS;
4 在SQL启动之前确认来自主数据库新分支的日志文件已经注册。
在主数据库执行以下查询: SQL SELECT resetlogs_id FROM V$DATABASE_INCARNATION WHERE status ‘CURRENT’;
在备数据库上执行以下查询 SQL SELECT * FROM DBA_LOGSTDBY_LOG WHERE resetlogs_id resetlogs_id_at_primary;
如果返回一行或多行它确认存在注册的来自主数据库新分支的日志文件。
1 启动SQL Apply SQL ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 9. 主数据库指定NOLOGGING子语句以后恢复
有些SQL语句允许指定NOLOGGING子语句因此操作就不会记录在在线redo日志文件中。
实际上redo记录仍然会写到在线redo日志文件但没有数据与记录关联。这将导致备站点上的日志应用程序或数据访问错误可能需要手动恢复来重新开始applying日志文件。
9.1. 在逻辑备数据库上的恢复步骤
在逻辑备数据库上当SQL Apply遇到在表上执行NOLOGGING子语句的操作的redo记录时它会停止和报以下错误 ORA-16211 unsupported record found in the archived redo log
为了在指定的NOLOGGING子语句之后进行恢复按照章节“在逻辑备数据库上增加或重建表”所描述的方法重建来自主数据库的一个或多个表。
注一般情况下使用NOLOGGING子语句是不建议的。因此如果你提前知道使用NOLOGGING子语句的操作会在主数据库的某些表上执行那么你可能想阻止应用与这些表相关的SQL语句到逻辑备数据库。可以通过使用DBMS_LOGSTDBY.SKIP存储过程来实现。 来源《Oracle Data Guard Concepts and Administration, 19c》
