这个章节讲述闪回数据库和还原点。作为数据保护策略整体的一部分,讨论配置,监控和维护这些特性。
1.闪回数据库,还原点和保证还原点概述
Oracle闪回数据库和还原点是相关的数据保护特性,让你可以按时间倒回数据,纠正在指定的时间窗口内任何逻辑数据损坏或用户错误导致的问题。
这些特性相对于时间点恢复提供了一个更有效的替代方案,它不需要先还原数据库的备份,效果与数据库时间点恢复(DBPITR)类似。闪回数据库和还原点不仅在传统的数据库恢复情形中有效,在数据库升级,应用部署和当测试数据库必须快速创建和重建的测试场景中也很有用。闪回数据库也提供了一个有效的替代方案,在Data Guard故障切换(failover)后重建故障的主数据库。
还原点提供了与闪回数据库和其它介质恢复操作相关的能力。特别地,在SCN(System Change Number)创建的保证还原点确保可以使用闪回数据库倒回数据库到这个SCN。可以独立使用还原点和闪回数据库或两者一起使用。
闪回数据库可以通过RMAN和SQL的FLASHBACK DATABASE来访问。可以使用其中一种方式来从逻辑数据损坏或用户错误中恢复数据库。以下示例还原数据库到一个指定的SCN或还原点:
FLASHBACK DATABASE TO RESTORE POINT ‘before_upgrade’;
FLASHBACK DATABASE TO SCN 202381;
1.1.关于闪回数据库
闪回数据库与传统的时间点恢复在效果上类似。它可以还原数据库到最近的过去的某个时间点的状态。闪回数据库比时间点恢复快很多,因为它不需要从备份中还原数据文件。只要求应用归档redo日志中的少量的更改。
如果数据文件完整的,可以使用闪回数据库来逆转大部分不想要的数据库更改。可以还原数据库到一个先前的转生(incarnation)的状态,然后撤销ALTER DATABASE OPEN RESETLOGS语句的效果。章节“Rewinding a Database with Flashback Database”阐述了如何使用FLASHBACK DATABASE命令逆转数据库更改。
闪回数据库使用它自己的机制,创建闪回日志和存储它们在快速恢复区域。如果闪回日志可用的话,可以只使用闪回数据库。为了利用这个特性,必须提前设置数据库来创建闪回日志。
为了启用闪回数据库,配置一个快速恢复区域和设置一个闪回保留目标。这个闪回保留目标指定可以使用闪回数据库往后倒回数据库多远。
从这个时间向前,数据库定期拷贝每个数据文件中的每个修改过的块的映像到闪回日志。这些块映像后面可以被用来重建任何捕获日志的时候的数据文件的内容。
当使用闪回数据库倒回数据库到过去的目标时间时,命令确认哪些块在目标时间之后更改过,然后从闪回日志中还原它们。数据库还原每个块的版本紧靠在目标时间之前。然后数据库使用redo日志来重新应用在这些块写到闪回日志之后所做的更改。
在磁盘或磁带上的redo日志必须在闪回日志所跨越的整个时间段内可用。例如,如果闪回保留目标是1周,那么必须确保包含过去一周的所有更改的在线和归档redo日志可以访问。实际上,redo日志需要保留的时间通常比闪回保留目标更长以支持时间点恢复。
1.2.关于闪回数据库窗口
当前存在足够的闪回日志数据以支持FLASHBACK DATABASE命令的SCN范围称为闪回数据库窗口。闪回数据库窗口不能向后延伸到比可用的闪回日志中的最早的SCN更早的SCN。
不能备份闪回日志到位于快速恢复区域之外的位置。为了增加保留足够的闪回日志来满足闪回数据库窗口的可能性,可以增加快速恢复区域中的空间。
如果快速恢复区域中没有足够的空间来存储闪回日志和诸如归档redo日志的文件以及其它保留策略需要的备份,那么数据库可能会从最早的SCN向前删除闪回日志腾出空间给其它文件使用。因此,闪回数据库窗口可能会比闪回保留目标更短,取决于快速恢复区域的大小,其它必须保留的备份和需要多少闪回日志数据。闪回保留目标是一个目标,不是一个闪回数据库可用的保证。
如果因为闪回数据库窗口不够长,你不能使用FLASHBACK DATABASE,那么通常可以使用数据库时间点恢复(DBPITR)来实现类似的结果。保证还原点是唯一可以确保使用闪回数据库还原到一个特定的时间点或保证闪回窗口大小的方式。
1.3.闪回数据库的限制
由于闪回数据库通过撤销(undo)运行命令的时候存在的数据文件的更改,它有一些限制。
以下是闪回数据库的限制:
1) 闪回数据库只能撤销(undo)Oracle数据库对数据文件做的更改。它不能用来修复介质故障或从意外的数据文件删除中恢复。
2) 不能使用闪回数据库来撤销(undo)缩小数据文件的操作。然而,可以将缩小的文件脱机,闪回其余的数据库,然后还原和恢复缩小的数据文件。
3) 不能只使用闪回数据库来找回删除(dropped)的数据文件。如果闪回数据库到一个删除的数据文件存在于数据库中的时间,只有数据文件条目会增加到控制文件中。只能通过使用RMAN来完全还原和恢复数据文件来恢复删除的数据文件。
4) 如果数据库控制文件从备份中还原或重建,所有累积的闪回日志信息都会丢弃。不能使用FLASHBACK DATABASE来还原到还原或重建控制文件之前的一个时间点。
5) 当与目标时间一起使用闪回数据库,在目标时间NOLOGGING操作正在进行中,块损坏可能会出现在NOLOGGING操作影响的数据库对象和数据文件中。例如,如果在NOLOGGING模式中执行直接路径(direct-path)INSERT操作,操作从9:00运行到9:15,后来使用闪回数据库还原到目标时间09:07,由直接路径INSERT更新的对象和数据文件在闪回数据库操作完成后可能会留下块损坏。
如果可能,避免与和NOLOGGING操作重叠的目标时间或SCN一起使用闪回数据库。此外,在任何NOLOGGING操作之后对受影响的数据文件立即执行完全或增量备份来确保NOLOGGING操作之后的时间点的可恢复性。如果期望使用闪回数据库还原到这个操作比如直接路径INSERT的过程中的时间点,考虑在LOGGING模式中执行操作。
1.4.关于正常的还原点
创建一个正常的还原点分配一个还原点名称给一个SCN或指定的时间点。
这样,还原点像书签或这个SCN的别名一样起作用。在执行任何你可能需要逆转的操作之前,可以创建一个正常的还原点。控制文件存储还原点的名称和这个SCN。
如果使用闪回特性或时间点恢复,那么可以使用还原点名称而不是时间或SCN。下面的命令支持使用还原点:
1)RMAN中的RECOVER DATABASE和FLASHBACK DATABASE命令
2)SQL上的FLASHBACK TABLE语句
创建一个正常的还原点消除了事先手动记录一个SCN或在事后通过使用特性比如闪回查询(Flashback Query)来确认正确的SCN的需要。
正常还原点是轻量的。控制文件可以维护几千个正常还原点的记录而对数据库性能没有重要的影响。
如果没有手动删除,正常还原点最终随着时间从控制文件中移除,所以它们不需要持续的维护。
1.5.关于保证还原点
像正常还原点一样,保证还原点(guaranteed restore point)在恢复操作中起SCN别名的作用。主要的不同是保证还原点不会随着时间从控制文件中移除和必须明确删除。
一般来说,可以作为一个SCN的别名与任何使用正常还原点工作的命令一起使用保证还原点。除了特别指出的情况以外,关于哪里和如何使用还原点的信息也同样应用到保证还原点。
保证还原点确保可以使用闪回数据库来倒回数据库到还原点SCN的状态,即使闪回日志的产生被禁用。如果启用闪回日志,那么保证还原点强制保留需要的闪回日志来闪回数据库到最早的保证还原点之后的任何SCN。这样,如果启用了闪回日志,可以倒回数据库到连续时间中的任何SCN而不只是一个单一的SCN。
注:如何禁用了闪回日志,那么不能FLASHBACK DATABASE直接到保证还原点和当前时间之间的SCN。然而,可以先闪回到保证还原点,然后恢复到保证还原点和当前时间点之间的SCN。
如果恢复区域中有足够的磁盘空间来存储需要的日志,那么可以使用保证还原点倒回整个数据库到一个已知的多天或多周以前的好的状态。与闪回数据库一起,即使NOLOGGING操作如直接路径INSERT的效果也可以使用保证还原点逆转。
保证还原点与存储快照对比
实际上,保证还原点提供了一个存储快照的有用的替代方案。
存储快照经常用来在有危险的操作比如大规模的数据库更新或应用补丁或升级之前保护数据库。在不创建一个快照或复制数据库来测试操作时,可以在主或物理备数据库上创建一个保证还原点,然后在确认需要的闪回日志有保留之后执行有危险性的操作。
2.关于闪回数据库和保证还原点的日志
闪回数据库和保证还原点的日志涉及在应用更改之前捕获数据文件块的映像。FLASHBACK DATABASE命令可以使用这些映像来还原数据文件到它们之前的状态。
正常的闪回日志和保证还原点的日志的主要区别与何时记录块和快速恢复区域中的空间紧张时日志是否可以被删除有关。这些区别影响日志的空间使用和数据库性能。
可恢复性的目标部分决定了是否启用闪回数据库日志或使用保证还原点或两者。这些特性分别的性能和空间使用影响,或一起使用时的影响,都要在决定中考虑进去。
2.1.保证还原点和快速恢复区域空间使用
某些规则管理快速恢复区域中的空间使用。
当创建一个还原点时,不论是否启用了全闪回数据库日志,必须监控快速恢复区域中的可用空间。“Managing Space for Flashback Logs in the Fast Recovery Area”阐述了如何监控快速恢复区域磁盘空间使用。
以下规则管理在快速恢复区域中创建,保留,覆盖和删除闪回日志:
1) 如果快速恢复区域有足够的空间,那么无论何时需要满足闪回保留目标时都会创建闪回日志。
2) 如果闪回日志太旧不再需要来满足闪回保留目标,那么闪回日志可能会被重用或删除。
3) 如果数据库必须创建闪回日志,而快速恢复区域已满或没有磁盘空间,那么最旧的闪回日志会被重用。
注:重用最旧的闪回日志会缩短闪回数据库窗口。如果太多的闪回日志由于缺少磁盘空间而被重用,那么闪回保留目标可能不会满足。
4)如果快速恢复区域已满,那么根据快速恢复区域规则可以收回的归档redo日志可能会被快速恢复区域自动删除来为其它文件腾出空间。在这种情况上,任何需要那个redo日志文件用来做FLASHBACK DATABASE的闪回日志也被删除。
注:根据快速恢复区域规则 ,当符合以下条件时,文件是可收回的:
a.文件被报告为过期的和不被闪回数据库需要。例如,文件在DB_FLASHBACK_RETENTION_TARGET参数之外。
b.文件已经备份到磁带。
5)在快速恢复区域中的文件如果要用来满足保证还原点,那么它们不符合删除条件或重用。然而 ,要用来满足保证还原点的归档redo日志在备份到磁盘或磁带后可能会被删除。当使用RMAN的FLASHBACK DATABASE命令时,如果需要用来满足指定的保证还原点的归档redo日志不在快速恢复区域中,那么从备份中恢复它们。
保留需要用来满足保证还原点的闪回日志和其它文件和要求用来满足备份保留策略的文件,可能会导致快速恢复区域完全占满。如果快速恢复区域变满,参考“Responding to a Full Fast Recovery Area”。
2.2.保证还原点和禁用闪回日志时的日志
假设在闪回数据库日志禁用时创建一个保证还原点。在这种情况中,在保证还原点之后数据文件的块第一次被更改时,数据库在闪回日志修改之前存储块的映像。这样,闪回日志保存了当保证还原点创建时每个更改的数据块的内容。后面对相同的数据块的更改不会导致再次记录块的内容,除非在数据块最后的更改或后来的闪回数据库操作还原了数据块的原始内容之后创建了另外一个保证还原点。当使用闪回数据库多次还原数据库到相同的还原点,常规的做法是每次都删除和重建保证还原点。这会删除旧的闪回日志和确保不会超过快速恢复区域的空间配额。
日志的方法有以下重要的结果:
1)FLASHBACK DATABASE可以使用块映像来重建保证还原点时的数据文件的内容
2)对于重复修改相同数据的负载,磁盘空间使用可以比正常的闪回日志少。因为每个更改地块只记录一次,所以需要更少的空间。有更少量插入的应用程序可能会受益于节省磁盘空间。对于有大量插入或大批量插入的应用程序,这个优势的可能性会更少。对于不启用闪回数据库日志的保证还原点的日志记录(logging)的开销的性能也会更低。
假设主要目的是还原数据库到创建保证还原点的时候的能力。在这种情况中,通常关闭闪回日志和使用保证还原点会更有效。例如,假设周末在数据库主机上执行应用程序的升级。可以在升级开始时创建一个保证还原点,如果升级失败,那么使用FLASHBACK DATABASE命令逆转更改。
2.3.闪回数据库和定义了保证还原点的日志
如果启用闪回数据库和定义了一个或更多的保证还原点,那么数据库执行正常的闪回日志。
在这种情况中,恢复区域保留需要的闪回日志来闪回到现在和最早的当前定义的保证还原点之间的任意的时间点。如果闪回日志需要用来满足保证还原点,当空间紧张时,它们也不会被删除。
闪回日志导致一些性能消耗。取决于数据库的活动模式,可能会导致快速恢复区域中的空间相当紧张。因此,应该监控快速恢复区域中的空间使用情况。
3.闪回数据库和保证还原点的先决条件
为了确保闪回数据库和保证还原点的成功操作,必须首先设置某些关键的数据库选项。
闪回数据库
在启用闪回数据库之前配置下面的数据库设置:
1)数据库必须运行在ARCHIVELOG模式,因为在闪回数据库操作中要使用归档日志。
2)必须启用快速恢复区域,因为闪回日志只能存储在快速恢复区域。
3)对于Oracle RAC数据库,快速恢复区域必须在集群文件系统或ASM中。
4)为了在CDB中创建还原点,初始化参数COMPATIBLE必须设置为12.1.0或更高。
保证还原点
为了使用保证还原点,数据库必须满足额外的先决条件:COMPATIBLE初始化参数必须设置为10.2.0或更高。
PDB中的还原点
为了在PDB(Pluggable Database)中创建还原点,COMPATIBLE初始化参数必须设置为12.2.0或更高。
4.使用正常和保证还原点
可以创建,监控和删除正常和保证还原点。
4.1.在非CDB中创建正常和保证还原点
在CDB和PDB中创建还原点请参考官方文档《Oracle Database Backup and Recovery User’s Guide,19c》。
使用SQL语句CREATE RESTORE POINT创建正常或保证还原点,提供还原点的名称和指定是否是保证还原点还是正常还原点(缺省值)。
创建还原点:
1) 确保数据库处于打开或挂载状态。如果数据库在挂载状态,那么它必须已经干净地关闭(除非它是物理备数据库)。
SQL> select name,open_mode from v$database;
NAME OPEN_MODE
--------- --------------------
ORCL READ WRITE
2) 运行CREATE RESTORE POINT命令。
以下示例显示如何创建正常还原点:
SQL> CREATE RESTORE POINT before_upgrade;
以下示例显示如何创建保证还原点:
SQL> CREATE RESTORE POINT before_upgrade GUARANTEE FLASHBACK DATABASE;
4.2.使用LIST命令列出还原点
可以使用LIST命令来列出特定的还原点或RMAN恢复目录已知的所有还原点。
LIST RESTORE POINT restore_point_name;
LIST RESTORE POINT ALL;
RMAN显示还原点的SCN,时间,类型和名称:
RMAN> LIST RESTORE POINT ALL;
using target database control file instead of recovery catalog
SCN RSP Time Type Time Name
---------------- --------- ---------- --------- ---------
341859 28-APR-15 28-APR-15 NORMAL_RS
343690 28-APR-15 GUARANTEED 28-APR-15 GUARANTEED_RS
4.3.使用视图V$RESTORE_POINT列出还原点
可以使用V$RESTORE_POINT控制文件视图来获取关于所有当前定义的还原点(正常和保证)的信息,包括CDB还原点和PDB还原点。
视图V$RESTORE_POINT包含额外的关于多租户环境中LIST RESTORE POINT命令不显示的还原点的信息。它包含详细的信息,例如创建了PDB还原点的PDB转生(incarnation),还原点是PDB还原点还是干净的PDB还原点等。
以下示例显示了多租户环境中的所有还原点:
SELECT name, guarantee_flashback_database, pdb_restore_point, clean_pdb_restore_point, pdb_incarnation#, storage_sizeFROM v$restore_point;
NAME GUARANTEE_ PDB_RESTORE_POINT CLEAN_PDB_RESTORE_POINT STORAGE_SIZE
---------- ---------- ---------------- ----------------------- ----------------
CDB_GRP_BEFORE_PATCH YES NO NO 84586
PDB_GRP_BEFORE_UPGRADE_TEMP YES YES NO 4562
CDB_RP1 NO NO NO 0
PDB1_BEFORE_PATCHING NO YES NO 0
MYPDB_CLEAN_GRP_BEFORE_UPGRADE NO YES YES 0
对于正常还原点,STORAGE_SIZE是0。对于保证的还原点,STORAGE_SIZE显示在快速恢复区域中通过FLASHBACK DATABASE命令还原到该还原点需要保留的日志占用的磁盘空间的大概大小(Byte)。
4.4.删除还原点
当不需要一个还原点时或当你想创建一个与存在的还原点相同名称的还原点时,可以使用DROP RESTORE POINT删除还原点。
SQL> DROP RESTORE POINT before_app_upgrade;
Restore point dropped.
注:正常还原点最终会随着时间从控制文件中移除,即使不明确地删除。管理控制文件中的还原点保留的规则是:
1) 最近的2048个还原点会一直保存在控制文件中,不管它们的时长。
2) 任何比CONTROL_FILE_RECORD_KEEP_TIME值更近的还原点都保留,不管有多少还原点被定义。
不符合这些条件的正常还原点可能会随着时间从控制文件中移除。
保证还原点不会随着时间从控制文件中移除。它们一直保留直到明确被删除为止。
5.使用闪回数据库
为了让目标数据库使用闪回日志,必须启用闪回数据库。可以遵循某些准则来确保闪回数据库的最佳性能。
5.1.启用闪回数据库
使用ALTER DATABASE命令来启用闪回数据库。
启用闪回日志:
1) 配置快速恢复区域。
2) 确保数据库实例处于打开或挂载的状态。如果实例处于挂载状态,那么数据库必须干净地关闭除非它是一个物理备数据库。其它Oracle RAC实例可以在任何模式。
3) 可选地,设置DB_FLASHBACK_RETENTION_TARGET到期望的闪回窗口长度(分钟):
ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320 SCOPE=BOTH; # 3 days
缺省情况下DB_FLASHBACK_RETENTION_TAGET设置为1天(1440分钟)。
4) 为整个数据库启用闪回数据库的特性:
ALTER DATABASE FLASHBACK ON;
5)可选地,为特定的表空间禁用闪回日志。
缺省情况下,为所有永久的表空间产生闪回日志。可以像如下示例一样,通过为特定表空间禁用闪回日志降低消耗:
ALTER TABLESPACE tbs_3 FLASHBACK OFF;
可以在后来重新对表空间启用闪回日志:
ALTER TABLESPACE tbs_3 FLASHBACK ON;
如果为表空间禁用闪回数据库,那么必须在运行FLASHBACK DATABASE之前将它的数据文件脱机。
当数据库打开时启用闪回数据库,可能有很小的机会不能获得需要的内存。如果因为这个原因命令失败,过一会儿再重新尝试命令或在关闭和重启实例后再次重试。
当在物理备数据库上启用闪回数据库时,可以闪回一个物理备数据库。在Data Guard环境中,物理备数据库的闪回数据库有一些应用情景。
查看闪回数据库的闪回日志的大小:
SQL> SELECT * FROM V$FLASHBACK_DATABASE_STAT;
BEGIN_TIME END_TIME FLASHBACK_DATA DB_DATA REDO_DATA ESTIMATED_FLASHBACK_SIZE CON_ID
------------ ------------ -------------- ---------- ---------- ------------------------ ----------
20-MAY-22 21-MAY-22 80674816 85573632 54020096 5252677632 0
SQL> SELECT * FROM V$FLASHBACK_DATABASE_LOG;
OLDEST_FLASHBACK_SCN OLDEST_FLASH RETENTION_TARGET FLASHBACK_SIZE ESTIMATED_FLASHBACK_SIZE CON_ID
-------------------- ------------ ---------------- -------------- ------------------------ ----------
32152131 20-MAY-22 4320 838860800 5252677632 0
5.2.禁用闪回数据库日志
使用ALTER DATABASE命令禁用闪回数据库。
在挂载和打开状态的数据库实例上,执行以下命令:
ALTER DATABASE FLASHBACK OFF;
5.3.为最佳的闪回数据库性能配置环境
维护闪回日志来对数据库实例施加相对限制的消耗。让更改的块以相对不频繁的频率和正常的间隔从内存写到闪回日志来限制运算和I/O消耗。
为了让启用了闪回数据库的大型生产数据库获得好的性能,Oracle建议采取以下措施:
1)给快速恢复区域使用快速文件系统,最好不使用文件系统缓存。
数据库在快速恢复区域中的创建的包括闪回日志的文件,一般很大。操作系统文件缓存通常对这些文件无效,实际上可能会增加CPU损耗来读取和写入这些文件。因此,建议避免使用操作系统文件缓存的文件系统 ,例如ASM。
2)为放置快速恢复区域的文件系统配置足够的磁盘轴(disk spindle)。对于大型的生产数据库,可能需要多个磁盘轴来为数据库有效地写闪回日志提供要求的磁盘吞吐量。
3)如果用来放置快速恢复区域的存储系统没有非易失性RAM,那么尝试在条带存储卷上配置文件系统。使用相对小的条带大小比如128KB,这让每个到闪回日志的写操作会分布到多个磁盘轴上,改善性能。
4)对于大型数据库,设置初始化参数LOG_BUFFER至少在8MB以上。
闪回数据库日志的消耗取决于数据库负载中的读写混合情况。当有写集中的负载时,闪回数据库日志消耗很高,因为它必须记录所有数据库更改。查询不会更改数据,因此不会引起闪回数据库的日志活动。
5.4.监控闪回数据库的性能影响
存在以下几种数据分析方法可以用来监控系统上的闪回数据库的负载:
1) AWR(Automatic Workload Repository)报告
AWR自动数据库统计数字通过为数据库问题检测和自我调整而采集,处理和维护性能统计数字来收集。可以比较闪回数据库启用前后的AWR报告来监控性能影响。
2) AWR快照
可以审查AWR快照来查明闪回日志导致的系统使用情况。例如,如果flashback but free by RVWR是高的等待事件,那么可以知道Oracle数据库不能快速写闪回日志。因此,可能需要调优快速恢复区域的文件系统和存储。
3) 视图V$FLASHBACK_DATABASE_STAT
视图V$FLASHBACK_DATABASE_STAT显示了数据库记录的闪回数据的大小。视图中的每行显示累计的数字(通常是一个小时的阶段)。列FLASHBACK_DATA和列REDO_DATA描述在时间间隔内分别写的闪回数据和redo数据容量(bytes),DB_DATA列描述读和写的数据块大小(bytes)。列FLASHBACK_DATA和REDO_DATA对于顺序写,而列DB_DATA对应随机读和写。
SQL> SELECT * FROM V$FLASHBACK_DATABASE_STAT;
BEGIN_TIME END_TIME FLASHBACK_DATA DB_DATA REDO_DATA ESTIMATED_FLASHBACK_SIZE CON_ID
------------ ------------ -------------- ---------- ---------- ------------------------ ----------
20-MAY-22 21-MAY-22 80674816 85573632 54020096 5252677632 0
4) 视图V$SYSSTAT
由于顺序I/O和随机I/O的不同,I/O消耗的更好指标是闪回日志的I/O操作数。下表列出的视图V$SYSSTAT的统计数字可以告诉你实例为各种目的发出的I/O操作数。
列名 | 列的含义 |
---|---|
physical write IO requests(物理写I/O请求 | 为写数据块发出的写操作数 |
physical read IO requests(物理读I/O请求) | 为读数据块发出的读操作数 |
redo writes(Redo写) | 为写redo日志发出的写操作数 |
flashback log writes(闪回日志写) | 为写闪回日志发出的写操作数 |
flashback log write bytes(闪回日志写大小) | 从实例中写的闪回数据库数据的总大小 |
5.5.关于I/O错误时的闪回写行为
当启用闪回或存在保证还原点时,后台进程RVWR将闪回数据写到在快速恢复区域中的闪回数据库日志。
如果RVWR遇到I/O错误,那么以下是预计的反应:
1) 如果存在任何的保证还原点定义,那么当RVWR遇到I/O错误时,实例出现故障。
2) 如果没有定义保证还原点,那么当RVWR遇到I/O错误时,实例保持不受影响。注意以下的情况:
a. 在主数据库上,Oracle数据库在打开状态时会自动禁用闪回数据库。所有存在的事务和请求继续进行而不受影响。对单实例和RAC数据库这都是预计的行为。
b. 在物理或逻辑备数据库上,RVWR表现像已经停止反应一样,会定期尝试一下I/O。这可能最终导致逻辑备数据库或物理备数据库的管理恢复挂起(Oracle数据库不会让备实例故障,因为它不想在最大保护模式中导致主数据库故障)。为了解决这个问题,可以执行SHUTDOWN ABORT或ALTER DATABASE FLASHBACK OFF命令。
来源:《Oracle Database Backup and Recovery User’s Guide,19c》