Oracle Recovery 02 - 常规恢复之不完全恢复

背景：这里提到的常规恢复指的是数据库有完备可用的RMAN物理备份。

实验环境：RHEL6.4 + Oracle 11.2.0.4 单实例.

二、常规恢复之不完全恢复：部分数据丢失

• 2.1 重做日志文件丢失或损坏
• 2.2 重做日志文件，数据文件丢失或损坏
• 2.3 控制文件丢失或损坏
• 2.4 控制文件，数据文件丢失或损坏
• 2.5 控制文件，重做日志文件，数据文件丢失或损坏
• 2.6 控制文件，重做日志文件丢失或损坏
• 2.7 控制文件，重做日志文件，参数文件丢失或损坏
• 2.8 控制文件，重做日志文件，参数文件，数据文件丢失或损坏
• 2.9 把数据库恢复到某个SCN
• 2.10 把数据库恢复到某个时间点
• 2.11 表空间基于时间点的恢复

二、常规恢复之不完全恢复：部分数据丢失

Oracle 数据库常规恢复的几个概念：

常规恢复之完全恢复：不丢失数据。

比如数据文件丢失，临时文件丢失，参数文件丢失。可以通过RMAN备份完全恢复数据库。

示例：Oracle Recovery 01 - 常规恢复之完全恢复

常规恢复之不完全恢复：部分数据丢失。

一般是有控制文件或是在线重做日志文件丢失。通过RMAN备份恢复，resetlogs会导致丢失数据。

示例：Oracle Recovery 02 - 常规恢复之不完全恢复

注意事项：每次不完全恢复完成后，按照规范，数据库应立即做一次全备，防止意外发生。

/bin/bash /usr2/backupsh/full_backup.rman

2.1 重做日志文件丢失或损坏

启动数据库报错：

SQL> startup
ORACLE instance started.

Total System Global Area 1620115456 bytes
Fixed Size                  2253704 bytes
Variable Size             939527288 bytes
Database Buffers          671088640 bytes
Redo Buffers                7245824 bytes
Database mounted.
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u02/oracle/JINGYU/onlinelog/o1_mf_1_bwjsmn50_.log'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 1 thread 1: '/u02/oracle/JINGYU/onlinelog/o1_mf_1_bwjsmn1l_.log'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

恢复方法：

SQL> shutdown immediate
SQL> startup mount
SQL> recover database until cancel;
SQL> alter database open resetlogs;

恢复完成后，数据库做一次全备。

2.2 重做日志文件，数据文件丢失或损坏

### 启动数据库报错： ###

SQL> startup
ORACLE instance started.

Total System Global Area 1620115456 bytes
Fixed Size                  2253704 bytes
Variable Size             939527288 bytes
Database Buffers          671088640 bytes
Redo Buffers                7245824 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1:
'/u02/oracle/JINGYU/datafile/o1_mf_system_bwjsmpcw_.dbf'

恢复方法：

RMAN> restore database;
SQL> recover database until cancel;
SQL> alter database open resetlogs;

# DRA建议：database point-in-time recovery
RMAN> restore database until scn 344834;
RMAN> recover database until scn 344834;
RMAN> alter database open resetlogs;

恢复完成后，数据库做一次全备。

2.3 控制文件丢失或损坏

启动数据库报错：

SQL> startup
ORACLE instance started.

Total System Global Area 1620115456 bytes
Fixed Size                  2253704 bytes
Variable Size             939527288 bytes
Database Buffers          671088640 bytes
Redo Buffers                7245824 bytes
ORA-00205: error in identifying control file, check alert log for more info

恢复方法：

查看alert.log, 是否所有的控制文件都丢失了？

第一种情况：并非所有的控制文件都丢失

这种情况其实并不算是不完全恢复，因为并没有丢失控制文件的信息。

可以直接从完好的控制文件拷贝到初始化参数文件中指定的控制文件的各个路径。

第一种情况恢复方法：

cp xxx01.ctl xxx02.ctl
SQL> alter database mount;
SQL> alter database open;

第二种情况：所有的控制文件都丢失

那么就只能从RMAN备份中恢复控制文件。

第二种情况恢复方法：

RMAN> restore controlfile from '/u02/BACKUP/20150812/controlfilec-3589019315-20150812-07';
RMAN> alter database mount;
RMAN> recover database;
RMAN> alter database open resetlogs;

恢复完成后，数据库做一次全备。

