我的编程空间,编程开发者的网络收藏夹
学习永远不晚

如何使用RMAN对PDB执行按时间点恢复

短信预约 -IT技能 免费直播动态提醒
省份

北京

  • 北京
  • 上海
  • 天津
  • 重庆
  • 河北
  • 山东
  • 辽宁
  • 黑龙江
  • 吉林
  • 甘肃
  • 青海
  • 河南
  • 江苏
  • 湖北
  • 湖南
  • 江西
  • 浙江
  • 广东
  • 云南
  • 福建
  • 海南
  • 山西
  • 四川
  • 陕西
  • 贵州
  • 安徽
  • 广西
  • 内蒙
  • 西藏
  • 新疆
  • 宁夏
  • 兵团
手机号立即预约

请填写图片验证码后获取短信验证码

看不清楚,换张图片

免费获取短信验证码

如何使用RMAN对PDB执行按时间点恢复

小编给大家分享一下如何使用RMAN对PDB执行按时间点恢复,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起去了解一下吧!

对PDB执行按时间点恢复类似于执行数据库按时间点恢复。当对一个或多个PDB恢复到指定时间点时,CDB中的其它PDB不受影响。在恢复之后,PDB原来的保留的旧备份仍然有效可以在出现介质恢复时使用,不需要创建新的备份。当对使用共享UNDO的CDB中的一个或多个PDB执行数据库按时间点恢复时,对于包含被恢复PDB的CDB的root与CDB seed(PDB$SEES)需要有备份。从Oracle 12.2开始,如果compatible参数被设置为12.2,那么可以跨PDB闪回操作或PDB按时间点恢复来对CDB执行闪回数据库操作。在DG环境中,对于备库将跟随主库PDB会被恢复到指定的时间点,你可以闪回整个备库,恢复PDB或对PDB执行闪回。

对PDB执行按时间点恢复的操作步骤如下:
1.登录数据库记录当前SCN号,然后将表t1中的数据删除。

SQL> conn jy/jy@jypdb
Connected.
SQL> SELECT CURRENT_SCN   FROM V$DATABASE;

CURRENT_SCN
-----------
    6255735

SQL> alter session set nls_date_format='yyyy-mm-dd hh34:mi:ss';

Session altered.

SQL> select sysdate from dual;

SYSDATE
-------------------
2017-12-20 16:52:31

SQL> select count(*) from t1;

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

SQL> truncate table t1;

Table truncated.

SQL> select count(*) from t1;

  COUNT(*)
----------
         0

2.如果使用时间表达式来代替目标SCN,那么在调用RMAN之前设置时间格式环境变量

[oracle@jytest1 ~]$ export NLS_DATE_FORMAT='yyyy-mm-dd hh34:mi:ss'

3.使用RMAN连接到root容器

[oracle@jytest1 ~]$ rman target/ catalog rco/abcd@jypdb_173

Recovery Manager: Release 12.2.0.1.0 - Production on Wed Dec 20 16:53:26 2017

Copyright (c) 1982, 2017, Oracle and/or its affiliates.  All rights reserved.

connected to target database: JY (DBID=979425723)
connected to recovery catalog database

4.将要执行恢复的PDB关闭,其它的PDB与CDB仍然处于open状态

RMAN> alter pluggable database jypdb close immediate;

starting full resync of recovery catalog
full resync complete
Statement processed
starting full resync of recovery catalog
full resync complete

5.使用RUN块来执行以下操作
a.对于数据库按时间点鶋,使用set until来指定恢复的目标时间,scn或日志序列号,或者使用set to来指定还原点。如果指定时间那么使用环境变量nls_lang与nls_date_format中所指定的日期格式。

b.如果RMAN没有配置自动通道,那么需要手动分配磁盘与磁带通道。

c.还原与恢复CDB

下面的命令将PDB(jypdb)恢复到SCN=6255735所在的状态

