« What's the Next to be Compressed? | Blog首页 | 2005-12-09 EMC DISK Fault »
Oracle10g New Feature:闪回恢复区空间管理
链接:https://www.eygle.com/archives/2005/12/oracle10g_flash_recovery_area_space_management.html
Oracle在10g中引入了闪回区(flash recovery area)的概念,用以简化和完善备份,但是闪回区同样需要精心规划和设置,否则一样会遇到问题,从Oracle10gR2开始,Oracle还提供了一个新的视图V$FLASH_RECOVERY_AREA_USAGE,用以监控闪回区空间的耗用情况。本文简要介绍Oracle闪回区的警报和空间维护机制。
每次RMAN在闪回区(flash recovery area)创建文件时,会同时更新可删除文件列表。当闪回区存在空间压力时,Oracle会自动从闪回区中删除废弃文件,当没有更多空间可以释放时,Oracle会给出空间压力警报。
当空间使用达到100%,数据库将会因为无法归档等原因挂起。
闪回区的大小由:db_recovery_file_dest_size 参数指定。
路径由: db_recovery_file_dest 参赛指定。
SQL> show parameter db_recovery NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /msflsh
db_recovery_file_dest_size big integer 65G
这两个参数都是动态参数。
当闪回区空间使用达到85%时,Oracle会发出警告:
*** SERVICE NAME:(SYS$BACKGROUND) 2005-12-03 13:20:16.864
*** SESSION ID:(156.1) 2005-12-03 13:20:16.864
ORA-19815: WARNING: db_recovery_file_dest_size of 53687091200 bytes is 85.00% used,
and has 8050696704 remaining bytes available.
当空间使用达到97%的时候,Oracle会发出Critical的警报:
ORA-19815: WARNING: db_recovery_file_dest_size of 53687091200 bytes is 97.02% used,
and has 1602355712 remaining bytes available.
当空间使用达到100%的时候,数据库无法归档就会挂起了:
ORA-19815: WARNING: db_recovery_file_dest_size of 53687091200 bytes is 100.00% used,
and has 0 remaining bytes available.
接下来就是这样的错误了:
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 9563136 bytes disk space from 53687091200 limit
*** 2005-12-04 13:59:14.011 52278 kcrr.c
ARC1: Error 19809 Creating archive log file to
'/msflsh/MMSDB/archivelog/2005_12_04/o1_mf_1_17108_%u_.arc'
*** 2005-12-04 13:59:14.011 50725 kcrr.c
kcrrfail: dest:10 err:19809 force:0 blast:1
*** 2005-12-04 13:59:14.012 52278 kcrr.c
ARC1: All standby destinations failed; successful archival assumed
*** 2005-12-04 13:59:14.026 16432 kcrr.c
ORA-16038: log 1 sequence# 17108 cannot be archived
注意这里的一个词:reclaim,Oracle用了回收在这里,意思就是已经没有空间可以回收以满足归档的空间需求了。
当Oracle在reclaim空间时,你可能看到如下类似信息:
Sat Oct 1 21:20:54 2005
Deleted Oracle managed file +ORADG/danaly/backupset/2006_09_07/ncsnf0_tag20060907t192619_0.274
Deleted Oracle managed file +ORADG/danaly/archivelog/2006_09_08/thread_1_seq_35.276.600588049
Sun Oct 2 05:46:40 2005
Thread 1 advanced to log sequence 80
Current log# 2 seq# 80 mem# 0: +ORADG/danaly/onlinelog/group_2.260.600173851
Current log# 2 seq# 80 mem# 1: +ORADG/danaly/onlinelog/group_2.261.600173853
Sun Oct 2 05:46:41 2005
Deleted Oracle managed file +ORADG/danaly/archivelog/2006_09_08/thread_1_seq_36.277.600600509
Deleted Oracle managed file +ORADG/danaly/archivelog/2006_09_08/thread_1_seq_37.278.600625093
Deleted Oracle managed file +ORADG/danaly/archivelog/2006_09_09/thread_1_seq_38.279.600674413
历史上的今天...
>> 2020-12-09文章:
>> 2016-12-09文章:
>> 2010-12-09文章:
>> 2008-12-09文章:
>> 2007-12-09文章:
>> 2006-12-09文章:
By eygle on 2005-12-09 16:19 | Comments (4) | Oracle12c/11g | 567 |
这个特性真是太棒了!如果使用flash recovery area的话,是不是rman只需要定期的备份数据文件、控制文件、spfile、pwdfile就可以了。归档日志就不需要了,因为它可以归档到闪回区,而且自动判断是否可以删除。是不是这样呢?
始终还是要备份的,很少的数据库能按照必要的备份策略把归档和备份集等都保存在磁盘上,空间的需求将是惊人。
小的数据库怎都好办,大起来就需要仔细规划了。
盖老师,你好!
我有个数据库版本是10.2.1的,设置了自动备份功能(安装时指定的),每晚2点开始备份,但奇怪的是,每次备份时都自动关闭数据库.数据库这样每天都重新启动一次,有没有隐患.
如蒙赐教,不胜感激!
看alert文件里怎么写的?