Oracle备份与恢复方案设计及运维：23个典型问题解答及经验分享

电玩女神 2022-06-16 06:27 164阅读 0赞

为了最大限度保障数据的安全性，同时能在不可预计灾难的情况下保证数据的快速恢复，需要根据数据的类型和重要程度制定相应的备份和恢复方案。在这个过程中，DBA的职责就是要保证数据库（其它数据由其它岗位负责）的高可用和高性能，比如：如何避免数据库发生常规错误、如何增加MTBF、如何降低MTTR、使用使用哪些冗余技术保护关键组件以及如何做到最小化数据丢失。

在社区最近的在线交流中集中讨论了Oracle数据库备份恢复相关的问题，同时也拓展到了其它方面，比如性能问题、案例分析、RAC相关的备份问题及生产环境中的经验分享。非常感谢爱好者的参与，特别是ttkanni、fengshuai等会员的积极参与，由主要分享者royalwzy对所涉及的问题进行了整理和归类，提供给大家参考，包括如下几个部分：

一、数据库备份恢复基本问题

二、数据库备份恢复性能相关问题

三、数据库备份恢复性能案例分析

四、数据库备份恢复性能优化问题

五、数据库备份恢复RAC相关问题

六、数据库备份恢复经验分享

##     ##

## 一、数据库备份恢复基本问题 ##

##     ##

1、问：Oracle11g数据库数据量有50T，每天增量50g左右，该如何制定备份方案，如何验证备份的有效性？

答：

50T的数据也不大，运营商的地市级市数据基本都在100T以上了，只要备份环境允许的话，也能在12h内备份完成。

以一次全备份来算，在12h内备份完成，那么平均备份速度最低是

5010241024/12/3600=1210MB/S

按照LTO 5 drive的速度（140MB/S）来算，备份最低的drive数量：1210/140=9

为了保障dive尽量保持最大IO，建议额外关注几点：

1，datafile较小的话，聚合成较大的bakcup piece

2，调整read/write blocksize减少读写次数，可酌情调整至MB大小

3，调整备份脚本，一个channel对应一个backup session，每个channel尽量保障只有一个大块backup piece写入

4，关闭备份软件和drive的多路复用功能，保证每个dive上只有一个session写入

5，备份尽量走单独的HBA卡，不要和业务或存储共用

备份策略的话，一个完整的备份周期肯定是FULL+INCR+INCR比较符合实际情况，如果条件允许Synthetic Full也是一个很不错的选择。归档看需求，4h或者6h备份频率都可以。

相关案例：

某地市数据库，大概数据量90T，备份从4块独立的16 GB HBA走，每块HBA绑2个LTO 5物理drive，备份起8个channel，每个channel对应一个bakcup piece，每个bakcup piece都聚合为500 GB，R/W blocksize为2MB，多路复用关闭。

2、问：Oracle的数据库备份，一般采用数据泵将库和数据备份，这样安全吗？一般是各一个周备份一次。

答：

安全这个词在这里的定义比较模糊。

1.expdp/impdp是逻辑备份，备份的过程中也可以使用加密从而保证数据的安全。

2.也正是因为这种方式是逻辑备份，不论你才用多久的时间间隔来备份，两次备份过程中有数据丢失都无法通过这种方式恢复到数据丢失的那一刻。  
想要保证数据可以恢复到任意时刻建议使用rman；如果每隔一段时间想要保存一下数据某时间点的快照的话，使用数据泵和rman都行。

3、问：如何设计oracle数据库的备份与恢复的时间窗口？都需要做都那些方面的考虑？系统环境越来越复杂，需要备份的数据库也越来越多。在做数据库的备份与恢复设计时，应如何设计oracle数据库的备份与恢复的时间窗口？都需要做都那些方面的考虑？

答：

先说备份，需要着重考虑几点：

1，备份方式：根据实际数据保护需要，确定备份方式，一般都是FULL+INCR。条件允许就全FULL。其次就是备份频率，一个FULL后追加多少个INCR，归档多久备份一次。

