Chinaunix首页 | 论坛 | 博客

railon的ChinaUnix博客railon.blog.chinaunix.net

首页　| 　博文目录　| 　关于我

railon

  • 博客访问： 1186041
  • 博文数量： 253
  • 博客积分： 5892
  • 博客等级： 大校
  • 技术积分： 1942
  • 用 户 组： 普通用户
  • 注册时间： 2011-02-24 14:20
文章分类

全部博文（253）

文章存档

2012年（98）

2011年（155）

我的朋友
最近访客
推荐博文
相关博文
[Oracle 10g] 闪回恢复区 (Flash Recovery Area)

分类： Oracle

2011-12-14 21:45:35

作者：Fenng
日期：05-Dec-2004　
出处：
版本：0.1

何为闪回恢复区

Oracle 10g 有一项新功能称为:自动的基于磁盘的备份与恢复( Automatic Disk-Based Backup and Recovery )。实现该功能的基础为本文要讲述的闪回恢复区( Flash Recovery Area )。闪回恢复区是 Oracle 10g 中的新事物。简单的说，闪回恢复区是一块用以存储恢复相关的文件的存储空间。 允许用户集中存储所有恢复相关的文件。

闪回恢复区可以放在如下几种存储形式上:

  • 目录
  • 一个文件系统
  • 自动存储管理(ASM)磁盘组

在 RAC 环境中,这个该位置必须为 集群文件系统 (cluster file system) 或是 ASM 磁盘组亦或是通过 NFS 控制的文件共享目录，还要注意的是，所有实例的位置和操作系统的磁盘限额 (disk quota) 必须一致。

如下几种文件可以放到闪回恢复区中:

  • 控制文件
  • 归档的日志文件(注：Oracle 手册上所说的在设定flash recovery area之后，LOG_ARCHIVE_DEST_10的值将自动设定为flash recovery area的位置，这个变化在笔者测试过程中观察不到)
  • 闪回日志
  • 控制文件和 SPFILE 自动备份
  • RMAN 备份集
  • 数据文件拷贝

为何要用闪回恢复区?

如前所述，闪回恢复区提供了一个集中化的存储区域，很大程度上减小了管理开销。这是其最主要的优点。与 RMAN 结合使用可以进行快速恢复。

近年来随着存储技术的发展，单个磁盘的存储能力已经加强。这使自动的基于磁盘的备份与恢复的技术实现成为可能。而闪回恢复区恰是基于磁盘的备份与恢复的基础。把闪回恢复区和 OMF 与 ASM 结合运用看起来是比较完美的方案。 当然，不可否认的是，自动备份恢复技术还远远不够成熟。

设定闪回恢复区

如果您使用DBCA创建的数据库，在安装时可以设定闪回恢复区的位置以及大小(点击这里查看)--这也是 Oracle 10g OUI 的新功能之一。如果在开始的时候没有启用闪回恢复区，可以通过如下方式设定。

调整如下两个动态初始化参数(无需重新启动实例)：

  1. SQL> ALTER SYSTEM SET db_recovery_file_dest_size=2g SCOPE=BOTH;

  3. System altered.

  5. SQL>

  7. SQL> ALTER SYSTEM SET db_recovery_file_dest='/u01/app/oracle/flash_recovery_area'
  8.   2 SCOPE=BOTH;

  10. System altered.

  12. SQL>
之后查看所作的修改是否生效：
  1. SQL> SHOW parameter db_recovery_file_dest

  3. NAME TYPE VALUE
  4. -------------------------------- ----------- -----------------------------------
  5. db_recovery_file_dest string /u01/app/oracle/flash_recovery_area
  6. db_recovery_file_dest_size big integer 2G

  8. SQL>

如上所示，我们设定了闪回恢复区，位置在 /u01/app/oracle/flash_recovery_area，上限为2G。如果要撤销闪回恢复区，把初始化参数 DB_RECOVERY_FILE_DEST 的值清空即可。

注意: DB_RECOVERY_FILE_DEST_SIZE 只有在 DB_RECOVERY_FILE_DEST 清空之后才可以清空。

初始化参数 db_recovery_file_dest_size 的设定有一点点需要注意的地方：

  • 文件的第0块和操作系统数据块头的空间大小不包含在内
  • 该参数并不代表实际占用的空间大小。如果空间被压缩、镜像、RAID 的话，该参数的值意义是不一样的
管理并监控闪回恢复区

