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中？