RMAN备份过程中会写脏块吗？

最新推荐文章于 2022-01-13 14:59:36 发布
最新推荐文章于 2022-01-13 14:59:36 发布
阅读量772 收藏
点赞数
分类专栏： ORACLE--安装备份恢复
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u013820054/article/details/38962117
版权
一次在群里看见有人讨论：
数据库在做rman备份的时候比如是10点整，数据块的scn号被锁定在10点这个时间点，这时候用户在10：05做操作的时候产生的数据是向数据块里写？还是只生成日志 等rman完了再写。
自己试验探讨一下（不知对否，互相交流）
思路：
创建一个每秒向一张表插入一行记录的job，并且每行记录alter system checkpoint确保触发DBWR；
1：执行JOB、2：开始备份、3、新环境用该备份恢复
如果备份过程中不写脏块，开始备份时锁定所有数据块SCN不在增大，因为备份有UNDO表空间，那么restore until开始备份时间，可以执行。

如果备份过程中一直在写脏块，随着备份时间增加，数据块SCN不断增大，那么只有restore until 备份结束时间，应用日志，在可以执行。

1、创建1张表
create table system_scn_time(scn varchar2(10),scn_time varchar2(40),systime varchar2(30)) tablespace system;

2、创建存储过程
alter session set nls_date_format = 'yyyy-dd-mm hh24-MI-Ss';

create or replace procedure proc_test as 
begin
  insert into system_scn_time(scn,scn_time,systime)                                                                            
  select dbms_flashback.get_system_change_number, SCN_TO_TIMESTAMP(dbms_flashback.get_system_change_number),sysdate from dual;
  commit;
  execute immediate 'alter system checkpoint';
end;
/
3、新建JOB每秒执行一次JOB
VAR JOB NUMBER
BEGIN
  DBMS_JOB.SUBMIT
    ( job      => :job
    ,what      => 'proc_test;'
    ,next_date => sysdate
    ,interval  => 'sysdate + 1/ (24*60*60*5)'
    ,no_parse  => TRUE
    );
END;
/
（有个疑问interval不论我设置'sysdate + 1/ (24*60*60*5)'还是'sysdate + 1/ (24*60*60)'，间隔基本都为5秒）

SYS@ fyl>select job from dba_jobs;
       JOB
----------
      4001
      4002
        42
       
exec dbms_job.run(42);
EXEC DBMS_JOB.BROKEN(42,FALSE);
EXEC DBMS_JOB.remove(42);
4、数据库备份0级
[fyl]数据库[0]级备份开始[2014/08/31 15:44:05] ...  
[fyl]数据库[0]级备份结束[2014/08/31 15:45:39] ...  

SYS@ fyl>select count(*) from system_scn_time;

  COUNT(*)
----------
        39

SYS@ fyl>select * from system_scn_time;
SCN                            SCN_TIME                                 SYSTIME
------------------------------ ---------------------------------------- ------------------------------
650472                         31-AUG-14 03.43.55.000000000 PM          2014-31-08 15-43-56
650479                         31-AUG-14 03.44.00.000000000 PM          2014-31-08 15-44-01
650500                         31-AUG-14 03.44.04.000000000 PM          2014-31-08 15-44-06      ----15-44-05开始备份
650508                         31-AUG-14 03.44.13.000000000 PM          2014-31-08 15-44-15
650516                         31-AUG-14 03.44.19.000000000 PM          2014-31-08 15-44-21
650525                         31-AUG-14 03.44.25.000000000 PM          2014-31-08 15-44-26
650532                         31-AUG-14 03.44.29.000000000 PM          2014-31-08 15-44-31
650540                         31-AUG-14 03.44.34.000000000 PM          2014-31-08 15-44-36
650550                         31-AUG-14 03.44.40.000000000 PM          2014-31-08 15-44-41      
650557                         31-AUG-14 03.44.45.000000000 PM          2014-31-08 15-44-46
650565                         31-AUG-14 03.44.56.000000000 PM          2014-31-08 15-44-56
650573                         31-AUG-14 03.44.59.000000000 PM          2014-31-08 15-45-01
650581                         31-AUG-14 03.45.05.000000000 PM          2014-31-08 15-45-06
650589                         31-AUG-14 03.45.10.000000000 PM          2014-31-08 15-45-11
650596                         31-AUG-14 03.45.16.000000000 PM          2014-31-08 15-45-17
650602                         31-AUG-14 03.45.20.000000000 PM          2014-31-08 15-45-22
650612                         31-AUG-14 03.45.28.000000000 PM          2014-31-08 15-45-28
650618                         31-AUG-14 03.45.33.000000000 PM          2014-31-08 15-45-33
650634                         31-AUG-14 03.45.37.000000000 PM          2014-31-08 15-45-38        ---15-45-39结束备份
650661                         31-AUG-14 03.45.42.000000000 PM          2014-31-08 15-45-43
650701                         31-AUG-14 03.45.48.000000000 PM          2014-31-08 15-45-48
650709                         31-AUG-14 03.45.52.000000000 PM          2014-31-08 15-45-53
650716                         31-AUG-14 03.45.58.000000000 PM          2014-31-08 15-45-58