2，备份时间窗口：备份的过程中对生产业务（数据库）压力是很大的，所以首先应该规划备份的时间窗口，一般都在晚上。

3，备份流量路径：确定了备份时间窗口，就想想备份的流量怎么走。LAN-FREE备份好说，LAN备份就要特别留意了，备份前先拉着网络的哥们交流下感情，最终确定好流量路径，不要影响其他业务。

4，数据保留、克隆：对于重要的数据，不仅需要备份，最好克隆一份。出入库看实际需求了。

恢复一般在单独的恢复环境，所以没什么需要特别注意的。

4、问：RMAN备份和数据泵备份的比较，适用范围？

答：

RMAN是oracle推荐的数据保护工具，在备份恢复上，RMAN能够借助备份数据恢复一段时间范围内某个时间点数据库的状态。此外RMAN在备份恢复的校验上更加严格，最大程度保护数据的完整性、一致性以及适用性，同时也方便备份恢复的统一管理。

EXP/EXPDB，在oracle的定位中，只是一个数据迁移的手段。在备份恢复上，数据泵只能利用备份数据来恢复一个时间点上的数据库状态，无法借助备份数据在一段时间内自由选择恢复点。在严格的意义说，数据泵备份并不能说是一种有效的数据保障措施，这更像是一种临时的保底操作。

5、问：oracle数据库备份及恢复那种方式更简单！更快捷？exp/imp 还是rman或是其他方式？

答：

应该按照系统的RTO的要求上来看，逻辑导出和RMAN配合使用，exp的方式因为要放到本地或者放到本地之后上传到服务器，这种比较占用磁盘空间，但是在一些跨平台恢复上exp又是可以的。rman主要还是防止逻辑错误，搭配备份软件，进行数据的集中管理较多。

集中化备份管理来说，rman是最有效也是最可靠的方式。exp、expdb虽然操作简单，对于数据的持续性保护太弱了~

6、问：ORACLE数据库该如何设定防范逻辑错误的备份策略和备份方案？

答：

逻辑错误有很多中解决办法，使用备份恢复是最有效的一种，但是大多时候并不是最优的一种方法。

如果要使用备份等话，那就建议保留所有的归档日志，除了备份恢复，还可以使用Oracle数据库的闪回功能，比如：闪回查询，闪回表，闪回事务和闪回数据库等操作。

7、问：很多时候Oracle备份或恢复都是由oracle结合第三方备份软件完成，在备份恢复的过程当中时不时的会遇到备份恢复的速度比预想的要差很多，各位有哪些经验？如何定位是oracle设置的问题还是备份软件的方面的原因？

答：

性能排查无外乎源、路径、目标这三点，第三方备份软件可以看做在“路径”上的管理员，调度数据从源到目标。

源端问题，存储问题就从存储读直接写到null看读速度，写就直接生产随机数据写存储。

路径问题，从源内存直接生产随机大数据写备份介质（drive一般不会有性能瓶颈）或者直接做rman的validate验证恢复

目标端问题，drive一般只需检查物理状态。AFTD文件类型设备检查其存储性能问题，方法如上。

8、问：针对不同业务系统采用的数据库备份策略是怎么样的？定期恢复验证的周期为多久？

答：

备份方式无外乎FULL INCR Synthetic Full

备份环境极好，只用FULL备份，恢复速度最快。

备份环境稍好，FULL +INCR +Synthetic Full，恢复速度适中。

备份环境有限，FULL +INCR +INCR，恢复速度一般。

对于FULL+INCR（Synthetic Full）这种方式，INCR次数不建议太多（INCR较大的数据库建议INCR次数不超过3），否则恢复速度会大打折扣。

现在厂商还宣传一种特殊的备份方式：Virtual synthetic full backup

这种备份方式，利用传统的FULL+INCR进行，Virtual synthetic full backup时在备份介质上将FULL +INCR整合成一个相当于实际的FULL对外提供恢复服务。

恢复验证周期，一般一个季度内至少挑选各类型备份恢复一次。