2.4 控制文件，数据文件丢失或损坏

启动数据库报错：

SQL> startup
ORACLE instance started.

Total System Global Area 1620115456 bytes
Fixed Size                  2253704 bytes
Variable Size             939527288 bytes
Database Buffers          671088640 bytes
Redo Buffers                7245824 bytes
ORA-00205: error in identifying control file, check alert log for more info

恢复方法：

RMAN> restore controlfile from '/u02/BACKUP/20150812/controlfilec-3589019315-20150812-07';
RMAN> alter database mount;
RMAN> restore database;
SQL> recover database using backup controlfile until cancel;
cancel
SQL> alter database open resetlogs;

恢复完成后，数据库做一次全备。

2.5 控制文件，重做日志文件，数据文件丢失或损坏

参考`2.4 控制文件，数据文件丢失或损坏`。
恢复完成后，数据库做一次全备。

2.6 控制文件，重做日志文件丢失或损坏

参考`2.3 控制文件丢失或损坏`，如果是控制文件有其他备份，同时参考`2.1 重做日志文件丢失或损坏`。
恢复完成后，数据库做一次全备。

2.7 控制文件，重做日志文件，参数文件丢失或损坏

启动数据库报错：

SQL> startup
ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/u01/app/oracle/product/11.2.0/db_1/dbs/initjingyu.ora'

恢复方法：

#恢复参数文件：
vi /u01/app/oracle/product/11.2.0/db_1/dbs/initjingyu.ora
SQL> startup pfile='/u01/app/oracle/product/11.2.0/db_1/dbs/initjingyu.ora'
RMAN> restore spfile from '/u02/BACKUP/20150813/controlfilec-3589191014-20150813-0b';
RMAN> shutdown immediate;
RMAN> startup nomount;

#恢复控制文件
RMAN> restore controlfile from '/u02/BACKUP/20150813/controlfilec-3589191014-20150813-0b';
RMAN> alter database mount;

#恢复数据库
RMAN> restore database;
SQL> recover database using backup controlfile until cancel;
auto
SQL> recover database using backup controlfile until cancel;
cancel
SQL> alter database open resetlogs;

##DRA的建议（启动到mount后，恢复到SCN 834531，测试也可行）
RMAN> restore database until scn 834531;
RMAN> recover database until scn 834531;
RMAN> alter database open resetlogs;

恢复完成后，数据库做一次全备。

2.8 控制文件，重做日志文件，参数文件，数据文件丢失或损坏

参考`2.7 控制文件，重做日志文件，参数文件丢失或损坏`。

恢复完成后，数据库做一次全备。

2.9 把数据库恢复到某个SCN

误操作truncate了表：

SQL> create table t_scn as select * from user_objects;

Table created.

SQL> select count(1) from t_scn;

  COUNT(1)
----------
         4

SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
                 1025158

SQL> truncate table t_scn;

Table truncated.
SQL> select count(1) FROM T_SCN;

  COUNT(1)
----------
         0

注意：这里用到的select dbms_flashback.get_system_change_number from dual;，在现实情况这个scn或者下面的时间点都是需要通过Logmnr分析日志获取的。

关于Logmnr的使用，后续会单独整理一篇文章。

恢复方法：

run {
shutdown immediate;
startup mount;
allocate channel c1 type disk;
allocate channel c2 type disk;
set until scn 1025158;
restore database;
recover database;
alter database open resetlogs;
}

验证t_scn的表记录已经恢复回来：

SQL> select count(1) from t_scn;

  COUNT(1)
----------
         4

恢复完成后，数据库做一次全备。

2.10 把数据库恢复到某个时间点

误操作truncate了表：

SQL> alter session set NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS';

Session altered.

SQL> select sysdate from dual;

SYSDATE
-------------------
2015-08-14 10:10:16

SQL> select count(1) from t_scn;

  COUNT(1)
----------
         4

SQL> truncate table t_scn;

Table truncated.

恢复方法：

run {
shutdown immediate;
startup mount;
allocate channel c1 type disk;
allocate channel c2 type disk;
sql "alter session set nls_date_format=''yyyy-mm-dd hh24:mi:ss''";
set until time '2015-08-14 10:10:16';
restore database;
recover database;
alter database open resetlogs;
}

恢复完成后，数据库做一次全备。

2.11 表空间基于时间点的恢复(TSPITR)

参考：表空间基于时间点的恢复(TSPITR)

恢复完成后，数据库做一次全备。