冷备下模拟rm -rf *.dbf恢复案例

浏览数：19 / 时间：2015年06月12日

关于备份恢复一直是所有关系型数据库的重头戏。下面会介绍冷备数据库，并模拟破坏数据文件进行恢复数据库，并涉及到其他相关内容。
[oracle@localhost ~]$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.5 (Tikanga)

SQL> select * from v$version where rownum<2;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
首先介绍一下冷备份（完全脱机备份），需要把数据库shutdown后，粘贴复制就可了，先备份先：
SQL> shutdown immediate;
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。

[oracle@localhost orcl3939]$ cp *.dbf /home/oracle/beifeng
[oracle@localhost orcl3939]$ cp *.log /home/oracle/beifeng
[oracle@localhost orcl3939]$ cp *.ctl /home/oracle/beifeng
控制文件只需要备份一份就行了，因为是镜像文件，完全一样。
是不是很简单！
这种方式适合archivelog和noarchivelog,其中涉及到了几类文件：

logfile:v$log v$logfile
controlfile:v$controlfile
datafile:dba_data_files
temp files:dba_temp_files
其中的临时文件并不是我们备份的对象，因为备份文件可以理解成数据库的虚拟内存，如linux中，我们分区时，如果内存较小时，可以分配swap分区，作用是交换缓存数据,作为内存不足的一种选择而已。
关于archivelog和noarchivelog，生产环境中几乎都是archivelog：
SQL> archive log list;
数据库日志模式非存档模式
自动存档禁用
存档终点 USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列 424
当前日志序列 426

此时我的练习库是非归档模式，那我们启动归档模式：
SQL> startup mount;
ORACLE 例程已经启动。
SQL> alter database archivelog;
数据库已更改。

SQL> select log_mode from v$database;

LOG_MODE
------------
ARCHIVELOG

此时数据库已经是归档模式。

关于归档文件存放位置，看参数：

SQL> show parameter db_recover
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /u01/app/oracle/flash_recovery
_area
db_recovery_file_dest_size big integer 3852M

第一个参数是存放位置，第二个参数是该空间的大小。
flash_recovery _area目录是10g才有的，便于管理归档等文件。
我们可以修改db_recovery_file_dest：

SQL> alter system set db_recovery_file_dest =‘ ‘;
系统已更改。
SQL> show parameter db_recover
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string
db_recovery_file_dest_size big integer 3852M

此时归档文件存放的目录回到了10g之前：
SQL> show parameter log_archive_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest string
log_archive_dest_1 string
log_archive_dest_10 string
log_archive_dest_11 string
log_archive_dest_12 string
log_archive_dest_13 string
log_archive_dest_14 string
log_archive_dest_15 string
log_archive_dest_16 string
log_archive_dest_17 string
log_archive_dest_18 string
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_19 string
log_archive_dest_2 string
log_archive_dest_20 string
log_archive_dest_21 string
log_archive_dest_22 string
log_archive_dest_23 string
log_archive_dest_24 string
log_archive_dest_25 string
log_archive_dest_26 string
log_archive_dest_27 string
log_archive_dest_28 string
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_29 string
log_archive_dest_3 string
log_archive_dest_30 string
log_archive_dest_31 string
log_archive_dest_4 string
log_archive_dest_5 string
log_archive_dest_6 string
log_archive_dest_7 string
log_archive_dest_8 string
log_archive_dest_9 string

指定目录位置即可用，但是这样很不利于管理。

简介下SCN:System change number | System Commit Number 但是很多情况下理解成第一种更为准确。

SQL> select current_scn from v$database;
CURRENT_SCN
-----------
0
SQL> alter database open;
数据库已更改。
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
7232872
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
7232878
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
7232879
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
7232905
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
7232915
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
7232917
SCN是oracle的一种时钟机制，随时间而增加，每个数据库都有一个全局SCN,通过SCN oracle来维护数据库的一致性。SCN无处不在，resetlogs scn,checkpoint scn.......
除非数据库重建，否则永远不会为0，上面出现0，是因为数据库还没打开啦。
此时我们在sysY用户下：
SQL> show user;
USER 为 "SYS"

