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

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

基础知识及讲解：http://blog.youkuaiyun.com/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号已经被冻结，

当备份过程中突然数据库崩溃，此时该块状态：数据块块头冻结，数据块一半已备份，另一半未备份，

这就是块撕裂 重新开启数据库需要对该块执行重新热备份。