oracle 10g 报错：ORA-00257: archiver error. Connect internal only, until freed

今天在公司，突然同事告诉我数据库无法登录了，想想这段时间没有动过库，为什么无法登录呢？一边想是什么问题，一边连接测试登录。

首先报错：ORA-00257: archiver error. Connect internal only, until freed.

赶紧上网一查：

这一段是从网上截过来的　从Oracle9i开始，借助于undo日志文件提供了闪回查询的功能，由于功能也有一定的局限性，也就是说依赖于ＵＮＤＯ日志的事务不能被覆盖，所以在oracle10g开始又采用了一种新的FlashBack日志来实现这个功能，而且更为强大，可以将数据库退回到过去的某个时间点去。这个文件默认最大为2g 。但是在一段时间过后，很快就达到了2G,这个时候就会出现ORA--00257 错误了。

有两种解决方法：

第一种　就是关闭闪回日志的功能，这种对于开发环境中不失为一种好方法，因为开发环境中，并不追求数据的可安全性什么的。通过如下语句可以改：

alter database flashback off

第二种　就是增大闪回日志文件的最大值，如下：

alter system set DB_RECOVERY_FILE_DEST_SIZE=10g

这个时候，你可以去查看V$flash_recovery_area_usage 视图中的使用率情况，这个时候发现使用率（PERCENT_SPACE_USED列的值）已经大大降低了。再通过如下语句去查看系统日志文件情况。

select * from V$log 　　会发现现在redo日志文件也可以正常写入了，至此问题解决。

我的解决过程：

首先我用sys（sysdba）帐户登录，还好可以登录，如果这也无法登录，那我就更伤心了。然后用第一种方法，过了几分钟，还在处理阶段一直显示无法完成，就放弃了。

马上使用第二种方法，修改日志文件大小为10g，然后查询，发现使用率确实比较小，再用普通用户登录，ＯＫ，可以登录了，至此问题解决了。

 

据数据库目前可用存储空间情况、FLASH_RECOVERY_AREA空间为2GB的实际情况，把FLASH_RECOVERY_AREA的空间修改为20GB()。
SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE=20g;
系统已更改。

(其实问题的本质是归档日志的使用已经达到了spfile等启动参数文件中指定的最大值。oracle 10g中归档日志默认的存放地是闪回目录，即%ORACLE_BASE%/flash_recovery_area的相应实例名下面，这个位置的大小在参数文件中有个限制，解决空间不足的问题可以通过两种方式来实现，一个修改这个大小限制，还有一个就是修改归档日志存放位置。)

如果不要这些archivelog的话，可以删除一些

rman>DELETE NOPROMPT ARCHIVELOG UNTIL TIME 'SYSDATE-3'; 直接运行这条 这样会只保留三天的归档

sql> select * from v$flash_recovery_area_usage;

FILE_TYPE                PERCENT_SPACE_USED    PERCENT_SPACE_RECLAIMABLE   NUMBER_OF_FILES
------------------------------- -------------------------------------      -----------------------------------------------------   -------------------------------
CONTROLFILE                    0                                                           0                                        0
ONLINELOG                        0                                                          0                                        0
ARCHIVELOG                 6.11                                                          0                                        3
BACKUPPIECE                   0                                                          0                                        0
IMAGECOPY                     0                                                         0                                         0
FLASHBACKLOG                0                                                        0                                         0

还可参考：http://www.eygle.com/archives/2004/12/rman_crosscheck.html