SQL> create table tt(id number,scn number);
表已创建。

SQL> insert into tt values(1,dbms_flashback.get_system_change_number);
已创建 1 行。
SQL> insert into tt values(2,dbms_flashback.get_system_change_number);
已创建 1 行。
SQL> commit;
提交完成。
SQL> select * from tt;
ID SCN
---------- ----------
1 7235265
2 7235294

通过查找tt,可以大致估算我们插入数据时的时间。
查看v$log:
SQL> select group#,status,archived,sequence#,first_change#,next_change# from v$log;
GROUP# STATUS ARC SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------------- --- ---------- ------------- ------------
1 INACTIVE YES 424 7179754 7189656
2 INACTIVE YES 425 7189656 7227701
3 CURRENT NO 426 7227701 2.8147E+14

有上述插入数据的SCN和目前日志的FIRST_CHANGE#知，上述数据的日志存放在当前日志文件中，也就是序列号为426。上述的FIRST_CHANGE#表示开始使用该组日志时的scn,
next_change#表示切换该组日志时的scn，也就是使用下一组日志的FIRST_CHANGE#。
分析一下status：
current:表示目前使用的日志，毫无疑问。
active:已经完成归档，日志文件已经写入磁盘，可能和该部分日志相对应的数据块的修改还没有写入磁盘，在内存里，所以该日志文件在数据库crash后恢复可能会用到。
inactive:此时已经完成归档，日志文件和对应修改的数据库已经写入磁盘。
由于这三组日志循环切换，产生的日志我们怎么标识呢，
这就是序列号重要的作用了：
SQL> alter system switch logfile;
系统已更改。
SQL> select name,thread#,sequence#,first_change#,next_change# from v$archived_log WHERE sequence# = 426;
NAME THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------- ---------- ------------- ------------
/u01/app/oracle/flash_recovery_area/ORCL3939/archivelog/2015_04_27/o1_mf_1_426_bmvr5f9j_.arc 1 426 7227701 7236412
看上面的 name,sequence#，知道序列用来标识归档文件的作用了吧。
THREAD#：因为此时数据库是在单实例下，一个数据库对应一个实例：
所以此时thread#可以理解为实例编号。
在RAC下，此时的THREAD#对应的是节点号。

我们现在模拟：
SQL> insert into tt values(3,dbms_flashback.get_system_change_number
2 );
已创建 1 行。
SQL> commit;
提交完成。
SQL> alter system switch logfile;
系统已更改。
SQL> insert into tt values(4,dbms_flashback.get_system_change_number
2 );
已创建 1 行。
SQL> COMMIT;
提交完成。
SQL> alter system switch logfile;
系统已更改。
SQL> insert into tt values(5,dbms_flashback.get_system_change_number);
已创建 1 行。
SQL> COMMIT;
提交完成。
SQL> alter system switch logfile;
系统已更改。

SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- -------------- ------------ --------------
1 1 433 52428800 512 1 NO CURRENT 7239074 27-4月 -15 2.8147E+14
2 1 431 52428800 512 1 YES ACTIVE 7239029 27-4月 -15 7239057 27-4月 -15
3 1 432 52428800 512 1 YES ACTIVE 7239057 27-4月 -15 7239074 27-4月 -15

我们此时删除数据文件：
[oracle@localhost ~]$ cd /u01/app/oracle/oradata/orcl3939
[oracle@localhost orcl3939]$ rm -rf *.dbf

然后把之前备份的数据文件移到/u01/app/oracle/oradata/orcl3939，如果全部移动的话，则数据库可以打开了，之前对于表tt的操作数据完全丢失
[oracle@localhost beifeng]$ cp *.dbf /u01/app/oracle/oradata/orcl3939

SQL> startup mount;

ORACLE 例程已经启动。
Total System Global Area 351522816 bytes
Fixed Size 1336484 bytes
Variable Size 297798492 bytes
Database Buffers 46137344 bytes
Redo Buffers 6250496 bytes
数据库装载完毕。

