ORA-19809: 超出了恢复文件数的限制故障处理实例
1.估计又是以前遇到过的错误的。
2.Oracle官方的有关19809的信息
3.ORA-19809: limit exceeded for recovery files
4.Cause: The limit for recovery files specified by the DB_RECOVERY_FILE_DEST_SIZE was exceeded.
5.Action: The error is accompanied by 19804. See message 19804 for further details.
6.
7.ORA-19804: cannot reclaim string bytes disk space from string limit
8.Cause: Oracle cannot reclaim disk space of specified bytes from the DB_RECOVERY_FILE_DEST_SIZE limit.
9.Action: There are five possible solutions:
10.1) Take frequent backup of recovery area using RMAN.
11.2) Consider changing RMAN retention policy.
12.3) Consider changing RMAN archivelog deletion policy.
13.4) Add disk space and increase DB_RECOVERY_FILE_DEST_SIZE.
14.5) Delete files from recovery area using RMAN.
15.
16.这里是官方提供的信息和解决方案了，以前遇过这个错误，还记得是怎么搞定的吗
17.
18.当然记得，经历是最好的学习方式。这样的错误恢复当然是记得怎么搞的的哟。
19.
20.基本上的原因是，db_recovery_file_desc有size限制，默认是2G，如果用户没有设置过的话，应该就是这里的归档的文件超过了这个大小，而导致归档失败了，
21.
22.先查看一下情况吧
23.
24.SQL> archive log list;
25.
26.数据库日志模式 存档模式
27.
28.自动存档 启用
29.
30.存档终点 USE_DB_RECOVERY_FILE_DEST
31.
32.最早的联机日志序列 23
33.
34.下一个存档日志序列 25
35.
36.当前日志序列 25
37.
38.SQL> select * from v$recovery_file_dest;
39.
40.NAME
41.
42.----------------------------------------------------------------
43.
44.SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
45.
46.----------- ---------- ----------------- ---------------
47.
48.F:developeroracleproduct10.2.0 lash_recovery_area
49.
50.2147483648 2547483848 0 73
51.
52.这里已经把所有的db_recovery_file_dest的容量都占完了。
53.
54.解决方法，
55.
56.删除多余的归档文件。
57.
58.然后设置较大的db_recovery_file_dest_size
59.
60.把log_archive_destx指定到别的地方，不要放到db_recovery_file_dest这里了
61.
62.开始我们的恢复之旅吧，数据的恢复就像旅行一般，让我们在oracle的知识体系里旅游一样
63.
64.删除多余的归档文件
65.
66.打开RMAN
67.
68.rman target /
69.
70.RMAN>crosscheck archivelog all;
71.
72.运行这个命令可以把无效的archivelog标准出来，这样，我们就知道哪些是expired的了
73.
74.RMAN>delete expired archivelog all;
75.
76.也可以直接用一个指定的日期来删除
77.
78.RMAN>delete noprompt archivelog until time "sysdate -3";
79.
80.我用的上面的方式 delete expired archivelog all; 低调低调
81.
82.这样基本上就搞定了，数据库应该可以启动了，
83.
84.试试看就知道
85.
86.SQL>alter database open;
87.
88.熟悉的启动的信息出来了。
89.
90.不过这样完，就有点不是学习知识的态度了，因为你这个是一个治标不治本的方法，
91.
92.随时客户还会因为这个问题，一个星期，一个月后找你，因为，这里的archivelog，可能又操过限制了
93.
94.因为这里的archivelog还在不断的增长，既然是这样就还会出现这样的问题。
95.
96.要解决他，
97.
98.我们要针对着这个问题的本质动刀了。
99.
100.action
101.
102.指定retention的策略，使得archivelog不至于这样增加
103.
104.RMAN>configure retention policy to recovery window of 7 days;
105.
106.RMAN>configure retention policy to redundancy 3;
107.
108.呵呵呵 客户没有使用RMAN来进行备份，下次有机会要介绍给客户，同时也多接这样一个业务，客户现在还没有因为数据崩溃而崩溃过，所以现在他还不知道这个价值，如果那天有这样一天，客户想起我给他介绍的RMAN，估计自己就会想起来找我的。 嘻嘻
109.
110.指定大一些db_recovery_file_dest_size
111.
112.SQL>alter system db_recovery_file_dest_size=4G scope=both;
113.
114.这个方法同样，治标不治本，好比，现在现在水库泄洪，你扩大水库的size是一种方法，但是单纯靠这个方法，总有一天，还是overflow了。我们需要的应该是定期的就放一放水，增加容量，同时最好放到无限制的水库里
115.
116.所以还有一个方法不要忘记了，就是把这个archivelog_dest指定到没有限制的地方
117.
118.SQL>alter system log_archive_dest='F:oracleproduct10.2.0archivelog_area';
119.
120.OK了
121.
122.这次故障处理，没有惊心动魄，以前遇到没有整理，这次详细的整理了一下记了下来。
123.
124.不过由于客户的故障不能宕机太久，所以在处理的时候，没有记录出错信息，现在的整理的过程中的错误信息和操作步骤中的一些信息，全是在自己机器中模拟出来的，如果和实例有差异，以你的机器的实际信息为主。
125.
126.查看修改ORACLE10G归档日志空间的限制
127.
128.在ORACLE10G中，默认的归档路径为$ORACLE_BASE/flash_recovery_area。对于这个路径，ORACLE有一个限制，就是默认只能有2G的空间给归档日志使用，可以使用下面两个SQL语句去查看它的限制：
129.1. select * from v$recovery_file_dest;
130.2. show parameter db_recovery_file_dest(这个更友好直观一些)
131.当归档日志数量大于2G时，那么就会由于没有更多的空间去容纳更多的归档日志会报无法继续归档的错误。
132.如：“RA-19809: limit exceeded for recovery files
133.ORA-19804: cannot reclaim 10017792 bytes disk space from 2147483648 limit
134.ARC0: Error 19809 Creating archive log file to '/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2007_04_30/o1_mf_1_220_0_.arc' ”这时我们可以修改它的默认限制，比如说将它增加到5G或更多，也可以将归档路径重新置到别的路径，就不会有这个限制了。
135.更改限制语句如下：
136.alter system set db_recovery_file_dest_size=5368709102 (这里为5G 5x1024x1024x1024=5G)
137.alter system set db_recovery_file_dest_size=10737418240
2.Oracle官方的有关19809的信息
3.ORA-19809: limit exceeded for recovery files
4.Cause: The limit for recovery files specified by the DB_RECOVERY_FILE_DEST_SIZE was exceeded.
5.Action: The error is accompanied by 19804. See message 19804 for further details.
6.
7.ORA-19804: cannot reclaim string bytes disk space from string limit
8.Cause: Oracle cannot reclaim disk space of specified bytes from the DB_RECOVERY_FILE_DEST_SIZE limit.
9.Action: There are five possible solutions:
10.1) Take frequent backup of recovery area using RMAN.
11.2) Consider changing RMAN retention policy.
12.3) Consider changing RMAN archivelog deletion policy.
13.4) Add disk space and increase DB_RECOVERY_FILE_DEST_SIZE.
14.5) Delete files from recovery area using RMAN.
15.
16.这里是官方提供的信息和解决方案了，以前遇过这个错误，还记得是怎么搞定的吗
17.
18.当然记得，经历是最好的学习方式。这样的错误恢复当然是记得怎么搞的的哟。
19.
20.基本上的原因是，db_recovery_file_desc有size限制，默认是2G，如果用户没有设置过的话，应该就是这里的归档的文件超过了这个大小，而导致归档失败了，
21.
22.先查看一下情况吧
23.
24.SQL> archive log list;
25.
26.数据库日志模式 存档模式
27.
28.自动存档 启用
29.
30.存档终点 USE_DB_RECOVERY_FILE_DEST
31.
32.最早的联机日志序列 23
33.
34.下一个存档日志序列 25
35.
36.当前日志序列 25
37.
38.SQL> select * from v$recovery_file_dest;
39.
40.NAME
41.
42.----------------------------------------------------------------
43.
44.SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
45.
46.----------- ---------- ----------------- ---------------
47.
48.F:developeroracleproduct10.2.0 lash_recovery_area
49.
50.2147483648 2547483848 0 73
51.
52.这里已经把所有的db_recovery_file_dest的容量都占完了。
53.
54.解决方法，
55.
56.删除多余的归档文件。
57.
58.然后设置较大的db_recovery_file_dest_size
59.
60.把log_archive_destx指定到别的地方，不要放到db_recovery_file_dest这里了
61.
62.开始我们的恢复之旅吧，数据的恢复就像旅行一般，让我们在oracle的知识体系里旅游一样
63.
64.删除多余的归档文件
65.
66.打开RMAN
67.
68.rman target /
69.
70.RMAN>crosscheck archivelog all;
71.
72.运行这个命令可以把无效的archivelog标准出来，这样，我们就知道哪些是expired的了
73.
74.RMAN>delete expired archivelog all;
75.
76.也可以直接用一个指定的日期来删除
77.
78.RMAN>delete noprompt archivelog until time "sysdate -3";
79.
80.我用的上面的方式 delete expired archivelog all; 低调低调
81.
82.这样基本上就搞定了，数据库应该可以启动了，
83.
84.试试看就知道
85.
86.SQL>alter database open;
87.
88.熟悉的启动的信息出来了。
89.
90.不过这样完，就有点不是学习知识的态度了，因为你这个是一个治标不治本的方法，
91.
92.随时客户还会因为这个问题，一个星期，一个月后找你，因为，这里的archivelog，可能又操过限制了
93.
94.因为这里的archivelog还在不断的增长，既然是这样就还会出现这样的问题。
95.
96.要解决他，
97.
98.我们要针对着这个问题的本质动刀了。
99.
100.action
101.
102.指定retention的策略，使得archivelog不至于这样增加
103.
104.RMAN>configure retention policy to recovery window of 7 days;
105.
106.RMAN>configure retention policy to redundancy 3;
107.
108.呵呵呵 客户没有使用RMAN来进行备份，下次有机会要介绍给客户，同时也多接这样一个业务，客户现在还没有因为数据崩溃而崩溃过，所以现在他还不知道这个价值，如果那天有这样一天，客户想起我给他介绍的RMAN，估计自己就会想起来找我的。 嘻嘻
109.
110.指定大一些db_recovery_file_dest_size
111.
112.SQL>alter system db_recovery_file_dest_size=4G scope=both;
113.
114.这个方法同样，治标不治本，好比，现在现在水库泄洪，你扩大水库的size是一种方法，但是单纯靠这个方法，总有一天，还是overflow了。我们需要的应该是定期的就放一放水，增加容量，同时最好放到无限制的水库里
115.
116.所以还有一个方法不要忘记了，就是把这个archivelog_dest指定到没有限制的地方
117.
118.SQL>alter system log_archive_dest='F:oracleproduct10.2.0archivelog_area';
119.
120.OK了
121.
122.这次故障处理，没有惊心动魄，以前遇到没有整理，这次详细的整理了一下记了下来。
123.
124.不过由于客户的故障不能宕机太久，所以在处理的时候，没有记录出错信息，现在的整理的过程中的错误信息和操作步骤中的一些信息，全是在自己机器中模拟出来的，如果和实例有差异，以你的机器的实际信息为主。
125.
126.查看修改ORACLE10G归档日志空间的限制
127.
128.在ORACLE10G中，默认的归档路径为$ORACLE_BASE/flash_recovery_area。对于这个路径，ORACLE有一个限制，就是默认只能有2G的空间给归档日志使用，可以使用下面两个SQL语句去查看它的限制：
129.1. select * from v$recovery_file_dest;
130.2. show parameter db_recovery_file_dest(这个更友好直观一些)
131.当归档日志数量大于2G时，那么就会由于没有更多的空间去容纳更多的归档日志会报无法继续归档的错误。
132.如：“RA-19809: limit exceeded for recovery files
133.ORA-19804: cannot reclaim 10017792 bytes disk space from 2147483648 limit
134.ARC0: Error 19809 Creating archive log file to '/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2007_04_30/o1_mf_1_220_0_.arc' ”这时我们可以修改它的默认限制，比如说将它增加到5G或更多，也可以将归档路径重新置到别的路径，就不会有这个限制了。
135.更改限制语句如下：
136.alter system set db_recovery_file_dest_size=5368709102 (这里为5G 5x1024x1024x1024=5G)
137.alter system set db_recovery_file_dest_size=10737418240