归档模式下有备份数据文件损坏的完全恢复-1
2013-10-07 11:29
435 查看
归档模式下的完全恢复
如果控制文件,联机重做日志文件都没有损坏,而只是数据文件损坏,并且存在备份以及该备份以来所有的归档日志文件,就能够把
数据库完全恢复到发生介质损坏的时间点上。
启动实验
alter tablespace system begin backup;
host copy D:\oracle\product\10.2.0\oradata\TEST\TEST.DBF d:\TEST.DBF;
alter tablespace system end backup;
shutdown immediate
然后我鼠标右键删除TEST.DBF这个文件
startup
Total System Global Area 612368384 bytes
Fixed Size 1292036 bytes
Variable Size 411044092 bytes
Database Buffers 192937984 bytes
Redo Buffers 7094272 bytes
数据库装载完毕。
ORA-01157: 无法标识/锁定数据文件 7 - 请参阅 DBWR 跟踪文件
ORA-01110: 数据文件 7: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\TEST.DBF'
alter database datafile 7 offline;
然后现在把备份的复制过来,如果数据文件所在磁盘损坏可以复制到其他目录,需要使用alter database rename datafile修改控制
文件中对该损坏数据文件的记录
host copy d:\TEST.DBF D:\oracle\product\10.2.0\oradata\TEST\TEST.DBF ;
此时,我们已经完成了数据文件的restore任何,现在我们看看数据文件为什么需要恢复,继续检查SCN信息。
查看v$recover_file数据字典,哪些需要文件恢复
select * from v$recover_file;
FILE# ONLINE ONLINE_ ERROR CHANGE# TIME
------ ------- ------- ----------------------------------------------------------------- ---------- ----------
7 OFFLINE OFFLINE 1836213 06-10月-13
看到了撒,需要恢复的有哪些文件撒,然后我们在恢复撒
提示数据文件7需要恢复,error类型为空,SCN为1836213,是指数据文件头中的信息
select file#,checkpoint_change#,last_change# from v$datafile where file#=7;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
------- ------------------ ------------
7 1838215 1838215
其中checkpoint_change#是控制文件中记录的数据文件SCN,而last_change#是数据文件离线时的数据文件SCN,显然数据文件头中的
记录的SCN和控制文件中记录的SCN不一致,需要恢复,现在我们把表空间设置为ONLINE
SQL> recover datafile 7;
完成介质恢复。
select count(*) from t
第 1 行出现错误:
ORA-00376: 此时无法读取文件 7
ORA-01110: 数据文件 7: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\TEST.DBF'
明明已经恢复了的嘛,为什么查询数据还会有错误嘛???
注意:此时不是提示数据文件不能锁定或者无法识别,说明我们已经restore了数据文件,其实这里的提示说明数据文件需要ONLINE,
因为我们打开数据库时将数据文件设置了OFFLINE了。
alter database datafile 7 online;
select * from v$recover_file;
未选定行
select file#,checkpoint_change#,last_change# from v$datafile where file#=7;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
------ ------------------ ------------
7 1838529
select file#,checkpoint_change# from v$datafile_header where file#=7;
FILE# CHECKPOINT_CHANGE#
------ ------------------
7 1838529
现在我们再次查看,完全恢复了数据文件7,此时也提升了控制文件和数据文件中的SCN
大功告成
如果控制文件,联机重做日志文件都没有损坏,而只是数据文件损坏,并且存在备份以及该备份以来所有的归档日志文件,就能够把
数据库完全恢复到发生介质损坏的时间点上。
启动实验
alter tablespace system begin backup;
host copy D:\oracle\product\10.2.0\oradata\TEST\TEST.DBF d:\TEST.DBF;
alter tablespace system end backup;
shutdown immediate
然后我鼠标右键删除TEST.DBF这个文件
startup
Total System Global Area 612368384 bytes
Fixed Size 1292036 bytes
Variable Size 411044092 bytes
Database Buffers 192937984 bytes
Redo Buffers 7094272 bytes
数据库装载完毕。
ORA-01157: 无法标识/锁定数据文件 7 - 请参阅 DBWR 跟踪文件
ORA-01110: 数据文件 7: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\TEST.DBF'
alter database datafile 7 offline;
然后现在把备份的复制过来,如果数据文件所在磁盘损坏可以复制到其他目录,需要使用alter database rename datafile修改控制
文件中对该损坏数据文件的记录
host copy d:\TEST.DBF D:\oracle\product\10.2.0\oradata\TEST\TEST.DBF ;
此时,我们已经完成了数据文件的restore任何,现在我们看看数据文件为什么需要恢复,继续检查SCN信息。
查看v$recover_file数据字典,哪些需要文件恢复
select * from v$recover_file;
FILE# ONLINE ONLINE_ ERROR CHANGE# TIME
------ ------- ------- ----------------------------------------------------------------- ---------- ----------
7 OFFLINE OFFLINE 1836213 06-10月-13
看到了撒,需要恢复的有哪些文件撒,然后我们在恢复撒
提示数据文件7需要恢复,error类型为空,SCN为1836213,是指数据文件头中的信息
select file#,checkpoint_change#,last_change# from v$datafile where file#=7;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
------- ------------------ ------------
7 1838215 1838215
其中checkpoint_change#是控制文件中记录的数据文件SCN,而last_change#是数据文件离线时的数据文件SCN,显然数据文件头中的
记录的SCN和控制文件中记录的SCN不一致,需要恢复,现在我们把表空间设置为ONLINE
SQL> recover datafile 7;
完成介质恢复。
select count(*) from t
第 1 行出现错误:
ORA-00376: 此时无法读取文件 7
ORA-01110: 数据文件 7: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\TEST.DBF'
明明已经恢复了的嘛,为什么查询数据还会有错误嘛???
注意:此时不是提示数据文件不能锁定或者无法识别,说明我们已经restore了数据文件,其实这里的提示说明数据文件需要ONLINE,
因为我们打开数据库时将数据文件设置了OFFLINE了。
alter database datafile 7 online;
select * from v$recover_file;
未选定行
select file#,checkpoint_change#,last_change# from v$datafile where file#=7;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
------ ------------------ ------------
7 1838529
select file#,checkpoint_change# from v$datafile_header where file#=7;
FILE# CHECKPOINT_CHANGE#
------ ------------------
7 1838529
现在我们再次查看,完全恢复了数据文件7,此时也提升了控制文件和数据文件中的SCN
大功告成
相关文章推荐
- 归档模式下无备份数据文件损坏的完全恢复-2
- RMAN数据库恢复 之归档模式有(无)备份-丢失数据文件的恢复
- 用备份控制文件做不完全恢复下的完全恢复(数据文件备份<旧>--新建表空间--控制文件备份<次新>--日志归档文件<新>)
- 用备份控制文件做不完全恢复下的完全恢复(数据文件备份<旧>--新建表空间--控制文件备份<次新>--日志归档文件<新>)
- 无备份有完全归档日志情况下恢复数据文件
- 归档模式下,恢复没有备份的数据文件
- rman实验之归档模式无备份,正常关机丢失数据文件的恢复
- 一个归档模式无备份丢失数据文件的恢复
- 当前控制文件损坏_不完全恢复_用控制文件二进制备份_数据不丢_不需备份
- 归档模式下恢复没有备份的数据文件
- ARCHIVELOG模式下用户管理的完全恢复(4)——在没有数据文件备份的情况下恢复数据文件!
- rman实验之归档模式有备份,正常关机丢失数据文件的恢复
- 无备份有完全归档日志情况下恢复数据文件
- ORACLE基础学习-RMAN应用之(归档模式无备份,丢失数据文件的恢复)
- 在归档模式下有备份,丢失数据文件的恢复
- ORACLE基础学习-RMAN应用--归档模式有备份,丢失数据文件恢复
- oracle数据恢复案例 - 控制文件损坏,无备份
- 归档模式下的手工备份及完全恢复
- 没有备份、只有归档日志,如何恢复数据文件?
- 拥有所有归档文件,但没有备份情况下的数据文件恢复