恢复环境好，恢复验证频率可以为一个月一次，每次都真实恢复。

恢复环境稍好，适当降低恢复验证频率，挑选重要系统备份真实恢复，其余做oracle validate恢复或者scan tape。

恢复环境一般，在连续的多个备份周期内至少能对一个完整周期的备份进行oracle validate恢复或者scan tape。

9、问：最近veritas的来做技术交流，据他说NBU的备份一体机在生产库出问题的情况下，可以通过rename一系列操作将库从备份一体机中拉起来直接用。有用过的吗？

答：

在其他厂商的产品里有VM\_RECOVERY可以实现这样一种恢复。直接从备份介质读备份数据，在前端虚拟出一台虚拟机。

但在数据库上，我记得还是要恢复的，厂商吹嘘的直接拉起库？只要你用RMAN rename就是有恢复，因为备份数据从备份软件还原到RMAN识别、rename就是恢复的过程。

10、问：一个数据库实例下面有十几个用户，如何实现分用户备份各自的数据，不用一个一个exp?各用户如何实现并发备份？

答：

Oracle Rman无法实现分用户备份，但可以折中处理：备份用户对应的所有表空间数据。

Oracle Rman是通过channel和复用来实现并发备份的，具体语法参考RMAN手册。

11、问：在三地两中心的双活结构中，oracle的数据库双活如何进行安装部署，在这种情况下还需要有数据库备份的必要性呢？ODG和ADG在这种数据库备份环境中该如何操作呢？

答：

数据库双活了更需要数据库备份，否则数据库逻辑错误，一损俱损，都没得恢复了。。ORACLE备份不就是RMAN或者数据泵，备到存储或磁带，保持一份最新的数据，防治数据库逻辑错误。

多活只能保障单边故障下业务还可以online（高可用），但对于数据逻辑错、历史数据审查、历史数据分析等问题，多中心多活的结构框架依旧无法克服。

的确，从另外一方面，数据库双活了，应用同样需要双活。切换时还需要考虑是直接切换到异地的机房，还是在原机房进行恢复。

12、问：Oracle 备份保留参数主要是两个：一个是保留的天数，另一个是保留的副本数。那么这两种情况具体有什么区别，在什么场景下使用什么样的参数设置呢？

答：

前者主要考虑的方面是：想要把数据库恢复到历史的哪一个时间点；后者主要考虑的方面是：要针对备份如何做冗余

Configure retention policy to recovery window of N days;

表示备份保留N天，即表示oracle可以保证还原到N天内的任意时间点。

CONFIGURE RETENTION POLICY TO REDUNDANCY n

表示备份保留N份。

区别就是基于恢复窗口的保留策略纬度不同，看你的具体需求 磁盘窨 备份策略 来选择不同的参数设置

13、问：oracle数据库的exp备份方式是否能否恢复存储过程和触发器？是否支持跨版本？RMAN方式呢？

答：

exp和expdp都能满足你的需求 rman更能满足。不过注意千万不要在平时用exp来做容灾备份 用rman来做 exp的定位还是数据迁移工具。

14、问：大家的Oracle备份环境中，是否建设有Catalog数据库用于存放备份记录啊？还是直接使用的控制文件？

在备份和恢复中，Catalog的主要优势在哪？哪些是必要因素说明必须要建设Catalog数据库？

答：

1.rman的备份信息默认是存放在目标数据库的控制文件中的,存放时间由control\_file\_record\_keep\_time参数控制,默认是7天;同时,也可以把rman的备份信息保存到一个独立的数据库中,叫做recovery catalog;

2.使用recovery catalog可以保存更长时间的备份信息,当目标数据库的控制文件丢失时非常有用;

3.recovery catalog可以保存多个目标数据库的备份信息,可以保存RMAN stored scripts(类似于存储过程,就是一系列rman脚本);另外如果想要试用永久保留备份的话,必须使用catalog;

4.如果只是简单的备份管理需求的话,建议使用控制文件即可,因为如果使用recovery catalog的话,意味着还要对其它的数据库做备份管理,Licence费用;所以,只有在使用recovery catalog带来的好处比较大时才使用。

