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

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

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

赶紧上网一查:

这一段是从网上截过来的 从Oracle9i开始,借助于undo日志文件提供了闪回查询的功能,由于功能也有一定的局限性,也就是说依赖于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,然后查询,发现使用率确实比较小,再用普通用户登录,OK,可以登录了,至此问题解决了。

 

据数据库目前可用存储空间情况、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


 



你可能感兴趣的:(oracle,数据库,Flash,database,System,oracle10g)