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

本文介绍了Oracle用户管理备份过程,包括将表空间置于热备份模式,利用操作系统工具进行文件拷贝,以及在备份过程中如何处理块撕裂问题,确保数据的安全性。
摘要由CSDN通过智能技术生成

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号已经被冻结,
当备份过程中突然数据库崩溃,此时该块状态:数据块块头冻结,数据块一半已备份,另一半未备份,
这就是块撕裂  重新开启数据库需要对该块执行重新热备份。





  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
毕业设计,基于SpringBoot+Vue+MySQL开发的公寓报修管理系统,源码+数据库+毕业论文+视频演示 现代经济快节奏发展以及不断完善升级的信息化技术,让传统数据信息的管理升级为软件存储,归纳,集中处理数据信息的管理方式。本公寓报修管理系统就是在这样的大环境下诞生,其可以帮助管理者在短时间内处理完毕庞大的数据信息,使用这种软件工具可以帮助管理人员提高事务处理效率,达到事半功倍的效果。此公寓报修管理系统利用当下成熟完善的Spring Boot框架,使用跨平台的可开发大型商业网站的Java语言,以及最受欢迎的RDBMS应用软件之一的MySQL数据库进行程序开发。公寓报修管理系统有管理员,住户,维修人员。管理员可以管理住户信息和维修人员信息,可以审核维修人员的请假信息,住户可以申请维修,可以对维修结果评价,维修人员负责住户提交的维修信息,也可以请假。公寓报修管理系统的开发根据操作人员需要设计的界面简洁美观,在功能模布局上跟同类型网站保持一致,程序在实现基本要求功能时,也为数据信息面临的安全问题提供了一些实用的解决方案。可以说该程序在帮助管理者高效率地处理工作事务的同时,也实现了数据信息的整体化,规范化与自动化。 关键词:公寓报修管理系统;Spring Boot框架;MySQL;自动化;VUE
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值