2008年1月17日星期四

Oracle学习笔记20080115和20080116

今天做了两个不同的实验,首先我建立了一张test1的表,插入2行数据,然后直接在OS下cp出来,然后shutdown了以后,删除原有的那个atu表空间,启动了以后startup了就发现缺少文件,但是restore做了一下就是把cp出来的东西在cp回去,发觉还是启动不了,应该是做的冷备份,没有做其他任何动作,没有recover修复,所以不明白,最后索性做了次全恢复。这点不明白了,难道是我开了归档模式的缘故?但是归档模式下也不应该会这样啊。第二次做了一个回复,同上的步骤,提示无法找到该表空间的时候,找到他的file#,然后做一次alter database datafile .. offline drop;继续alter database open;这个以后数据库就能起来但是没有atu这个表空间,于是乎在cp回来,修复下recover datafile..;然后alter database datafile .. online;(..表示的是改datafile的号码),然后做下select是和cp出去的时候是一样的。其实很奇怪,为什么这么说呢,因为有归档日志的缘故,所以你做回复后肯定是你在commit的时候是一样的。

20080116
非归档模式下,冷备份直接将备份的文件restore就可以,归档模式下需要把该丢失的表空间设为offline drop,然后restore以后再设为online,其中alter system switch logfile是切换日志文件,但是既然alter system archive log current就可以了可以回复单个tablespace,单个datafile或者整个。

说明:
1、不完全恢复最好备份所有的数据,冷备份亦可,因为恢复过程是从备份点往后恢复的,如果因为其中一个数据文件的时间戳(SCN)大于要恢复的时间点,那么恢复都是不可能成功的。
2、不完全恢复有三种方式,过程都一样,仅仅是recover命令有所不一样,这里用基于时间的恢复作为示例。recover database until time '某个时间'
3、不完全恢复之后,都必须用resetlogs的方式打开数据库,建议马上再做一次全备份,因为resetlogs之后再用以前的备份恢复是很难了。
4、以上是在删除之前获得时间,但是实际应用中,很难知道删除之前的实际时间,但可以采用大致时间即可,或可以采用分析日志文件(logmnr),取得精确的需要恢复的时间。
5、一般都是在测试机后备用机器上采用这种不完全恢复,恢复之后导出/导入被误删的表回生产系统
基于RMAN的回复获得SCN 删除测试表,在删除之前,便于测试,继续插入数据并应用到归档,并获取删除前的scn号
SQL> select max(ktuxescnw * power(2, 32) + ktuxescnb) scn from x$ktuxe;
开始恢复到改变点SCN 31014
RMAN> run{
2> allocate channel c1 type disk;
3> restore database;
4> recover database until scn 31014;
5> sql 'ALTER DATABASE OPEN RESETLOGS';
6> release channel c1;
7> }
说明:
1、RMAN也可以实现不完全恢复,方法比OS备份恢复的方法更简单可靠

2、RMAN可以基于时间,基于改变与基于日志序列的不完全恢复,基于日志序列的恢复可以指定恢复到哪个日志序列,如
run {
allocate channel ch1 type disk;
allocate channel ch2 type 'sbt_tape';
set until logseq 1234 thread 1;
restore controlfile to '$ORACLE_HOME/dbs/cf1.f' ;
replicate controlfile from '$ORACLE_HOME/dbs/cf1.f';
alter database mount;
restore database; recover database; s
ql "ALTER DATABASE OPEN RESETLOGS";
}

3、与所有的不完全恢复一样,必须在mount下,restore所有备份数据文件,需要resetlogs

4、基于改变的恢复比基于时间的恢复更可靠,但是可能也更复杂,需要知道需要恢复到哪一个改变号(SCN),在正常生产中,获取SCN的办法其实也有很多,如查询数据库字典表(V$archived_log or v$log_history),或分析归档与联机日志(logmnr)等。

没有评论: