這個是一個真實的oracle（ORA-19815解決方法）的案例，希望對大家有幫助。
今天朋友公司的平台出現了登陸緩慢、查詢數據慢問題，並且通過spotlight監控oracle也出現登陸不成功現象，通過查看系統的內存、進程等，沒有發現問題，最后找到了我，我先查看了一下平台的內存、進程，也沒有發現問題，最后查看oracle的告警日志，發現問題如下：
1 ARC0: Failed to archive thread 1 sequence 53 (19809)
2 Sun Jun 10 23:12:12 2012
3 Errors in file /home/oracle/admin/BGTP/bdump/bgtp_arc1_3906.trc:
4 ORA-19815: WARNING: db_recovery_file_dest_size of 2147483648 bytes is 100.00% used, and has 0 remaining bytes available.
5 Sun Jun 10 23:12:12 2012
6 ************************************************************************
7 You have following choices to free up space from flash recovery area:
8 1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
9 then consider changing RMAN ARCHIVELOG DELETION POLICY.
10 2. Back up files to tertiary device such as tape using RMAN
11 BACKUP RECOVERY AREA command.
12 3. Add disk space and increase db_recovery_file_dest_size parameter to
13 reflect the new space.
14 4. Delete unnecessary files using RMAN DELETE command. If an operating
15 system command was used to delete files, then use RMAN CROSSCHECK and
16 DELETE EXPIRED commands.
17 ************************************************************************
是ORA-19815問題，通過metalink查詢，是閃回區空間耗盡，解決的方法我使用增大閃回區的存儲空間，來解決此問題
現在先查看一下v$recovery_file_dest試圖
可以發現可以回收的空間為0，在查看閃回區的使用率
18 SQL> select file_type, percent_space_used as used,percent_space_reclaimable as reclaimable, number_of_files as "number" from v$flash_recovery_area_usage;
19
20 FILE_TYPE USED RECLAIMABLE number
21 ------------ ---------- ----------- ----------
22 CONTROLFILE 0 0 0
23 ONLINELOG 0 0 0
24 ARCHIVELOG 98.65 0 51
25 BACKUPPIECE 0 0 0
26 IMAGECOPY 0 0 0
27 FLASHBACKLOG 0 0 0
28
29 6 rows selected.
發現已經使用了98.65%了
下面為解決此問題的方法
登陸數據庫
30 [oracle@master ~]$ sqlplus / as sysdba
31
32 SQL*Plus: Release 10.2.0.1.0 - Production on Sun Jun 10 22:41:54 2012
33
34 Copyright (c) 1982, 2005, Oracle. All rights reserved.
35
36
37 Connected to:
38 Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
39 With the Partitioning, OLAP and Data Mining options
先查看當前的閃回區大小
40 SQL> show parameter db_recovery_file_dest
41
42 NAME TYPE VALUE
43 ------------------------------------ ----------- ------------------------------
44 db_recovery_file_dest string /home/oracle/flash_recovery_ar
45 ea
46 db_recovery_file_dest_size big integer 2G
47 SQL> archive log list;
48 Database log mode Archive Mode
49 Automatic archival Enabled
50 Archive destination USE_DB_RECOVERY_FILE_DEST
51 Oldest online log sequence 53
52 Next log sequence to archive 53
53 Current log sequence 55
可以看得閃回區的大小為2g，所以我把他擴展為10g
54 SQL> alter system set db_recovery_file_dest_size=10G scope=both;
55
56 System altered.
然后在查看閃回區的使用情況
57 SQL> select * from v$recovery_file_dest;
58
59 NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
60 ---------------------------------------- ------------ ---------- ----------------- ---------------
61 /home/oracle/flash_recovery_area 10737418240 2383963648 0 57
62
63 SQL> show parameter db_recovery_file_dest
64
65 NAME TYPE VALUE
66 ------------------------------------ ----------- ------------------------------
67 db_recovery_file_dest string /home/oracle/flash_recovery_ar
68 ea
69 db_recovery_file_dest_size big integer 10G
在查看一下閃回區的使用率
70 SQL> select file_type, percent_space_used as used,percent_space_reclaimable as reclaimable, number_of_files as "number" from v$flash_recovery_area_usage;
71
72 FILE_TYPE USED RECLAIMABLE number
73 ------------ ---------- ----------- ----------
74 CONTROLFILE 0 0 0
75 ONLINELOG 0 0 0
76 ARCHIVELOG 22.2 0 57
77 BACKUPPIECE 0 0 0
78 IMAGECOPY 0 0 0
79 FLASHBACKLOG 0 0 0
80
81 6 rows selected.
從之前的98.65%降到了22.2%，在查看一下告警日志
82 db_recovery_file_dest_size of 10240 MB is 20.14% used. This is a
83 user-specified limit on the amount of space that will be used by this
84 database for recovery-related files, and does not reflect the amount of
85 space available in the underlying filesystem or ASM diskgroup.
86 Sun Jun 10 23:12:12 2012
87 ALTER SYSTEM SET db_recovery_file_dest_size='10G' SCOPE=BOTH;
88 Sun Jun 10 23:12:15 2012
89 Archiver process freed from errors. No longer stopped
90 Sun Jun 10 23:12:15 2012
91 Thread 1 advanced to log sequence 56
92 Current log# 1 seq# 56 mem# 0: /home/oracle/oradata/BGTP/redo01.log
93 Thread 1 advanced to log sequence 57
94 Current log# 2 seq# 57 mem# 0: /home/oracle/oradata/BGTP/redo02.log
95 Sun Jun 10 23:12:27 2012
96 Thread 1 cannot allocate new log, sequence 58
97 Checkpoint not complete
98 Current log# 2 seq# 57 mem# 0: /home/oracle/oradata/BGTP/redo02.log
99 Thread 1 advanced to log sequence 58
100 Current log# 3 seq# 58 mem# 0: /home/oracle/oradata/BGTP/redo03.log
101 Sun Jun 10 23:12:52 2012
102 Thread 1 advanced to log sequence 59
103 Current log# 1 seq# 59 mem# 0: /home/oracle/oradata/BGTP/redo01.log
104 Sun Jun 10 23:12:52 2012
105 Trying to expand controlfile section 11 for Oracle Managed Files
106 Expanded controlfile section 11 from 56 to 112 records
107 Requested to grow by 56 records; added 2 blocks of records
已經不在重復的報ORA-19815錯誤了，現在閃回區空間使用爆滿問題已經解決。
然后我的spotlight監控也已經可以監控oracle了，下面是spotlight監控oracle的圖
解決ORA-19815的方法很多，我這個只是其中的一種，感謝oracle 的metalink
本文出自 “吟—技術交流” 博客，請務必保留此出處http://dl528888.blog.51cto.com/2382721/895168