分享
 
 
 

热备份原理分析

王朝other·作者佚名  2008-05-19
窄屏简体版  字體: |||超大  

我们都知道oracle的备份有几钟方式,冷备,热备,rman,imp等,我们注意到当我们采取热备的时候,需要对每个要备份的表空间置为backup模式。通常的热备脚本都是这样的

alter tablespace XXX begin backup;

cp XXX ....

alter tablespace XXX end backup;

(这里需要注意一点,oracle的最小存储单位是一个数据块,一个块的大小通常设置为8k,而操作系统的块通常是512bytes,这样的话一个oracle的数据由很多个操作系统的块组成。而且对于一个数据文件来说,它的所有块对应的操作系统的块并不是按顺序存储的,当运行cp

等操作系统命令时并不能指定从那个oracle数据块开始拷贝。)

当open数据库的时候,oracle会去比较控制文件中数据文件记录和数据文件头的checkpoint cnt,如果两者相同,则判断不需要介质恢复,如果不同,这时候oracle就会报某某文件需要介质恢复。然后拷贝回数据文件备份我们开始recover,这时候就从上次做备份时的scn开始恢复,运用日志,直到恢复结束。当cp数据文件时,比如说我们拷贝的第一个块可能是scn为100的数据块,当我们完成这个块的拷贝后,这个块有可能被别的进程多次修改,scn变为900。我们知道当数据库发生检查点时会去更新数据文件头和控制文件中的checkpoint scn,如果当我们在cp数据文件的同时发生了n次checkpoint,这时候数据文件头的scn可能被更新了很多次。这时候cp的进程去拷贝数据文件头所在的操作系统块,可能这个数据文件头的块因为被checkpoint了很多次导致它的scn为1000,这时候整个数据文件会出现不一致,当用这个备份文件去恢复时,恢复进程会从scn=1000开始恢复,这样的话开始那个scn=100的块将丢失从scn100-scn1000的数据,因为数据块并不应用scn在1000以前的日志,而且这样做的话可能出现一些数据块的corruption,所以不置成backup模式备份的话并不可取。当然,如果你能确保当cp的时候不发生checkpoint,或者你的操作系统块的大小不小于oracle的数据块大小,这些情况下不置backup mode拷贝出来的文件也是有效的。

现在我们知道了为什么不能不设置backup模式,下面来讲讲alter tablespace XXX begin backup做了什么?

当数据文件置于backup模式时,oracle会去锁定数据文件头,这时候数据库发生检查点的话将不会修改文件头的checkpoint scn,而只是增加checkpoint cnt,所以不管执行cp的时候操作系统块的拷贝顺序是如何,oracle总会从文件头的scn开始恢复,这样的话也就避免了数据丢失和数据块corruption.如果大家用的是rman来备份,那么就不会有这个问题,因为rman备份的时候rman会去对比数据块的头尾标志,如果发现不一致,那么它将会再去读这个块,直到读到一致的块才往备份集里写。

但是alter tablespace XXX begin backup带来的另一个问题是会导致产生多余的日志,通过一个小小的试验就可以证明这一点。

SQL> select name,value from v$sysstat where name='redo size';

NAME VALUE

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

redo size 43408

SQL> update test set a=a;

1 row updated.

SQL> commit;

Commit complete.

SQL> select name,value from v$sysstat where name='redo size';

NAME VALUE

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

redo size 44060

SQL> ALTER SYSTEM DUMP LOGFILE '/netappredo/redo05.log';

System altered.

一个update的动作产生44060-43408=652bytes的redo

把表空间置为backup mode

SQL> alter tablespace test begin backup;

Tablespace altered.

SQL> select name,value from v$sysstat where name='redo size';

NAME VALUE

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

redo size 44732

SQL> update test set a=a;

1 row updated.

SQL> commit;

Commit complete.

SQL> select name,value from v$sysstat where name='redo size';

NAME VALUE

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

redo size 53560

SQL> alter tablespace test end backup;

