19185错误解决
协助解决 软件部数据库故障
上午接到消息，反映数据库起不来了
“
昨天我们有个系统数据库挂了,
”
登上数据库，尝试打开数据库，出现下面的错误
Tue Jul 28 09:17:28 2009
alter database open
Tue Jul 28 09:17:28 2009
LGWR: STARTING ARCH PROCESSES
ARC0 started with pid=16, OS id=2020
Tue Jul 28 09:17:28 2009
ARC0: Archival started
ARC1 started with pid=17, OS id=2488
Tue Jul 28 09:17:28 2009
ARC1: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
Tue Jul 28 09:17:28 2009
ARC1: STARTING ARCH PROCESSES
Tue Jul 28 09:17:28 2009
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
Tue Jul 28 09:17:28 2009
ARC2: Archival started
ARC2 started with pid=18, OS id=764
Tue Jul 28 09:17:28 2009
ARC1: STARTING ARCH PROCESSES COMPLETE
ARC1: Becoming the heartbeat ARCH
Tue Jul 28 09:17:28 2009
Errors in file f:/oracle/product/10.2.0/admin/orcl/udump/orcl_ora_1780.trc:
ORA-19815: ??: db_recovery_file_dest_size ?? (? 2147483648 ??) ??? 100.00%, ?? 0 ?????
Tue Jul 28 09:17:28 2009
************************************************************************
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.
Tue Jul 28 09:17:29 2009
Errors in file f:/oracle/product/10.2.0/admin/orcl/bdump/orcl_arc0_2020.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 2147483648 bytes is 100.00% used, and has 0 remaining bytes available.
3. Add disk space and increase db_recovery_file_dest_size parameter to
Tue Jul 28 09:17:29 2009
************************************************************************
reflect the new space.
You have following choices to free up space from flash recovery area:
4. Delete unnecessary files using RMAN DELETE command. If an operating
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
system command was used to delete files, then use RMAN CROSSCHECK and
then consider changing RMAN ARCHIVELOG DELETION POLICY.
DELETE EXPIRED commands.
2. Back up files to tertiary device such as tape using RMAN
************************************************************************
BACKUP RECOVERY AREA command.
Tue Jul 28 09:17:30 2009
Errors in file f:/oracle/product/10.2.0/admin/orcl/udump/orcl_ora_1780.trc:
ORA-19809: ???????????
ORA-19804: ???? 29703680 ?????? (? 2147483648 ???)
3. Add disk space and increase db_recovery_file_dest_size parameter to
Tue Jul 28 09:17:30 2009
ARCH: Error 19809 Creating archive log file to 'F:/ORACLE/PRODUCT/10.2.0/FLASH_RECOVERY_AREA/ORCL/ARCHIVELOG/2009_07_28/O1_MF_1_141_U_.ARC'
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
ARCH: Failed to archive thread 1 sequence 141 (19809)
system command was used to delete files, then use RMAN CROSSCHECK and
ORA-16038 signalled during: alter database open...
DELETE EXPIRED commands.
************************************************************************
Tue Jul 28 09:17:30 2009
Errors in file f:/oracle/product/10.2.0/admin/orcl/bdump/orcl_arc0_2020.trc:
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 18791424 bytes disk space from 2147483648 limit
Tue Jul 28 09:17:30 2009
ARC0: Error 19809 Creating archive log file to 'F:/ORACLE/PRODUCT/10.2.0/FLASH_RECOVERY_AREA/ORCL/ARCHIVELOG/2009_07_28/O1_MF_1_142_U_.ARC'
ARC0: Failed to archive thread 1 sequence 142 (19809)
ARCH: Archival stopped, error occurred. Will continue retrying
Tue Jul 28 09:17:31 2009
Errors in file f:/oracle/product/10.2.0/admin/orcl/bdump/orcl_arc0_2020.trc:
ORA-16038: log 3 sequence# 142 cannot be archived
ORA-19809: limit exceeded for recovery files
ORA-00312: online log 3 thread 1: 'F:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO03.LOG'
Tue Jul 28 09:18:28 2009
ARC0: Archiving not possible: No primary destinations
ARC0: Failed to archive thread 1 sequence 141 (4)
ARCH: Archival stopped, error occurred. Will continue retrying
Tue Jul 28 09:18:28 2009
Errors in file f:/oracle/product/10.2.0/admin/orcl/bdump/orcl_arc0_2020.trc:
ORA-16014: log 2 sequence# 141 not archived, no available destinations
ORA-00312: online log 2 thread 1: 'F:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02.LOG'
Tue Jul 28 09:19:28 2009
ARC1: Archiving not possible: No primary destinations
ARC1: Failed to archive thread 1 sequence 141 (4)
Tue Jul 28 09:19:40 2009
ALTER SYSTEM SET db_recovery_file_dest_size='200G' SCOPE=BOTH;
Tue Jul 28 09:19:55 2009
alter database open
Tue Jul 28 09:19:56 2009
db_recovery_file_dest_size of 204800 MB is 1.01% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Tue Jul 28 09:19:57 2009
Thread 1 advanced to log sequence 144
Thread 1 opened at log sequence 144
Current log# 2 seq# 144 mem# 0: F:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02.LOG
Successful open of redo thread 1
Tue Jul 28 09:19:58 2009
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Tue Jul 28 09:20:00 2009
SMON: enabling cache recovery
Tue Jul 28 09:20:00 2009
Archiver process freed from errors. No longer stopped
Tue Jul 28 09:20:02 2009
Successfully onlined Undo Tablespace 1.
Tue Jul 28 09:20:02 2009
SMON: enabling tx recovery
Tue Jul 28 09:20:02 2009
Database Characterset is ZHS16GBK
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=19, OS id=2700
Tue Jul 28 09:20:09 2009
Completed: alter database open
从上面信息可以看出，在对 redo2.log进行归档的时候，失败了。
Errors in file f:/oracle/product/10.2.0/admin/orcl/bdump/orcl_arc0_2020.trc:
ORA-16014: log 2 sequence# 141 not archived, no available destinations
ORA-00312: online log 2 thread 1: 'F:/ORACLE/PRODUCT/10.2.0/ORADATA/ORCL/REDO02.LOG'
粗略原因是 “ no available destinations”，
再根究其原因，可以看到 有错误
Errors in file f:/oracle/product/10.2.0/admin/orcl/bdump/orcl_arc0_2020.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 2147483648 bytes is 100.00% used, and has 0 remaining bytes available.
原来是归档空间 2G已经完全使用了，
无法再对联机日志归档，导致无法打开数据库。
解决方法如下：
直接把数据库的归档空间大小放大 即可
把数据库从mount状态打开
startup mount;
alter system set db_recovery_file_dest_size=200G
alter database open;
问题解决。