Oracle 10g默认归档路径在闪回区的2G空间大小限制问题

Oracle 10g默认归档路径在闪回区的2G空间大小限制问题是本文我们主要要介绍的内容，接下来我们就通过一个实际的例子来开始介绍。实例使这样的，在为客户解决问题时，打开数据解压缩后一看，他们还是用的Oracle 815版本的(他们exp导出时，带了导出日志，从导出日志中看出来是oracle 815版本的)，不过没有关系，低版本的exp是可以用高版本的imp导入到高版本数据库中的。
一看是导入还很正常，导入到其中某个表的时候，突然就不动了。一开始我还没有弄明白怎么回事。后来，无意中看到了计算机管理--事件查看器中，有很多报错信息：
Archive process error: ORA-16038: log 1 sequence# 317 cannot be archived 
ORA-19809: limit exceeded for recovery files 
ORA-00312: online log 1 thread 1: 'E:/ORACLE/PRODUCT/10.2.0/ORADATA/ORACLE/REDO01.LOG'
我这才发现，问题出在了归档上了。
又看了alert_oracle.log文件，也有很多这个报错信息。到这里，这个问题给了我一个教训：与oracle有关的操作，只要有问题，肯定会向alert_oracle.log文件写入日志的，就看你有没有意识去看这个日志文件了。
网上查看资料得知：Oracle 10g在默认情况下，归档日志是保存在闪回恢复区的（对于我的来说是：E:/oracle/product/10.2.0/flash_recovery_area/ORACLE/ARCHIVELOG），如果你建库的时候用的默认设置，闪回恢复区应该是2G，空间被占满了以后就无法再归档了。
此时，我从sqlplus  open database，有提示：
Microsoft Windows XP [版本 5.1.2600] 
(C) 版权所有 1985-2001 Microsoft Corp. 
C:/Documents and Settings/Administrator>sqlplus / as sysdba 
SQL*Plus: Release 10.2.0.1.0 - Production on 星期三 11月 26 17:58:22 2008 
Copyright (c) 1982, 2005, Oracle.  All rights reserved. 
连接到: 
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production 
With the Partitioning, OLAP and Data Mining options 
SQL> select open_mode from v$database; 
OPEN_MODE 
---------- 
MOUNTED 
SQL> alter database open; 
alter database open 
* 
第 1 行出现错误: 
ORA-16014: 日志 1 的序列号 317 未归档, 没有可用的目的地 
ORA-00312: 联机日志 1 线程 1: 
'E:/ORACLE/PRODUCT/10.2.0/ORADATA/ORACLE/REDO01.LOG' 
SQL>
那怎么解决这个问题呢？网上的高手也给出了不少方法（以下的方法为转载，原文地址：http://yaanzy.itpub.net/post/1263/286285  ）：
解决方法：
1.将归档设置到其他目录，修改alter system set log_archive_dest = 其他路径。
2.转移或者删除闪回恢复区里的归档日志。
3.增大闪回恢复区。
ALTER SYSTEM SET db_recovery_file_dest_size=4g scope=both;
我的处理方法是采用第3种方法，下边是我的操作过程：
SQL> show parameter db_recovery_file_dest_size; 
NAME                                 TYPE        VALUE 
------------------------------------ ----------- ------------------------------ 
db_recovery_file_dest_size           big integer 2G 
SQL> alter system set db_recovery_file_dest_size=3G; 
系统已更改。 
SQL> alter database open; 
数据库已更改。 
SQL> show parameter db_recovery_file_dest_size; 
NAME                                 TYPE        VALUE 
------------------------------------ ----------- ------------------------------ 
db_recovery_file_dest_size           big integer 3G 
SQL>
值得注意的是，我执行完毕alter system set db_recovery_file_dest_size=3G;后，马上又去show parameter db_recovery_file_dest_size;此时显示的是3g了，不是原来的2g了。从另外一个方面来说：E:/oracle/product/10.2.0/db_1/dbs/SPFILEORACLE.ORA这个文件的修改时间，就是我执行alter system set db_recovery_file_dest_size=3G; 这就更证明，此更改马上就生效了。
如果将归档路径下的可用空间扩充到了3G,也就是在原来2G的基础上又加了1G.  oracle database下新形成的归档日志，实际上是用的这个新增的1G的空间。也许会有人提出疑问，“那我把原来已经形成的2G归档日志删除掉，oracle database不就能用3G了么？”其实不是这样，虽然在物理空间上，已经删除了2G,但是动态性能视图（v$recovery_file_dest)并没有释放此这2g空间，可以使用select * from v$recovery_file_dest 查询出来。
若你不从动态性能视图里删除这2G的空间，oracle database会认为这2G依然被占用。若是有个大的事物提交，并有频繁的日志切换，1G的空间马上就被用完，到时候你的alert_oracle.log就有错误出现，比如：
ORA-19815: WARNING: db_recovery_fi