Oracle数据库备份恢复十大问题和解决之道（二）.pdf

dbtiger

All China Database Union

104

12页

5次

2024-03-19

5墨值下载

Oracle数据库备份恢复十大问题和解决之道

（二）

本文继续RMAN十大问题中后面六个问题的描述，然后进行总结并从服务角度进行展望。

1. RMAN十大问题之五：没有在表空间、数据文件级进行备份和恢复

 问题描述

我发现国内Oracle数据库RMAN实施另一个普遍性问题就是备份恢复策略基本都是基于数据

库级别的，例如全库备份和增量备份都是基于数据库级别，而且数据库恢复也基本是数据库级别

的全库恢复，我几乎没有见过在表空间、数据文件级进行备份和恢复的实施案例。我想主要原因

还是在于数据库设计者在表空间设计方面的粗放风格而导致，即国内大部分数据库的表空间都

只有几个，甚至几十TB的数据库都只有几个表空间，乃至我见过某四大行还把表空间简约化设计

原则写入了该行的设计开发规范。

于是，在这种粗线条表空间设计之下，一个表空间可能就存储了整个数据库的80%数据，表

空间级备份与数据库级备份没有本质区别，因此表空间级别的备份就没有什么意义了。在恢复方

面也是如此，反正一个存储故障导致某个数据文件出问题，其所在的表空间可能就占了80%的数

据，还不如直接进行全库恢复呢，但是耗费的资源和时间呢？是否能满足最终的恢复需求呢？

 问题结果

这种数据库级备份和恢复策略带来什么问题呢？首先，在备份方面就是RMAN每次都无谓地

备份了绝大多数没有发生变化的历史数据，不仅备份时间冗长，而且浪费了宝贵的系统资源尤其

是存储和磁带库资源。尽管有增量备份甚至快速增量备份技术（FIB）的运用，RMAN可以跳过大

部分没有变更的数据，但是RMAN还是要在数据库级别对增量数据进行分析，还是有一定的资源消

耗。相比之下，假设我们将表空间按年份进行设计和存储业务数据，当年之前的表空间就完全可

以不备份了，备份操作本身就大大节流了，备份性能的提升和资源消耗的下降显而易见。其次在

恢复方面，一旦出现存储故障，我们通过精确定位到故障涉及的某个或某几个表空间，于是我们

就可以只将这些故障表空间设置为Offline状态，并进行restore和recover操作，不仅恢复操作

读取的数据更少，恢复时间更快，而且其它表空间上的业务可继续进行，也就是恢复效率和业务

连续性都更好。

 解决之道

此类问题解决之道的根本在于项目前期的表空间设计原则的设定，国内大部分系统只有几

个表空间的粗放式设计风格显然不可取，表空间设计应该充分体现数据可管理性、高可用性、高

性能等多方目标的诉求，也需要设计者非常熟谙Oracle表空间级的多种管理操作，例如本文提及

的基于表空间实施RMAN，还有只读表空间、表空间传输、基于表空间的数据加密、基于表空间的

数据压缩、基于表空间的ADO历史数据管理、基于表空间实施IMO等各种新老技术。然后结合业务

需求，再在时间、业务分类等维度展开表空间的精细化设计。

回到RMAN实施主题，表空间级RMAN备份可以直接通过backup tablespace进行，也可以通过

exclude命令选项将某些表空间排除或包括在数据库级的备份操作之中，例如以下就是我当年为

国税系统编写的只备份2006年业务数据的备份脚本：

RMAN> CONFIGURE EXCLUDE FOR TABLESPACE CTAIS2_DAT_2002 ;

RMAN> CONFIGURE EXCLUDE FOR TABLESPACE CTAIS2_DAT_2003 ;

RMAN> CONFIGURE EXCLUDE FOR TABLESPACE CTAIS2_DAT_2004 ;

RMAN> CONFIGURE EXCLUDE FOR TABLESPACE CTAIS2_DAT_2005 ;

RMAN> CONFIGURE EXCLUDE FOR TABLESPACE CTAIS2_DAT_2006 clear;

RMAN> backup incremental level 0 database format='/ctais/ctaisbak/FULL_%d_%t_%U'

plus archivelog delete all input tag= Level0_Backup;

上述语句的思路有点绕，即2002年至2005年表空间通过EXCLUDE选项排除在外，而2006年数

