ORACLE数据库冷备的数据恢复_行业资讯_山东DATAHELP数据恢复中心

数据恢复资讯

联系我们

济南市山大路157号华强电子世界三楼Q3059，Q3060室

传真：0531-67757760

行业资讯

ORACLE数据库冷备的数据恢复

发布时间：2016/8/21 0:04:53 来源：阅读：81

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 中
指定日志: {=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 中
指定日志: {=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 中
指定日志: {=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 中
指定日志: {=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

数据已经全部恢复回来。

数据恢复资讯

传真：0531-67757760

关于我们
公司介绍 组织机构 企业文化 服务理念

数据恢复服务
服务器数据恢复 RAID存储数据恢复 数据库数据恢复 非线编视频恢复

数据恢复资讯
行业资讯 公司新闻

技术中心
服务器数据恢复 数据库数据恢复 虚拟化数据恢复 块存储数据恢复 硬盘数据恢复

加入我们
员工福利 人才招聘

数据恢复资讯

传真：0531-67757760

关于我们 公司介绍 组织机构 企业文化 服务理念

数据恢复服务 服务器数据恢复 RAID存储数据恢复 数据库数据恢复 非线编视频恢复

数据恢复资讯 行业资讯 公司新闻

技术中心 服务器数据恢复 数据库数据恢复 虚拟化数据恢复 块存储数据恢复 硬盘数据恢复

加入我们 员工福利 人才招聘

关于我们
公司介绍组织机构企业文化服务理念

数据恢复服务
服务器数据恢复 RAID存储数据恢复数据库数据恢复非线编视频恢复

数据恢复资讯
行业资讯公司新闻

技术中心
服务器数据恢复数据库数据恢复虚拟化数据恢复块存储数据恢复硬盘数据恢复

加入我们
员工福利人才招聘