用户管理的热备份恢复

前天太忙了，没得时间写blog，今天一早弄完所有的事情就来更新了！昨天看了eygle的关于oracle中用户管理的热备份恢复，自己动手试了一下 成功恢复！
alter tablespace users begin backup
host copy d:oracleproduct10.2.0oradatatestusers01.dbf d:users01.dbf
表空间热备，这个时候我们对数据库的修改都会产生过多的redo log，是因为产生了split block，oracle为了解决split block而要在日志中记录数据块的前镜像。
可以让表空间分别处于
alter tablespace users begin backup
alter tablespace users end backup
查看下面的具体的m-n的值
select a.statistic#,a.sid,a.value from v$mystat a,v$statname b
where a.statistic#=b.statistic# and b.name='redo size'
此时value等于m
update ashuang.test_os_backup set id=2 where id=1
commit

select a.statistic#,a.sid,a.value from v$mystat a,v$statname b
where a.statistic#=b.statistic# and b.name='redo size'
此时value等于n
此时热备期间关于my session也就是dml产生redo size等于m-n
如果从原理的角度来分析就是由于os下面的拷贝数据文件时，oracle很可能往此数据文件dbwn写数据，如果涉及到数据块的修改，数据文件中的数据块就很可能包含一个是os block的数据块，另一部门是os拷贝后数据文件中修改的数据块。
此时oracle的redo log就会维护数据块的前镜像，这样如果在恢复的时候出现split block分裂块，就能通过前镜像来覆盖备份。
关于热备份期间的redo log就不讨论了，现在os下面的拷贝已经结束
alter tablespace users end backup
此时在users下面建立测试表
create table test_os_backup
(id number,
name varchar2(10))
tablespace users
然后insert values
insert into test_os_backup values(1,'test001');
commit;
insert into test_os_backup values(2,'test002');
commit;
此时由于是测试库，switch logfile发生的不是很平常，手动交换
alter system switch logfile
来个4 5次，注意如果太过平凡的日志交换，可能会发生检查点没有完成，此时oracle就会把资源都给dbwn进程让其把需要覆盖的日志中的所有维护的关于重做记录的脏块缓存写进数据文件，也就是oracle中的等待事件。
如果是生产库这个就需要我们进一步用statspack等来查看具体数据库的瓶颈了，例如增加日志组，增大dbwn，但是dbwn一般是和cpu个数对等的，所以一般考虑增加日志组。
日志交换几次后，我们的test_os_backup的信息已经不再联机日志中了，而是放在归档日志中，此时我们再来一个
insert into test_os_backup values(3,'test003')
commit;
然后关闭数据库shutdown immediate
在os上面的d:oracleproduct10.2.0oradatatestusers01.dbf删除掉。
此时重启数据库
startup nomount 需要spfile或者pfile参数文件来启动数据库实例，分配sga
alter database mount 需要控制文件来定位数据文件和日志文件
alter database open 打开数据文件和日志文件
此时到open状态时数据库报缺少数据文件users01.dbf
先从os下把备份的d:users01.dbf数据文件放置在原数据文件位置，此时由于备份的数据文件的scn和数据文件和控制文件scn不一致，需要介质恢复。
recover database
。。。
d:oracleproduct10.2.0flash_recovery_areatestarchivelog01arc00187_0748801584.001
上面用到了归档日志恢复
此时altersid.ora警告日志中有关于恢复的具体信息。
ALTER DATABASE RECOVER database
Thu Aug 04 11:19:07 2011
Media Recovery Start
ORA-279 signalled during: ALTER DATABASE RECOVER database ...
Thu Aug 04 11:19:26 2011
ALTER DATABASE RECOVER CONTINUE DEFAULT
Thu Aug 04 11:19:26 2011
Media Recovery Log D:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG01ARC00187_0748801584.001
Thu Aug 04 11:19:27 2011
Recovery of Online Redo Log: Thread 1 Group 3 Seq 188 Reading mem 0
Mem# 0: D:ORACLEPRODUCT10.2.0ORADATATESTREDO03.LOG
Thu Aug 04 11:19:27 2011
Recovery of Online Redo Log: Thread 1 Group 1 Seq 189 Reading mem 0
Mem# 0: D:ORACLEPRODUCT10.2.0ORADATATESTREDO01.LOG
Thu Aug 04 11:19:28 2011
Recovery of Online Redo Log: Thread 1 Group 4 Seq 190 Reading mem 0
Mem# 0: D:ORACLEPRODUCT10.2.0ORADATATESTREDO04.LOG
。。。。。。
上面用到了归档日志和联机重做日志用于数据库恢复，此时我们就可以alter database open
select * from test_os_backup
可以查到数据已经恢复完整。
这是用户管理的热备份用于恢复数据库，还有一个就是关于oracle管理的热备份恢复了，rman由于知识点过多，等俺整理一段时间然后再拿出来与大家分享。不过热备份的原理确实一样的，就是用备份来还原，用redo log和archivelog辅助完成完整的数据库恢复。

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25362835/viewspace-1053427/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25362835/viewspace-1053427/