5、恢复备份，resetlog打开
恢复前手动切几个日志，然后删除，防止恢复的时候应用online redo
手动指定时间点
RMAN> run{
2> set until time "to_date('2014-08-31 15:45:00','yyyy-mm-dd hh24:mi:ss')";
3> restore database;
4> recover database;
5> }

executing command: SET until clause

Starting restore at 31-AUG-14
using channel ORA_DISK_1

creating datafile file number=1 name=+ORADATA/fyl/datafile/system.260.845725985
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/31/2014 16:09:28
ORA-01180: can not create datafile 1
ORA-01110: data file 1: '+ORADATA/fyl/datafile/system.260.845725985'
尝试过15-45-39之前任意时间都报错 

RMAN> run{
2> set until time "to_date('2014-08-31 15:45:39','yyyy-mm-dd hh24:mi:ss')";
3> restore database;
4> recover database;
5> }

executing command: SET until clause

Starting restore at 31-AUG-14
using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to +ORADATA/fyl/datafile/system.260.845725985
channel ORA_DISK_1: restoring datafile 00002 to +ORADATA/fyl/datafile/sysaux.261.845726017
channel ORA_DISK_1: restoring datafile 00003 to +ORADATA/fyl/datafile/undotbs1.262.845726043
channel ORA_DISK_1: restoring datafile 00004 to +ORADATA/fyl/datafile/users.264.845726073
channel ORA_DISK_1: reading from backup piece /oracle/rman_fyl/20140831_0/fyl_1_60_1sphbau5.dbf
channel ORA_DISK_1: piece handle=/oracle/rman_fyl/20140831_0/fyl_1_60_1sphbau5.dbf tag=TAG20140831T154405
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:01:25
Finished restore at 31-AUG-14

Starting recover at 31-AUG-14
using channel ORA_DISK_1

starting media recovery

channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=4
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=5
channel ORA_DISK_1: reading from backup piece /oracle/rman_fyl/20140831_0/fyl_1_65_21phbb17.arc
channel ORA_DISK_1: piece handle=/oracle/rman_fyl/20140831_0/fyl_1_65_21phbb17.arc tag=TAG20140831T154539
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/oracle/arch_fyl/1_4_857051384.dbf thread=1 sequence=4
archived log file name=/oracle/arch_fyl/1_5_857051384.dbf thread=1 sequence=5
unable to find archived log
archived log thread=1 sequence=6   ---手动切的日志，然后删除了
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/31/2014 16:11:13
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 6 and starting SCN of 650648

RMAN> alter database open resetlogs;
alter日志 

Sun Aug 31 16:00:32 2014
Checker run found 5 new persistent data failures
Sun Aug 31 16:09:48 2014
Full restore complete of datafile 4 +ORADATA/fyl/datafile/users.264.845726073.  Elapsed time: 0:00:06 
  checkpoint is 650498                             -------650498开始备份时间点对于的SCN由快照控制文件记录
  last deallocation scn is 551013               -------？没找到什么意思~
