oracle热备份用户管理备份之块撕裂

oracle热备份-----用户管理备份

基础知识及讲解：http://blog.csdn.net/wanghui5767260/article/details/20627639

用户管理备份：是指用户通过将表空间置于热备份模式，然后通过操作系统工具进行拷贝，拷贝结束后表空间热备份模式。

1.表空间单独存盘

2.冻结文件头 其他块继续使用此时拷贝只有文件头是好块

3.改变了日志的行为

实验步骤：
1. 创建一个带有序列号的大表作为测试表 tyger
2. 没有开启表空间热备模式
① 查看当前的日志产生量
② 更新测试表中的第3行数据，并查看日志产生量
③ 更新完第3行数据产生的日志量 新的日志产生量-旧的日志产生量
3. 开启表空间热备模式

① 在次更新第3行数据，并查看日志产生量
② 对比开启热备模式更新操作产生的日志 会发现产生大量日志
③ 更新第10000行数据，并查看日志产生量
④ 对比发现 更新操作也产生了大量的日志
⑤ 更新第10001行数据，并查看日志产生量
⑥ 发现这次更新操作反而产生了很少的日志

1. 创建一个带序列号的大表tyger，这样相邻行都会在一个块里，序列号相距比较远的就不会在同一个块中

SYS@ORCL>create table tyger tablespace users as select rownum rn,o.*

2 from dba_objects o;

Table created.

2. 查看当前日志产生量（没有开启表空间热备模式）

SYS@ORCL>select ms.statistic#,name,value

2 from v$mystat ms,v$statname sn

3 where ms.statistic#=sn.statistic# and name='redo size';

STATISTIC# NAME VALUE

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

134 redo size
12245956

3. 更行 表tyger 中的第3行数据

SYS@ORCL>update tyger set object_id=99999 where rn=3;

1 row updated.

SYS@ORCL>commit;

Commit complete.

4.查看更新第3行数据后的日志产生量

SYS@ORCL>select ms.statistic#,name,value

2 from v$mystat ms,v$statname sn

3 where ms.statistic#=sn.statistic# and name='redo size';

STATISTIC# NAME VALUE

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

134 redo size
12246604

5. 计算更新第3行产生的日志量

SYS@ORCL>select 12246604-12245956 from dual;

12246604-12245956

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

648 //未开启热备模式

6. 开启users表空间热备模式

SYS@ORCL>alter tablespace users begin backup;

Tablespace altered.

7. 继续更新第3行的ID

SYS@ORCL>update tyger set object_id=88888 where rn=3;

1 row updated.

SYS@ORCL>commit;

Commit complete.

8.查看当前的日志产生量

SYS@ORCL>select ms.statistic#,name,value

2 from v$mystat ms,v$statname sn

3 where ms.statistic#=sn.statistic# and name='redo size';

STATISTIC# NAME VALUE

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

134 redo size
12256856

9. 计算在开启热备模式后 更新第3行数据产生的日志量
（明显高于没有开启热备模式的日志量10252 >> 648）

SYS@ORCL>select 12256856-12246604 from dual;

12256856-12246604

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

10252 //开启热备模式后产生大量的日志量

10. 更新第10000行的ID查看更新后的日志量

SYS@ORCL>update tyger set object_id=77777 where rn=10000;

1 row updated.

SYS@ORCL>commit;

Commit complete.

SYS@ORCL>select ms.statistic#,name,value

2 from v$mystat ms,v$statname sn

3 where ms.statistic#=sn.statistic# and name='redo size';

STATISTIC# NAME VALUE

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

134 redo size 12265660

11. 计算更新了第10000行后的日志产生量

SYS@ORCL>select 12265660-12256856 from dual;

12265660-12256856

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

8804 //首次更新第10000行产生大量日志量

12. 继续更新第10001行的数据查看日志产生量

SYS@ORCL>update tyger set object_id=98765 where rn=10001;

1 row updated.

SYS@ORCL>select ms.statistic#,name,value

2 from v$mystat ms,v$statname sn

3 where ms.statistic#=sn.statistic# and name='redo size';

STATISTIC# NAME VALUE

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

134 redo size 12266140

13. 此时发现更新完第10000行后继续更新第10001行数据日志量很少

SYS@ORCL>select 12266140-12265660 from dual;

12266140-12265660

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

480 //再次更新第10001行产生很少的日志量

结论：

通过用户管理备份方式备份数据文件时，会将需要备份的数据文件头部的SCN号冻结，但是其他块还是好块，可以继续写入数据，更新10000行数据时将所在数据块头部冻结，所以会产生大量日志，但是更新10001行数据时，此时的数据文件头部已经被冻结，所以产生的日志量会很少。所以通过热备-用户管理备份方式
改变了日志的行为。



图中所示：对于一个正在进行热备--用户管理备份的数据块，此时的数据块块头的SCN号已经被冻结，
当备份过程中突然数据库崩溃，此时该块状态：数据块块头冻结，数据块一半已备份，另一半未备份，
这就是块撕裂 重新开启数据库需要对该块执行重新热备份。