我们先看看闪回恢复区内的文架结构层次

  1. SQL> host tree /u01/app/oracle/flash_recovery_area
  2. /u01/app/oracle/flash_recovery_area
  3. |-- DEMO
  4. | |-- archivelog
  5. | | |-- 2004_12_07
  6. | | | |-- o1_mf_1_10_0vbwz2fm_.arc
  7. | | | |-- o1_mf_1_11_0vc1yj14_.arc
  8. | | | |-- o1_mf_1_12_0vc6vvws_.arc
  9. | | | |-- o1_mf_1_13_0vcbv6cg_.arc
  10. | | | |-- o1_mf_1_14_0vchlxb3_.arc
  11. | | | |-- o1_mf_1_15_0vcnh2bz_.arc
  12. | | | |-- o1_mf_1_5_0vbk8goo_.arc
  13. | | | |-- o1_mf_1_6_0vbkq6dk_.arc
  14. | | | |-- o1_mf_1_7_0vbktl5f_.arc
  15. | | | |-- o1_mf_1_8_0vbo97xp_.arc
  16. | | | `-- o1_mf_1_9_0vbrrlo6_.arc
  17. | | `-- 2004_12_08
  18. | | |-- o1_mf_1_16_0vcnyqvf_.arc
  19. | | |-- o1_mf_1_17_0vcp58bj_.arc
  20. | | |-- o1_mf_1_18_0vcv4qxb_.arc
  21. | | |-- o1_mf_1_19_0vczcsl0_.arc
  22. | | |-- o1_mf_1_20_0vd34svw_.arc
  23. | | |-- o1_mf_1_21_0vd7tg4h_.arc
  24. | | |-- o1_mf_1_22_0vddq7lc_.arc
  25. | | |-- o1_mf_1_23_0vdk0nbh_.arc
  26. | | |-- o1_mf_1_24_0vdojjky_.arc
  27. | | |-- o1_mf_1_25_0vdtg1rq_.arc
  28. | | |-- o1_mf_1_26_0vdz23h2_.arc
  29. | | |-- o1_mf_1_27_0vf3nlnw_.arc
  30. | | |-- o1_mf_1_28_0vf6hon5_.arc
  31. | | |-- o1_mf_1_29_0vf867lt_.arc
  32. | | |-- o1_mf_1_30_0vf86pkg_.arc
  33. | | `-- o1_mf_1_31_0vfjphqm_.arc
  34. | `-- backupset
  35. | |-- 2004_12_07
  36. | | |-- o1_mf_ncsn1_TAG20041207T150715_0vboq7kv_.bkp
  37. | | `-- o1_mf_nnnd1_TAG20041207T150715_0vboo3t2_.bkp
  38. | `-- 2004_12_08
  39. | |-- o1_mf_ncsnf_TAG20041208T161219_0vffxv2n_.bkp
  40. | |-- o1_mf_ncsnf_TAG20041208T165456_0vfjcvgl_.bkp
  41. | `-- o1_mf_nnndf_TAG20041208T161219_0vffv40q_.bkp
  42. `-- tracking.dbf

  44. 7 directories, 33 files

闪回恢复区中添加或删除文件等变化都将记录在数据库的 alert 日志中，Oracle 10g 也针对该新特性提供了一个新的视图， DBA_OUTSTANDING_ALERTS，通过该视图可以得到相关的信息。

DBA_OUTSTANDING_ALERTS 视图的存在体现了 Oracle 愈加人性化的一面。我们先来看一下该视图的基本结构，后面会用到。

  1. SQL> DESC dba_outstanding_alerts
  2. Name Null? Type
  3. ----------------------------------------- -------- ----------------------------
  4. SEQUENCE_ID NUMBER
  5. REASON_ID NOT NULL NUMBER
  6. OWNER VARCHAR2(30)
  7. OBJECT_NAME VARCHAR2(513)
  8. SUBOBJECT_NAME VARCHAR2(30)
  9. OBJECT_TYPE VARCHAR2(64)
  10. REASON VARCHAR2(4000)
  11. TIME_SUGGESTED TIMESTAMP(6) WITH TIME ZONE
  12. CREATION_TIME TIMESTAMP(6) WITH TIME ZONE
  13. SUGGESTED_ACTION VARCHAR2(4000)
  14. ADVISOR_NAME VARCHAR2(30)
  15. METRIC_VALUE NUMBER
  16. MESSAGE_TYPE VARCHAR2(12)
  17. MESSAGE_GROUP VARCHAR2(64)
  18. MESSAGE_LEVEL NUMBER
  19. HOSTING_CLIENT_ID VARCHAR2(64)
  20. MODULE_ID VARCHAR2(64)
  21. PROCESS_ID VARCHAR2(128)
  22. HOST_ID VARCHAR2(256)
  23. HOST_NW_ADDR VARCHAR2(256)
  24. INSTANCE_NAME VARCHAR2(16)
  25. INSTANCE_NUMBER NUMBER
  26. USER_ID VARCHAR2(30)
  27. EXECUTION_CONTEXT_ID VARCHAR2(60)
  28. ERROR_INSTANCE_ID VARCHAR2(142)

  30. SQL>

