使用FLASHCOPY+数据库归档日志文件进行数据库不完整恢复技术实施方案(2 /2)

1.1.10 在主机上识别8000－8100等LUN,导入VG,设置lv的访问权限

#cfgmgr –v

# datapath query device

Total Devices : 6

DEV#: 0 DEVICE NAME: vpath0 TYPE: 2107900 POLICY: Optimized

SERIAL: 75TXXXX8000

DEV#: 1 DEVICE NAME: vpath1 TYPE: 2107900 POLICY: Optimized

SERIAL: 75TXXXX8001

DEV#: 2 DEVICE NAME: vpath2 TYPE: 2107900 POLICY: Optimized

SERIAL: 75TXXXX8002

DEV#: 3 DEVICE NAME: vpath3 TYPE: 2107900 POLICY: Optimized

SERIAL: 75TXXXX8100

DEV#: 4 DEVICE NAME: vpath4 TYPE: 2107900 POLICY: Optimized

SERIAL: 75TXXXX8101

DEV#: 5 DEVICE NAME: vpath5 TYPE: 2107900 POLICY: Optimized

SERIAL: 75TXXXX8102

#lspv

hdisk0 00c87badb8db2ba6 rootvg active

hdisk1 00c87bad75ee70a9 rootvg active

hdisk2 none None

。。。。。。

hdisk49 none None

vpath0 00c87badd701de12 None

vpath1 00c87badd701dff1 None

vpath2 00c87badd701e1a2 None

vpath3 00c87badd701e362 None

vpath4 00c87badd701e514 None

vpath5 00c87badd701e6de None

注意flashcopy 的目标盘与源盘的PVID是相同的，所以最好不要同时将源盘和目标盘都赋予主机访问。

# importvg -y testvg vpath0

testvg

# chown oracle:dba /dev/rora*

# chmod 755 /dev/rora*

# lsvg -l testvg

testvg:

LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT

ora_system raw 6 6 6 closed/syncd N/A

ora_sysaux raw 6 6 6 closed/syncd N/A

ora_data01 raw 30 30 6 closed/syncd N/A

ora_data02 raw 30 30 6 closed/syncd N/A

ora_data03 raw 30 30 6 closed/syncd N/A

ora_index01 raw 30 30 6 closed/syncd N/A

ora_index02 raw 30 30 6 closed/syncd N/A

ora_redo01 raw 6 6 6 closed/syncd N/A

ora_redo02 raw 6 6 6 closed/syncd N/A

ora_redo03 raw 6 6 6 closed/syncd N/A

ora_control02 raw 6 6 6 closed/syncd N/A

ora_control03 raw 6 6 6 closed/syncd N/A

ora_control01 raw 6 6 6 closed/syncd N/A

ora_temp01 raw 30 30 6 closed/syncd N/A

ora_undotbs01 raw 30 30 6 closed/syncd N/A

1.1.11 进行数据库恢复操作

1.1.11.1 启动数据库到mount状态(注意千万不要启动到open状态)

SQL> startup mount;

ORACLE instance started.

Total System Global Area 1073741824 bytes

Fixed Size 2101912 bytes

Variable Size 545262952 bytes

Database Buffers 524288000 bytes

Redo Buffers 2088960 bytes

Database mounted.

生成的Flashcopy目标盘相当于数据库的冷备份，使用flashcopy目标盘启动数据库到mount状态，应该没有任何问题。

启动到mount状态而不是open状态,是为了不更改数据文件的SCN。(曾经尝试启动数据库到open状态,然后进行后面的恢复,结果失败,分析一下原因,发现问题出在了启动数据库后,很多数据库文件的SCN发生了变化,导致与归档日志里的记录不吻合,从而导致恢复失败)

1.1.11.2 创建生成controlfile的trace文件,编辑创建控制文件的脚本

SQL> alter database backup controlfile to trace;

Database altered.

打开$ORACLE_BASE/admin/udump/目录下最新的trace文件,找出该文件中创建controlfile文件的脚本(注意选择resetlogs那一节的脚本).

$cd /oracle/admin/test1/udump

$more test1_ora_5570654.trc

……

CREATE CONTROLFILE REUSE DATABASE "TEST1" RESETLOGS ARCHIVELOG

MAXLOGFILES 30

MAXLOGMEMBERS 5

MAXDATAFILES 200

MAXINSTANCES 2

MAXLOGHISTORY 292

LOGFILE

GROUP 1 '/dev/rora_redo01' SIZE 256M,

GROUP 2 '/dev/rora_redo02' SIZE 256M,

GROUP 3 '/dev/rora_redo03' SIZE 256M

-- STANDBY LOGFILE

DATAFILE

'/dev/rora_system',

'/dev/rora_undotbs01',

'/dev/rora_sysaux',

'/dev/rora_data01',

'/dev/rora_data02',

'/dev/rora_index01',

'/dev/rora_index02'

CHARACTER SET ZHS16GBK

;