Sun Aug 31 16:10:20 2014
Full restore complete of datafile 3 +ORADATA/fyl/datafile/undotbs1.262.845726043.  Elapsed time: 0:00:38 
  checkpoint is 650498                           -------650498开始备份时间点对于的SCN由快照控制文件记录
  last deallocation scn is 627897             -------？
  Undo Optimization current scn is 624066        -------？
Sun Aug 31 16:10:52 2014
Full restore complete of datafile 2 +ORADATA/fyl/datafile/sysaux.261.845726017.  Elapsed time: 0:01:10 
  checkpoint is 650498                           -------650498开始备份时间点对于的SCN由快照控制文件记录
  last deallocation scn is 648869               -------？
Sun Aug 31 16:11:07 2014
Full restore complete of datafile 1 +ORADATA/fyl/datafile/system.260.845725985.  Elapsed time: 0:01:25 
  checkpoint is 650498                         -------650498开始备份时间点对于的SCN由快照控制文件记录
  last deallocation scn is 650368                      -------？
  Undo Optimization current scn is 624066        -------？
Sun Aug 31 16:11:10 2014
alter database recover datafile list clear
6、查看system_scn_time表

SYS@ fyl>select count(*) from system_scn_time;
  COUNT(*)
----------
        24
SCN                            SCN_TIME                                 SYSTIME
------------------------------ ---------------------------------------- ------------------------------
650451                         31-AUG-14 03.43.40.000000000 PM          2014-31-08 15-43-42
650458                         31-AUG-14 03.43.45.000000000 PM          2014-31-08 15-43-46
650465                         31-AUG-14 03.43.50.000000000 PM          2014-31-08 15-43-51
650472                         31-AUG-14 03.43.55.000000000 PM          2014-31-08 15-43-56
650479                         31-AUG-14 03.44.00.000000000 PM          2014-31-08 15-44-01
650500                         31-AUG-14 03.44.04.000000000 PM          2014-31-08 15-44-06             ----15-44-05开始备份
650508                         31-AUG-14 03.44.13.000000000 PM          2014-31-08 15-44-15
650516                         31-AUG-14 03.44.19.000000000 PM          2014-31-08 15-44-21
650525                         31-AUG-14 03.44.25.000000000 PM          2014-31-08 15-44-26
650532                         31-AUG-14 03.44.29.000000000 PM          2014-31-08 15-44-31
650540                         31-AUG-14 03.44.34.000000000 PM          2014-31-08 15-44-36
650550                         31-AUG-14 03.44.40.000000000 PM          2014-31-08 15-44-41
650557                         31-AUG-14 03.44.45.000000000 PM          2014-31-08 15-44-46
650565                         31-AUG-14 03.44.56.000000000 PM          2014-31-08 15-44-56
650573                         31-AUG-14 03.44.59.000000000 PM          2014-31-08 15-45-01
650581                         31-AUG-14 03.45.05.000000000 PM          2014-31-08 15-45-06
650589                         31-AUG-14 03.45.10.000000000 PM          2014-31-08 15-45-11
650596                         31-AUG-14 03.45.16.000000000 PM          2014-31-08 15-45-17
650602                         31-AUG-14 03.45.20.000000000 PM          2014-31-08 15-45-22
650612                         31-AUG-14 03.45.28.000000000 PM          2014-31-08 15-45-28
650618                         31-AUG-14 03.45.33.000000000 PM          2014-31-08 15-45-33
650634                         31-AUG-14 03.45.37.000000000 PM          2014-31-08 15-45-38         ---15-45-39结束备份
650908                         31-AUG-14 04.12.32.000000000 PM          2014-31-08 16-12-33        --resetlogs open后job的插入
650929                         31-AUG-14 04.12.37.000000000 PM          2014-31-08 16-12-37
7、RMAN备份是一种物理的备份，它直接去读取数据块，因此rman是块级别的备份。从备份的那个时间点开始rman将锁定此刻的数据文件信息，也就是说只是备份数据文件到此刻的信息为止。但是rman并不锁定数据文件的使用，也就是说rman的备份，不是数据库一致性状态的备份，由于rman备份是块级别的，它只备份控制文件中已经存在的数据块，同时数据库还在运行之中，那么就有可能会出现某些已经提交的操作，但是dbwn还没有写入数据文件，或者已经被rman备份过的数据块，又重新被修改，等等。这些信息rman备份都不会记录，也是rman无法记录的。但是记录这些信息的是redo file，所以在rman完毕建议马上执行日志切换，然后备份归档日志，因为在rman恢复过程中，对于inconsistent backup，RMAN要靠这些已经归档的redo file信息恢复和保持数据库的一直状态。
由此，我们可以可以看出，其实归档文件中真正有用的是从rman备份开始到rman备份结束时刻系统产生的归档日志。同时rman在恢复的时候，restore database完毕后，会依次利用归档日志和联机日志进行完全恢复。此时利用的这些归档就是从rman备份开始到rman备份结束产生的归档日志。

