ORA-19815错误的重现和解决办法

作者：gtlions 【转载时请以超链接心事标明文章出处和作者信息,谢谢.】

链接：http://blog.csdn.net/gtlions/archive/2010/04/06/5455418.aspx

----------------------------------------------------------------------------------------------------------

前几天写到在同事机器上解决了因归档设置造成的问题，当时是麻利得解决了，今天给重现下。

这个错误的产生背景应该是如下：

Oracle10G 版本，启用的自动归档，没有设置archive_log_dest和log_archive_dest_n，设置了db_recovery_file_dest，db_recovery_file_dest_size为默认的2G，在自动的日志归档的时候，日志文件即将大于db_recovery_file_dest_size的限制值造成的。

还原过程如下：

SQL> set linesize 1000;

SQL> set wrap off;

SQL> show parameter recover;

NAME TYPE VALUE

------------------------------------ --------------------------------- ------------------------------

db_recovery_file_dest string /oradata/crmtest01/reco/

db_recovery_file_dest_size big integer 100M

recovery_parallelism integer 0

为了便于试验，本例中将上限设置为100M。

接着清空log_archive_dest_n。

SQL> alter system set log_archive_dest_1='' scope=both;

System altered.

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup

ORACLE instance started.

Total System Global Area 1207959552 bytes

Fixed Size 2083528 bytes

Variable Size 335545656 bytes

Database Buffers 855638016 bytes

Redo Buffers 14692352 bytes

Database mounted.

Database opened.

SQL> show parameter archive;

NAME TYPE VALUE

------------------------------------ --------------------------------- ------------------------------

archive_lag_target integer 0

log_archive_config string

log_archive_dest string

log_archive_dest_1 string

log_archive_dest_10 string

log_archive_dest_2 string

log_archive_dest_3 string

log_archive_dest_4 string

log_archive_dest_5 string

log_archive_dest_6 string

log_archive_dest_7 string

NAME TYPE VALUE

------------------------------------ --------------------------------- ------------------------------

log_archive_dest_8 string

log_archive_dest_9 string

log_archive_dest_state_1 string enable

log_archive_dest_state_10 string enable

log_archive_dest_state_2 string enable

log_archive_dest_state_3 string enable

log_archive_dest_state_4 string enable

log_archive_dest_state_5 string enable

log_archive_dest_state_6 string enable

log_archive_dest_state_7 string enable

log_archive_dest_state_8 string enable

NAME TYPE VALUE

------------------------------------ --------------------------------- ------------------------------

log_archive_dest_state_9 string enable

log_archive_duplex_dest string

log_archive_format string %t_%s_%r.dbf

log_archive_local_first boolean TRUE

log_archive_max_processes integer 2

log_archive_min_succeed_dest integer 1

log_archive_start boolean FALSE

log_archive_trace integer 0

remote_archive_enable string true

standby_archive_dest string ?/dbs/arch

SQL> alter system switch logfile;

System altered.

SQL> show parameter recover;

NAME TYPE VALUE

------------------------------------ --------------------------------- ------------------------------

db_recovery_file_dest string /oradata/crmtest01/reco/

db_recovery_file_dest_size big integer 100M

recovery_parallelism integer 0

SQL> Insert Into crmii.arch_test Select * From crmii.arch_test;

911 rows created.

SQL> /

1822 rows created.

SQL> /

3644 rows created.

SQL> commit;

Commit complete.

SQL> /

Commit complete.

SQL> Insert Into crmii.arch_test Select * From crmii.arch_test;

7288 rows created.

SQL> Insert Into crmii.arch_test Select * From crmii.arch_test;

14576 rows created.

SQL> Insert Into crmii.arch_test Select * From crmii.arch_test;

29152 rows created.

SQL> Insert Into crmii.arch_test Select * From crmii.arch_test;

58304 rows created.

SQL> commit;

Commit complete.

SQL> Insert Into crmii.arch_test Select * From crmii.arch_test;

116608 rows created.

SQL> /

233216 rows created.

SQL> /

466432 rows created.

SQL> commit;

Commit complete.

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 98.47 0 3

BACKUPPIECE 0 0 0

IMAGECOPY 0 0 0

FLASHBACKLOG 0 0 0

可以看到这个区域将要到达上限值了。

此时去检查相关日志文件，重新出现了报警和错误：

Tue Apr 6 17:33:22 2010

Errors in file /oracle/ora10g/admin/crmtest01/bdump/crmtest01_arc0_30467.trc:

ORA-19815: WARNING: db_recovery_file_dest_size of 104857600 bytes is 100.00% used, and has 0 remaining bytes available.

Tue Apr 6 17:33:22 2010

************************************************************************

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: limit exceeded for recovery files

ORA-19804: cannot reclaim 44691968 bytes disk space from 104857600 limit

此时数据库已经HANG住了。

解决办法是将这些已经归档的日志文件备份起来，oracle就会回收相关的占用空间继续做归档。或者是临时的将db_recovery_file_dest_size增大。

SQL>alter system set db_recovery_file_dest_size=3G scope=both;

另外，如果是手工从磁盘上删除这些文件并无法解决该问题，因为只是从OS级别的做了删除，Oracle并不会自动和重新统计释放了的空间，具体还需要参考RMAN备份与恢复。

oracle10g推出db_recovery_file_dest和db_recovery_file_dest_size是出于新的特性、便于管理考虑的，因此oracle将要使用这对参数。

如果你不想要，那完全可以废了db_recovery_file_dest而是用log_archive_dest_n参数。

-The End-