5.数据库完全恢复
如果损坏的块是数据文件开头，这将导致数据库无法正常启动和关闭，并且使用RMAN BLOCKRECOVER也不能恢复。因此此时就要进行完全恢复或者尝试使用BBED修改块头。
1) 模拟损坏数据文件头的块
使用BBED方法将数据文件6的第1个块损坏，DBV的检查结果如下：
$ dbv file=/test/test01.dbf
2) 尝试使用RMAN BLOCKRECOVER进行恢复
执行以下命令使用RMAN的BLOCKRECOVER对数据文件6的第1个块进行恢复：
RMAN> blockrecover datafile 6 block 1;
Starting recover as 2013-12-07 16:24
Using channel ORA_DISK_1
Starting media recovery
Media recovery complete,elapsed time: 00:00:00
Finished recover at 2013-12-07 16:24
恢复显示是完成的，也没有报错。但是执行DBV验证命令发现标记的坏块还是两个，及没有真正修复。说明使用RMAN BLOCKRECOVER对数据文件头的修复是没有作用的。
尝试正常关闭数据库，由于数据库无法完成检查点工作，所以正常关闭操作失败：
SQL> shutdown immediate
ORA-01122: database file 6 failed verification check
ORA-01110: data file 6: ‘/test/test01.dbf’
ORA-01210: data file header is media corrupt
强制关闭数据库：
SQL> shutdown abort
重启数据库，发现数据库无法打开数据文件：
SQL> startup
……
ORA-01122: database file 6 failed verification check
ORA-01110: data file 6: ‘/test/test01.dbf’
ORA-01210: data file header is media corrupt
3) 执行数据文件的完全恢复
执行以下命令还原、恢复6号数据文件：
RMAN> restore datafile 6;
RMAN> recover datafile 6;
尝试打开数据库：
SQL> alter database open;
Database altered.
Oracle数据库中有各种各样的块，如空块、表头块、数据块、索引块、数据文件头块、UNDO段块等。如果损坏的是普通表的数据块，那即不会影响启动数据库，也不会影响其他表的正常访问，只是在访问该表的时候会出现问题。如果损坏的是数据文件的块头，那么将导致数据库无法正常启动和停止，执行块恢复不能修复这个问题，执行数据文件的完全恢复才能恢复数据文件块头的损坏或尝试使用BBED修改数据文件块头。
6.数据库不完全恢复
不完全恢复又称为数据库基于时间点恢复，是将整个数据库恢复到之前的某个时间点、日志序列号或者SCN号。如下不完全恢复的选项：
不完全恢复的选项
不完全恢复方式
RMAN选项
用户管理备份选项
恢复到某个时间点
until time
until time
恢复到某个日志序列号
until suquence
until cancel
恢复到某个SCN号
until SCN
until change
不完全恢复只能针对整个数据库而言，并不能执行数据文件和表空间的不完全恢复；另外，对于非归档模式的恢复来说，也不能执行不完全恢复。
1) 基于时间点的不完全恢复
RMAN> run {
shutdown immediate;
startup mount;
SQL “alter session set nls_date_format=’’YYYY-MM-DD HH24:MI:SS’’”;(两个单引号之间没有空格)
set until time ‘2013-12-07 17:24:00’;
restore database;
recover database;
alter database open resetlogs;}
SET UNTIL TIME时间可以使用多种表示方式，可以使用TO_DATE函数来表示时间，还可以使用SYSDATE-1方式来表示时间。
注意：不完全恢复是针对整个数据而言，如果在上面的脚本中，还原和恢复的是某个数据文件或表空间，那么脚本将忽略set until time设置，对数据文件或表空间进行完全恢复。对RESTORE命令指定until time或者until scn的意义在于这样可以自动选择最近的RMAN备份来恢复数据，以上的批量命令相当于为RESTORE和RECOVER都指定了until time子句，这样比单命令模式更加简单和合理。基于时间点的恢复不能恢复到最终备份完成时间点以前的时段。
2) 基于序列号的不完全恢复
基于序列号的不完全恢复须指定某个Redo线程的序列号，那么在这个序列号切换时间点之前的所有实例的归档日志都需要的，每个节点的负载不同，其他实例的序列号可能比指定的Redo线程序列号要大。
以下是在RMAN中基于日志序列号的不完全恢复的例子：
RMAN> run {
Shutdown immediate;
Startup mount;
Set until sequence 10350 thread 1;
Restore database;
Recover database;
Alter database open resetlogs;}
注意：指定线程序列号为10350，但是恢复是不包含该序列号的日志的，也就是说恢复只会恢复到thread 1 sequence 10304的日志，时间点和scn恢复同样如此。
3) 基于SCN的不完全恢复
下面是在RMAN中基于SCN的不完全恢复的例子：
RMAN> run {
shutdown immediate;
startup mount;
set until scn 324394;
restore database;
recover database;
alter database open resetlogs;}
注意：对打开的数据库执行的全库备份或者0级备份，即使不完全恢复到执行全库备份或者0级备份的备份时间点也可能需要部分Redo日志，原因在于对打开的数据库执行RMAN备份是一个不一致的备份。
7.表空间时间点恢复
表空间时间点恢复(Tablespace Point-in-time Recovery，TSPITR)特性可以恢复一个或更多的表空间早于数据库其他部分的某个时间点。表空间时间点恢复是表空间的不完全恢复，操作起来比较复杂。
表空间时间点恢复能在不影响数据库其它表空间和对象的情况下，恢复一个或更多的用户表空间到之前的某个时间点。表空间时间点恢复是对某个表空间执行基于某个时间点的恢复，是特殊的不完全恢复。RMAN TSPITR可以用于以下场景：
n 一个不正确的job或者DML语句破坏了数据库其中一个表空间的数据，RMAN TSPITR可用于被破坏表空间的恢复。
n DDL操作改变了表的结构之后，RMAN TSPITR可用于丢失数据的恢复。这种情况不能使用Flashback Table找回表之前的结构的数据，如表结构变化后的一个TRUNCATE表操作。
n 一个表被一个drop语句加了purge选项彻底drop。RMAN TSPITR可用于这种情况的恢复。
n 恢复drop的表空间，当没有使用恢复目录，RMAN能对被drop的表空间执行TSPITR。
n 从一个表的逻辑损坏中恢复。
表空间时间点恢复和Flashback有点类似，在没有介质失败的情况下，数据也可以使用Flashback Database找回，但是Flashback Database会导致整个数据库被闪回到之前的某个时间点。与TSPITR不同的是，Flashback Database特性必须产生Flashback日志，使用Flashback Database闪回数据库比使用TSPITR有更多的限制，TSPITR可以扩展到能找回可用于恢复的更早备份数据。
1) TSPITR的工作原理
TSPITR工作原理的5个步骤：
步骤1 在辅助实例上用目标数据库的备份集还原数据文件。
步骤2 在辅助实例上用目标数据库的归档文件恢复数据文件。
步骤3 在辅助数据库上导出相关数据。
步骤4 修改主库的控制文件。
步骤5 将辅助数据上导出的文件导入目标数据库。
2) RMAN TSPITR模式
表空间时间点恢复使用的是RMAN的RECOVER tablespace命令，执行RMAN TSPITR有几个选项，不同的选项协调各种不同的操作模式之间对特定环境的自动化操作。
a. 全自动化(默认方式)
在这种模式下，RMAN管理整个TSPITR过程。制定表空间的恢复集、辅助目的地、目标时间和允许RMAN管理所有TSPITR的其它方面。
b. 自动化
可以覆盖一些默认RMAN TSPITR设置，但仍然使用RMAN管理辅助实例和辅助目的地。这是默认方式的变种，RMAN TSPITR提供一些固定管理的同事允许手动指定一些参数，主要包含以下两个参数：
n 辅助集或恢复集文件的位置
n 初始化参数文件
除了在TSPITR之后的恢复集文件位置，在TSPITR期间的辅助集文件、通道设置和参数或辅助实例的其它方面等更多控制都推荐使用默认方式。全自动和自动化都是使用RMAN自动管理辅助实例。
c. 非自动化
使用这种模式是手动创建和管理辅助实例的所有方面和一部分TSPITR过程。当必须分配不同的通道或者使用用户管理辅助实例改变参数时，使用这种模式是合适的。
3) 执行全自动化的TSPITR
下面以默认的全自动化模式在目标数据库服务器创建辅助数据库构建TSPITR，恢复在目标数据库对表的一个误操作。目标数据库与辅助数据库都在一台服务器上，下表是两个数据库的实例名和数据库名称对照表：
数据库类型
实例名称
数据库名称
目标数据库
test
test
辅助数据库
test2
test
a. 创建模拟环境
步骤1 在目标数据创建测试表空间xy_tbs:
SQL> create tablespace xy_tbs datafile ‘/u01/app/oracle/test/xy_tbs01.dbf’ size 5M;
步骤2 确保目标数据库处在归档模式，使用RMAN查找出xy_tbs表空间的file_id，对它进行备份：
RMAN> report schema;
……
RMAN> backup datafile 5;
步骤3 创建测试用户xiaoyang：
SQL> create user xiaoyang identified by xiaoyang default tablespace xy_tbs tempory tablespace temp;
SQL> grant create session,create table,unlimited tablespace to xiaoyang;
SQL> connect xiaoyang/xiaoyang;
步骤4 创建两个测试表：x1和x2，每个表插入一条测试数据：
SQL> create table x1(D date);
SQL> create table x2(D2 date);
SQL> insert into x1 values(sysdate);
SQL> insert into x2 values(sysdate);
SQL> commit;
步骤5 查看当前时间作为表空间的恢复时间点：
SQL> alter session set nls_date_format=’YYYY-MM-DD HH24:MI:SS’;
SQL> select sysdate from dual;
步骤6 在恢复时间点之后向x2表中插入一条数据和创建一个新表x3，向x3插入一条测试数据：
SQL> insert into x2 values(sysdate);
SQL> create table x3(D3 date);
SQL> insert into x3 values(sysdate);
SQL> commit;
步骤7 手动drop掉表x1：
SQL> drop table x1 purge;
假设drop x1表是一个误操作，现在要通过TSPITR恢复技术恢复该表。
b. 检查表空间是否自关联
执行以下SQL语句检查表空间自关联情况：
SQL> execute dbms_tts.transport_set_check(‘xy_tbs’,true,true);
SQL> select * from transport_set_violations;
如果查询transport_set_violations视图有值返回，说明表空间有自关联，需要手动处理提示的问题。
c. 标识TSPITR之后将会丢失的对象
步骤1 通过时间标识TSPITR之后将会丢失的对象：
SQL> select owner,name,tablespace_name,to_char(creation_time,’YYYY-MM-DD HH24:MI:SS’) from ts_pitr_objects_to_be_dropped where tablespace_name in(‘xy_tbs’) and creation_time > to_date(‘2013-12-08 09:43:00’,’YYYY-MM-DD HH24:MI:SS’) order by tablespace_name,creation_time;
步骤2 通过SCN标识TSPITR之后将会丢失的对象：
SQL> select owner,names,tablespace_name,to_char(creation_time,’YYYY-MM-DD HH24:MI:SS’) from ts_pitr_objects_to_be_dropped where tablespace_name in(‘xy_tbs’) and creation_time > to_date(to_char(scn_to_timestamp(1638492),’YYYY-MM-DD HH24:MI:SS’),’YYYY-MM-DD HH24:MI:SS’) order by tablespace_name,creation_time;
如果以上两个查询有结果返回，那么在执行TSPITR之前应该先将这些对象进行逻辑备份，TSPITR完成之后，再将这些对象以替换的方式导入，以恢复产生数据丢失的对象。
d. 创建辅助数据库参数文件
转储目标数据库参数文件，将该参数文件拷贝到$ORACLE_HOME目录，重命名为inittest2.ora，参考如下参数文件内容调整inittest2.ora实例的初始化参数文件：
*.audit_file_dest=’/u01/app/oracle/admin/test2/adump’
*.control_files=’/u01/app/oracle/oradata/test2/control01.ctl’
……
db_file_name_convert=(“/u01/app/oracle/oradata/test”,”/u01/app/oracle/oradata/test2”)
log_file_name_convert=(“/u01/app/oracle/oradata/test”,”/u01/app/oracle/oradata/test2”)
log_archive_start=false
lock_name_space=test2
修改test2实例初始化参数文件中的audit_file_dest、control_file参数，确保与原有数据库的存储位置不同。添加db_file_name_convert、log_file_name_convert、log_archive_start和lock_name_space参数设置。
e. 创建目录结构
根据实例test2参数的设置创建相应的目录结构：
$ mkdir –p /u01/app/oracle/admin/test2/adump
$ mkdir –p /u01/app/oracle/oradata/test2
f. 创建test2实例密码文件
$ cd $ORACLE_HOME/dbs/
$ orapwd file=orapwtest2 password=oracle entries=5
g. 创建辅助数据库实例的静态注册
在grid用户下的$GRID_HOME/network/admin/listener.ora文件中修改如下配置：
$ cat listener.ora
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = test2)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)
(SID_NAME = test2)
)
)
h. 添加Oracle Net本地服务名
在Oracle用户下的$ORACLE_HOME/network/admin/tnsnames.ora文件中添加如下配置：
TEST2 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = rhel2)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = test2)
)
)
i. 启动辅助数据库到NOMOUNT状态
$ export ORACLE_SID=test2
$ sqlplus / as sysdba
SQL> create spfile from pfile;
SQL> startup nomount
j. 执行TSPITR恢复
使用RMAN同时连接到目标数据库和辅助数据库，使用RECOVER TABLESPACE命令执行TSPITR操作：
$ rman target /
RMAN> connect auxiliary sys/oracle@test2
RMAN> run {
allocate auxiliary channel a1 type disk;
allocate channel c1 type disk;
recover tablespace xy_tbs until time “to_date(‘2013-12-08 09:30:00’,’YYYY-MM-DD HH24:MI:SS’)”;
release channel c1;
}
执行TSPITR需要手动分配auxiliary通道
使目标数据中xy_tbs表空间ONLINE：
SQL> alter tablespace xy_tbs online;
k. 验证恢复结果
SQL> select * from xiaoyang.x1;
SQL> select * from xiaoyang.x2;
SQL> select * from xiaoyang.x3;
455
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
