Oracle数据库-企业版-版本10.2.0.1至11.2.0.3 [版本10.2至11.2]
本文档中的信息适用于任何平台。
***已在2015年5月28日进行了相关性检查***
添加了新的日志组:
ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 1 ( '<Diskgroup1>', '<Diskgroup2>') SIZE 100M;
ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 2 ( '<Diskgroup1>', '<Diskgroup2>') SIZE 100M;
ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 3 ( '<Diskgroup1>', '<Diskgroup2>') SIZE 100M;
磁盘组“ <Diskgroup2>”用于闪回恢复区。
然后在警报日志中引发以下警告:
ORA-19816: WARNING: Files may exist in db_recovery_file_dest that are not known to database.
运行CATALOG RECOVERY AREA命令后:
List of files in Recovery Area not managed by the database
==========================================================
File Name: <Diskgroup2>/<db_unique_name>/onlinelog/group_1.4506.718549659
RMAN-07527: Reason: File was not created using DB_RECOVERY_FILE_DEST initialization parameter
File Name: <Diskgroup2>/<db_unique_name>/onlinelog/group_2.4507.718549665
RMAN-07527: Reason: File was not created using DB_RECOVERY_FILE_DEST initialization parameter
这是在创建日志组时明确指定文件名的结果(“ <Diskgroup1>”,“ <Diskgroup2>”),其中一个是FRA(<Diskgroup2>)的磁盘组。对于数据库,只有第二个成员(即FRA中的成员)被视为“未知”。它们并不是真正的“未知”-它们位于闪回恢复区中,因为它们是与FRA在同一磁盘组上创建的,但它们不被视为“位于” FRA中或参与FRA的空间管理算法。
您可以通过执行以下操作来识别此问题:
SQL> select * from v$logfile;
GROUP# STATUS TYPE MEMBER IS_
---------- ------- ------- ---------------------------------------------------------------------- ---
1 ONLINE <Diskgroup1>/<db_unique_name>/onlinelog/group_1.287.817399289 NO
1 ONLINE <Diskgroup2>/<db_unique_name>/onlinelog/group_1.268.817399295 NO <<===
请注意,IS_RECOVERY_DEST_FILE列显示为NO。
SQL> select file_type, PERCENT_SPACE_USED "%used" , PERCENT_SPACE_RECLAIMABLE "%reclaimable"
, NUMBER_OF_FILES files
from v$flash_recovery_area_usage
order by 1; 2 3 4
FILE_TYPE %used %reclaimable FILES
-------------------- ---------- ------------ ----------
ARCHIVED LOG 35.77 34.59 2321
BACKUP PIECE 43.56 43.56 302
CONTROL FILE 0 0 1
FLASHBACK LOG 0 0 0
FOREIGN ARCHIVED LOG 0 0 0
IMAGE COPY 0 0 0
REDO LOG 0 0 0
请注意,FRA中REDO LOG文件的数量为0。
出现问题是因为当前没有方法在FRA中显式添加联机重做日志文件成员。目前,这是预期的行为。但是,提出了一个增强请求来更改此行为:
错误6612535:无法直接在创建在线重做日志时指定FRA位置
必须正确创建FRA中的联机重做日志,以便它们参与FRA的空间管理算法,否则,如果底层FRA存储空间有限,则可能会产生后果。
删除新添加的组并按如下所示重新创建它们:
对于要添加到FRA的每个新日志组:
SQL>alter database add logfile;
对要添加的每个新组执行一次此操作。
确认新的日志组:
SQL>select f.member, v.sequence#, v.group#, v.status, f.is_recovery_dest_file
from v$log v, v$logfile f where v.group# = f.group#;
使用不同的磁盘组将新成员添加到每个适当的组:
SQL> alter database add logfile member '<+NEW GRP name>' to group n;
然后再次运行CATALOG RECOVERY AREA命令,以确认Oracle知道FRA中的所有文件。上面的解决方案对文件系统位置以及ASM有效。
请注意,如果使用DB_CREATE_ONLINE_LOG_DEST_n (例如,在RMAN复制运行中),可能会发生类似情况。没有可用于指定DB_CREATE_ONLINE_LOG_DEST_n ='USE_DB_RECOVERY_FILE_DEST'的 语法, 因此将其明确设置为FRA磁盘组确实会在FRA中创建日志,但它们不会参与空间管理算法。增强请求也解决了此问题。错误6612535:无法直接在创建联机重做日志时指定FRA位置
注意:833553.1-如何对重做日志进行多重处理,以便将一个副本放入FRA中?