据则通过exclude … clear的否定之否定命令，将包含在后面的全库备份操作之中。

 真实案例的深入探讨

上文讲述的那个每个数据文件为50M、2TB数据库的数据文件多达1万多个，最终导致60小时

备份时间的案例，我其实还不了解这个系统的表空间设计情况，是若干个大表空间包含了几十、

几百个50M大小的数据文件，还是每个表空间只包括一个50M数据文件，从而也导致1万多个表空

间？我很想一探究竟，但是我想该客户的备份恢复处可能不仅回答不了这个问题，而且他们也可

能没有兴趣去了解，因为他们只是在数据库级进行备份和恢复，全然没有考虑在表空间级进行备

份恢复所带来的显著收益。我认为这也是众多客户尤其是国企客户的一个更深层次问题：即过于

考虑分工负责，缺乏跨部门的IT系统总体规划和更精细化的实施策略。这就是国内IT系统可提升

和精雕细琢的巨大空间，最终也一定能给各行各业的IT系统带来显著的降本增效。

表空间精细化设计与其说是追求诸如RMAN备份、数据压缩、数据加密等数据管理工作的更加

精细化和高效能，不如说是更体现出IT从业人员做事风格的更加缜密、更加专业、更加职业化。

2. RMAN十大问题之六：没有实施全面的备份数据管理功能

 问题描述

就像我们在将自己笔记本电脑的文件数据备份到活动硬盘或某个云存储服务器时，需要考

虑备份数据的份数或保存期限一样，RMAN也提供了强大的备份数据管理功能，例如RMAN提供了两

种保存策略：基于冗余份数和基于恢复时间窗口，然后基于备份数据保存策略，RMAN自动分析哪

些备份集和复制数据是废弃的（obsolete）备份数据。另外通过交叉检查（crosscheck命令），

RMAN可将被删除的备份数据标记为失效的（expired）备份数据。这样，基于这些技术和功能编

写自动化运行脚本，RMAN可自动进行备份数据管理工作，既大大简化DBA们的工作量，也充分节

约了磁带库等硬件资源。

可是，我却很少见到客户在编写自动化管理备份数据的脚本。难道都是手工在管理备份数

据，例如手工删除老的备份数据，或者直接在磁带库管理软件中进行备份数据的管理吗？甚至压

根儿就不定义备份数据的冗余份数或保存时间周期，无限期地保存备份数据吗？那需要磁带库

等多少硬件资源？也是不是每年都不断追加磁带库等硬件资源的投入？

 解决之道

RMAN的备份数据管理操作命令其实非常简单，这就是20多年前我为某银行实施RMAN备份数

据管理的相关命令：

首先，如下命令定义了备份数据冗余份数为2份。

CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

由于该系统每周进行一次全库备份，因此这种备份数据冗余策略能保证该系统恢复到最近

两周的任意时间点。

其次，在备份脚本之后，进行如下的备份数据管理操作：

backup incremental level 0 database format='/backup/FULL_%d_%t_%U' plus archivelog

delete all input tag=Weekly_Full_Backup;

crosscheck backup;

delete noprompt expired backup;

report obsolete;

delete noprompt obsolete;

即在备份操作之后，先根据备份数据冗余策略进行交叉检查（crosscheck backup）操作，

然后再删除失效的（expired）和废弃的（obsolete）备份数据。

 真实案例总结的最佳实践经验

就在20年前该银行的RMAN投产几年之后，我再次去现场巡检时，发现crosscheck操作时间长

达1小时20分钟，原因是系统中有大量被删除的备份数据，而crosscheck操作会把被删除的备份

数据标识为expired，因此crosscheck操作时间变长了。但是谁在删除备份数据呢？我最初编写

的RMAN脚本里面只有delete noprompt obsolete命令，即超出RMAN保存期限的备份数据才被删

除掉。因此，理论上不会产生大量expired备份数据的。

后来我和客户一起打开磁带库管理软件NBU的相关配置和脚本才发现，NBU对备份数据的保

存期限设置为3天，而我在RMAN中设置冗余份数为2份，由于每周进行一次全备，因此保存期限实

际上为14天。这样，NBU将3天以上备份数据删除之后，crosscheck操作将被删除的备份数据标识

of 12

5墨值下载

oracle dba

相关文档

评论