RMAN> run
2> {
3>    set until scn 6255735;
4>    restore pluggable database jypdb;
5>    recover pluggable database jypdb;
6> }

executing command: SET until clause

Starting restore at 2017-12-20 17:00:38
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 00010 to +DATA/JY/5F9AC6865E87549FE053AB828A0ADE94/DATAFILE/system.271.962209649
channel ORA_DISK_1: restoring datafile 00011 to +DATA/JY/5F9AC6865E87549FE053AB828A0ADE94/DATAFILE/sysaux.316.962209649
channel ORA_DISK_1: restoring datafile 00012 to +DATA/JY/5F9AC6865E87549FE053AB828A0ADE94/DATAFILE/undotbs1.264.962209649
channel ORA_DISK_1: restoring datafile 00013 to +DATA/JY/5F9AC6865E87549FE053AB828A0ADE94/DATAFILE/undo_2.268.962209649
channel ORA_DISK_1: restoring datafile 00014 to +DATA/JY/5F9AC6865E87549FE053AB828A0ADE94/DATAFILE/users.278.962209649
channel ORA_DISK_1: restoring datafile 00015 to +DATA/JY/5F9AC6865E87549FE053AB828A0ADE94/DATAFILE/test.275.962210609
channel ORA_DISK_1: reading from backup piece +TEST/rman_backup/jy_979425723_962563516_11slv3ds_1_1
channel ORA_DISK_1: piece handle=+TEST/rman_backup/jy_979425723_962563516_11slv3ds_1_1 tag=TAG20171212T184328
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:35
Finished restore at 2017-12-20 17:01:15

Starting recover at 2017-12-20 17:01:16
current log archived
using channel ORA_DISK_1


starting media recovery