Tablespace altered.

一个update的动作产生53560-44732=8828bytes的redo

看看到底是记了些什么?

SQL> ALTER SYSTEM DUMP LOGFILE '/netappredo/redo05.log';

System altered.

REDO RECORD - Thread:2 RBA: 0x00004e.000000b0.0128 LEN: 0x01b0 VLD: 0x01

SCN: 0x0000.19ed24f7 SUBSCN: 1 06/29/2004 15:05:32

CHANGE #1 TYP:0 CLS:29 AFN:33 DBA:0x08400029 SCN:0x0000.19ed24f2 SEQ: 1 OP:5.2

...... (改动向量1,记载对undo header事务表的修改)

CHANGE #2 TYP:0 CLS:30 AFN:33 DBA:0x0840002e SCN:0x0000.19ed24f0 SEQ: 1 OP:5.1

...... (改动向量2,记载对undo block的修改)

CHANGE #3 TYP:2 CLS: 1 AFN:51 DBA:0x0cc0000f SCN:0x0000.19ed24e8 SEQ: 1 OP:11.5

KTB Redo (改动向量3,记载对数据块的修改,也就是在数据块上执行update test set a=a)

op: 0x11 ver: 0x01

op: F xid: 0x0007.001.00014ece uba: 0x0840002e.0859.38

Block cleanout record, scn: 0x0000.19ed24f7 ver: 0x01 opt: 0x02, entries follow...

itli: 1 flg: 2 scn: 0x0000.19ed24e8

KDO Op code: URP row dependencies Disabled

xtype: XA bdba: 0x0cc0000f hdba: 0x0cc0000b

itli: 2 ispac: 0 maxfr: 4858

tabn: 0 slot: 0(0x0) flag: 0x2c lock: 2 ckix: 0

ncol: 1 nnew: 1 size: 0

col 0: [ 2] c1 02

CHANGE #4 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:5.20

......(改动向量4,一些标记)

我们看到了正常的日志记录,此外还有些block cleanout及回滚段改变的日志记录,但是相比较不是backup模式的日志来说多了这一部分。

Log block image redo entry

Dump of memory from 0x0AE48820 to 0x0AE4A808

AE48820 00280001 00002C32 19ED24E6 1FE80000 [..(.2,...$......]

AE48830 00321F02 0CC00009 00210005 000307F1 [..2.......!.....]

AE48840 0840000E 0021100C 00002001 19ED24E8 [..@...!.. ...$..]

AE48850 001F0016 0001A94C 0840007C 000D0C08 [....L...|.@.....]

AE48860 00008000 19ED2468 00000000 00000000 [....h$..........]

AE48870 00020100 00160001 1F791F8C 00001F79 [..........y.y...]

AE48880 1F920002 0F88FFFF 0ED00F2C 0E180E74 [........,...t...]

AE48890 0D600DBC 0CA80D04 0BF00C4C 0B380B94 [..`.....L.....8.]

AE488A0 0A800ADC 09C80A24 0910096C 085808B4 [....$...l.....X.]

AE488B0 07A007FC 06E40744 06240684 056405C4 [....D.....$...d.]

......

这一部分是对更改的数据块做的一个镜像,把这个块完全记录到redo里面去了,但是为什么要这么做呢。

这就又牵扯到一个概念,'block split',当数据文件在备份cp时,因为oracle数据块和操作系统块的差异,一个数据块可能由16个操作系统块组成(8k 数据块,512bytes 系统块),这样的话可能出现一个数据块包含了几个不同版本的操作系统块,会导致数据块的不一致,所以在备份模式下如果有语句对备份块产生更新,那么oracle会先把当前块复制一份到redo,当恢复的时候如果碰到数据块不一致就从redo把这个镜像拷贝回去,然后在这个一致性的镜像开始恢复。 如果使用rman来备份可以避免产生过多的块,就像上面所说的,rman会去建议块的一致性,所以不用复制镜像块到日志。

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有