该trace文件中有两个地方存在创建controlfile的脚本，分别为noresetlogs和resetlogs，我们这里应该选择resetlogs的那段，如上所示。

1.1.11.3 关闭数据库

SQL> shutdown immediate;

ORA-01109: database not open

Database dismounted.

ORACLE instance shut down.

1.1.11.4 启动数据库到nomount状态,创建新的控制文件

SQL> startup nomount;

ORACLE instance started.

Total System Global Area 1073741824 bytes

Fixed Size 2101912 bytes

Variable Size 545262952 bytes

Database Buffers 524288000 bytes

Redo Buffers 2088960 bytes

SQL> CREATE CONTROLFILE REUSE DATABASE "TEST1" RESETLOGS ARCHIVELOG

2 MAXLOGFILES 30

3 MAXLOGMEMBERS 5

4 MAXDATAFILES 200

5 MAXINSTANCES 2

6 MAXLOGHISTORY 292

7 LOGFILE

8 GROUP 1 '/dev/rora_redo01' SIZE 256M,

9 GROUP 2 '/dev/rora_redo02' SIZE 256M,

10 GROUP 3 '/dev/rora_redo03' SIZE 256M

11 -- STANDBY LOGFILE

12 DATAFILE

13 '/dev/rora_system',

14 '/dev/rora_undotbs01',

15 '/dev/rora_sysaux',

16 '/dev/rora_data01',

17 '/dev/rora_data02',

18 '/dev/rora_index01',

19 '/dev/rora_index02'

20 CHARACTER SET ZHS16GBK

21 ;

Control file created.

SQL> select open_mode,checkpoint_change# from v$database;

OPEN_MODE CHECKPOINT_CHANGE#

MOUNTED 0

SQL> select checkpoint_change# from v$datafile;

CHECKPOINT_CHANGE#

454267

454267

。。。。。。

7 rows selected.

1.1.11.5 进行数据库恢复

SQL> recover database using backup controlfile until cancel;

ORA-00279: change 454517 generated at 05/18/2011 10:09:44 needed for thread 1

ORA-00289: suggestion : /archivelog/1_18_750759569.dbf

ORA-00280: change 454517 for thread 1 is in sequence #18

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

AUTO

ORA-00279: change 454599 generated at 05/18/2011 10:13:07 needed for thread 1

ORA-00289: suggestion : /archivelog/1_19_750759569.dbf

ORA-00280: change 454599 for thread 1 is in sequence #19

ORA-00278: log file '/archivelog/1_18_750759569.dbf' no longer needed for this

recovery

ORA-00279: change 454634 generated at 05/18/2011 10:13:49 needed for thread 1

ORA-00289: suggestion : /archivelog/1_20_750759569.dbf

ORA-00280: change 454634 for thread 1 is in sequence #20

ORA-00278: log file '/archivelog/1_19_750759569.dbf' no longer needed for this

recovery

ORA-00308: cannot open archived log '/archivelog/1_20_750759569.dbf'

ORA-27037: unable to obtain file status

IBM AIX RISC System/6000 Error: 2: No such file or directory

Additional information: 3

最终以找不到新的归档日志序列文件的错误提示结束,这属于正常的情况,因为ORACLE 会在auto方式下穷尽寻找,直至最后,然后报一个找不到下一个归档日志的错误。

SQL> alter database open resetlogs; ###以resetlogs的方式打开数据库，完成不完整恢复

Database altered.

1.1.12 检验数据库是否恢复到最新的数据状态.

u 检查恢复后的数据库SCN

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

------------------

454638 ####大于停库前的454267

u 检查特征表的记录

SQL> conn aidu/aidu****

Connected.

SQL> select count(1) from test01;

COUNT(1)

1024 ####与恢复前的数据记录数完全相同,恢复成功.

我们可以看到这里只恢复了1024条记录，即恢复到最后一个日志文件包含的内容，最后插入的1024条记录因为没有做日志切换，只保留在redo文件中，所以这里不能够恢复回来。本实验是不完整恢复的例子，redo文件的内容无法恢复回来。

1.2 总结

当我们开始使用IBM DS8100高端存储存放数据库数据时,我们可以使用存储的flash copy来获取某个时间点的数据。IBM DS8100的FLASH COPY 还支持增量备份,而且FLASH COPY的复制速度很快,复制工作直接在存储内部完成,不消耗网络的带宽.(笔者测试过,1.2T容量的在投运数据库，完成一次flashcopy，耗时1个小时零5分钟),而且FLASHCOPY 是随时都可以做的,不需要停止数据库和挂起数据库。

使用FLASHCOPY 进行数据库恢复，只需要将相应的FBVOL配置给主机访问，在主机端认到这些vpath，导入vg信息，设置lv访问属性，就可以启动数据库了，前后时间不超过10分钟。（如果使用rman进行恢复，1.2T的内容应该在4个小时以上）。而且结合本案例，我们可以使用FLASHCOPY +归档日志文件，将数据库恢复到最新的状态，用时20分种以内。