archived log for thread 1 with sequence 38 is already on disk as file +TEST/arch/1_38_961976319.dbf
archived log for thread 1 with sequence 39 is already on disk as file +TEST/arch/1_39_961976319.dbf
archived log for thread 1 with sequence 40 is already on disk as file +TEST/arch/1_40_961976319.dbf
archived log for thread 1 with sequence 41 is already on disk as file +TEST/arch/1_41_961976319.dbf
archived log for thread 1 with sequence 42 is already on disk as file +TEST/arch/1_42_961976319.dbf
archived log for thread 1 with sequence 43 is already on disk as file +TEST/arch/1_43_961976319.dbf
archived log for thread 1 with sequence 44 is already on disk as file +TEST/arch/1_44_961976319.dbf
archived log for thread 1 with sequence 45 is already on disk as file +TEST/arch/1_45_961976319.dbf
archived log for thread 1 with sequence 46 is already on disk as file +TEST/arch/1_46_961976319.dbf
archived log for thread 1 with sequence 47 is already on disk as file +TEST/arch/1_47_961976319.dbf
archived log for thread 1 with sequence 48 is already on disk as file +TEST/arch/1_48_961976319.dbf
archived log for thread 1 with sequence 49 is already on disk as file +TEST/arch/1_49_961976319.dbf
archived log for thread 1 with sequence 50 is already on disk as file +TEST/arch/1_50_961976319.dbf
archived log for thread 1 with sequence 51 is already on disk as file +TEST/arch/1_51_961976319.dbf
archived log for thread 1 with sequence 52 is already on disk as file +TEST/arch/1_52_961976319.dbf
archived log for thread 1 with sequence 53 is already on disk as file +TEST/arch/1_53_961976319.dbf
archived log for thread 1 with sequence 54 is already on disk as file +TEST/arch/1_54_961976319.dbf
archived log for thread 1 with sequence 55 is already on disk as file +TEST/arch/1_55_961976319.dbf
archived log for thread 1 with sequence 56 is already on disk as file +TEST/arch/1_56_961976319.dbf
archived log for thread 1 with sequence 57 is already on disk as file +TEST/arch/1_57_961976319.dbf
archived log for thread 2 with sequence 32 is already on disk as file +TEST/arch/2_32_961976319.dbf
archived log for thread 2 with sequence 33 is already on disk as file +TEST/arch/2_33_961976319.dbf
archived log for thread 2 with sequence 34 is already on disk as file +TEST/arch/2_34_961976319.dbf
archived log for thread 2 with sequence 35 is already on disk as file +TEST/arch/2_35_961976319.dbf
archived log for thread 2 with sequence 36 is already on disk as file +TEST/arch/2_36_961976319.dbf
archived log for thread 2 with sequence 37 is already on disk as file +TEST/arch/2_37_961976319.dbf
archived log for thread 2 with sequence 38 is already on disk as file +TEST/arch/2_38_961976319.dbf
archived log for thread 2 with sequence 39 is already on disk as file +TEST/arch/2_39_961976319.dbf
archived log for thread 2 with sequence 40 is already on disk as file +TEST/arch/2_40_961976319.dbf
archived log for thread 2 with sequence 41 is already on disk as file +TEST/arch/2_41_961976319.dbf
archived log for thread 2 with sequence 42 is already on disk as file +TEST/arch/2_42_961976319.dbf
archived log for thread 2 with sequence 43 is already on disk as file +TEST/arch/2_43_961976319.dbf
archived log for thread 2 with sequence 44 is already on disk as file +TEST/arch/2_44_961976319.dbf
archived log for thread 2 with sequence 45 is already on disk as file +TEST/arch/2_45_961976319.dbf
archived log for thread 2 with sequence 46 is already on disk as file +TEST/arch/2_46_961976319.dbf
archived log for thread 2 with sequence 47 is already on disk as file +TEST/arch/2_47_961976319.dbf
archived log for thread 2 with sequence 48 is already on disk as file +TEST/arch/2_48_961976319.dbf
archived log for thread 2 with sequence 49 is already on disk as file +TEST/arch/2_49_961976319.dbf
archived log for thread 2 with sequence 50 is already on disk as file +TEST/arch/2_50_961976319.dbf
archived log for thread 2 with sequence 51 is already on disk as file +TEST/arch/2_51_961976319.dbf
archived log for thread 2 with sequence 52 is already on disk as file +DATA/JY/ONLINELOG/group_4.262.961976705
archived log for thread 2 with sequence 53 is already on disk as file +DATA/JY/ONLINELOG/group_3.263.961976697
media recovery complete, elapsed time: 00:04:03
Finished recover at 2017-12-20 17:05:30
starting full resync of recovery catalog
full resync complete

6. 以读写方式打开PDB,放弃目标SCN之后的所有改变,执行以下命令

RMAN> alter pluggable database jypdb open resetlogs;

Statement processed
starting full resync of recovery catalog
full resync complete



SQL> conn jy/jy@jypdb
Connected.
SQL> select count(*) from t1;

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

以上是“如何使用RMAN对PDB执行按时间点恢复”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注亿速云行业资讯频道!

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

如何使用RMAN对PDB执行按时间点恢复

下载Word文档到电脑,方便收藏和打印~

下载Word文档

猜你喜欢

如何在SQL Server中执行点对时间的恢复

在SQL Server中执行点对时间的恢复,您可以使用数据库备份和恢复操作来还原数据库到特定的时间点。以下是一些步骤,您可以按照这些步骤执行点对时间的恢复:首先,确保您有数据库的完整备份,包括差异备份和日志备份。这样可以确保您能够还原数据库
如何在SQL Server中执行点对时间的恢复
2024-06-03

java如何实现对可恢复条件使用检查异常并对编程错误使用运行时异常

这篇文章将为大家详细讲解有关java如何实现对可恢复条件使用检查异常并对编程错误使用运行时异常,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。对可恢复条件使用检查异常,对编程错误使用运行时异常大多数情况下,
2023-06-27

编程热搜

目录