## 二、数据库备份恢复性能相关问题 ##

##     ##

15、问：Oracle 强大之处之一在于有很多表和视图用于性能分析和故障诊断，哪些表可以用于备份恢复异常时的性能诊断，有无经验分享？

答：

select s.status as "备份状态",

b.INPUT\_TYPE as "备份类型",

to\_char(b.START\_TIME,'yyyy-mm-dd hh24:mi:ss') as 总的开始时间,

to\_char(b.end\_time, 'yyyy-mm-dd hh24:mi:ss') as 总的结束时间,

trunc(b.ELAPSED\_SECONDS/60,0) as 耗时多少分钟,

b.INPUT\_BYTES\_PER\_SEC\_DISPLAY "in\_sec/s",

b.OUTPUT\_BYTES\_PER\_SEC\_DISPLAY "out\_sec/s",

trunc((s.END\_TIME-s.START\_TIME)2460,0) "单个文件备份用时(分)",

to\_char(s.START\_TIME, 'yyyy-mm-dd hh24:mi:ss') as "开始备份时间",

to\_char(s.END\_TIME, 'yyyy-mm-dd hh24:mi:ss') as "结束备份时间",

s.OPERATION as "命令",

trunc(s.INPUT\_BYTES/1024/1024,2) as "INPUT-M",

trunc(s.OUTPUT\_BYTES/1024/1024,2) as "OUTPUT-M",

s.OBJECT\_TYPE as "对象类型",

s.MBYTES\_PROCESSED as "百分比",

s.OUTPUT\_DEVICE\_TYPE as "设备类型"

from v$rman\_status s,v$rman\_backup\_job\_details b

where to\_char(s.START\_TIME, 'yyyy-mm-dd hh24:mi:ss') < to\_char(sysdate,'yyyy-mm-dd hh24:mi:ss')

and to\_char(s.END\_TIME, 'yyyy-mm-dd hh24:mi:ss') > to\_char(sysdate-7,'yyyy-mm-dd hh24:mi:ss')

and s.COMMAND\_ID=b.COMMAND\_ID

order by s.START\_TIME desc ;

select s.status as 备份状态,

trunc((s.END\_TIME-s.START\_TIME)2460,0) "备份用时(分钟)",

to\_char(s.START\_TIME, 'yyyy-mm-dd hh24:mi:ss') as 开始备份时间,

to\_char(s.END\_TIME, 'yyyy-mm-dd hh24:mi:ss') as 结束备份时间,

s.OPERATION as 命令,

trunc(s.INPUT\_BYTES/1024/1024,2) as "INPUT/M",

trunc(s.OUTPUT\_BYTES/1024/1024,2) as "OUTPUT/M",

s.OBJECT\_TYPE as "对象类型",

s.MBYTES\_PROCESSED as 百分比,

s.OUTPUT\_DEVICE\_TYPE as "设备类型"

from v$rman\_status s

where to\_char(s.START\_TIME, 'yyyy-mm-dd hh24:mi:ss') < to\_char(sysdate,'yyyy-mm-dd hh24:mi:ss')

and to\_char(s.END\_TIME, 'yyyy-mm-dd hh24:mi:ss') > to\_char(sysdate-7,'yyyy-mm-dd hh24:mi:ss')

order by s.START\_TIME desc ;

16、问：请问各位在生产环境中遇到哪些备份恢复的问题？

答：

源库和恢复的目标库 数据库编码格式不一样，导致一直提示找不到bakcup piece。

备份时遇到坏块

备份时文件被误删除

17、问：数据库从9版本迁移到12c 数据表结构都变了，怎么迁移数据呢？

答：

可以使用kettel等etl工具来帮忙，当然你也可以先升10再升11再升12 一步一步的升上去；同是oracle数据导出再导入也简单。

##     ##

## 三、数据库备份恢复性能案例分析 ##

##     ##

18、问：oracle用rman做recover和用sqlplus做recover有什么区别？

