1.1 应用场景
1.1.1 应用场景条件
u 使用FLASHCOPY功能,生成一个全库数据的时间点拷贝。
u 拥有从那个时间点开始的所有的数据库归档日志文件。
u 数据库使用的存储完全损坏，无法恢复，数据库当机。
1.1.2 应用场景目标
使用FLASHCOPY 生成的存储的时间点数据，进行数据库的恢复，步骤和原理和使用数据库冷备份（cold backup）进行数据库恢复是一样的。但这样的恢复只能够恢复到生成flashcopy的时间点。当我们还有很多这个时间点后归档日志文件的前提下，如何才能恢复更多的数据呢？
使用FLASHCOPY生成的时间点全库数据和时间点后的数据库归档日志文件，使用特殊的方法，进行数据库恢复，数据库恢复到最后一个归档日志文件确定的时间点。
[@more@]1.1 实验内容
1.1.1 实验总体步骤
实验总体步骤如下：
1. 启动数据库(归档模式)，数据库数据文件是建立在DS8100的5000－5102等 FBVOL上。
2. 记录数据库SCN,进行FLASHCOPY,源FBVOL为5000-5102，目标FBVOL为8000－8102。
3. 在数据库上添加特征记录，并进行归档日志切换。
4. 关闭数据库，删除原来的存储设备，模拟灾难发生。
5. 检查FLASHCOPY的进度，直至FLASHCOPY 完成复制工作。
6. 在DS8100上，取消主机访问5000－5102的路径，增加主机访问8000－8102的路径
7. 在主机上识别8000－8100等FBVOL,导入VG,设置lv的访问权限。
8. 进行数据库恢复。
9. 检查特征记录，检验数据库恢复是否成功。
1.1.2 实验环境总体情况描述
1.1.2.1 主机总体情况
u 主机:IBM P570 小型机
# oslevel -s
6100-06-03-1048
#lsvg –p testvg
testvg:
PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION
vpath0 active 159 116 32..00..20..32..32
vpath1 active 159 116 32..00..20..32..32
vpath2 active 159 116 32..00..20..32..32
vpath3 active 159 116 32..00..20..32..32
vpath4 active 159 116 32..00..20..32..32
vpath5 active 159 116 32..00..20..32..32
# datapath query device
Total Devices : 6
DEV#: 0 DEVICE NAME: vpath0 TYPE: 2107900 POLICY: Optimized
SERIAL: 75TXXXX5000
==========================================================================
Path# Adapter/Hard Disk State Mode Select Errors
0 fscsi0/hdisk2 OPEN NORMAL 425 0
1 fscsi0/hdisk8 OPEN NORMAL 385 0
2 fscsi0/hdisk14 OPEN NORMAL 388 0
3 fscsi0/hdisk20 OPEN NORMAL 394 0
4 fscsi1/hdisk26 OPEN NORMAL 422 0
5 fscsi1/hdisk32 OPEN NORMAL 415 0
6 fscsi1/hdisk38 OPEN NORMAL 395 0
7 fscsi1/hdisk44 OPEN NORMAL 406 0
DEV#: 1 DEVICE NAME: vpath1 TYPE: 2107900 POLICY: Optimized
SERIAL: 75TXXXX5001
。。。。。。
DEV#: 2 DEVICE NAME: vpath2 TYPE: 2107900 POLICY: Optimized
SERIAL: 75TXXXX5002
。。。。。。
DEV#: 3 DEVICE NAME: vpath3 TYPE: 2107900 POLICY: Optimized
SERIAL: 75TXXXX5100
。。。。。。
DEV#: 4 DEVICE NAME: vpath4 TYPE: 2107900 POLICY: Optimized
SERIAL: 75TXXXX5101
。。。。。。
DEV#: 5 DEVICE NAME: vpath5 TYPE: 2107900 POLICY: Optimized
SERIAL: 75TXXXX5102
。。。。。。
1.1.2.2 存储总体情况
存储:IBM DS8100
#lsfbvol -l
test_p0_02 5000 Online Normal Normal 2107-900 FB 512 P0 standard
test_p0_03 5001Online Normal Normal 2107-900 FB 512 P0 Standard
test_p0_04 5002 Online Normal Normal 2107-900 FB 512 P0 standard
test_p1_02 5100 Online Normal Normal 2107-900 FB 512 P1standard
test_p1_03 5101 Online Normal Normal 2107-900 FB 512 P1standard
test_p1_04 5102 Online Normal Normal 2107-900 FB 512 P1standard
fltest_01 8000 Online Normal Normal 2107-900 FB 512 P0 Standard
fltest_02 8001 Online Normal Normal 2107-900 FB 512 P0 Standard
fltest_03 8002 Online Normal Normal 2107-900 FB 512 P0 Standard
fltest_01 8100 Online Normal Normal 2107-900 FB 512 P0 Standard
fltest_02 8100 Online Normal Normal 2107-900 FB 512 P0 Standard
fltest_03 8102 Online Normal Normal 2107-900 FB 512 P0 Standard
其中：5000－5102是flashcopy的源盘，8000－8102是flashcopy的目标盘。每个FBVOL都是20G大小。
1.1.2.3 数据库总体情况
数据库：Oracle 10.2.0.5
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Prod
数据库数据文件都是裸设备格式。
SQL> select file#,name,bytes/1024/1024 from v$datafile;
FILE# NAME BYTES/1024/1024
1 /dev/rora_system 700
2 /dev/rora_undotbs01 3500
3 /dev/rora_sysaux 700
4 /dev/rora_data01 3500
5 /dev/rora_data02 3500
6 /dev/rora_index01 3500
7 /dev/rora_index02 3500
SQL> select * from v$controlfile;
NAME IS_ BLOCK_SIZE FILE_SIZE_BLKS
/dev/rora_control01 NO 16384 386
/dev/rora_control02 NO 16384 386
/dev/rora_control03 NO 16384 386
数据库运行在归档模式下
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /archivelog
Oldest online log sequence 3
Next log sequence to archive 5
Current log sequence 5
SQL> select username,default_tablespace from dba_users;
USERNAME DEFAULT_TABLESPACE
OUTLN SYSTEM
SYS SYSTEM
SYSTEM SYSTEM
AIDU YD_DATA
TSMSYS SYSTEM
1.1.3 记录数据库的SCN,检查特征表是否存在
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
454267
SQL> select count(1) from aidu.test01;
select count(1) from aidu.test01
ERROR at line 1:
ORA-00942: table or view does not exist
此时还没有建立特征表，所以报对象不存在的错误，这是正常的。
1.1.4 将数据库设置为begin backup状态
笔者曾经尝试过三个场景，只有使用begin backup场景，实验才成功。
场景一：数据库不做任何特殊操作（不执行suspend和不执行begin backup）
场景一结果：数据库无法使用归档日志进行不完整恢复，恢复时报file #1需要恢复的错误，alert日志里报：
Recovering data file 1 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command.
不过数据库在不做任何特殊操作的前提下，直接执行flashcopy，然后使用目标盘是可以成功启动数据库到open状态，可以实现时间点的数据库恢复。
场景二：在FLASHCOPY 执行前，先执行数据库的suspend操作。
场景二结果：数据库无法使用归档日志进行不完整恢复，报file #1需要恢复的错误，alert日志里报：
Recovering data file 1 from a fuzzy file. If not the current file it might be an online backup taken without entering the begin backup command.
不过数据库在执行了suspend的前提下，使用目标盘是可以成功启动数据库到open状态，可以实现时间点的数据库恢复。
场景三：在FLASHCOPY执行前，先执行数据库的begin backup操作。
场景三结果：数据库可以使用归档日志进行不完整恢复；当然也可以实现时间点的恢复。所以本技术方案采用这种场景。
笔者在研究的过程中，按照上述场景顺序一一进行实验的。刚开始以为flashcopy和数据库冷备份是完全一样的（笔者在windows环境里已经测试过使用数据库冷备份与归档日志文件进行数据库的不完全恢复，比较成功，详见笔者的博客文章：http://djb1008.itpub.net/post/42280/517938），但多次测试的结果都是失败的。于是笔者测试将数据库的I/O挂起（执行ALTER SYSTEM SUSPEND命令），即测试场景二，以为I/O都停止的情况下，再做flashcopy,恢复工作一定可以完成，测试结果和场景一完全相同，无法进行时间点的恢复。在metalink上就错误信息’Recovering data file 1 from a fuzzy file’进行搜索，找到一篇关于IBM ESS flashcopy的文章，ID=300255.1,该文中提到了多卷组复制时需要执行begin backup的命令，将数据库设置在online backup 模式，即场景三。通过设置数据库进入online backup模式，然后再执行flashcopy，就可以使用flashcopy和数据库归档日志文件进行数据库不完整恢复了。
SQL> alter system checkpoint;
SQL>alter database begin backup;
System altered.
1.1.5 在DS8100存储上登录DSCLI管理界面，开始进行FLASHCOPY操作
执行begin backup命令，将数据库设置为online backup模式后，就可以执行存储的flashcopy命令了，当flashcopy命令（mkflash）执行后，不用等到整个复制工作完成，而是马上可以在数据库端执行end backup命令，将数据库退出online backup模式，以减少对业务系统的影响。
数据库设置为online backup模式后，执行mkflash命令，生成flashcopy的对应关系，这个操作基本上是1秒左右就可以完成，存储端马上就可以显示’FlashCopy pair successfully created.’信息,执行mkflash命令前，需要保证数据库是处于online backup模式；当mkflash命令使用约1秒种左右的时间，完成了flashcopy pair关系的建立，启动了后台的复制工作后，就不再需要数据库处于online backup模式了，数据库可以马上退出online backup模式，而不影响flashcopy的运行，同样也不影响后面的flashcopy+归档日志的不完整恢复。为什么执行完mkflash命令，需要立即将数据库退出online backup模式呢？
数据库进入online backup模式后，数据库数据文件被锁定，不写入任何内容，数据库仍然不间断运行，对数据库用户没有任何影响，只是变化的数据被写入到redo日志文件中，对日志文件的开销比较大，所以需要尽快退出online backup模式，退出online backup模式时，数据库会自动将变化量恢复到数据文件中，如果处于online backup模式时间过长，这种应用变化也会造成数据库的短时间的性能瓶颈。
dscli> mkflash -freeze -cp 5000-5002:8000-8002 5100-5102:8100-8102
Date/Time: 2011年5月17日 下午03时13分01秒 IBM DSCLI Version: 5.3.1.172 DS: IBM.2107-75TXXXX
CMUC00137I mkflash: FlashCopy pair 5000:8000 successfully created.
CMUC00137I mkflash: FlashCopy pair 5001:8001 successfully created.
CMUC00137I mkflash: FlashCopy pair 5002:8002 successfully created.
CMUC00137I mkflash: FlashCopy pair 5100:8100 successfully created.
CMUC00137I mkflash: FlashCopy pair 5101:8101 successfully created.
CMUC00137I mkflash: FlashCopy pair 5102:8102 successfully created.
dscli> unfreezeflash 50 51
Date/Time: 2011年5月17日 下午03时13分16秒 IBM DSCLI Version: 5.3.1.172 DS: IBM.2107-75TXXXX
CMUC00172I unfreezeflash: FlashCopy consistency group for logical subsystem 50: successfully reset.
CMUC00172I unfreezeflash: FlashCopy consistency group for logical subsystem 51: successfully reset.
立刻退出online backup模式
SQL> alter database end backup; #### 在mkflash没有完成的时候就运行这个命令。
System altered.
不断查看flashcopy的复制进度
dscli> lsflash -l 5000-8200
Date/Time: 2011年5月17日 下午03时13分32秒 IBM DSCLI Version: 5.3.1.172 DS: IBM.2107-75TXXXX
ID SrcLSS SequenceNum Timeout ActiveCopy Recording Persistent Revertible SourceWriteEnabled TargetWriteEnabled BackgroundCopy OutOfSyncTracks DateCreated Da
teSynced State AllowTgtSE
5000:8000 50 0 60 Enabled Enabled Enabled Disabled Enabled Enabled Enabled 287952 Tue May 17 15:31:38 CST 2011 Tue May 17 15:31:38 CST 2011 Valid Disabled
5001:8001 50 0 60 Enabled Enabled Enabled Disabled Enabled Enabled Enabled 287976 Tue May 17 15:31:38 CST 2011 Tue May 17 15:31:38 CST 2011 Valid Disabled
5002:8002 50 0 60 Disabled Enabled Enabled Disabled Enabled Enabled Enabled 327680 Tue May 17 15:31:38 CST 2011 Tue May 17 15:31:38 CST 2011 Valid Disabled
5100:8100 51 0 60 Enabled Enabled Enabled Disabled Enabled Enabled Enabled 287136 Tue May 17 15:31:38 CST 2011 Tue May 17 15:31:38 CST 2011 Valid Disabled
5101:8101 51 0 60 Enabled Enabled Enabled Disabled Enabled Enabled Enabled 288000 Tue May 17 15:31:38 CST 2011 Tue May 17 15:31:38 CST 2011 Valid Disabled
5102:8102 51 0 60 Disabled Enabled Enabled Disabled Enabled Enabled Enabled 327680 Tue May 17 15:31:38 CST 2011 Tue May 17 15:31:38 CST 2011 Valid Disabled
复制的空间大小为120G，DS8100完成120G的复制工作，大概需要7分钟。在flashcopy复制数据期间可以同步进行下面的插入数据的操作。
1.1.6 插入实验数据，生成两个归档日志文件,记载SCN
SQL>conn aidu/*******
SQL>create table test01(id number(10,2),name varchar2(200),primary key(id));
SQL> insert into test01(id,name) values(1,’test for restore db from full db copy’);
已创建 1 行。
SQL> insert into test01(id,name) select id+(select count(1) from test01),name from test01;
已创建 1 行。
SQL> /
已创建2行。
SQL> /
已创建4行。
SQL> /
已创建8行。
SQL> /
已创建16行。
SQL> /
已创建32行。
SQL> /
已创建64行。
SQL> commit;
提交完成。
SQL> select count(1) from test01;
COUNT(1)
----------
128
在表test01里插入了128条记录后，进行一次归档日志的切换，将这个变化保存到归档日志文件中。
SQL> conn / as sysdba
Connected.
SQL> alter system switch logfile;
System altered.
SQL> host
$ ls -lt /archivelog
total 148552
-rw-r----- 1 oracle oinstall 76055552 May 17 15:22 1_18_750759569.dbf
drwxr-xr-x 2 oracle dba 256 May 05 04:09 lost+found
可以看到在/archivelog目录下增加了一个归档日志文件,文件名称为：1_18_750759569.dbf
再次向aidu.test01表中插入记录
SQL>conn aidu/*******
Connected.
SQL> insert into test01(id,name) select id+(select count(1) from test01),name from test01;
128 rows created.
SQL> /
256 rows created.
SQL> /
512 rows created.
SQL> select count(1) from test01;
COUNT(1)
1024
SQL> conn / as sysdba
Connected.
SQL> alter system switch logfile;
System altered.
SQL> host
$ ls -lt /archivelog
total 148784
-rw-r----- 1 oracle oinstall 118784 May 17 15:24 1_19_750759569.dbf
-rw-r----- 1 oracle oinstall 760555 May 17 15:22 1_18_750759569.dbf
drwxr-xr-x 2 oracle dba 256 May 05 04:09 lost+found
可以看到在/archivelog目录下增加了一个归档日志文件,文件名称为：1_19_750759569.dbf
SQL>alter system switch logfile;
System altered.
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
453645
SQL> select first_change#,next_change#,name,sequence# from v$archived_log;
FIRST_CHANGE# NEXT_CHANGE# NAME SEQUENCE#
------------- ------------ --------------------------------------------- ----------
453962 453994 /archivelog/1_17_750759569.dbf 17
453994 454599 /archivelog/1_18_750759569.dbf 18
454599 454634 /archivelog/1_19_750759569.dbf 19
1.1.7 检查FLASHCOPY的进度，直至FLASHCOPY 完成复制
检查mkflash命令是否完成，看到下面的结果就表示复制完成了。
dscli> lsflash -l 1000-9000
Date/Time: 2011年5月18日 上午10时17分07秒 IBM DSCLI Version: 5.3.1.172 DS: IBM.2107-75TC601
CMUC00234I lsflash: No Flash Copy found.
1.1.8 关闭数据库,模拟灾难发生
1.1.8.1 插入最后的特征记录，停止数据库运行
SQL> conn aidu/aidutest
Connected.
SQL> insert into test01(id,name) select id+(select count(1) from test01),name from test01;
1024 rows created.
SQL> commit;
Commit complete.
SQL> conn / as sysdba
Connected.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
最后插入1024条记录，但不切换archivelog，只是保留在redo文件中。Redo文件的内容在本实验中将无法恢复。
1.1.8.2 卸载和删除VG,删除相关hdisk,vpath等设备
# varyoffvg testvg
# exportvg testvg
# rmdev -dl fcs0 -R
。。。。。。
hdisk25 deleted
sfwcomm0 deleted
fscsi0 deleted
fcs0 deleted
# rmdev -dl fcs1 -R
fcnet1 deleted
。。。。。。
sfwcomm1 deleted
fscsi1 deleted
fcs1 deleted
# rmdev -dl dpo -R
vpath0 deleted
vpath1 deleted
vpath2 deleted
vpath3 deleted
vpath4 deleted
vpath5 deleted
dpo deleted
# lspv
hdisk0 00c87badb8db2ba6 rootvg active
hdisk1 00c87bad75ee70a9 rootvg active
# lsvg
rootvg
磁盘主机中只有rootvg，保存数据库数据的VG被删除，模拟了发生了存储损坏的灾难情况。
1.1.9 在DS8100上，取消主机访问5000－5102的路径，增加主机访问8000－8102的路径
dscli> chvolgrp -action remove -volume 5000-5002,5100-5102 V4
Date/Time: 2011年5月17日 下午04时00分49秒 IBM DSCLI Version: 5.3.1.172 DS: IBM.2107-75TXXXX
CMUC00031I chvolgrp: Volume group V4 successfully modified.
dscli> chvolgrp -action add -volume 8000-8002,8100-8102 V4
Date/Time: 2011年5月17日 下午04时01分11秒 IBM DSCLI Version: 5.3.1.172 DS: IBM.2107-75TXXXX
CMUC00031I chvolgrp: Volume group V4 successfully modified.
未完，下一章节见http://djb1008.itpub.net/post/42280/518102
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/32980/viewspace-1050092/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/32980/viewspace-1050092/
扫一扫
1686
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
