来看看美国最大电信公司AT&T的Oracle数据库备份策略

​ 
AT&T公司是美国最大的固网电话服务供应商及第一大的行动电话服务供应商,此外还提供宽频及收费电视服务。合共1.5亿户提供服务,当中8,510万户为无线用户(dbdao.com 数据岛)。
AT&T是Oracle数据库的重度用户,从oracle的官方网站上可以了解到  AT&T 采用的产品不仅仅是Oracle Database ,还有Oracle EBS 、Peoplesoft和Siebel等等。 http://www.oracle.com/us/products/applications/att-170685.html
 ​
作为Oracle数据库的重度用户,且数据是十分重要的巨无霸级电信运营商而言数据库备份策略十分重要。
 ​
由于AT&T的维护人员运维着成百上千套Oracle数据库,    他们把数据库按照不同的可用性要求划分为三个可用性/恢复级别,分别为低、中、高。低是应用程序可以承受的在任何类型的介质失败后需要最长的平均恢复时间,高是应用程序有很少的停机时间或不允许停机。
下列是对上述三个级别的数据库备份的保存策略。推荐的保存周期取决于硬件的限制和用户描述的平均恢复时间。说明一些磁盘备份和恢复文件可能存储在FRA外面。FRA以外的磁盘存储空间应该通过OS 和RMAN命令手动管理
 ​

以下是AT&T的最优备份方法和策略

 

  • 使用闪回区作为归档日志的存放位置

 

使用闪回区作为归档位置,因为归档日志被数据库自动管理,因此归档空间不足的风险大大降低,要发挥闪回区(FRA)的最大优势,尽可能的依赖磁盘的可用性存储和管理许多不同的文件。

 

  • 多重归档日志记录

 

通过实现硬盘镜像(有归档日志区域的镜像)保存归档日志的多个副本,或者通过设置LOG_ARCHIVE_DEST_n初始化参数为一个FRA 以外的位置。

 

  • 在磁盘上保存归档的redo日志

一般来说,归档日志文件保存在磁盘至少48小时或者你可以取决于存储的可用性。这将保证在介质失败后更快恢复,因为日志不能存储在慢的磁带机上,在闪回区达到83%或93%时,信息将放到告警日志。不再被恢复所需要(或者备份到磁带机上)的日志将被自动删除。记住在闪回数据库操作时归档日志如果不在磁盘上,他们必须从磁带上转储来“倒回”数据库(dbdao.com 数据岛)。

  • 备份控制文件

在每一次关键备份时,获得数据库控制文件的二进制和文本类型的副本。这对数据库结构改变后尤其重要。

 

为了RMAN 在每次备份和数据库结构改变后可以自动备份控制文件和服务器参数文件,需要开启自动备份 AUTOBACKUP ON (默认为OFF)。自动备份特点使得RMAN 转储自动备份的控制文件,在你不能访问数据库,甚至控制文件丢失/破坏后恢复数据库。

  • 备份参数文件和密码文件

RMAN 工具不支持ORACLE_HOME, init.ora 和密码文件备份。然而,所有的这些文件必须使用系统命令备份或者第三方备份工具。如果你的实例使用spfile代替init.ora 文件,你可以用RMAN 自动备份spfile 或者使用BACKUP SPFLE 命令。

  • 增量备份的改变跟踪文件

这个特点是允许RMAN 只备份上次全备份以来改变的数据块,减少了执行备份所需的时间,只备份很少的数据块,

size of change tracking file = # of redo threads * (# of old backups + 2) * (size of db/250000)

  • 备份归档日志时不要指定DELETE ALL INPUT

DELETE ALL INPUT 会在目标备份然后删除归档日志和其副本,“delete  input”会在目标备份后删除已经备份的归档。下一次将从位置1备份来作为位置2的新日志备份,然后删除备份过的日志。这意味着你可以有自从上次磁盘上位置2 的可用备份(只要备份过一次)和上次备份之前的两个备份副本。查看说明443814.1-用RMAN管理多个归档日志目录的详细内容。

  • RAC 环境下备份所有的CRS资源

RAC 数据库需要OCR 的备份和Voting 磁盘文件。RMAN 不支持这个,因此使用系统命令定期执行备份。

阅读 Metalink 说明: 279793.1 How to Restore a Lost Voting Disk in 10g and Note: 268937.1 Repairing or Restoring an Inconsistent OCR in RAC regarding backup and restore a lost Voting/OCR.

  • 考虑使用增量更新备份