我曾经遇到过这样一个问题，生产的存储卡坏了（生产是2个节点的ＲＡＣ），需要在另一台服务器恢复数据库（非ＲＡＣ），幸好我把归档日志保存了一份在本地磁盘。在还原旱，用 rman 做 restore 正常完成，但在做 recover 的时候，报错了（具体的错误号我忘了，但大概意思是找不到所需要的归档日志，但在新的服务器上的归档路径下有这归档日志文件），整了半天，就是不得行，后来，我用　sqlplus recover 成功了，命令如下：  
sql> recover database using backup controlfile until cancel;

为什么为这样，我至今没有搞明白，请高手们分析一下。

答：

如果你的oracle rman恢复是没有catalog，且在rman中的恢复仅仅是“recover database”的话，会出现你说的这个问题。

要想明白问题的原因，还得从这两句恢复命令出发：

recover database using backup controlfile until cancel;

在单一的recover database 或者 recover tablespace, recover datafile时，Oracle会以当前controlfile所记录的SCN为准，利用archive log和 redo log的redo entry, 把相关的datafile 的 block恢复到“当前controlfile所纪录的SCN”  
而当前controlfile和current/active redo都丢失的情况下，你就需要使用你在SQLPLUS里输入的那句恢复命令，在很多情况下，由于datafile数据的不一致性，Oracle需要把数据恢复到比当前controlfile所纪录的SCN还要靠后的位置，简单的说，就是需要更多的归档。

如果你还能复现这个恢复场景，你查询下你报错的所需的归档，利用原来的controlfile进rman里list backup看一下就能知道了。

##     ##

## 四、数据库备份恢复性能优化问题 ##

##     ##

19、问：随着数据库体量的增大，有时每天全备已经不能满足需要了，考虑使用增量备份。各位专家有没有遇到过实施增量备份过程中的问题呢？还有就是对于OLTP系统，每天大量数据块是被更新了的，这样的话block change tracking即使打开了，也很难提高备份速度（因为大部分块都被修改过，仍然需要备份），这类问题同行朋友有没有比较好的建议？

答：

首先确认一下数据库大小有多大，使用的lan备份还是光纤，使用的几个通道，平均一个通道io有多大？如果使用的lan 是否网卡已经饱和等等？  
如果你的状况是每天变化的数据能影响到几乎所有的数据块的话，那么考虑使用backup as copy。

## 五、数据库备份恢复RAC相关问题 ##

##     ##

20、问：Oracle 10gr2 RAC因为需要更换存储，数据库迁移有什么特别的方案吗？系统Oracle Linux 5.7，DB：10.2.0.5。

答：

具体看停机窗口时间跟数据量，可以采用集中方式：1）导入导出；2）备份恢复；3）使用新的存储做一个DG的备机，然后切换过去。

21、问：现有数据库为oracle rac，想搭建一套完全实时互备的数据库，能做DataGuard吗？如果可以那么scanip 和VIP、sid和原库能保持一致吗？如不行那么有什么能实现以上功能？

答：

完全可以在现有环境下搭建adg。

scanip，VIP，sid都不能一致，但是数据库唯一名必须一致，这是adg的配置条件。

22、问：一个oracle数据库的RAC环境，在日常运维管理中应重点关注那些方面的具体内容？

在对oracle数据库进行日常运维管理中，我们都应该重点关注那些方面的具体内容？

我们目前能够关注的，如：ORA-告警信息，一些表空间的的告警。这个也是主要从监控系统（如TIVOLI监控系统）中获得，除此之外，我们还应该重点关注那些具体方面的内容?

答：

除了监控，也需要关注RAC环境的性能调优，Service的管理，负载均衡等方面吧

23、问：如果Orace数据库的RAC在建设的时候，归档没有放在共享或者ASM上，只是在单边存放，那么这种的Oracle数据库备份大家一般都怎么做？两边都备份？还是mount NFS？哪种更好些？

答：

归档还是建议放在共享存储上，不太建议单边存放。一是方便管理，二是简化备份流程。

