本文出自头条号老王谈运维，转载请说明出处。
前言
在 DBA 的日常工作中不可避免存在着数据库的损坏，本文将主要介绍 Oracle 数据库遇到不同损坏级别下的应该采用的恢复方法，供读者在遇到此类情景时，能的找到适合自己的恢复方法，提高工作效率。
数据块损坏的恢复
当数据文件中仅有少量的数据块发生了介质损坏时，我们可以利用RMAN对其进行数据块一级的恢复。数据块级的局部恢复可以大大缩短恢复时间，甚至缩短到其他恢复方式的千分之几。此外，在数据块存在损坏而进行的恢复中，系统可以处于运行状态，这个数据文件也可以处于联机应用状态，无须将其设置为脱机，保持应用运行状态。
1）连接RMAN环境，并以 SYSDBA(SYSOPER) 身份连接数据库：
$rman target /
2）执行下面的数据块修复命令进行数据块的修复：
rman>blockrecover datafile 3 block 2,150,152;
现在数据块得以恢复，系统继续运行。
数据文件损坏的恢复
第一步：设置损坏的数据文件脱机
SQL>alter database datafile 4 offline;
第二步：由RMAN装载数据文件
RMAN>restore datafile 4;
第三步：对损坏的数据文件进行恢复
RMAN>recover datafile 4;
第四步：设置已恢复数据文件联机
RMAN>sql “alter database datafile 4 online”;
第五步：查看数据文件的可用性
SQL>select name,enabled,status from v$datafile;
至此，一个非系统表空间的数据文件恢复过程完成。
表空间损坏的恢复
当然数据库恢复方法不仅一个，管理员也可以按照表空间恢复的方法进行恢复操作。还是上面的案例，如果发生了失败，现在按照表空间损坏情况下的恢复方法进行恢复。
下面用备份来恢复表空间users中的全部数据文件：
第一步：将表空间脱机
SQL> alter tablespace users offline;
第二步：装载表空间
RMAN>restore tablespace users;
第三步：恢复表空间
RMAN>recover tablespace users;
第四步：将表空间联机
RMAN>sql “alter tablespace users online”;
第五步：查看数据文件的可用性
SQL>select name,enabled,status from v$datafile;
系统表空间的恢复
如果是还原表空间或者系统表空间损坏，则数据库系统不能运行，数据库一定不能处于打开状态，在RMAN环境下连接Oracle，注意，此时的连接并不是连接到已经打开的数据库，而是连接到处于装载状态下的数据库：
第一步：连接RMAN
$rman target /
第二步：装载表空间
RMAN>restore tablespace system;
第三步：恢复表空间
RMAN>recover tablespace system;
第四步：打开数据库
SQL>alter database open;
数据库的崩溃恢复
一种全数据库恢复方法，用于数据库彻底崩溃，不可以进行数据库局部恢复操作的情况。这种方法很简单---装载回数据库的一个完整备份集进行恢复操作。虽然方法是简单的，但代价是庞大的----时间可能会很长！ 首先需要启动数据库实例。在控制文件完好的情况下，启动到mount状态是没有问题的，如果控制文件损坏，则只能启动到nomount状态。在本例中，数据库可以启动到mount状态：
第一步：启动实例
SQL>startup mount
第二步：进入到RMAN环境下：
$rman target /
第三步：装载数据库备份
RMAN>restore database;
第四步：执行下面的命令进行数据库的完全恢复：
RMAN>recover database;
第五步：打开数据库
RMAN>alter database open;
控制文件损坏的恢复
由于某种原因，例如介质损坏导致所有控制文件都不可用时，管理员可以使用RMAN的控制文件自动备份，对控制文件进行恢复。
为了描述的方便，这里我们假设在一套归档方式运行的数据库中，所有控制文件由于介质损坏导致不可用。其他数据库文件，包括数据文件、参数文件（SPFILE）、归档日志文件、联机重做日志文件等均完好无损。 我们可以按照下面的步骤进行恢复。由于数据库控制文件损坏，因此数据库这时只能处于脱机状态。
第一步：启动数据库到nomount状态：
SQL>startup nomount
第二步：在RMAN环境中，注册数据库ID(DBID)
$rman target / rman>set DBID=1195474494
第三步：从数据库备份集中装载控制文件备份
RMAN>restore controlfile from autobackup
第四步：将数据库开启到mount状态：
RMAN>alter database mount
第五步：用RMAN备份恢复数据库
RMAN>recover database;
第六步：将数据库实例打开，但需要进行日志的重置（resetlogs）:
RMAN>alter database open resetlogs;
由于数据库以resetlogs方式打开，虽然本系统数据并未丢失，但由于所有日志文件已被重置，因此，需要进行完全数据库备份。 如果控制文件损坏，且伴着其他数据文件等的损坏，则按照本节介绍的控制文件恢复，加上数据库的崩溃恢复，可以实现数据库的完全恢复（或不完全恢复）。
日志文件损坏的恢复
由于数据库日志可以采用多成员机制，这种方式保证在单个日志文件损坏下的系统连续运行。即便一个日志组的所有成员都已经损坏，如果是当前日志组，则数据丢失、数据库执行不完全恢复是必然的选择。如果不是当前日志组，可能根本无须修复，直接将日志组删除，再创建新的日志组就可以了。
第一步：进行数据库的不完全恢复
SQL>recover database until cancel;
第二步：按照重置日志的方式打开数据库
SQL>alter database open resetlogs;
数据库得到不完全恢复。当然，上述过程也可以在RMAN中完成。
从指定备份集中恢复
RMAN>
run{
set until scn=1645604; --执行不完全恢复
restore database from tag='TAG20110702T231137'; --指定备份集的tag值，在list backup of database中可以查到
recover database;
sql 'alter database open resetlogs';
}
网站崩溃找不到原因？平台搭建无从下手？热门技术不想落伍？想要变强找不到资料？
加入[IT拯救联盟]，让大牛和同伴拯救你，带你装x带你飞。定期干货分享、大牛专业解答、实用IT工具优选.....
私信小编“联盟”，即可加入我们～
