如何建设本地网站,大同网站建设开发,如何查看wordpress版本,深圳坪山医院1#xff0e;打开物理备数据库
物理备数据库可以打开做只读访问#xff0c;用于从主数据库卸载查询负载。
如果已经购买Oracle Active Data Guard选项的授权#xff0c;当数据库打开时Redo Apply可以是激活的#xff0c;因此允许查询返回与从主数据库返回的完全相同的结果…1打开物理备数据库
物理备数据库可以打开做只读访问用于从主数据库卸载查询负载。
如果已经购买Oracle Active Data Guard选项的授权当数据库打开时Redo Apply可以是激活的因此允许查询返回与从主数据库返回的完全相同的结果。这个功能也称为实时查询特性。 1.1. 实时查询
数据库初始化参数COMPATIBLE必须设置成11.0或更高来使用Oracle Active Data Guard选项的实时查询特性。
如果挂载的数据库实例上Redo Apply是活动的物理备数据库实例不能被打开。使用以下SQL语句停止Redo Apply以只读方式打开备数据库实例然后重启Redo Apply SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; SQL ALTER DATABASE OPEN; SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
注如果在一个打开的实例上Redo Apply是活动的其他备数据库实例不用停止Redo Apply就可以被打开。
如果物理备数据库的其他实例在打开状态挂载的物理备数据库实例上的Redo Apply不可以启动。实例必须打开后再启动Redo Apply。
以下示例显示V$DATABASE.OPEN_MODE列在物理数据库以实时查询模式打开时的变化。
SQL select open_mode from v$database;
OPEN_MODE
--------------------
MOUNTEDSQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Database altered.SQL ALTER DATABASE OPEN;
Database altered.SQL SELECT open_mode FROM V$DATABASE;
OPEN_MODE
--------------------
READ ONLYSQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
Database altered.SQL select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY1.1.1. 监控实时查询环境中的延迟应用
如果使用实时查询来从主数据库卸载查询到物理备数据库可以监控应用延迟来确保它在可以接受的范围内。
当前的应用延迟是在上次应用的更改在备数据库上可见和相同的更改在主数据库上可见之间过去的时间的差异。
查询视图V$DATAGUARD_STATS获得应用延迟。 SQL SELECT name, value, datum_time, time_computed FROM V$DATAGUARD_STATS WHERE name like ‘apply lag’;
NAME VALUE DATUM_TIME TIME_COMPUTED
--------- ------------- ------------------- -------------------
apply lag 00 00:00:00 05/27/2009 08:54:16 05/27/2009 08:54:17apply lag度量值是使用从主数据库定期接收的数据计算的。DATUM_TIME列包含备数据库上次接收数据的时间戳。TIME_COMPUTED列包含计算apply lag度量时的时间戳。这些列的值的差异应该少于30秒如果差异大于30秒apply lag度量值可能会不准确。
查询视图V$STANDBY_EVENT_HISTOGRAM获取显示从备实例上次启动以来的apply lag的历史值直方图。
SQL SELECT * FROM V$STANDBY_EVENT_HISTOGRAM WHERE NAME ‘apply lag’ AND COUNT 0;
NAME TIME UNIT COUNT LAST_TIME_UPDATED
--------- --------- -------- ----------- ------------------------
apply lag 0 seconds 79681 06/18/2009 10:05:00
apply lag 1 seconds 1006 06/18/2009 10:03:56
apply lag 2 seconds 96 06/18/2009 09:51:06
apply lag 3 seconds 4 06/18/2009 04:12:32
apply lag 4 seconds 1 06/17/2009 11:43:51
apply lag 5 seconds 1 06/17/2009 11:43:52注COUNT值是应用延迟落在这个时间范围内的次数物理备数据库每秒采集一次数据增加直方图中对应的时间范围的COUNT值。
为了评估一段时间的apply lag可以在时间段的开始对视图V$STANDBY_EVENT_HISTOGRAM做个快照然后在时间段的末尾再对视图做个快照进行对比。 1.1.2. 在实时查询环境中配置apply lag tolerance
会话参数STANDBY_MAX_DATA_DELAY可以用来为非管理用户向处于实时查询模式的物理备数据库发出的查询指定会话特定的应用延迟容忍值以秒为单位。
这个特性允许查询安全地从主数据库卸载到物理备数据库因为它可以检测到备数据库是否变成不可接受的已过时的。
STANDBY_MAX_DATA_DELAY值说明NONE缺省值不管备数据库的应用延迟多少总是执行向物理备数据库发出的查询。非零值只有应用延迟少于或等于STANDBY_MAX_DATA_DELAY值时才执行向物理备数据库发出的查询。0向物理备数据库发出的查询保证会返回与在主数据库上发出的查询完全相同的结果除非物理备数据库落后于主数据库这时会返回ORA-3172错误。
使用ALTER SESSION语句设置STANDBY_MAX_DATA_DELAY值 SQL ALTER SESSION SET STANDBY_MAX_DATA_DELAY2 1.1.3. 在实时查询环境中强制Redo Apply同步
为了确保所有从主数据库接收的redo数据已经应用到物理备数据库可以使用以下SQL语句 SQL ALTER SESSION SYNC WITH PRIMARY;
语句会阻塞直到在命令发出时备数据库接收到的所有redo数据已经应用到物理备数据库。如果备数据库的redo传输状态不是SYNCHRONIZED或Redo Apply不是活动的将会立即返回错误ORA-3173不会进行同步。
在某些特定的情况下为了确保执行Redo Apply同步使用函数SYS_CONTEXT(‘USERENV’,‘DATABASE_ROLE’)创建备数据库专用的触发器在主数据库上启用但只有运行在备数据库上才会采取某些行动。例如在某个特定用户登录连接时才执行ALTER SESSION SYNC WITH PRIMARY语句 CREATE TRIGGER adg_logon_sync_trigger AFTER LOGON ON user.schema begin if (SYS_CONTEXT(‘USERENV’, ‘DATABASE_ROLE’) IN (‘PHYSICAL STANDBY’)) then execute immediate ‘alter session sync with primary’; end if; end; 1.1.4. 实时查询限制
以下是实时查询模式的相关限制 1以上描述的应用延迟控制和Redo Apply同步机制要求客户端连接和发出查询的物理备数据库在实时查询模式 2如果应用延迟控制参数STANDBY_MAX_DATA_DELAY设置为0或使用了SQL语句ALTER SESSION SYNC WITH PRIMARY还有下面的限制 a. 备数据库必须通过SYNC传输接收redo数据 b. 备数据库的redo传输状态必须是SYNCHRONIZED和主数据库必须运行在最大保护模式或最大可用模式 c. 实时Apply必须启用 3Oracle Active Data Guard在Oracle RAC环境中通过使用缓存融合cache fusion来获得实时查询的高性能。这允许Oracle Data Guard apply instance和查询在缓存上工作而不被磁盘I/O限制减慢速度。 1.1.5. 自动块介质恢复
如果数据库被访问时遇到了损坏的数据块它们可以自动被没有损坏的数据块拷贝替换。自动块介质恢复要求符合以下条件 1物理备数据库必须运行在实时查询模式需要购买Oracle Active Data Guard授权 2物理备数据库必须运行实时Apply。
取决于是在主数据库还是备数据库上遇到损坏块自动块介质恢复运行在两个方向上。
主数据库的损坏块 如果在主数据库上遇到了损坏数据块主数据库会在备数据库上自动搜索这些数据块未损坏的拷贝如果找到了将它们传输回主数据库。 主数据库只需要设置了LOG_ARCHIVE_DEST_n参数指向备数据库。
备数据库的损坏块 如果在备数据库上遇到了损坏数据块备数据库自动发起与主数据库的通讯请求这些数据块的未损坏的拷贝。为了让主数据库可以传输这些未损坏的数据块到备数据库下面的数据库初始化参数必须在备数据库上配置。即使主数据库不是直接为备数据库提供服务例如在层叠配置中也需要配置。 配置参数LOG_ARCHIVE_CONFIG包含DG_CONFIG列表和为主数据库配置LOG_ARCHIVE_DEST_n参数。 或 配置FAL_SERVER参数它的值包含主数据库的Oracle网络服务名。
额外的自动块介质修复说明 1Oracle Data Guard保护模式支持自动修复但是使用备数据库非损坏版本的数据块修复主数据库的损坏块的效果取决于备数据库的Redo Apply与主数据库生成的redo同步的紧密程度。 2当执行自动块修复时相关消息会写到数据库alert日志里。 3如果块不能自动修复会返回ORA-1578错误。 1.1.6. 手动块介质恢复
RMAN的RECOVER BLOCK命令可以用来手动修复损坏的数据块。命令从几个位置搜索数据块的非损坏拷贝。缺省时其中一个位置是任何可用的运行在实时查询模式下的物理备数据库。 RMAN的RECOVERY BLOCK命令的EXCLUDE STANDBY选项可以用来排除物理备数据库作为替换块的来源。 1.1.7. 增加临时文件到物理备数据库
如果使用备数据库来从主数据库卸载查询那么备数据库必须至少配置使用一个临时数据文件的临时表空间。 如果负载本质上比备数据库第一次创建时自动创建的要求更多的表空间可以手动增加额外的空间。
执行以下步骤来为物理备数据库增加临时文件 1确认包含临时文件的表空间。在物理备数据库上执行以下语句 SQL SELECT TABLESPACE_NAME FROM DBA_TABLESPACES WHERE CONTENTS ‘TEMPORARY’;
TABLESPACE_NAME
--------------------------------
TEMP1
TEMP22对于在步骤1中确认的每个表空间增加一个临时文件到备数据库。 SQL ALTER TABLESPACE TEMP1 ADD TEMPFILE ‘/arch1/boston/temp01.dbf’ SIZE 40M REUSE; 2需要在物理备数据库中人工干预的主数据库更改
大部分主数据库的结构性更改会通过redo数据自动传播到物理备数据库但有些更改需要人工干预。
下面列出了需要在物理备数据库上人工干预的主数据库的结构性和配置更改。
主数据库更改要求在物理备数据库上人工干预的操作增加数据文件或创建表空间如果STANDBY_FILE_MANAGEMENT数据库初始化参数设置为AUTO那么不需要人工操作。 如果参数设置为MANUAL新的数据文件必须手工复制到物理备数据库。删除表空间或删除数据文件在包含DROP或DELETE命令的redo数据应用到物理备数据库后从主数据库和物理备数据库删除数据文件在物理备数据库使用可传输表的空间在主数据库和物理备数据库之间移动表空间在主数据库重命名数据文件在物理备数据库上重命名数据文件增加或删除redo日志文件组在物理备数据库上评估redo日志和备redo日志然后进行必要的调整NOLOGGING或不能恢复的操作使用RMAN命令的RECOVER … NOLOGGED BLOCK用主数据库的更改过的数据坏来替换备数据库上的无效数据块更新密码文件从Oracle数据库12.2.0.1版本开始主数据库上的密码文件更改会自动传播到备数据库。唯一的例外是far sync实例。更新的密码文件必须手动拷贝到far sync实例因为far sync实例接收redo但不应用redo数据。Far sync实例上的密码文件更新后主数据库上包含密码更新的redo数据会自动传播到设置从far sync实例接收redo的备数据库上。当redo应用时备数据库上的密码文件就会更新。重置TDE主加密密钥使用主数据库上的新的数据库加密钱包拷贝替换物理备数据库上的数据库加密钱包初始化参数评估物理备数据库上的初始化参数是否要做相应的更改2.1.增加数据文件或创建表空间
数据库初始化参数STANDBY_FILE_MANAGEMENT控制主数据库增加数据文件是否会自动传播到物理备数据库。 1如果物理备数据库的数据库参数STANDBY_FILE_MANAGEMENT设置为AUTO在主数据库上创建的新数据文件会自动在物理备数据库上创建 2如果物理备数据库的数据库参数STANDBY_FILE_MANAGEMENT设置为MANUAL主数据库上的新数据文件必须在增加后手动拷贝到物理备数据库。
注如果物理备数据库的Oracle Actvie Data Guard选项已经启用不能使用手工拷贝方法。 必须执行以下SQL语句来创建空的数据文件 SQL ALTER DATABASE CREATE DATAFILE [filename | filenumber] AS [NEW | new_filename]; 必须指定filename或filenumber来重命名同时指定新的文件名或NEW。如果启用了OMFOracle Managed FilesNEW关键字让Oracle自动选择一个文件名。
如果从其他数据库拷贝一个存在的数据文件到主数据库不管STANDBY_FILE_MANAGEMENT参数设置为何值也必须拷贝该数据文件到物理备数据库和重建备数据库的控制文件。 2.2.删除表空间和数据文件
当从主数据库删除表空间或数据文件时相应的数据文件也必须 从物理备数据库上删除。 下面示例如何删除表空间 SQL DROP TABLESPACE tbs_4; SQL ALTER SYSTEM SWITCH LOGFILE;
查询视图V$DATAFILE确认删除的数据文件是否还属于数据库。
在包含删除表空间操作的redo数据已经应用到备数据库后删除相应的数据文件 % rm /disk1/oracle/oradata/payroll/s2tbs_4.dbf
在主数据库上在确保备数据库应用了包含删除表空间的redo数据后可以删除表空间的数据文件 % rm /disk1/oracle/oradata/payroll/tbs_4.dbf 2.2.1.使用DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES语句
可以在主数据库上使用SQL语句DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES在主数据库和备数据库上都删除数据文件。
为了使用这个语句初始化参数STANDBY_FILE_MANAGEMENT必须设置为AUTO。 SQL DROP TABLESPACE tbs_4 INCLUDING CONTENTS AND DATAFILES; SQL ALTER SYSTEM SWITCH LOGFILE; 2.3. 物理备数据库使用可传输表空间
可以使用Oracle可传输表空间特性来移动数据库的子集和插入到其他Oracle数据库本质上在数据库之间实现表空间移动。
当使用物理备数据库时执行以下步骤来移动或拷贝表空间集到主数据库 1生成包含数据文件的可传输表空间集和包含表空间结构信息的export文件
2传输表空间集 a. 拷贝数据文件和export文件到主数据库 b. 拷贝数据文件到备数据库
主数据库和备数据库上的数据文件必须拥有相同的路径名称除非已经配置DB_FILE_NAME_CONVERT数据库初始化参数。如果没有设置参数DB_FILE_NAME_CONVERT而主备数据库的数据文件路径名不同时使用ALTER DATABASE RENAME FILE语句重命名数据文件。在Redo Apply应用插入表空间到主数据库生成的redo数据失败后再进行操作。在重命名前初始化参数STANDBY_FILE_MANAGEMENT必须设置为MANUAL然后在重命名数据文件后再重新设置为之前的值。
3插入表空间。 使用Data Pump工具将表空间集插入到主数据库。插入操作会生成Redo数据然后在备数据库上应用redo插入表空间到备数据库。 2.4. 在主数据库上重命名数据文件
当重命名一个或更多主数据库的数据文件时更改不会传播到备数据库必须手动更改。
重命名物理备数据库上的相同数据文件时必须在备数据库上手动进行相同的更改因为修改不会自动执行即使初始化参数STANDBY_FILE_MANAGEMENT设置为AUTO。
以下步骤描述如何在主数据库上重命名数据文件和手动传播更改到备数据库。 1 为了重命名主数据库的数据文件将表空间脱机 SQL ALTER TABLESPACE tbs_4 OFFLINE;
2 退出SQL提示符执行操作系统命令例如UNIX的mv命令在主数据库所在的系统上重命名数据文件 % mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf
3 在主数据库上重命名数据文件然后将表空间联机 SQL ALTER TABLESPACE tbs_4 RENAME DATAFILE ‘/disk1/oracle/oradata/payroll/tbs_4.dbf’ TO ‘/disk1/oracle/oradata/payroll/tbs_x.dbf’;
SQL ALTER TABLESPACE tbs_4 ONLINE;
注可替代以上3个步骤的方法是使用ALTER DATABASE MOVE DATAFILE命令来重命名数据文件。命令可以让数据文件在重命名的同时继续被读写访问。足够的剩余存储空间是命令执行的前提条件因为在执行MOVE DATAFILE命令的过程中数据库需要同时维护原数据文件和重命名的数据文件这两个不同的文件。
4 连接到备数据库停止Redo Apply SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
5 关闭备数据库 SQL SHUTDOWN;
6 使用操作系统命令重命名备数据库的数据文件例如UNIX mv命令 % mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf
7 启动和挂载备数据库 SQL STARTUP MOUNT;
8在备数据库的控制文件中重命名数据文件。为了重命名数据文件必须设置STNADBY_FILE_MANAGEMENT参数为MANUAL在完成重命名数据文件后再重新设置参数为之前的值。 SQL ALTER DATABASE RENAME FILE ‘/disk1/oracle/oradata/payroll/tbs_4.dbf’ TO ‘/disk1/oracle/oradata/payroll/tbs_x.dbf’;
9在备数据库上重新启动Redo Apply SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
如果在备系统上没有重命名相应的数据文件然后尝试刷新备数据库的控制文件备数据库尝试使用重命名的数据文件但会无法找到它。类似下面的消息会写到alert日志中 ORA-00283: recovery session canceled due to errors ORA-01157: cannot identify/lock datafile 4 - see DBWR trace file ORA-01110: datafile 4: ‘/Disk1/oracle/oradata/payroll/tbs_x.dbf’
注如前面所述可替换步骤4-9的方法是使用ALTER DATABASE MOVE DATAFILE命令来在备数据库上重命名数据文件。 2.5. 增加或删除redo日志文件组
在主数据库上增加和删除日志文件组后需要对物理备数据库上的在线redo日志和备redo日志的配置重新评估和进行必要的调整。
采取以下步骤在物理备数据为上添加或删除日志文件组或备日志文件组 1停止Redo Apply: SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 2如果STANDBY_FILE_MANAGEMENT初始化参数设置为AUTO更改为MANUAL。 SQL alter system set standby_file_managementmanual; 3增加或删除日志文件组 注在从物理备数据库删除前必须先清空在线日志组例如 ALTER DATABASE CLEAR LOGFILE GROUP 3; 状态为CURRENT或CLEARING_CURRENT的在线日志文件组不能从物理备数据库上删除。具有这种状态的在线日志组在角色转换后可以删除。 4 恢复STANDBY_FILE_MANAGEMENT初始化参数的值 5 重新启动Redo Apply。
在Oracle RAC环境中注意以下几点 1 当主数据库增加在线redo日志组的时候必须手动在备数据库增加在线redo日志组。这个不会自动完成。 2 当主数据库增加一个新的redo线程备数据库上会自动增加一个新的redo线程。缺省情况下新的线程会配置2个100MB的日志组不能更改或覆写。 3 当增加一个新的日志组到现有的redo线程新的日志组不会自动增加到现有的线程When a new log group is added to an existing redo thread, a new log group is not automatically added to its existing thread。 2.6. NOLOGGING或不可恢复的操作
当使用NOLOGGING或UNRECOVERABLE子语句执行DML或DLL操作时备数据库上的数据块可能会被标记为无效的也称为非日志块。
当redo应用到物理备数据库时一部分数据文件会被标记为不可恢复。当故障切换到物理备数据库或以只读模式打开备数据库时尝试读取标记为UNRECOVERABLE的数据块的区块图时会看到类似以下的错误信息 ORA-01578: ORACLE data block corrupted (file # 1, block # 2521) ORA-01110: data file 1: ‘/oracle/dbs/stdby/tbs_1.dbf’ ORA-26040: Data block was loaded using the NOLOGGING option
当使用STANDBY NOLOGGING FOR LOAD PERFORMANCE模式时在物理备数据库上执行的查询仍然可能会因为nologging操作而报告损坏块。然而当管理的恢复managed recovery作为Active Data Guard配置的一部分运行在备数据库上时它自动会从主数据库提取替换块。管理的恢复使用ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT来启动。管理的恢复在数据块开始创建之后不久就尝试提取所有这些块和继续尝试修复它们直到成功为止。无论何时启动管理恢复它会再开始修复任何在前面恢复会话中的未完成的块。这个自动的恢复只应用到STANDBY NOLOGGING FOR LOAD PERFORMANCE模式启用时产生的redo导致的损坏块。由于传统的nonlogged操作损坏的数据块必须使用以下步骤来进行恢复。
1 在备数据库上停止恢复 SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
2 使用RMAN连接到备数据库执行以下命令来恢复nonlogged数据块 RMAN RECOVER DATABASE NONLOGGED BLOCK;
如果不可恢复的数据块只在switchover后被发现存在那么可以使用这两个相同的步骤但主数据库必须在mount状态不是open和RMAN必须连接到主数据库。
RMAN的RECOVER命令也许不能恢复所有nonlogged的数据块。可能发生的原因会详细地列在执行RMAN命令的数据库的alert.log文件中。最普遍的原因是数据块最近在主数据库上被更改还没有写入到相应的数据文件中。这可能意味着发送到备数据库的数据块太旧而不能替换备数据库上的不可恢复块。为了解决这个问题在迟些时间数据块被写出到数据文件之后再次执行RECOVER命令。 2.6.1.确认在不可恢复操作之后是否需要备份
如果在主数据库上执行不可恢复的操作那么需要确认是否需要进行新的备份操作。
采取以下步骤来操作 1在主数据库上查询视图V$DATAFILE来确认数据库产生最近无效redo数据的SCNsystem change number或时间。
2在主数据库上执行以下SQL语句来确认是否需要执行另外一个备份 SQL SELECT UNRECOVERABLE_CHANGE#,TO_CHAR(UNRECOVERABLE_TIME, ‘mm-dd-yyyy hh:mi:ss’) FROM V$DATAFILE;
3如果在前面步骤的查询报告数据文件的不可恢复的时间比上一次数据文件备份的时间更近那么对有问题的数据文件再做另外一次备份。 2.6.2. 物理备数据库的部分恢复步骤
RMAN命令RECOVER … NONLOGGED BLOCK可以用来恢复属于一组数据文件或表空间的数据块。
这个功能可能有用如果可以接受在某些数据文件中仍然含有nonlogged数据块例如因为明确知道nologged数据块作为导入行到现在已经被删除的对象的结果而创建的。
视图V$NONLOGGED_BLOCK一般会列出每个数据文件已知的无效数据块的区块图整体会作为介质恢复的一部分来维护。然而有时候信息不完整。典型的情况是在从12.1之前的版本升级之后或在还原操作系统备份的数据文件之后。下次介质恢复运行时失效的整体会被移除任何新的无效数据块会被记录但之前无效的数据块不会在视图V$NONLOGGED_BLOCK有记录。视图V$DATAFILE的列FIRST_NONLOGGED_SCN仍然可以用来查看至少存在1个无效数据块的数据文件即使数据文件在视图V$NONLOGGED_BLOCK中没有记录。
RMAN命令VALIDATE … NONLOGGED BLOCK可以用来将视图V$NONLOGGED_BLOCK中的记录带回到与数据文件同步。它通过确认存在的区块图是否完整如果不完整就扫描必要的数据文件来鉴别任何无效数据块确认它们被V$NONLOGGED_BLOCK的记录捕获。命令VALIDATE … NONLOGGED BLOCK含有与命令RECOVER … NONLOGGED BLOCK一样的选项来验证一组数据文件或表空间。
如果只有脱机的数据文件被验证或恢复那么它们所属的数据库可以在RMAN命令运行的时候打开。 2.7. 更新密码文件
如果数据库初始化参数REMOTE_LOGIN_PASSWORDFILE设置为SHARED或EXCLUSIVE那么物理备数据库的密码文件会自动被来自主数据库的新拷贝替换。 在授予或撤销管理权限后或在有管理权限的用户密码更改时密码文件会被替换。唯一的例外是far sync实例。更新过的密码文件必须手动拷贝到far sync实例因为far sync实例接收redo数据但不会应用它。当密码文件在far sync实例上手工更新后包含密码更改的redo会自动传播到设置为从far sync实例接收redo的备数据库。当redo应用时密码文件就会在备数据库上更新。 3使用OPEN RESETLOGS语句恢复
Oracle Data Guard允许物理备数据库在主数据库以RESETLOGS选项打开后继续恢复。
当ALTER DATABASE OPEN RESETLOGS语句在主数据库上执行时数据库更改的转生incarnation会创建redo数据的一个新分支。
当物理备数据库接收到redo数据的新分支时Redo Apply自动采用redo数据的新分支。对于物理备数据库如果备数据库没有应用超过新resetlogs的SCN超过redo数据的新分支的起点的redo数据不需要人工干预。下表描述了如何使用主数据库的新分支同步备数据库
如果备数据库…那么…执行下面的步骤…还没有应用超过新resetlogs SCN超过redo数据的新分支的起点的redo数据而且来自OPEN RESETLOGS的新的redo分支已经在备数据库上注册Redo Apply自动采用redo数据的新分支不需要人工干预。管理redo进程MRP自动使用redo数据的新分支来同步物理备数据库。 注在主备数据库执行以下查询检查新redo新分支是否已经在备数据库上注册确认结果匹配SELECT resetlogs_id, resetlogs_change# FROM V$DATABASE_INCARNATION WHERE status‘CURRENT’已经应用了超过新resetlogs SCN超过redo数据的新分支的起点的redo数据而且闪回数据库在物理备数据库上已启用备数据库已恢复到redo数据的新分支的未来时间点1按照闪回物理备数据库到特定的时间点的步骤闪回物理备数据库 2重启Redo Apply继续应用redo数据到新的resetlogs分支。 3管理redo进程MPR自动使用新分支redo同步备数据库已经应用了超过新resetlogs SCN超过redo数据的新分支的起点的redo数据而且闪回数据库在物理备数据库上未启用主数据库与备数据库在表明的主数据库分支上偏离按照创建物理备数据库的步骤重新创建物理备数据库缺失从redo数据的新分支开始介于中间的归档redo日志文件MRP不能继续直到找回缺失的日志文件找到和注册来自每个分支的缺失的归档redo日志文件缺失redo数据之前的分支从结尾开始的归档redo日志文件MRP不能继续直到找回缺失的日志文件找到和注册来自以前的分支的缺失的归档redo日志文件3.1.主数据库RESETLOGS操作后自动闪回挂载的备数据库
在挂载状态的备数据库可以在主数据库执行RESETLOGS操作后自动仿效主数据库。这简化了在主数据库上执行RESETLOGS操作后的备数据库的管理。
当在主数据库或主数据库的PDB上执行闪回或时间点恢复时主数据库或PDB移动到之前的时间点然后以RESETLOGS选项打开主数据库。主数据库或PDB的转生incarnation会被创建。为了让备数据库自动效仿主数据库MRP执行以下操作 1检测到新的转生 2闪回备数据库或PDB到与主数据库相同的时间点 3重启备数据库恢复和移动备数据到redo的新分支
闪回操作只有在备数据库有足够的闪回数据时才会成功。
如果不想备数据库自动效仿主数据库将备数据库保持在打开状态或停止备数据库的MRP进程。
如果备数据库以只读模式打开相应的报错信息会记录在alert日志中。当在关闭物理备数据库后重启MRP恢复进程会自动闪回备数据库然后继续应用redo数据的新分支。 3.2. 闪回物理备数据库到指定时间点
下面步骤描述如何在主数据库发出OPEN RESETLOGS语句后避免重建物理备数据库。
在Oracle Database 19c版本中如果备数据库在挂载状态和闪回已启用可能不需要做任何操作。一般情况下如果有足够的闪回数据可用备数据库会自动闪回这样备数据库继续效仿主数据库。
如果备数据库是打开状态和已启用闪回数据库可以将备数据库置于挂载状态然后启动备数据库恢复。MRP进程尝试让备数据库效仿主数据库触发备数据库自动闪回。如果这个操作成功像alert日志报告的一样跟着需要打开Active Data Guard实例。
如果自动闪回没有触发或自动闪回没有让备数据库效仿主数据库可以执行以下步骤来闪回备数据库。 1确认在RESETLOGS操作发生前的SCNsystem change number。例如在主数据库上使用以下查询来获取在RESETLOGS操作发生前2个SCN的SCN值: SQL SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) FROM V$DATABASE;
2在备数据库上获取当前SCN: SQL SELECT TO_CHAR(CURRENT_SCN) FROM V$DATABASE;
3根据当前SCN的值执行相应的操作 a. 如果备数据库当前SCNCURRENT_SCN比resetlogs_change# - 2的值大执行以下语句闪回备数据库 SQL FLASHBACK STANDBY DATABASE TO SCN resetlogs_change# -2;
b. 如果当前SCN比resetlogs_change# -2小跳到步骤4。 如果备数据库的SCN是远远落后于主数据库的SCN从执行语句OPEN RESETLOGS开始的redo新分支已经在备数据库上注册那么应用服务会继续通过OPEN RESETLOGS语句而不会停止。在这种情况下闪回数据库是不必要的因为应用服务在到达redo数据的OPEN RESETLOGS语句时不会停止。
4在物理备数据库上启动Redo Apply执行以下语句 SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
备数据库准备接收和应用来自主数据库redo数据。 4监控主数据库物理备数据库和快照备数据库
下表总结了一般主数据库管理操作和在哪里能找到这些操作相关的信息。
主数据库操作主数据库信息备数据库信息启用或禁用redo线程1alert日志 2V$THREADalert日志查看数据库角色保护模式保护级别正常切换状态快速启动故障切换信息等V$DATABASEV$DATABASE增加或删除redo日志文件组1alert日志 2V$LOG 3V$LOGFILE的STATUS列alert日志创建控制文件CREATE CONTROLFILEalert日志alert日志监控Redo Apply1alert日志 2V$ARCHIVE_DEST_STATUS1alert日志 2V$ARCHIVED_LOG 3V$LOG_HISTORY 4V$MANAGED_STANDBY更改表空间状态1V$RECOVER_FILE 2DBA_TABLESPACES 3 alert日志1V$RECOVER_FILE 2DBA_TABLESPACES增加或删除数据文件或表空间1DBA_DATA_FILES 2alert日志1V$DATAFILE 2alert日志重命名数据文件1V$DATAFILE 2alert日志1V$DATAFILE 2alert日志unlogged或unrecoverable操作1V$DATAFILE 2V$DATABASEalert日志监控redo传输1V$ARCHIVE_DEST_STATUS 2V$ARCHIVED_LOG 3V$ARCHIVE_DEST 4alert日志1V$ARCHIVED_LOG 2alert日志执行OPEN RESETLOGS或CLEAR UNARCHIVED LOGFILES语句alert日志alert日志更改初始化参数alert日志alert日志5从主数据库复制还原点到备数据库
在主数据库上创建的还原点会自动复制到备数据库。在备数据库上创建的还原点称为复制的还原点replicated restore points。不管主数据库的还原点是保证还原点guaranteed restore point还是正常还原点normal restore point相应的复制还原点总是正常还原点。
符合以下条件时Oracle数据库自动复制主数据库的还原点到备数据库 1主备数据库的COMPATIBLE初始化参数都设置为19.0.0或更高 2主数据库在打开的状态 当主数据库处于挂载状态时主数据库上创建的还原不会被复制。具有这个限制是因为还原点信息需要通过redo来复制的。 复制的还原点的命令惯例是使用主数据库的还原点名称加上后缀_PRIMARY。如果有相同名称的复制还原点在备数据库上存在那么复制还原点将不会创建。例如当在主数据库上创建一个还原点PRE_MYTBS时复制还原点命名为PRE_MYTBS_PRIMARY。当在主数据库上删除还原点时备数据库上相应的复制还原点也会被删除。
管理Redo进程MRP管理创建和维护复制还原点。如果主数据库的还原点在MRP没有运行时创建那么这些还原点在MRP启动后会复制到备数据库。
可以查询视图V$RESTORE_POINT来确认还原点已自动复制。 6调整Redo Apply
参考Active Data Guard 11g Best Practices (includes best practices for Redo Apply)来优化Redo Apply和介质恢复性能在Oracle Maximum Availability Architecture (MAA)主页http://www.oracle.com/goto/maa可以下载文档high-availability-overview-and-best-practices.pdf。
还可以参考文档454848.1安装和使用Standby Statspack从备数据库上收集Redo Apply性能数据。 7使用SQL Tuning Advisor调整Active Data Guard环境中的数据库
在Active Data Guard环境中SQL Tuning Advisor可以在主数据库上调优备数据库的负载。 使用数据库链接可以在一个数据库上发出SQL Tuning Advisor语句但在另外的的数据库上执行该语句。
7.1. 在主数据库上调优备数据库负载
在某些情况下备数据库除了数据保护角色外还可以承担报告角色。备数据库可以有自己的查询负载有些可能需要调优。在这个场景中可以在备数据库上发出调优语句来调优备数据库的负载但SQL Tuning Advisor使用备到主数据库链接来在主数据库上执行分析。
下面的任务必须在主数据库上执行来调整备数据库的负载。使用DBMS_SQLTUNE PL/SQL包这些任务必须按照指定的顺序在备数据库上执行 1执行DBMS_SQLTUNE.CREATE_TUNING_TASK语句从主数据库获取需要的数据创建任务。因为备数据库是只读数据库关于任务的数据会远程写到主数据库。数据库链接参数要求在这个步骤中写到主数据库数据库链接参数在接下来的步骤中是可选的因为它绑定到这个步骤创建的任务中。 2执行DBMS_SQLTUNE.EXECUTE_TUNING_TASK语句。最初执行任务要求的数据从远程主数据库获取。寻找可能建议的调优分析进程tuning analysis process被执行。因为备数据库是只读数据库当结果可用时会远程存储到主数据库里。 3执行DBMS_SQLTUNE.REPORT_TUNING_TASK语句。需要构建报告的数据远程存储在主数据库里。数据从主数据库远程获取然后在备数据库上构建。 4执行DBMS_SQLTUNE.ACCEPT_TUNING_TASK语句。profile数据写到远程主数据库因为备数据库是可读的。 5使用Redo Apply让SQL Profile在备数据库上可用。 8使用Oracle Diagnostic Pack来调优Oracle Active Data Guard备数据库
可以在以只读方式打开的Oracle Active Data Guard备数据库上使用Oracle Diagnostic Pack。这让你可以为Oracle Active Data Guard备数据库抓取性能数据到AWRAutomatic Workload Repository然后在AWR数据上运行ADDMAutomatic Database Diagnostic Monitor分析。关于如何执行这些操作的详情请参考《Oracle Database Performance Tuning Guide》。 9管理快照备数据库
快照备数据库是完全可更新的备数据库。它从主数据库接收和归档redo数据但不会应用它。
当快照备数据库转换回物理备数据库时在丢弃快照备数据库的所有本地更新以后从主数据库接收的redo数据会被应用。
快照备数据库通常会随着时间与主数据库偏离因为来自主数据库的redo数据不会在接收时应用。快照备数据库本地的更新导致额外的偏离。然而主数据库的数据会完全得到保护因为快照备数据库可以在任何时候转换回物理备数据库然后应用从主数据库接收的redo数据。
快照备数据库提供与物理备数据库类似的灾难恢复和数据保护好处。快照备数据库适合用在拥有临时的可更新的主数据库快照的好处多于更短的时间从主数据库故障中恢复的场景。 9.1. 转换物理备数据库到快照备数据库
以下步骤描述如何转换物理备数据库到快照备数据库。 1如果Redo Apply是活动的停止它
2确保数据库在挂载状态不是打开状态。
3确保已经配置快速恢复区域。启用闪回数据库时这不是必需的。
4执行以下SQL语句进行转换 SQL ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;
5打开快照备数据库到可读写模式 SQL ALTER DATABASE OPEN READ WRITE; 9.2. 使用快照备数据库
快照备数据库可以以读写模式打开和是完全可更新的。
快照备数据库有以下特性 1快照备数据库不能作为正常切换或故障切换的目标数据库。快照备数据库必须先转换回物理备数据库然后再执行角色转换。 2快照备数据库在Oracle Data Guard最大保护配置中不能作为唯一的备数据库。
注闪回数据库用来转换快照备数据库回物理备数据库。任何不能使用闪回数据库技术撤销的操作都会阻止快照备数据库转换回物理备数据库。 9.3. 转换快照备数据库到物理备数据库
以下步骤描述如何转换快照备数据库到物理备数据库。 1在Oracle RAC数据库环境中关闭除其中一个以外的其它所有实例
2确保数据库在挂载状态不是打开状态。
3执行以下SQL语句进行转换 SQL ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
当数据库是快照备数据库时接收的redo数据会在Redo Apply启动时自动应用。
注在转换回物理备数据库前快照备数据库必须至少一次以读写模式打开。 10恢复主数据库的丢失写Lost-Write错误
在Oracle Data Guard配置的介质恢复中物理备数据库可以用来检测主数据库上的丢失写数据损坏错误。
通过比较存储在主数据库的redo日志中存储的数据块的SCN与物理备数据库上的数据块的SCN来完成。如果主数据库的数据块的SCN比备数据库的SCN低那么主数据库上存在丢失写错误。
在这种情况中如果丢失写检测设置DB_LOST_WRITE_PROTECT初始化参数在主备数据库上都已启用那么在备数据库上的恢复尝试会导致ORA-00752错误。如果丢失写检测没有启用那么恢复尝试会导致ORA-600[3020]错误。然而不是所有ORA-600[3020]错误都是因为主数据库的丢失写错误导致。因此在遵循这个部分的指南之前与支持人员确认ORA-00600 [3020]错误的根本原因是否真的是主数据库上发生了丢失写错误。也请查看Oracle Support Note 1265884 “Resolving ORA-752 or ORA-600 [3020] During Standby Recovery”。
当在备数据库上检测到主数据库丢失写错误时类似于下面的每个失效数据块错误日志会输出到备数据库的alert.log文件中
Tue Dec 12 19:09:48 2006
STANDBY REDO APPLICATION HAS DETECTED THAT THE PRIMARY DATABASE
LOST A DISK WRITE OF BLOCK 26, FILE 7
NO REDO AT OR AFTER SCN 389667 CAN BE USED FOR RECOVERY.然后alert.log日志文件显示一条备数据库的错误ORA-00752和管理恢复被取消
Slave exiting with ORA-752 exception
Errors in file /oracle/log/diag/rdbms/dgstwrite2/stwrite2/trace/
stwrite2_pr00_23532.trc:
ORA-00752: recovery detected a lost write of a data block
ORA-10567: Redo is inconsistent with data block (file# 7, block# 26)
ORA-10564: tablespace TBS_2
ORA-01110: data file 7: /oracle/dbs/btbs_21.f
ORA-10561: block type TRANSACTION MANAGED DATA BLOCK, data object# 57503然后备数据库恢复到一致的状态在alert文件中打印的SCN处没有该错误导致的数据文件损坏
Recovery interrupted!
Recovered data files to a consistent state at change 389569最后一条日志可能会相当迟才会在alert文件中出现它可能会比数据块错误日志更低的SCN。同时主数据库可能会没有可见的错误在运行即使它的数据文件可能已经损坏 。
建议的恢复这些错误的过程是failover到物理备数据库上如下面的步骤描述一样。 在主数据库检测到丢失写错误之后failover到物理备数据库的步骤
1关闭主数据库。所有在数据块错误日志中打印的SCN时或之后的数据已经丢失。
2在备数据库上执行以下SQL语句将它转换为主数据库 SQL ALTER DATABASE ACTIVATE STANDBY DATABASE;
Tue Dec 12 19:15:23 2006
alter database activate standby database
ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE (stwrite2)
RESETLOGS after incomplete recovery UNTIL CHANGE 389569
Resetting resetlogs activation ID 612657558 (0x24846996)
Online log /oracle/dbs/bt_log1.f: Thread 1 Group 1 was previously
cleared
Online log /oracle/dbs/bt_log2.f: Thread 1 Group 2 was previously
cleared
Standby became primary SCN: 389567
Tue Dec 12 19:15:23 2006
Setting recovery target incarnation to 3
Converting standby mount to primary mount.
ACTIVATE STANDBY: Complete - Database mounted as primary (stwrite2)
Completed: alter database activate standby database3备份新的主数据库。立即执行备份是必要的安全措施因为如果没有完整的数据库备份拷贝的话不能恢复在failover以后的更改。作为failover的结果原主数据库不再参与Oracle Data Guard的配置所有其它备数据库现在接收和应用来自新主数据库的redo数据。
4打开新的主数据库。
5一个可选的步骤是重建故障主数据库为物理备数据库。可以使用步骤3里的新主数据库备份来完成。在这种情况中不能使用闪回数据库或Oracle Data Guard broker来重建旧主数据库。 11使用DBCOMP存储过程来检测丢失写和其它不一致
可以使用PL/SQL存储过程DBMS_DBCOMP.DBCOMP来检测丢失写和主备数据库之间的不一致。
DBMS_DBCOMP.DBCOMP存储过程比较主备数据库上相同的数据块。这个存储过程可以在任何时间执行。它不需要DB_LOST_WRITE_PROTECT初始化参数启用。可以查询视图V$SESSION_LONGOPS监控进行中的块比较操作的进度。
注逻辑备数据库far sync实例和层叠备数据库不能作为DBMS_DBCOMP.DBCOMP存储过程的目标数据库。
存储过程DBMS_DBCOMP.DBCOMP假设存在一个主数据库和一个或更多的物理备数据库。数据库至少应该在块比较前处于挂载状态。
在下面的示例情况中假设主数据库的唯一名称为dgmain物理备数据库的名称为dgmainbdgmaincdgmaind等。
示例1主数据库和所有备数据库处于挂载或打开状态DBCOMP从主数据库执行 在这种情况中当DBCOMP存储过程从主数据库上执行时指定的数据文件在主备物理数据库之间逐个数据块进行比较。例如假设执行以下查询 SQL exec sys.dbms_dbcomp.dbcomp(‘1’,’BlockCompare’,:retval);
产生的输出文件是BlockCompare_dgmainb_1和BlockCompare_dgmainc_d_1。 示例2主数据库和所有备数据库处于挂载或打开状态DBCOMP从备数据库执行 在这种情况中当DBCOMP存储过程从其中一个备数据库上执行时指定的数据文件只在主数据库和执行命令的物理备数据库之间进行比较。其它的备数据库不考虑在内。例如假设执行以下查询 SQL exec sys.dbms_dbcomp.dbcomp(‘1’,’BlockCompare’,:retval);
产生的输出文件是BlockCompare_dgmain_1。 示例3主数据库处于挂载或打开状态不是所有备数据库处于挂载或打开状态DBCOMP从主数据库执行 在这种情况中当DBCOMP存储过程从主数据库上执行时指定的数据文件在主数据库和所有挂载或打开的物理备数据库之间进行比较。对于那些没有挂载或打开的备数据库不采取任何行动。 来源《Oracle Data Guard Concepts and Administration, 19c》