若是单边存放，只能在每个节点上单独备份各自的归档。

对于归档数据量较大的场景，不太建议NFS。如果允许，能共享尽量共享

六、数据库备份恢复经验分享

#### （一）、Oracle 备份和恢复的一点体会 ####

架构

Oracle的备份一般来说还是基于第三方备份软件来完成日常备份的，诸如NBU，TSM等

那么在设计架构方面应该多考虑一下是集中的方式来做还是分开来做，主要考虑有几点：

1.公司需要备份的节点数量和位置

2.目前公司网络情况（是否有分支机构走专线备份，备份网段和生产网段的连通性等，是否有专用备份网络）

3.是否使用catalog

4.备份设备是否分层或异地同步

5.是否有出库异地存放需求。

数据量

1.数据量小，基本上可以考虑使用lan方式配合备份窗口来完成

2.数据量大，考虑配合高速以太网和lanfree方式完成，备份方式（全备+曾备+归档备份完成）

配置

1.选用较高配置X86 服务器+linux 完成备份环境搭建

2.备份server和节点session和资源限制不要使用默认，看情况修改

3.Oracle 备份片和通道要做适当设置

4.专有备份lan或光纤卡

性能定位

1.本地io

2.网络io

3.备份软件兼容性，已经版本bug

4.备份软件trace跟踪

5.oracle备份参数设置：备份片和备份方式，是否压缩，块跟踪等

#### （二）、结合实际做备份恢复设计才能最大限度的满意要求 ####

备份恢复的方法和种类很多，为啥有的时候客户还不满意？因为你不对他路子。

举个例子，开发人员不小心删错了数据。你说有flash back呀一看undo retention不够。

那开始备份恢复吧，结果system或者user表空间巨大，哇数据全在system里面是不是原来设计好的想法都没用啦?

如果可以依照先有的数据库结构做些适当的引导那么会好很多。

且国内客户和国外客户处理的方式太不一样。特别是韩国和日本客户。针对细节问题到了无以复加的地步，那么这个时候备份和恢复设计就不能有自己解释不通的地方。

说了那么多具体谈下怎么做事吧。

最重要的一点，备份的东西可以吐出来。

那么要给自己留后路，备份的东西要异与恢复。

那么如果钱足，上硬件级别备份。例如emc timefinder，SRDF等等。条件好的可以做个备份的colne。

一定要建议购买专业的备份恢复软件，关键时刻可以用来顶包。

那么最好做物理备份，用于防止物理的损坏。

如果既要防止物理损坏又要很快的把人为的错误数据找回来就可以设置一个standby那么防止物理损坏的备份直接在原库备份，用于防止人为损坏的备份在standby节点备份，延时个一天吧。应该可以满足要求。

以上是大致的经验，我的意思是备份手段多种多样，怎么搞成最适合的场景可是个大学问。

#### （三）、Oracle 11.2.0.3版本以上的RAC数据库备份时，偶尔出现ORA-00245的报错。 ####

问题现象：ORA-00245: control file backup failed; target is likely on a local file system

解决办法：

1. Check the snapshot controlfile location:  
RMAN> show snapshot controlfile name;

2. Configure the snapshot controlfile to a shared disk:

RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/snapcf\_.f';  
Or in case of ASM use

RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+/snapcf\_.f';

Oracle备份与恢复方案设计及运维：23个典型问题解答及经验分享

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关 MySQL备份恢复失败：问题及解决方案

相关 Oracle数据库备份恢复失败：原因及解决方案

相关 Oracle数据库备份恢复演练及问题剖析

相关 Oracle数据库备份恢复不彻底：问题及解决方案

相关 Oracle数据库备份与恢复失败：故障排查及解决方案

相关 Oracle备份恢复演练：实战经验分享

相关 Oracle数据库备份与恢复问题：故障场景及解决方案

相关企业备份方案设计干货参考：典型场景、典型问题及案例

相关 Oracle备份与恢复方案设计及运维：23个典型问题解答及经验分享

相关 #mysql运维日记（二）：备份与恢复