Oracle 手工备份恢复（1）

冷备份的备份流程：
（1）shutdown immediate。
（2）cp拷贝需要备份的文件。

热备份的备份流程：
（1）alter database begin backup 启动热备份
（2）进行cp拷贝需要备份的文件
（3）alter system switch logfile 对热备份期间产生的日志进行归档。
（4）alter database end backup 结束

非归档模式的恢复：
场景1：
有整库的冷备份
非归档，数据文件丢失
备份后，到数据文件丢失期间所有日志都是存在的
恢复步骤：
1.停止数据库
sql>shutdown abort
2.复制所有备份的数据文件到原来位置
$cp *.dbf /u01/app/oracle/oradata/orcl11g/
3.数据库启动到mount
sql>startup mount
4.修复数据库
recover database； --就提升数据文件比较老的scn到最新的状态，重新应用一下日志。
5.打开数据库
alter database open

场景2：
有整库的冷备份
非归档，数据文件丢失
备份后，到数据库文件损坏的日志文件有丢失的情况(和备份相邻部分的日志正常，但是，比较新的日志丢失)
恢复步骤：
1.停止数据库
2.复制所有的数据文件和控制文件到原来位置
3.修复数据库
recover database using backup controlfile until cancel;
4.以resetlogs的方式打开数据库
alter database open resetlogs;

场景3:
有整库的备份
非归档，数据文件丢失或和损坏
备份距离数据库损坏之间的日志文件有gap

恢复数据库到以前的状态：
1.停止数据库
2.复制所有的文件到原来的位置
数据文件，控制文件，日志文件
3.直接打开数据库
数据库还原到备份的时刻，之后的所有操作丢失；

归档模式恢复：
很简单，关于此部分资料有许多，不再叙述
注意的位置：
recover datafile 5;
当在sqlplus进行手工恢复时，
如果需要使用归档日志，它会让你进行选择。
suggested(回车自己找一个)
filename(自定义一个文件名)
auto(自动)
cancel (有多少日志就使用多少日志)

---

–如果在当前日志中（current）存在需要应用的redo信息。
进行auto自动寻找时，可能会报错，
因为当需要使用归档日志进行恢复时，Oracle会一直自动寻找归档日志，直到找不到为止，对于找不到的归档日志，一般情况下是当前的redo日志。
解决办法：再执行一次recover
自行输入需要应用的日志文件名字，让其应用当前日志组。

---

–如果在当前日志中（current）不存在需要应用的redo信息。
进行auto自动应用时，会直接恢复成功
Media recovery complete.

---

无备份恢复数据文件的场景：
技术原理：
控制文件记录数据库的物理结构(数据文件)
可以根据控制文件，将这个损坏的数据文件重建；
但是重建之后的数据文件，没有数据的记载；
再根据日志（归档日志和在线重做日志）来recover这个数据文件；

技术应用限制：
1.数据文件创建之后，控制文件没有变化过；
2.自数据文件创建之后的所有的日志文件，需要全部存在；
3.数据库建库是就生成的数据文件,不能应用这个技术；

–根据控制文件的信息，创建一个新的数据文件–>空的数据文件
SYS@orcl11g> alter database create datafile ‘/u01/app/oracle/oradata/orcl11g/tbs04.dbf’
as ‘/u01/app/oracle/oradata/orcl11g/tbs04.dbf’;

select * from v$ recover_file;
查看需要恢复的文件
select * from v$ recovery_log;
查看恢复需要应用的日志

然后进行recover指定数据文件即可。

控制文件备份的几种方式：
1.二进制备份
alter database backup controlfile to ‘/home/oracle/con.ctl’
2.文本格式备份（用于重建控制文件）
alter database backup controlfiles to trace as ‘/home/oracle/con.ctl’
3.RMAN手动备份：
RMAN>backup current controlfile
4.RMAN下的控制文件自动备份。
5.在一致性关库情况下，进行cp拷贝备份。

恢复时，就用存在的控制文件备份进行恢复，
不存在备份，就使用trace脚本进行重建。
trace重建控制文件分为日志文件存在，日志文件损坏。

---

日志文件存在时noresetlogs。
此时控制文件从日志文件中获取到最新的SCN，然后进行recover应用日志，将数据文件头部SCN与控制文件SCN保持一致。

---

日志文件损坏时resetlogs。
此时控制文件从数据文件头部获取到SCN，
然后alter database open resetlogs。重置日志打开。

---

归档模式下重做日志丢失：
inactive/unused日志丢失情况：
如果是inactive/unused日志，日志中记录的数据块变化都已经同步到数据文件，这样的日志损坏，没有影响。
mount模式进行清空日志组，自动生成新的日志组：
SYS@>alter database clear logfile group 1
SYS@> alter database open;

active状态的日志文件损坏：
active日志文件是指该日志文件中记录的数据还未同步到数据文件，但是该日志组已经被归档，所以数据也不会有丢失。
mount模式下执行recover：
SYS@>recover database until cancel;
指定需要的日志文件即可。
SYS@> alter database open resetlogs;
因为日志组的日志文件损坏，所以需要resetlogs重置日志。

current日志被损坏：
当前日志组不会被归档，所以会有数据丢失。
强制参数修改：
–alter system set “_allow_resetlogs_corruption”=true scope=spfile;
SYS@> recover database until cancel;
SYS@> alter database open resetlogs;

手工备份的不完全恢复：
SYS@orcl11g> recover database until change 1615006;
SYS@orcl11g> alter database open resetlogs;
不完全恢复必须使用resetlogs，需要重置日志中的事务记录，由于日志中的SCN是大于不完全恢复时刻的SCN。