增量更新备份使用合并数据库镜像复制和增量备份,来提供快速且有效的数据库恢复。使用RMAN具有数据高可用性需求的特点,保证少的平均恢复时间并且能消除全库备份的需要。

  • 设置RMAN 恢复目录

使用恢复目录数据库作为备份和转储操作的仓库。恢复目录提供了与RMAN数据保存在每个目标数据库的控制文件中的以下几种另外的功能:

  • 在恢复目录里存储RMAN脚本
  • 一个节点的备份能转储到另一个节点
  • 没有控制文件的空间限制并且能储存更多关于备份的历史数据
  • 在恢复和维护操作期间提高性能
  • 备份物理备库需要恢复目录

 

备份过程

计划实现三个独立标准备份程序,这将适用于上述相应的可用性和恢复要求。

 

MTTR的数据库备份过程

 

对于有高可用需求和低容忍恢复时停机的的数据库,保证在磁盘上的0级增量备份并且每天用1级增量备份增量更新这个副本,然后把所有其他的文件转移到DSU/磁带(dbdao.com 数据岛)。

FRA DISK QUOTA =  Size of 1 full copy of database
+ size of 1 day’s level 1 incremental backup
+ size of (Y+1) days of archived logs
+ size of flshback logs

Y是脚本里 BACKUP RECOVERY AREA执行的时间。

FRA 设置以下步骤用来执行备份

  • 备份控制文件
    • 文本复制用RMAN 命令 BACKUP CURRENT CONTROLFILE;
    • SQL: ‘alter database backup control file to trace’;
    • SET CONTROL FILE AUTOBACKUP ON.
  • 每天执行1级增量备份和用前一天的1级备份前滚0级备份
  • 把所有的闪回区文件备份到DSU/磁带上,这将备份所有不存在于磁带上的备份集,以及自上次备份以来所有已归档的重做日志。。
  • 删除DSU/磁带上过期的备份。
  • 如果是RAC 环境,通过OS 命令从CRS复制OCR和卷文件

 

中等MTTR的数据库备份过程

每周执行一次完全压缩的0级增量备份到FRA以外的磁盘,并且每天执行1级压缩增量备份到FRA。每天把闪回区备份到DSU/磁带,因此保证备份集和归档日志可以被删除,以满足更新需求的空间。

FRA DISK QUOTA =   size of X day’s level 1 incremental backup
+ size of (Y+1) days of archived redologs
+ size of  flashback logs x 2

X是你想要 保存在FRA中的增量备份的数量,Y是在备份脚本中执性BACKUP RECOVERY AREA所用的天数。

如果FRA和外部的磁盘存储区被配置, 用下列步骤完成备份

  • 一周一次
    • 备份控制文件
    • 备份上周的0级压缩备份到磁带并且用OS命令从磁盘中删除
    • 执行检查并从磁盘删除过期的0级备份
    • 每周执行0级增量备份到FRA以外的磁盘
    • 从磁带删除过期的备份
    • 备份闪回区
  • 每天执行1级增量备份到FRA
    • 备份所有的闪回区文件到DSU/磁带。这将备份所有磁带上没有的备份集以及上一次任何类型的备份以来所有的归档日志
    • 执行1级增量备份到FRA
  • 如果是RAC环境,通过OS命令从CRS 复制OCR和卷文件

 

MTTR的数据库存储过程

 

对于能承受足够的时间来恢复和磁盘存储限制,使用FRA仅仅作为归档的目的地。磁盘配额规则将自动从FRA删除不再被恢复所需要的日志。

FRA DISK QUOTA =   size of 1 day’s level 1 incremental backup
+ size of (1 days of archived logs) * 2
+ size of  flashback logs x 2

按下列步骤设置FRA,用来执行备份

  • 归档日志文件在FRA里
  • 每周执行0级全增量备份到磁带作为压缩备份集。
    • 备份控制文件
    • 执行0级备份到磁带
    • 删除磁带上的过期备份
    • 备份恢复文件目的地到磁带
  • 一周内的其他天
    • 备份恢复文件目录到磁带
    • 执行1级增量备份到FRA

关注刘相兵的新浪微博

扫码加入微信Oracle小密圈,了解Oracle最新技术下载分享资源

Speak Your Mind

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569