采用Oracle ArchiveLog模式和非ArchiveLog模式对备份恢复的影响

老邱

以下是兄弟写的一篇文章，希望对大家有参考价值。

采用Oracle Archive Log模式和非Archive Log模式对备份恢复的影响

备份的目的在于，当系统或数据库出现问题时，能够快速将数据库进行恢复。对于Oracle数据库，一般有两种备份方式：“物理备份”和“逻辑备份”。“物理备份”指的是以copy数据文件方式进行备份；“逻辑备份”指的是用export等方式将数据从数据库中抽取出来。物理备份又可以分为冷备份和热备份。以下是各种备份的说明及前提条件。
-        Cold Backup（冷备份） 主要指在关闭数据库的状态下进行的数据库完全备份，备份内容包括所有数据文件、控制文件、联机日志文件、ini文件。
-        Hot Backup（热备份） 指在数据库处于运行状态下，对数据文件和控制文件进行备份，要使用热备份必须将数据库运行在(Archive Log)归档方式下。
-        Export（逻辑备份）这是最简单的备份方法，可按数据库中某个表、某个用户或整个数据库来导出，并且支持全部、累计、增量三种方式。使用这种方法，数据库必须处于打开状态，而且如果数据库不是在restrict状态将不能保证导出数据的一致性。

“物理备份”方式以相当于copy数据文件的方式进行备份，恢复时可以快速以相当于copy的方式将备份的数据copy回来，所以备份速度特别是恢复速度非常快。

如果不采用Archive Log模式运行Oracle数据库，只有两种可用的备份方法：冷备份或export逻辑备份。根据关键业务服务器的特点，停下数据库进行冷备份是根本不可能的，因此如果不采用Archive Log，只能进行逻辑备份。

如果仅采用“逻辑备份”方式，恢复时会有以下两个主要问题：
1.        无法恢复到最近时间点的数据。只能恢复到上一次export时的数据状态，当天的数据将丢失。Archive Log模式下的物理备份可以用数据文件备份及Archive Log备份，将数据库恢复到数据库失败前的时间点，不会丢失数据。
2.        完成恢复可能需要很长时间。恢复只能用import方法进行，所以需要的时间包括：
a.        create database及所有的tablespace: 以每2分钟初始化一个2G的数据文件来计算，建立一个400G的Oracle数据库需要约6.7个小时。
b.        import。时间较难确定，但保守估计应在10个小时以上（如果import过程中出现问题，恢复时间将延长）
3.        恢复时步骤较多，易出现人为故障。

由于 这些原因，一般备份/恢复时都把export/import的方式做为辅助备份/恢复方式，对一些重要的表进行二级保护。这种备份方式也称为“逻辑备份”方式，当某些重要的表被意外删除时可进行逻辑import恢复。

而对于整个数据库的日常备份/恢复，需要采用“物理备份”方式，即以相当于copy数据文件的方式进行备份，恢复时可以快速以相当于copy的方式将备份的数据copy回来。一般物理备份/恢复都采用Oracle RMAN工具来进行。

下面是“逻辑备份”与“物理备份”在数据库故障时的恢复比较：

1. Oracle逻辑错误造成无法启动       
逻辑恢复: 重新create database及各tablespace，import。可恢复到上次export的数据       
物理恢复: 将所有datafile copy回来，并利用archivelog将数据库recover到故障前的状态

2. 某一个datafile故障或丢失       
逻辑恢复: 重新create database及各tablespace，import。可恢复到上次export的数据       
物理恢复: 将该datafile copy回来

3. 某一个tablespace故障       
逻辑恢复: 重新create database及各tablespace，import。可恢复到上次export的数据       
物理恢复: 将该tablespace copy回来

4. 意外drop table       
逻辑恢复: Import 该table
物理恢复: 将备份恢复到另一服务器上，export该table，在原数据库中import

5. 意外drop user       
逻辑恢复: Import 该user
物理恢复: 将备份恢复到另一服务器上，export该user，在原数据库中import

6. 意外drop tablespace       
逻辑恢复: 情况较复杂，恢复易造成数据库表之间的参照完整性被破坏。在此不做分析       
物理恢复: 情况较复杂，恢复易造成数据库表之间的参照完整性被破坏。在此不做分析

        在进行数据库的恢复时，一定要了解Oracle数据库的原理，分析故障的原因，然后针对故障的情况进行相应的恢复。例如以下情况：
-        Oracle程序文件损坏？
-        control file损坏？
-        Online redo log损坏？
-        datafile损坏？
-        archive log损坏？
-        table或其中数据被意外删除？

不同情况下需要采用的恢复手段都是不尽相同的，需根据损坏的情况进行相应的恢复步骤。

xiaomao2006

ding

vishnoo

数据库做的双机，安装在盘阵上，从1月15到1月18号期间，archive目录下产生了上百G的日志文件，按理讲是应该定期删除过期的日志文件，可为何日志文件推挤了呢？

fengwy

老邱，怎么没谈到RMAN呀，对于oracle来说备份最好的工具就是rman

blue_stone

>3. 某一个tablespace故障        
>逻辑恢复: 重新create database及各tablespace，import。可恢复到上次export的数据        
>物理恢复: 将该tablespace copy回来

>6. 意外drop tablespace        
>逻辑恢复: 情况较复杂，恢复易造成数据库表之间的参照完整性被破坏。在此不做分析        
>物理恢复: 情况较复杂，恢复易造成数据库表之间的参照完整性被破坏。在此不做分析

某一tablespace故障的情况下，如果有物理备份，将文件恢复回去，然后用recover 一下就可以了
如果只有逻辑备份，就删除该表空间，然后新建立一个表空间，将数据导入就可以了
6. 意外drop tablespace 的情况下，有逻辑备份的情况和tablespace故障的情况非常相似。不过省略了删除故障表空间的步骤。
物理恢复则比较麻烦，需要使用表空间时间点恢复。需要建立辅助数据库，然后在辅助数据库上使用基与时间点的不完全恢复将数据库恢复到表空间的某一个时间点，然后将误删除的表空间使用传递表空间的方法传递回原来的数据库。

小艾

不错的文章啊，很长时间没有见这么好的了

大坏蛋

好。谢谢，学习

w3wu

学习了

cnccie

呵呵，什么时候出一个“对性能的影响”呀

4nai

顶，好贴。
但有几个疑问，原文：
3. 某一个tablespace故障        
逻辑恢复: 重新create database及各tablespace，import。可恢复到上次export的数据        
物理恢复: 将该tablespace copy回来
6. 意外drop tablespace        
逻辑恢复: 情况较复杂，恢复易造成数据库表之间的参照完整性被破坏。在此不做分析        
物理恢复: 情况较复杂，恢复易造成数据库表之间的参照完整性被破坏。在此不做分析
上面两个有什么区别？

另外个人觉得对于import应该是很容易imp失败，但不那么容易破坏参照完整性，对于一个有参照关系的表来说，如主外键约束，我觉得不在之前import主键表是不会让你import外键表的，除非是想强行忽略这些关系。如果要能破坏了，应该是数据库设计人员在设计数据库时是有问题。请版主指点。

另外补充一点，虽然rman是oracle比较常用的一种热备份方式，但通过将数据库至于backup mode,在通过相应操作系统备份命令备份数据文件也还是比较常见。如sap管理员可能更倾向于不用rman,另外好象Backupexec备份oracle也不是用rman.

另外还有个问题请教版主，总听人说veritas能支持oracle直接恢复到表级，想问一下veritas是和什么工具结合的。