10g 的新视图 V$RECOVERY_FILE_DEST 包含闪回恢复区的相关信息：

  1. SQL> desc V$RECOVERY_FILE_DEST
  2. Name Null? Type
  3. ----------------------------------------- -------- ----------------------------
  4. NAME VARCHAR2(513)
  5. SPACE_LIMIT NUMBER
  6. SPACE_USED NUMBER
  7. SPACE_RECLAIMABLE NUMBER
  8. NUMBER_OF_FILES NUMBER

  10. SQL> SELECT NAME, space_limit, space_used, space_reclaimable space_rec,
  11. 2 number_of_files file_num
  12. 3 FROM v$recovery_file_dest;

  14. NAME SPACE_LIMIT SPACE_USED SPACE_REC FILE_NUM
  15. ----------------------------------- ----------- ---------- ---------- ----------
  16. /u01/app/oracle/flash_recovery_area 2147483648 1106849280 602410496 30

  18. SQL>

在一些 10g 的动态视图里( V$CONTROLFILE, V$LOGFILE, V$ARCHIVED_LOG, V$DATAFILE_COPY 等 )的新的列 IS_RECOVERY_DEST_FILE ,指明相关的文件是否在恢复区内。

  1. SQL> SELECT recid, blocks, is_recovery_dest_file
  2. 2 FROM v$archived_log
  3. 3 WHERE recid < 5;

  5. RECID BLOCKS IS_RECOVERY_DEST_FILE
  6. ---------- ---------- ----------------------------------------
  7. 1 20072 YES
  8. 2 19566 YES
  9. 3 19566 YES
  10. 4 19566 YES

  12. SQL>
闪回恢复区中文件的保持策略
  • 持久文件从不会被删除。
  • 通过RMAN 配置策略过期的文件会被删除。
  • 已经拷贝到磁带上的临时性文件会被删除。
  • 在 Data Guard 环境中，当已归档的重作日志文件可以从闪回恢复区中删除的时候，可以应用归档的重作日志删除策略进行自动删除(在恢复管理器中CONFIGURE ARCHIVELOG DELETION POLICY TO ......)

在闪回恢复区中的空间使用超过 85% 的时候，数据库将会向 alert 文件中写入告警信息。而当超过 97% 的时候将会写入严重告警信息。当闪回恢复区空间不够的时候，Oracle将报告如下类似的错误：

  1. ORA-19809: limit exceeded for recovery files
  2. ORA-19804: cannot reclaim 52428800 bytes disk space from 1258291200 limit

这个时候查询 dba_outstanding_alerts：

  1. SQL> select reason,object_type,suggested_action from dba_outstanding_alerts;

  3. REASON OBJECT_TYPE SUGGESTED_ACTION
  4. ------------------------------ -------------------- ----------------------------------------
  5. db_recovery_file_dest_size of RECOVERY AREA Add disk space and increase db_recovery_
  6. 1258291200 bytes is 88.20% use file_dest_size, backup files to tertiary
  7. d and has 148509184 remaining device, delete files from recovery area
  8. bytes available. using RMAN, consider changing RMAN rete
  9. ntion policy or consider changing RMAN a
  10. rchivelog deletion policy.

  12. 1 rows selected.

  14. SQL>

会给出相关的原因和建议的操作。

注意事项

自动化的东西总是给人不确定性。如果您在测试环境中启用了闪回恢复区，那么一定要注意监控空间的使用。在生产数据库上使用(如果有这样的人的话)，必须要把闪回恢复区放到单独的磁盘上。

结束语

本文介绍了闪回恢复区 -- Oracle 10g 的又一个华而不实的新功能 -- 的基本功能。在后续的文档中我会结合RMAN的新特性展示闪回恢复区的其他方面。

参考信息

Oracle Database Backup and Recovery Basics 10g Release 1 (10.1)
Part Number B10735-01
在 可以得到最新的 Oracle 参考文档。

本文作者 Fenng，某美资公司DBA，业余时间混迹于各数据库相关的技术论坛且乐此不疲。 目前关注如何利用ORACLE数据库有效地构建企业应用。对Oracle tuning、troubleshooting有一点研究。
个人技术站点: 。 可以通过电子邮件 dbanotes@gmail.com 联系到他。 原文出处
阅读(958) | 评论(0) | 转发(0) |
0

上一篇：JBOSS4 数据源配置大全

下一篇：Linux内核参数-proc

给主人留下些什么吧！~~
关于我们 | 关于IT168 | 联系方式 | 广告合作 | 法律声明 | 免费注册

Copyright 2001-2010 ChinaUnix.net All Rights Reserved 北京皓辰网域网络信息技术有限公司. 版权所有

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6