实验环境：Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
实验背景：向tough.t中插入40万条记录，然后rollback，接着执行了shutdown abort命令。当重新启动数据库的时候遇到以下问题。
SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-16038: 日志 1 序列号 14 无法归档
ORA-19809: 超出了恢复文件数的限制
ORA-00312: 联机日志 1 线程 1:
'C:ORACLEPRODUCT10.2.0ORADATAORA11GREDO01.LOG'
解决步骤：
从提示信息大概可以看出问题出在归档上，我们首先看一下trace文件。
C:oracleproduct10.2.0adminora11gudumpora11g_ora_4480.trc是最新trace文件，下面是部份文件内容：
************************************************************************
************************************************************************
*** 2014-04-06 15:17:54.943
*** SERVICE NAME:() 2014-04-06 15:17:54.943
*** SESSION ID:(155.481) 2014-04-06 15:17:54.943
ORA-19815: 警告: db_recovery_file_dest_size 字节 (共 1073741824 字节) 已使用 100.00%, 尚有 0 字节可用。
*** 2014-04-06 15:17:54.943
************************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
ORA-19809: 超出了恢复文件数的限制
ORA-19804: 无法回收 47715840 字节磁盘空间 (从 1073741824 限制中)
*** 2014-04-06 15:17:54.959 60680 kcrr.c
ARCH: Error 19809 Creating archive log file to 'C:ORAFLASH_RECOVERY_AREAORA11GARCHIVELOG2014_04_06O1_MF_1_14_%U_.ARC'
*** 2014-04-06 15:17:54.959 58942 kcrr.c
kcrrfail: dest:10 err:19809 force:0 blast:1
*** 2014-04-06 15:22:06.428
ORA-19815: 警告: db_recovery_file_dest_size 字节 (共 1073741824 字节) 已使用 99.34%, 尚有 7127040 字节可用。
*** 2014-04-06 15:22:06.428
************************************************************************
************************************************************************
从trace文件我们很容易发现问题出在db_recovery_file_dest_size上（db_recovery_file_dest_size 字节 (共 1073741824 字节) 已使用 100.00%, 尚有 0 字节可用。），并且trace文件中提供了相关的解决思路。我们也可以查看v$recovery_file_dest发现这个问题。
SQL> select * from v$recovery_file_dest;
NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
------------------------------ ----------- ---------- ----------------- ---------------
C:oraflash_recovery_area 1073741824 1071208960 7127040 40
SQL> show parameter db_recovery_file_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string C:oraflash_recovery_area
db_recovery_file_dest_size big integer 1G
现目前db_recovery_file_dest_size是1G，我们把它设置大一点，设置成2G。
SQL> alter system set db_recovery_file_dest_size=2G;
系统已更改。
重试后发现一切OK！
SQL> alter database open;
数据库已更改。