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

最新推荐文章于 2022-01-13 14:59:36 发布
最新推荐文章于 2022-01-13 14:59:36 发布
阅读量831 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： ORACLE--安装备份恢复
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/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住了。所以肯定会写的！

20、RMAN配置与数据库恢复全解析
assembly8low的博客
07-07 21
本文深入解析了Oracle数据库中RMAN的配置与连接方法，以及数据库恢复的两大类型——崩溃恢复和介质恢复。文章涵盖了恢复过程中的关键术语、数据库启动阶段、崩溃/实例恢复步骤、介质恢复操作流程、恢复场景分析、恢复策略制定等内容，旨在帮助DBA掌握数据库恢复的核心知识，提升应对数据库故障的能力。通过合理配置RMAN和制定恢复策略，可以有效保障数据库的安全性与稳定性。
RMAN系列（一）RMAN体系结构概述
长亭路
04-08 294
原 RMAN 系列（一）---- RMAN 体系结构概述https://blog.youkuaiyun.com/tianlesoftware/article/details/5659701版权声明： https://blog.youkuaiyun.com/tianlesoftware/article/details/5659701 一． 服务器管理恢复 恢复管理器, Recovery Manager, 简陈 RMAN。 ...
oracle 脏块 空闲块,详解Oracle数据库LRU算法：LRU链、脏块与脏LRU链
weixin_29147539的博客
04-15 652
概述所谓的LRU(Least recently used)算法的基本概念是当内存的剩余的可用空间不够时,缓冲区尽可能的先保留使用者最常使用的数据,换句话说就是优先清除”较不常使用的数据”,并释放其空间.之所以”较不常使用的数据”要用引号是因为这里判断所谓的较不常使用的标准是人为的、不严格的.所谓的MRU(Most recently used)算法的意义正好和LRU算法相反。Oracle在高速缓...
关于 RMAN 备份 数据块 一致性的讨论
David Dai -- Focus on Oracle
08-10 1万+
<br /> <br />今天和 杭州恒生 的一个朋友讨论一个RMAN 在备份时数据块一致性的问题。<br /> <br />关于RMAN 的备份原理参考blog：<br />    RMAN 系列（一）---- RMAN 体系结构概述 <br />http://blog.youkuaiyun.com/tianlesoftware/archive/2010/06/09/5659701.aspx<br /> <br /> <br /><br /> <br />先看官方文档上的一段话：<br /> <br />Consis
oracle 脏块 空闲块,Oracle 内存结构
weixin_34219634的博客
04-15 325
内存结构Oracle内存，进程与数据库的图 sga：系统全局区，用来存放操作的数据，库缓存，数据字典等控制信息的内存区域，pga:进程全局区，服务进程专用的内存区域，大多数内容非共享uga：用来保存用户的会话信息(如打开的游标，执行语句的私有变量)，如果使用专用服务器，则uga在pga中分配，使用共享服务器，则uga在sga中分配。 1 sga组成结构sga是用来缓存数据库数据及控制信息的内存结构...
检查数据块是否是脏块
dnil27295的博客
07-30 166
转载于:https://www.cnblogs.com/iyoume2008/p/4690656.html
oracle 数据库脏块,PostgreSQL缓存脏块的一个奇怪现象
weixin_30868807的博客
04-16 232
这是我在写程序过程中发现的，一个不应该为脏的块被标记为脏，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工作原理
lucky-laoA
08-06 3971
Rman备份与还原 推荐的oracle官方文档http://tahiti.oracle.com 需要翻墙的技术文档资源http://www.slideshare.net 恢复管理器, Recovery Manager, 简陈 RMAN。 RMAN 实现是服务器管理恢复（Server Managed Recovery： SMR）。SMR 是一种数据库执行所需要的操作以确保自身备份成功的能力，依
Rman系列专题（一）·····体系结构
weixin_44167712的博客
12-26 496
Rman体系结构rman体系结构图1 rman核心及组成2 Rman与数据库权限3 Rman信息库（元数据）来源及位置3.1 控制文件3.2 恢复目录4 Rman块备份的优点5 快速闪回区(FRA) rman体系结构图 1 rman核心及组成 RMAN要进行备份的数据库叫做目标数据库。 RMAN是一个客户端程序，需要建立到目标数据库的客户端连接，并在目标数据库上创建对应的服务器进...
Oracle知识精华：存储过程与RMAN操作解析
DBWR负责将数据缓冲区（data buffer cache）中的脏块（已修改但未写回磁盘的块）写入数据文件。它被触发的条件主要有： - DBWR超时，大约3秒未写入 - 系统内无额外的空缓冲区以存放新数据 通过这些基础知识的...
写完的脏块是这么处理的
weixin_34392906的博客
07-06 173
从LRUW写和从检查点队列写区别是什么呢？为什么这种紧急情况写，就要从LRUW写呢？ 回答这个问题，主要要看写完的脏块会如何处理。 如果脏块从检查点队列中写到磁盘，脏块在LRU、LRUW链表的位置，不会任何变化，这一点很容易证明： SQL> select dbms_rowid.ROWID_RELATIVE_FNO(rowid),dbms_rowid.rowid...
关于oracle 检查点队列 脏块的理解
敖尔其楞的专栏
12-20 666
之前能理解lruw上面挂的是脏块，其实一个脏块是同时挂到了lruw和检查点队列上的，只不过在检查点队列上只有一个块的版本，就是最早修改的时候的那个版本，这个块上有lrba的信息，在检查点发生的时候，会记录rba，在本次与上次的2个rba中间的数据块会被刷到文件中。
记一次AIX平台存储脏块处理
老A的自留地，欢迎加微信交流，微信号zhoul777
08-06 520
客户数据库出现问题，归档日志不可读，具体表现为 [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_...
数据文件丢失的恢复（改变目录）
clhljaa02293633的博客
08-26 171
报错信息： SQL> startup ORACLE instance started. Total System Global Area 849530880 bytes Fixed Size ...
（整理）RMAN备份详解
热门推荐
s_156的博客
06-08 1万+
网上查到一篇RMAN工具的使用，这篇文档记录写的比较详细，自己目前的工作环境反复使用的几率不高，有些时候就容易忘，特此记录下来。 –====================== – RMAN备份详解 –====================== 一、数据库备份与RMAN备份的概念 1.数据库完全备份：按归档模式分为归档和非归档 归档模式： 打开状态，属于非一致性备份 关闭状态，可以分为一致性和非一致性 非归档模式： 打开状态，非一致性备份无效 关闭状态，一致性备份，非一致性备份不被推荐 2.RMAN备份
给你的rman备份集加上密码锁
zhenglib18的专栏
06-01 747
数据的安全越来越重要,不是说你的生产库安全，你的数据就一定安全了，rman备份也是泄露数据的一个重要地方,如果别人拿到了你的备份集,一样等同入侵了你的生产库。为了rman备份的安全，最简单方式就是使用set encryption方式在rman备份过程中设置密码,需要版本为10.2及其以后企业版版,另外如果需要备份到带库只能使用oracle自己的osb(Oracle Secure Backup),注
RMAN-06094
喝醉酒的小白
01-13 2323
表空间为read only
ORACLE 只读数据文件备份与恢复
coco3600的博客
02-03 250
第一章只读数据文件备份与恢复 BLOG文档结果图： 只读数据文件是只读表空间的数据文件，其数据块包括...
oracle跨平台备份恢复,12C RMAN 传输表空间及跨平台备份恢复PDB
weixin_35038173的博客
04-07 499
在12C中传输表空间变得非常简单，一条语句搞定。还可以通过RMAN跨平台备份恢复数据，另外还可以通过增量备份传输表空间减少应用停机时间。在本机上做了个表空间传输的例子，建一个表空间，RMAN备份，再删除表空间，然后恢复表空间：1、创建表空间，并初始化表SQL>showuser;USERis"C##AWEN"SQL>selectnamefromv$datafile;NAM...
如何通过RMAN备份恢复Oracle容器中的数据库？
最新发布
03-28
<think>好的，我现在需要回答用户关于如何使用RMAN备份和恢复Oracle容器数据库的问题。用户提到了三个引用资料，我需要仔细分析这些内容，并结合自己的知识，给出结构清晰的回答。 首先，用户提供的引用中，引用[1]提到在PDB下使用RMAN进行镜像备份，例如BACKUP AS COPY DATAFILE，以及连接到指定PDB的方法。引用[3]指出备份可插拔数据库的命令是backup pluggable database，并且根容器需要加引号。引用[2]涉及删除备份片段的操作，可能和配置或清理有关。 接下来，我需要整理RMAN备份和恢复容器数据库的步骤，分CDB和PDB的情况。对于CDB，可能需要备份整个数据库，包括控制文件、归档日志等，而PDB则可以单独备份。恢复部分，需要考虑恢复到特定时间点或使用镜像备份。 还要注意用户提到的镜像备份和直接复制数据文件的方式，这在恢复时可能更直接。同时，归档日志的管理在容器数据库中可能有所不同，因为CDB级别的归档日志服务于所有PDB，所以在备份PDB时可能不会包含归档日志，如引用[1]所述。 需要检查是否有遗漏的步骤，比如配置RMAN、设置保留策略等，但用户的问题更侧重于备份和恢复的具体操作。可能需要分点说明备份CDB、备份PDB、恢复CDB、恢复PDB的步骤，并给出示例命令。 此外，用户可能需要了解常见问题，例如如何处理整个CDB的故障或单个PDB的恢复。引用[3]提到备份多个PDB的命令，可以举例说明。同时，恢复时可能需要使用备份的控制文件或数据文件，具体步骤需要详细说明。 最后，生成相关问题，帮助用户进一步学习，比如增量备份、处理归档日志、多租户环境下的优化等。</think>### RMAN备份与恢复Oracle容器数据库教程 #### **一、容器数据库（CDB/PDB）备份** 1. **连接RMAN** - **连接到CDB**： ```bash rman target sys/oracle@CDB_SID ``` - **连接到指定PDB**： ```bash rman target sys/oracle@PDB_SID ``` 2. **备份整个CDB（包含所有PDB）** ```sql RMAN> BACKUP DATABASE PLUS ARCHIVELOG; -- 备份数据库及归档日志[^1] RMAN> BACKUP CURRENT CONTROLFILE; -- 备份控制文件 ``` 3. **单独备份PDB** - **备份单个PDB**： ```sql RMAN> BACKUP PLUGGABLE DATABASE pdbname; -- 备份指定PDB[^3] ``` - **备份多个PDB**： ```sql RMAN> BACKUP PLUGGABLE DATABASE pdb1, pdb2; -- 同时备份多个PDB ``` - **镜像备份PDB数据文件**： ```sql RMAN> BACKUP AS COPY DATAFILE 'u01/app/oracle/oradata/pdb_user01.dbf'; -- 直接复制数据文件 ``` 4. **查看备份信息** ```sql RMAN> LIST BACKUP; -- 列出所有备份 RMAN> REPORT SCHEMA; -- 查看当前数据库文件结构[^1] ``` --- #### **二、容器数据库恢复** 1. **恢复整个CDB** - 进入RMAN后执行： ```sql RMAN> RESTORE DATABASE; -- 恢复数据文件 RMAN> RECOVER DATABASE; -- 应用归档日志 RMAN> ALTER DATABASE OPEN; -- 打开数据库 ``` 2. **恢复单个PDB** - **步骤1：关闭PDB** ```sql SQL> ALTER PLUGGABLE DATABASE pdbname CLOSE IMMEDIATE; ``` - **步骤2：恢复PDB数据文件** ```sql RMAN> RESTORE PLUGGABLE DATABASE pdbname; RMAN> RECOVER PLUGGABLE DATABASE pdbname; ``` - **步骤3：重新打开PDB** ```sql SQL> ALTER PLUGGABLE DATABASE pdbname OPEN; ``` 3. **使用镜像备份快速恢复** ```sql RMAN> SWITCH DATAFILE '原数据文件路径' TO COPY; -- 将镜像备份替换原文件[^1] ``` --- #### **三、关键注意事项** 1. **归档日志管理** - CDB的归档日志为所有PDB共享，备份PDB时需单独处理归档日志[^1]。 - 执行`BACKUP ... PLUS ARCHIVELOG`时需在CDB级别操作。 2. **保留策略配置** ```sql RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; -- 保留7天内的备份 ``` 3. **删除过期备份** ```sql RMAN> DELETE OBSOLETE; -- 删除过期备份 RMAN> DELETE BACKUP ...; -- 手动删除指定备份（参考[^2]） ``` --- #### **四、应用场景示例** - **场景1：误删PDB表空间** 使用`RESTORE PLUGGABLE DATABASE`恢复至删除前的状态。 - **场景2：CDB控制文件损坏** 通过`RESTORE CONTROLFILE`从备份恢复控制文件。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值