此时打开到mount状态是完全可以的。

SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-01113: 文件 1 需要介质恢复
ORA-01110: 数据文件 1: ‘/u01/app/oracle/oradata/orcl3939/system01.dbf‘

此时我们恢复数据库：
SQL> recover database;
ORA-00279: 更改 7233493 (在 04/27/2015 13:51:53 生成) 对于线程 1 是必需的 ORA-00289:
建议:
/u01/app/oracle/flash_recovery_area/ORCL3939/archivelog/2015_04_27/o1_mf_1_426_b
mvr5f9j_.arc
ORA-00280: 更改 7233493 (用于线程 1) 在序列 #426 中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}

此时会用到归档日志：/u01/app/oracle/flash_recovery_area/ORCL3939/archivelog/2015_04_27/o1_mf_1_426_b
mvr5f9j_.arc

序列号为：426,
更改时的scn：7233493
指定日志分析：
suggest:表示用的归档日志文件位置就是建议的位置
filename:表示归档后的日志若你修改位置，此时你需要指定位置
auto:表示数据库自动恢复
cancle:只恢复到该步骤即停止

下面我们按回车键选择suggest：

ORA-00279: 更改 7236412 (在 04/27/2015 15:09:33 生成) 对于线程 1 是必需的 ORA-00289:
建议:
/u01/app/oracle/flash_recovery_area/ORCL3939/archivelog/2015_04_27/o1_mf_1_427_b
mvrj552_.arc
ORA-00280: 更改 7236412 (用于线程 1) 在序列 #427 中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00279: 更改 7236929 (在 04/27/2015 15:15:17 生成) 对于线程 1 是必需的 ORA-00289:
建议:
/u01/app/oracle/flash_recovery_area/ORCL3939/archivelog/2015_04_27/o1_mf_1_428_b
mvrooz2_.arc
ORA-00280: 更改 7236929 (用于线程 1) 在序列 #428 中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00279: 更改 7237015 (在 04/27/2015 15:18:13 生成) 对于线程 1 是必需的 ORA-00289:
建议:
/u01/app/oracle/flash_recovery_area/ORCL3939/archivelog/2015_04_27/o1_mf_1_429_b
mvs29ny_.arc
ORA-00280: 更改 7237015 (用于线程 1) 在序列 #429 中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}

是不是这样很慢，我这样是让大家看到每一步用到的归档日志文件，那下面我们使用auto：
AUTO
ORA-00279: 更改 7237261 (在 04/27/2015 15:24:57 生成) 对于线程 1 是必需的 ORA-00289:
建议:
/u01/app/oracle/flash_recovery_area/ORCL3939/archivelog/2015_04_27/o1_mf_1_430_b
mvvf00h_.arc
ORA-00280: 更改 7237261 (用于线程 1) 在序列 #430 中
已应用的日志。
完成介质恢复。

此时我们查找数据文件的scn（全部来自控制文件，shutdown之后保留的），以及数据头的scn（数据头的scn是旧的，来自拷贝回来的数据文件头）

要想数据库打开，则两者scn相等：
SQL> select file#,checkpoint_change# from v$datafile;

FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 7259884
2 7259884
3 7259884
4 7259884
5 7259884
6 7259884
7 7259884
8 7259884
9 7259884
10 6980281
11 7259884
FILE# CHECKPOINT_CHANGE#
---------- ------------------
12 7259884
已选择12行。

SQL> select file#,checkpoint_change# from v$datafile_header;

FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 7259884
2 7259884
3 7259884
4 7259884
5 7259884
6 7259884
7 7259884
8 7259884
9 7259884
10 6980281
11 7259884

FILE# CHECKPOINT_CHANGE#
---------- ------------------
12 7259884

已选择12行。

现在两者已经对应相等了，此时可以打开数据库。

SQL> alter database open;

数据库已更改。

SQL> select * from tt;

ID SCN
---------- ----------
1 7235265
2 7235294
3 7239015
4 7239050
5 7239064

数据已经全部恢复回来。

郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。

冷备下模拟rm -rf *.dbf恢复案例