Recovery in Archivelog (完整恢复)
完整的恢复, 即恢复到数据库损坏的时刻, 不是恢复到数据库的之前的某个时间点.
注意, 我们只考虑 Archivelog 模式的恢复.
步骤:
1. 首先之前要有全备的文件, 就是操作系统级别的 copy. (全备之后的所有的archivelog文件都要保存起来)
2. database 出现问题 , 比如一个数据文件丢失
3. 将全备的文件(与丢失的文件相同) copy 到正常的文件的路径, 比如从 /backup/user01.dbf –> /u01/oradata/ora10g/user01.dbf ( 注意, 此时的数据是不一致的, 因为是全备的 datafile )
4. 打开数据库到 mount 状态
5. recover database 这个命令即可. (向前滚, 后滚等所有动作, 全部由 oracle 自动完成) 注意, 这个命令之所以能自动完成, 要求它所需要的文件都在指定的路径上. 比如 archivelog 文件, 等等, 换句话说, 只要没有损坏redo log 和 archive log 文件, 那么这两种文件在原来的路径上就可以了, 然后使用 recover automatic database; 就可以恢复了. (细节由oracle自己完成)
以上恢复就完成了.
如果你要恢复到不同的路径, 比如原来的磁盘损坏了, 新增加了一块磁盘, 这时候就需要指定恢复的路径:
1. 首先, 加一块新的磁盘, 分区, 格式化.
2. 挂在, mount /dev/sdb1 md(目录), 将备份文件复制到md目录下, 注意路径
3. 修改 parameter file 中对应文件的路径 (spfile, 注意这步关键是将数据文件找到对应的正确的路径)
上边步骤的前提是, 你有一个正确的control file. 因为 control file 里记录了数据库的动态信息. 所以非常重要.
综上恢复, 可知, 一般情况下, 可以参考我们系统这种方式, 每半个月全备, 出问题, 直接 recover automatic database, 当然也可以分部分backup 进行, 就 alter system begin backup, 然后copy, 最后再归档一下, 这种肯定也是可以自动恢复, 只要你不变更文件的路径, 所以… 备份策略如下:
备份策略
小的系统, 参考我们系统, 半个月全备, 然后保存好所有的 archivelog 和 redo 信息, 有问题, 直接 recover automtic database.
大的系统, 参考 rman
重建control file
- All control files are lost becuase of a failure
- The name of a database needs to be changed
- The current settings in the control file need to be changed
control file 丢失, 代价是巨大的, 所以最好不要丢失 control file.
解决办法:
1. 你有多路复用的 control file, 这种基本上相当于没丢
2. create controlfile 命令创建一个新的control file, 这种要求你知道所有的file关于database的细节. (alter database backup controlfile to trace as ‘/u01/user_backup/ctl.txt’, 保存成这个文件格式, 便于我们查看.)
3. 使用之前备份的 control file 来恢复, alter database backup controlfile to ‘/u01/user_backup/controlfile_back.bak’;
控制文件的恢复管理
控制文件版本不一致的问题
用较新版本的控制文件覆盖旧版本的控制文件
直接修改参数control_file
丢失问题
归档模式下
当归档日志全的时候,先做全备,然后使用备份的控制文件恢复即可
当归档日志不全的时候,先做全备,然后建立新的控制文件即可
非归档模式下
先做全备,然后建立新的控制文件即可
新建控制文件语句
数据库处于mount及open状态
执行alter database backup controlfile to trace as ‘<dir>‘;得到建立语句
注意[no]archievelog [no]resetlogs 两个参数的区别
问题1: 版本不一致
(假如 control01 的版本高于另外两个, 则参考如下办法:)
办法: cp /u01/oracle/oradata/ora10g/control01.ctl cp /u01/oracle/oradata/ora10g/control02.ctl
cp /u01/oracle/oradata/ora10g/control01.ctl cp /u01/oracle/oradata/ora10g/control03.ctl
问题2: 部分控制文件丢失
将存在的控制文件复制到目的路径并更改控制文件名字为正确的控制文件名称
问题3: 非归档模式下, 所有 control file 丢失, 重建control file
考虑以下因素:
- 搞清各个日志文件的大小和位置
- 搞清各个数据文件的位置
- 设置正确的字符集
注意上边的是, NOARCHIVELOG模式, 即非归档模式
然后打开数据库以后, 由于多路复用, 可以看到新增加的control file。
问题4: 归档模式下, 所有 control file 丢失
先利用之前的备份文件进行恢复
备份 : alter database backup controlfile to ‘/u01/user_backup/control_backup.bak’;
然后模拟所有的控制文件丢失:
1. 首先将归档的controlfile 转移到本来controlfile 指定的路径, 并将名字改成 control file 的名字.
cp /u01/user_backup/control_backup.bak’ /u01/oracle/oradata/ora10g/control01.ctl
cp /u01/user_backup/control_backup.bak’ /u01/oracle/oradata/ora10g/control02.ctl
cp /u01/user_backup/control_backup.bak’ /u01/oracle/oradata/ora10g/control03.ctl
2. alter database mount ( 打开数据库到mount 状态 )
3. alter database open resetlogs;
control file 真的要小心, 问题很严重, 因为control file 是动态变化的, 如果不是自动备份, 那么当所有的 control file 都丢失了, 那么就要进行 不完整恢复了, 因为如果你用之前的 control file, 那么 control file 里边的内容, 比如 SCN 等内容必然跟现在不一样, 所以还是设置自动备份 control file 和进行多路复用, 一定要保住 control file.
不完整恢复
Reasons for Performing Incomplete Recovery : (不完整恢复的原因)
- Complete recovery fails because an archived log is lost.
- All control files are lost. (哇, 如果所有的控制文件丢失, 那么只能不完整恢复)
- All unarchived redo log files and a datafile are lost.
- User error
- An important table was dropped.
- Invalid data was committed in a table.
Missing archive: A complete recovery operation fails because of a bad or missing archived log. Recovery can only be completed to a time in the past, prior to applying the archived log.
Loss of control files : You did not mirror your control file and you do not know the structure of your database, but you have a backup of an old binary copy.
Loss of redo logs: Redo logs were not mirrored and you lost a redo log before it was archived, along with a datafile. Recovery cannot continue past the lost redo log.
User error: A user drops the wrong table, commits data updated with an incorrect WHERE clause, and so forth.
3 种类型的 不完整恢复
- Time-based recovery : 故名思议, 恢复到之前的一个时间点.
- Cancel-based recovery : 跟 redo log sequence 有关. 下边有例子, 参考蓝色例子
- Change-based recovery : 恢复到之前一个 SCN.
另外, 如果你需要使用旧的 control file 来进行不完全恢复, 那么要使用 recovery using a backup control file. ( 这种情况一般用于 all control files are lost, 只剩下之前备份的control file了.
执行不完整恢复的需要注意的内容 :
1. 在进行不完整恢复之前, 先保存所有的数据库文件到其他目录, 包括 redo log 和 archive log. (防止你在操作的时候对数据库造成不可逆转的伤害, 如果实在不能全部备份, 最起码也要备份 control file 和 archive log file)
2. 在没有确认所有的恢复成功之前, 不要让用户可以访问数据库.
3. Back up (and later remove) archived logs from the system to prevent mixing archives from different database incarnations.
例如:
- A database at log seq 144 has archived logs from arch_120.rdo to arch_143.rdo.
- After performing incomplete recovery, a new database incarnation is created, setting the database log seq to 0.
- Archived log arch_120.rdo to arch_143.rdo are now part of the old database incarnation.
- After 120 log switches, the archived log arch_120.rdo will be overwritten, and is backed up with all other archives(including the old archived logs arch_121.rdo to arch_143.rdo). 两个database 的 archivelog 混在一起了 mixing
- At a later stage, if recovery requires arch_124.rdo, you need to make sure that the archived log restored from the backup is for the correct database incarnation, otherwise an error will result.
4. 在备份和恢复之前, 要一直确认 Alert Log file, 因为所有的流程的信息都会被存储在 alert log file 里.
执行不完整恢复的步骤:
1. Shutdown and backup the database.
例如: shutdown immediate
2. Restore all datafiles. Do not restore the control file, redo logs, password file, or parameter file.
这一步的目的是, 将所有的 datafile 和 archivelog file 备份一下, 是将目前数据库目录中的数据文件和 archivelog文件copy 到别的地方.
3. Mount the database.
startup mount;
4. Recovery the datafiles to a point before the time of failure.
recover database until cancel
recover database until time ‘2014-03-14:14:22:22’
recover database until time ‘2014-03-14:14:22:22’ using backup controlfile -- 使用以前备份的控制文件
recover [automatic] database <option> , 其中:
automatic 表示: 自动应用 archived 和 redo log files.
option: until time ‘YYYY-MM-DD:HH:MI : SS’;
until cancel;
until scn <integer>;
using backup control file;
5. Open the database with RESETLOGS.
alter database open resetlogs;
archive log list; -- 可以看到目前的 log sequence 号码, 例如上边说明, 之前的 seq 号已经到了 144, 可能你恢复完以后就看到 seq 号为0, 那么表示恢复成功了.
6. Perform a closed database backup.
shutdown immediate;
copy 所有的文件, 备份起来(全备), 注意, 全备以后, archivelog 文件就没有用了, 前面也提到了, 如果继续使用, 会出现混合mixing, 所以全备以后, 删除所有的数据库指定目录的archivelog 文件, 至于你在恢复之前的 archivelog 文件, 是否删除自己考虑, 因为对目前数据库没有影响(存储在别的目录)
注意: 由于数据库恢复到了之前的一个时间点, 那么该时间点之后的正确事务要再进行一次.
例子:
cancel-based recovery 例子 (跟日志文件有关)
假设:
现在是12：00, EMPLOYEES table was dropped while someone was trying to fix bad blocks, log files 同时存放在这个磁盘上, 这个 table 是在上午 11:45 左右被删除的, 现在开会: 开会发现:
redo log 没有多路复用, 换句话丢失的 redo log 没有镜像. 1 个 redo log file missing. 并且丢失的这个 log file 也没有被归档. (log2a.rdo 丢失)
现在有的 redo log 包含了 11:34 的信息. 26 分钟的数据丢失了. 通过 v$logfile 可以看到这个时间.
这时候查询 v$log_history 可以看到 缺失的那个 log seq 号, 这里是 48.
恢复的步骤与前面基本相同, 只是恢复的命令是 recover database until cancel. 注意, 这样是恢复到了(recover the database until log seq 48) 前面seq 47 的内容全面恢复了, 恢复完以后, 可以查看该 EMPLOYEES, 看到该内容可以查找的到.
Using backup control file recovery :
假设:
现在是12:00, tablespace containing the EMPLOYEES table has been dropped. The error occurred around 11:45, Many employee records were updated this morning, but not since 11:00. 并且每天晚上都会做一次备份.
事件顺序:
1. someone, drop tablespace emp_ts including contents;
2. 立刻告诉所有用户退出登录, 你将数据库设置成 restircted, 限制用户登录, alter system enable restricted session;
3. 经过分析, 你找到了昨天晚上备份的 control file, 因为当前的 control file 将被覆盖, 所以你要先确认目前这个 control file 里的信息.
select * from v$log;
select tablespace_name, file_name from dba_data_files where tablespace_name = ‘EMP_TS’
通过以上确认, 可以发现
EMP_TS tablespace has one datafile.
The current log sequence number is 61.
You confirm that the tablespace was dropped at 11:44:54 ( 通过 alert_log file 中的时间戳, 可以确认这个操作的时间 )
datafile number 4 is offline.
4. shutdown the database, backup control files. 然后将之前备份的包含了该tablespace信息的 control file 和 datafile 移动到当前数据库文件的目录.
5. 要确认所有的 offline datafiles 都变成 online, because any offline files may be unrecoverable after recovery:
select * from v$recover_file; 看到有 offline的, 就 alter database datafile 4 online;
6. recover database until time ‘2001-03-09:11:44:00’ using backup controlfile;
7. alter database open resetlogs;
8. 确认 EMPLOYEES table 是否存在
9. 全备
10. 通知用户, 11:44 分之后的操作要重做.
Loss of Current Redo log files 丢失了当前正在使用的 redo log file
1. 当想要打开数据库时, 会得到错误, current log file 丢失.
2. 需要 recovery 了, 首先确认 log sequence number , select * from v$log; 假如 current log seq no. 是 61
3. 将原来备份的 datafile copy 到数据库指定的路径. 然后, recover until cancel, 这个操作会将数据库恢复到 log seq 到 60.
4. alter database open resetlogs
5. The database should now be operational, because any missing log files will be re-created.
Note: If log files need to be re-created on another disk due to media failure, use the ALTER DATABASE DROP LOG GROUP and ALTER DATABASE ADD LOG GROUP commands to create the log files manually.
6. 全备