8、这么验证麻烦了，假设RMAN备份时,DBWR不写脏块的话，随着DML语句执行，BUFFER CACHE一定会找不到free budder，数据库肯定就hang住了。所以肯定会写的！

Two手揣兜
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
oracle 脏块 空闲块,详解Oracle数据库LRU算法：LRU链、脏块与脏LRU链
weixin_29147539的博客
04-15 538
概述所谓的LRU(Least recently used)算法的基本概念是当内存的剩余的可用空间不够时,缓冲区尽可能的先保留使用者最常使用的数据,换句话说就是优先清除”较不常使用的数据”,并释放其空间.之所以”较不常使用的数据”要用引号是因为这里判断所谓的较不常使用的标准是人为的、不严格的.所谓的MRU(Most recently used)算法的意义正好和LRU算法相反。Oracle在高速缓...
Oracle 12c备份恢复-RMAN工具技术手册
12-27
Oracle 12c 备份恢复-RMAN 工具技术手册 本文档旨在提供 Oracle 12c 备份恢复的技术手册，主要介绍 RMAN 工具的概念、架构、备份类型和使用方法。 一、RMAN 概念 RMAN（Recovery Manager）是 Oracle 推荐的备份和...
关于 RMAN 备份 数据块 一致性的讨论
热门推荐
David Dai -- Focus on Oracle
08-10 1万+
<br /> <br />今天和 杭州恒生 的一个朋友讨论一个RMAN 在备份时数据块一致性的问题。<br /> <br />关于RMAN 的备份原理参考blog：<br />    RMAN 系列（一）---- RMAN 体系结构概述 <br />http://blog.csdn.net/tianlesoftware/archive/2010/06/09/5659701.aspx<br /> <br /> <br /><br /> <br />先看官方文档上的一段话：<br /> <br />Consis
oracle 脏块 空闲块,Oracle 内存结构
weixin_34219634的博客
04-15 261
内存结构Oracle内存，进程与数据库的图 sga：系统全局区，用来存放操作的数据，库缓存，数据字典等控制信息的内存区域，pga:进程全局区，服务进程专用的内存区域，大多数内容非共享uga：用来保存用户的会话信息(如打开的游标，执行语句的私有变量)，如果使用专用服务器，则uga在pga中分配，使用共享服务器，则uga在sga中分配。 1 sga组成结构sga是用来缓存数据库数据及控制信息的内存结构...
检查数据块是否是脏块
dnil27295的博客
07-30 127
转载于:https://www.cnblogs.com/iyoume2008/p/4690656.html
oracle 数据库脏块,PostgreSQL缓存脏块的一个奇怪现象
weixin_30868807的博客
04-16 159
这是我在写程序过程中发现的，一个不应该为脏的块被标记为脏，PostgreSQL 9.3.1。出现步骤(用UPDATE语句也同样出现)创建表并插入一条数据create table t1(c1 integer);insert into t1 values(1);此时postgres=# select * from pg_buffercache where isdirty;bufferid | relf...
rman备份脚本和rman增量备份脚本分享
09-10
Oracle的恢复管理器(RMAN)是Oracle数据库系统中的一个重要工具，用于数据库的备份和恢复操作。本文将详细介绍RMAN备份脚本和RMAN增量备份脚本的使用方法，帮助需要进行数据库维护的朋友理解和应用。 首先，我们来看...
rman备份策略
07-13
自己用过的备份策略，简单实用，包含了rman0级备份，1级和2级备份的脚本。rman0级备份 #!/bin/bash #chkinst.sh export EDITOR=vi export ORACLE_BASE=/u01/app/oracle ...
Oracle rman 增量备份
最新发布
08-02
Oracle RMAN（Recovery Manager）是Oracle数据库管理系统中一个强大的备份和恢复工具，它提供了多种备份策略，其中增量备份是企业级数据保护的关键组成部分。在Oracle数据库环境中，增量备份允许数据库管理员只备份...
写完的脏块是这么处理的
weixin_34392906的博客
07-06 126
从LRUW写和从检查点队列写区别是什么呢？为什么这种紧急情况写，就要从LRUW写呢？ 回答这个问题，主要要看写完的脏块会如何处理。 如果脏块从检查点队列中写到磁盘，脏块在LRU、LRUW链表的位置，不会任何变化，这一点很容易证明： SQL> select dbms_rowid.ROWID_RELATIVE_FNO(rowid),dbms_rowid.rowid...
关于oracle 检查点队列 脏块的理解
敖尔其楞的专栏
12-20 619
之前能理解lruw上面挂的是脏块，其实一个脏块是同时挂到了lruw和检查点队列上的，只不过在检查点队列上只有一个块的版本，就是最早修改的时候的那个版本，这个块上有lrba的信息，在检查点发生的时候，会记录rba，在本次与上次的2个rba中间的数据块会被刷到文件中。
记一次AIX平台存储脏块处理
老A的自留地，欢迎加微信交流，微信号zhoul777
08-06 465
客户数据库出现问题，归档日志不可读，具体表现为 [quote]$ du -sm /arch du: /arch/1_418_722029122.dbf: 路径名中的文件或目录不存在。 du: /arch/1_419_722029122.dbf: 路径名中的文件或目录不存在。 du: /arch/1_41_722029122.dbf: 路径名中的文件或目录不存在。 du: /arch/1_...
（整理）RMAN备份详解
s_156的博客
06-08 1万+
网上查到一篇RMAN工具的使用，这篇文档记录写的比较详细，自己目前的工作环境反复使用的几率不高，有些时候就容易忘，特此记录下来。 –====================== – RMAN备份详解 –====================== 一、数据库备份与RMAN备份的概念 1.数据库完全备份：按归档模式分为归档和非归档 归档模式： 打开状态，属于非一致性备份 关闭状态，可以分为一致性和非一致性 非归档模式： 打开状态，非一致性备份无效 关闭状态，一致性备份，非一致性备份不被推荐 2.RMAN备份
给你的rman备份集加上密码锁
zhenglib18的专栏
06-01 678
数据的安全越来越重要,不是说你的生产库安全，你的数据就一定安全了，rman备份也是泄露数据的一个重要地方,如果别人拿到了你的备份集,一样等同入侵了你的生产库。为了rman备份的安全，最简单方式就是使用set encryption方式在rman备份过程中设置密码,需要版本为10.2及其以后企业版版,另外如果需要备份到带库只能使用oracle自己的osb(Oracle Secure Backup),注
RMAN-06094
喝醉酒的小白
01-13 2219
表空间为read only
ORACLE 只读数据文件备份与恢复
coco3600的博客
02-03 170
第一章只读数据文件备份与恢复 BLOG文档结果图： 只读数据文件是只读表空间的数据文件，其数据块包括...
oracle跨平台备份恢复,12C RMAN 传输表空间及跨平台备份恢复PDB
weixin_35038173的博客
04-07 421
在12C中传输表空间变得非常简单，一条语句搞定。还可以通过RMAN跨平台备份恢复数据，另外还可以通过增量备份传输表空间减少应用停机时间。在本机上做了个表空间传输的例子，建一个表空间，RMAN备份，再删除表空间，然后恢复表空间：1、创建表空间，并初始化表SQL>showuser;USERis"C##AWEN"SQL>selectnamefromv$datafile;NAM...
基于时间不完全恢复之rman篇
chen5131421的专栏
08-06 6661
基于时间不完全恢复之rman篇

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值