Oracle 数据库在使用和维护过程中难免会发生一些故障，针对不同的故障有多种处理方式。通常情况下DBA做一些修复操作即可恢复，但也有很多时候需要借助第三方备份软件才能修复故障。
AnyBackup 7.0 恢复概述
AnyBackup 7.0 版本对 Oracle 数据库定时备份提供了丰富的恢复方式选择，主要有：实例恢复和单独恢复各类文件，其中文件恢复包含：日志文件恢复、控制文件恢复、参数文件、数据文件恢复。
实例恢复的原理是采用先恢复控制文件，然后恢复数据文件，再前滚归档日志的方式恢复数据库。当用户的数据库出现崩溃，无法恢复的故障时，或者需要做异机的迁移时，选择实例恢复方式。实例恢复方式需要采用 alter database open resetlogs 的方式打开数据库，造成 Oracle 日志的截断，可能会有短时间内的数据丢失。
日志文件，控制文件，参数文件、数据文件的恢复主要是提供给对 Oracle 有一定基础的 dba 使用，用户可以根据Oracle 的故障原因的判断，有选择的恢复控制文件、参数文件或日志文件，然后通过 Oracle 自己的管理手段，将数据库恢复至可用的状态。
Oracle故障诊断及恢复方式选择
实例级恢复应用场景：
- 需要恢复之前某个时间点的备份；
- 需要进行异机恢复；
- 需要进行数据迁移；
- 用户仅需要恢复部分PDB数据库；
- 控制文件损坏，数据库无法通过单独恢复各种文件来修复；
- 数据库服务器物理存储损坏，更换存储后数据恢复；
各类文件恢复应用场景：
- 当Oracle 归档日志文件、参数文件丢失时，用户不需要进行实例恢复，在不改变现有数据库结构下，可以进行单独的文件恢复；
- 用户想手工通过 rman 命令来恢复数据库时，可以依次恢复控制文件、数据文件、归档日志来实现，这种恢复方式类似于用实例恢复；
- 用户某个数据文件出现误删、物理损坏等，且实例数据量很大，做实例恢复影响太大需要快速恢复单个数据文件；
- 当用户手工通过 rman 命令来恢复数据库，如果提示需要相关归档日志可以通过文件恢复恢复归档日志；
恢复案例
控制文件丢失或损坏，则实例通常会中止。丢失了控制文件后，可选的恢复方案取决于控制文件的存储配置以及是至少还有一个控制文件还是丢失了所有文件。如果丢失一个控制文件副本可通过复制现有的控制文件。如果丢失所有的控制文件后，此时可以采用AnyBackup原机恢复控制文件。
丢失了重做日志文件，需要判断丢失的重做日志文件是否已经归档，如果丢失的重做日志文件已经归档，此时可选方案为DBA清理丢失的重做日志文件，如果重做日志文件未归档，DBA清理丢失的重做日志文件会导致日志链中断，清理后需要立即用 AnyBackup 做一个完全备份。
丢失非系统表空间所在的数据文件，则需要将丢失或者损坏的数据文件offline，然后采用AnyBackup原机恢复丢失的数据文件。AnyBackup 会将该数据文件最近的备份时间点数据恢复出来，并通过归档日志完全恢复到最新状态。此时也可采用整个实例的恢复方式，恢复整个实例到最新状态。
丢失归档日志文件不会影响到实例的运行，也不会造成故障，通常历史归档日志文件会被用来进行坏块修复，数据前滚。当明确丢失的归档序列号后可采用AnyBackup原机或者异机恢复指定序列号的归档日志文件。
数据库存储损坏属于特别严重的损坏，将导致实例的所有数据文件、控制文件、redo日志损坏，此时可采用AnyBackup不完全恢复整个实例，恢复到备份完成的时间点，如存储修复能导出备份时间点到存储故障时间之类的归档日志，则可选择使用rman工具利用归档手工前滚，以便丢失最少的数据。
数据库逻辑错误无法通过完全恢复来实现故障处理，必须选择不完全恢复，也就是恢复到逻辑错误发生前的时刻。此时可以采取指定时间点恢复整个实例到异机或者原机。逻辑错误影响单张表的情况下更好的方式是采用AnyBackup 异机指定时间点恢复，异机恢复成功后将出现逻辑错误的表通过数据泵导入到原库。逻辑错误影响整个实例的情况下，则必须通过AnyBackup不完全恢复整个实例的方式进行原机或异机恢复。
语言选择
