rman完全恢复
目录
rman完全恢复
概念
实例恢复
是指数据库在遭遇突然情况下崩溃，在处理的事务中有提交的，有没有提交的，也就是说有脏数据，数据库系统本身有某种记录状态和数据的机制。在下次重启之后，再次运行该实例时，系统自动检查相关状态并有进程将该实例的状态、数据恢复到崩溃的那个时候。
介质恢复
首先使用备份还原数据，然后再应用归档日志、重做日志的恢复方式称为介质恢复。介质恢复能将一个经过还原的数据更新到当前的时间点或之前的某个时间点。通常介质恢复这个术语专指对数据文件进行恢复的过程。数据块的介质恢复指数据文件中的个别数据块出现错误时进行的特殊恢复操作。介质恢复通常又可以分为完全恢复和不完全恢复
完全恢复
使用数据库,表空间或数据文件的备份进行还原,再使用归档,重做日志或增量备份将数据更新到当前时间点,用户可以实现基于对数据库、表空间、数据文件执行完全恢复。
不完全恢复
将数据恢复到某一个特定的时间点或特定的SCN。
需要的是：
- 有效的备份
- 备份以来的所有redo log（包括归档和在线redolog）
常用视图:
v$reover_file --查询需要恢复的文件,该视图信息来自控制文件,如控制文件来自备份或重建过则信息会不准
`v$archived_log --查询所有归档日志列表
v$recovery_log --查询所有需要用于恢复的日志
完全恢复的一些情况
恢复整个数据库
恢复步骤：
1) 关闭实例
2) startup mount;
3) 还原数据库
restore database;
4) 使用增量备份和归档日志更新到最新+redo文件
recover database;
5) 打开数据库
alter database open;
恢复表空间
#非system的可以在open，system的只能在mount
#数据库必须处于关闭状态恢复：system、Undo 表空间。
1) 关闭实例
2) startup mount;
3) 还原表空间
restore tablespace tablespace_name;
4) 使用增量备份和归档日志更新到最新
recover tablespace tablespace_name;
5) 打开数据库
#数据库open状态恢复：system、undo之外的其他表空间
1) 离线表空间
alter tablespace users offline immediate;
2) 还原表空间
restore tablespace tablespace_name;
3) 使用增量备份和归档日志更新到最新
recover tablespace tablespace_name;
4) 表空间在线
alter tablespace users online;
数据文件恢复
数据文件或者表空间offline后，要紧跟着执行一个recover操作，这样不管过多久，再次执行online时不需要在recover
#与表空间情况一样：非system的可以在open，system的只能在mount
#数据库必须处于关闭状态恢复：system，undo表空间的数据文件。
1) 关闭实例
2) startup mount;
3) 还原数据文件
restore datafile 7;
4) 使用增量备份和归档日志更新到最新
5) recover datafile 7;
6) 打开数据库
#数据库open状态恢复：system、undo之外的其他表数据文件
1) 离线数据文件
alter database datafile 7 offline;
2) 还原数据文件
restore datafile 7;
3) 使用增量备份和归档日志更新到最新
recover datafile 7;
4) 数据文件在线
alter database datafile 7 online;
控制文件恢复
1) 关闭数据库
2) 启动到nomount
3) 恢复控制文件
restore controlfile from '/tmp/test/controlfile.bk';
#restore controlfile from autobackup;
4) 启动到mount
5) Recover database;
6) 以resetlogs 方式打开数据库
alter database open resetlogs
7) 对数据库进行全备
#转换控制文件为可读
SQL> alter database backup controlfile to trace as '/tmp/test/control.sql';
shutdown immediate;
参数文件恢复
#备份spfile
backup spfile;
#恢复
#nomount模式启动
startup force nomount;
#恢复
restore spfile;
restore spfile from autobackup;
restore spfile from '/tmp/test/spfile.bak';
shutdown immediate;
start;
恢复pdb
PDB分类：根容器、种子容器、其他PDB
1.恢复根容器（mount状态恢复）
restore database root;
recover database root;
2.恢复种子容器
restore pluggable database "pdb$seed";
recover pluggable database "pdb$seed";
3.恢复PDB
restore pluggable database my_pdb;
recover pluggable database my_pdb;
或
restore pluggable database my_pdb,my_pdb1;
recover pluggable database my_pdb,my_pdb1;
4.恢复PDB表空间
restore tablespace MY_PDB:SYSAUX;
recover tablespace MY_PDB:SYSAUX;
注意：PDB数据文件的offline 和 online 需要切换到对应pdb 会话操作。
5.恢复数据文件
report schema;
restore datafile 17;
recover datafile 17;
异机恢复
异机恢复要注意目标数据库的相关目录路径，如数据文件目录、归档目录、redo目录等待，同时注意控制文件的信息
1) 安装相同版本的操作系统和数据库软件
2) 创建相同名字的数据库
3) 还原参数文件
4) 设置dbid和原数据库dbid相同
Set dbid=123456
5) 还原控制文件
6) 还原数据库文件
如果还原到其他路径使用下面命令重定向路径：
set newname for datafile 1 to '/dev/vx/rdsk/ora_dg/rvdata_jf_system';
restore database;
switch datafile all;
7) 应用增量或则归档日志
8) 打开数据库
其他:
SET NEWNAME FOR DATAFILE and SET NEWNAME FOR TEMPFILE
SET NEWNAME FOR TABLESPACE
SET NEWNAME FOR DATABASE
run {
set newname for database to '/home/oracle/oradata/ORCL/%U';
restore database;
switch datafile all;
}
#还可以
catalog start with '......'
switch database to copy
switch更新数据文件名为rman下镜像拷贝时指定的数据文件名
switch更新数据文件名为 set newname 命令指定的名字。
switch database to copy在11g不能用在run{}语句块中
联机重做日志丢失恢复
联机日志重做文件3种状态：当前的 、活动的 、非活动的重做日志
-
活动的(Active)：该类联机重做日志并非当前正在使用的重做日志。但它包含尚未写入数据文件中的重做。其日志组可能（也可能不）需要被归档。
-
当前的(Current)：该类联机重做日志为当前的联机重做日志组。Oracle主动将重做写入该联机重做日志组中。
-
非活动的(Inactive)：该类联机重做日志不是当前正在使用的联机重做日志组。其重做己经被DBWR进程写入数据文件。
通过查询V$LOG视图的STATUS列查看联机重做日志组的状态。
Inactive损坏
假如日志组 4 损坏，状态 inactive。解决很简单，重建或删除日志组即可（删除则确保最少两个日志组）
alter database drop logfile group 5;
alter database clear logfile group 5; 这里 clear 的意思是重建 group5 的文件。
alter database clear unarchived logfile group 5;
active 日志组损坏
做检查点切换，如成功，按照 inactive 损坏处理。否则，按 current 损坏处理。
常见为inactive 损坏：
alter database clear unarchived logfile group 5;
current 日志组丢失
例如:
rm redo01.log
SQL> alter system switch logfile; 切换几次，主动触发
告警日志会记录有关信息，当 current 又转会到 group1 时，session 死！
可以分以下几种情况讨论
1）数据库没有崩溃
第一步，可以做一个完全检查点，将 db buffer 中的所有 dirty buffer 全部刷新到磁盘上。
SQL> alter system checkpoint;
第二步，尝试数据库在打开状态下进行不做归档的强制清除。
SQL> alter database clear unarchived logfile group n;
数据库此时为打开状态，这步若能成功，一定要做一个新的数据库全备，因为当前日志无法归档，归档日志 sequence 已无法保
持连续性。全备的目的就是甩掉之前的归档日志。
2）数据库已经崩溃，只能做传统的基于日志的不完全恢复或使用闪回数据库。
SQL> recover database until cancel;
SQL> alter database open resetlogs;
3）如果之前没有可用的备份，或问题严重到任何方法都不能 resetlogs 打开数据库，为了抢救数据，考虑最后一招使用 Oracle
的隐含参数：_allow_resetlogs_corruption=TRUE
Oracle 不推荐使用这个隐含参数
该参数的含义是：允许数据库在不致性的情况下强制打开数据库。_
在不一致状态下强行打开了数据库后，建议做一个逻辑全备。
示例：恢复时更改存储路径
可能由于磁盘故障等原因，不能恢复到当前的磁盘，需要恢复到另一个位置
SQL> select file#,name from v$datafile;
FILE# NAME
---------- --------------------------------------------------
1 /u01/app/oracle/oradata/ORCL/system01.dbf
3 /u01/app/oracle/oradata/ORCL/sysaux01.dbf
4 /u01/app/oracle/oradata/ORCL/undotbs01.dbf
5 /u01/app/oracle/oradata/ORCL/pdbseed/system01.dbf
6 /u01/app/oracle/oradata/ORCL/pdbseed/sysaux01.dbf
7 /u01/app/oracle/oradata/ORCL/users01.dbf
8 /u01/app/oracle/oradata/ORCL/pdbseed/undotbs01.dbf
9 /u01/app/oracle/oradata/ORCL/orclpdb/system01.dbf
10 /u01/app/oracle/oradata/ORCL/orclpdb/sysaux01.dbf
11 /u01/app/oracle/oradata/ORCL/orclpdb/undotbs01.dbf
12 /u01/app/oracle/oradata/ORCL/orclpdb/users01.dbf
18 /u01/app/oracle/oradata/ORCL/orclpdb/abc.dbf
SQL> conn abc/abc@192.168.250.31:1521/orclpdb
Connected.
SQL> select table_name,tablespace_name from user_tables where table_name='T1';
TABLE_NAME TABLESPACE_NAME
------------------------------ ------------------------------
T1 ABC
SQL> select count(*) from t1;
COUNT(*)
----------
67119
#以pdb的orclpdb的abc表空间为例
rm -f /u01/app/oracle/oradata/ORCL/orclpdb/abc.dbf
alter system flush buffer_cache;
#恢复
#直接转储会按照控制文件的信息还原,set newname告诉控制文件数据文件转储位置
#set newname在resotore前，recover前要switch datafile
run {
sql'alter database datafile 18 offline';
set newname for datafile 18 to '/tmp/abc.dbf';
restore datafile 18;
switch datafile 18;
recover datafile 18;
sql'alter database datafile 18 online';
}
