归档模式下有备份数据文件损坏的完全恢复-1
来源:互联网 发布:云 大数据 编辑:程序博客网 时间:2024/05/29 07:21
归档模式下的完全恢复
如果控制文件,联机重做日志文件都没有损坏,而只是数据文件损坏,并且存在备份以及该备份以来所有的归档日志文件,就能够把
数据库完全恢复到发生介质损坏的时间点上。
启动实验
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
大功告成
- 归档模式下有备份数据文件损坏的完全恢复-1
- 归档模式下无备份数据文件损坏的完全恢复-2
- 在归档模式下有备份,丢失数据文件的恢复
- Oracle归档模式有备份,丢失数据文件的恢复
- 归档模式下恢复没有备份的数据文件
- 归档模式下,恢复没有备份的数据文件
- 归档模式下的手工备份及完全恢复
- rman实验之归档模式有备份,正常关机丢失数据文件的恢复
- DG有归档无备份时的数据文件恢复
- Oracle归档模式无备份,丢失数据文件的恢复
- ARCHIVELOG模式下用户管理的完全恢复—在没有数据文件备份的情况下恢复数据文件
- 用备份控制文件做不完全恢复下的完全恢复(数据文件备份<旧>--新建表空间--控制文件备份<次新>--日志归档文件<新>)
- 热备份 所有数据文件损坏的恢复
- 归档模式下恢复被删除的数据文件
- RMAN之非归档日志模式下的数据文件恢复
- 非归档模式下恢复数据文件浅析
- Oracle归档模式下恢复-数据库完全恢复方法1
- ARCHIVELOG模式下用户管理的完全恢复(4)——在没有数据文件备份的情况下恢复数据文件!
- 登录失败:用户帐户限制。可能的原因包括不允许空密码登录时间限制或强制的策略限制。
- UVALive 3942 Remember the Word(trie + dp)
- 堆排序 Java实现
- RS-232C接口
- 设计模式12:策略模式
- 归档模式下有备份数据文件损坏的完全恢复-1
- eclipse单步调试
- 二级联动菜单--常见的城市二级联动
- 关于在SLES11, RHEL6, OEL6 and UEK2 Kernels使用hugepages的告警
- 归档模式下无备份数据文件损坏的完全恢复-2
- MySQL改变默认编码为utf-8
- Java中变量的内存分析
- 文件操作-文件操作柄,NSFileHandle
- sscanf()的2个用法.