设为首页 加入收藏

TOP

归档模式下四种完全恢复的场景(一)
2015-08-31 20:00:24 来源: 作者: 【 】 浏览:292
Tags:归档 模式 完全 恢复 场景

在数据的备份恢复中,基本都在使用rman来做了,但是从数据库的内部原理来说,对于介质恢复,其实还是做两件事,restore和recover.
?restore是一个类似物理文件的复制,而recover则在数据库后台根据scn做相关的数据恢复。
?在归档模式下,一般有下面四种场景可以做完全恢复,当然前提还是在有备份的情况下。
?我们可以不依赖rman来手工完成备份恢复的这些过程。因为手工的过程其实也不复杂。
?手工备份恢复,那么备份就是热备了。如果连归档没开,就会报出下面的错误。
SQL> alter tablespace data begin backup;
?alter tablespace data begin backup
?*
?ERROR at line 1:
?ORA-01123: cannot start online backup; media recovery not enabled
启用归档胡,我们可以使用动态sql来生成热备的语句,我们过滤了temp表空间,因为是不需要的。
select 'alter tablespace '||tablespace_name||' begin backup;' from dba_tablespaces where logging='LOGGING'
?alter tablespace SYSTEM begin backup;
?alter tablespace SYSAUX begin backup;
?alter tablespace UNDOTBS begin backup;
?alter tablespace DATA begin backup;
?alter tablespace TESTDATA begin backup;


然后拷贝物理文件到一个指定目录。
?最后使用end backup来完成热备。这个过程比较常规,也比较简单。


?有了备份,我们来看看四种完全恢复的场景。我们都可以手工破坏。
第一种是数据open状态,普通数据文件损坏的情况。
?假定test用户下的表test是存储在表空间data上的。


SQL> select count(*)from test.test;


? COUNT(*)
?----------
? ? ? ? ? 0
我们手工破坏一下。
SQL> !rm /u02/ora11g/oradata/TEST/data02.dbf
然后做一个全局检查点,这个时候原来可访问的表就报错了。


SQL> alTer system checkpoint;


System altered.


SQL> select count(*)from test.test;
?select count(*)from test.test
?*
?ERROR at line 1:
?ORA-00376: file 4 cannot be read at this time
?ORA-01110: data file 4: '/u02/ora11g/oradata/TEST/data02.dbf'
我们可以尝试offline表空间,但是因为数据文件丢失,所以offline失败
SQL> alter tablespace data offline;
?alter tablespace data offline
?*
?ERROR at line 1:
?ORA-01191: file 4 is already offline - cannot do a normal offline
?ORA-01110: data file 4: '/u02/ora11g/oradata/TEST/data02.dbf'
需要使用offline immediate,不会去写入检查点。
SQL> alter tablespace data offline immediate;


Tablespace altered.


这个时候我们可以从热备份中找到对应的文件走还原。
SQL>? !cp /u02/ora11g/oradata/hot_bak/data02.dbf /u02/ora11g/oradata/TEST


然后就是恢复。
SQL> recover tablespace data;
?Media recovery complete.
恢复完成之后把表空间置为online
?SQL> alter tablespace data online;


Tablespace altered.


这个时候表又可以访问了。
SQL> select count(*)from test.test;


? COUNT(*)
?----------
? ? ? ? ? 0


Total System Global Area? 209235968 bytes
?Fixed Size? ? ? ? ? ? ? ? ? 1335528 bytes
?Variable Size? ? ? ? ? ? 125832984 bytes
?Database Buffers? ? ? ? ? 75497472 bytes
?Redo Buffers? ? ? ? ? ? ? ? 6569984 bytes
?Database mounted.
?ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
?ORA-01110: data file 1: '/u02/ora11g/oradata/TEST/system01.dbf'


?这个时候问题也很明显,简单检查一下就会发现系统数据文件不存在。
?这个时候直接从热备处拷贝系统文件
SQL> !cp /u02/ora11g/oradata/hot_bak/system01.dbf /u02/ora11g/oradata/TEST
然后直接恢复数据文件即可。
SQL> recover datafile 1;
?Media recovery complete.
完成之后可以尝试启库,会发现另外几个数据文件丢失,方法也是类似的,还原,恢复。


SQL> !cp /u02/ora11g/oradata/hot_bak/sysaux01.dbf? /u02/ora11g/oradata/TEST


SQL> !cp /u02/ora11g/oradata/hot_bak/undo* /u02/ora11g/oradata/TEST


SQL> recover datafile 2;
?Media recovery complete.
?SQL> recover datafile 3;
?Media recovery complete.


SQL> alter database open;


Database altered.


第三种场景是在停库的时候,删除了普通数据文件。这个时候操作还是存在一定的差别。
?我们还是手工破坏
[ora11g@oel1 TEST]$ rm data02.dbf
然后启库的时候肯定会报错。


SQL> startup
?ORACLE instance started.


Total System Global Area? 209235968 bytes
?Fixed Size? ? ? ? ? ? ? ? ? 1335528 bytes
?Variable Size? ? ? ? ? ? 125832984 bytes
?Database Buffers? ? ? ? ? 75497472 bytes
?Redo Buffers? ? ? ? ? ? ? ? 6569984 bytes
?Database mounted.
?ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
?ORA-01110: data file 4: '/u02/ora11g/oradata/TEST/data02.dbf'


?我们简单检查一下就会发现对应的表空间是DA

首页 上一页 1 2 下一页 尾页 1/2/2
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
分享到: 
上一篇基于时间点的不完全恢复的例子 下一篇Oracle 10g,11g中的数据库克隆安装

评论

帐  号: 密码: (新用户注册)
验 证 码:
表  情:
内  容: