iis服务器助手广告广告
返回顶部
首页 > 资讯 > 数据库 >如何使用RMAN对PDB执行按时间点恢复
  • 889
分享到

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

2024-04-02 19:04:59 889人浏览 安东尼
摘要

小编给大家分享一下如何使用RMAN对PDB执行按时间点恢复,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起去了解一下吧!对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执行按时间点恢复”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注编程网数据库频道!

您可能感兴趣的文档:

--结束END--

本文标题: 如何使用RMAN对PDB执行按时间点恢复

本文链接: https://www.lsjlt.com/news/64154.html(转载时请注明来源链接)

有问题或投稿请发送至: 邮箱/279061341@qq.com    QQ/279061341

本篇文章演示代码以及资料文档资料下载

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

下载Word文档
猜你喜欢
  • 如何使用RMAN对PDB执行按时间点恢复
    小编给大家分享一下如何使用RMAN对PDB执行按时间点恢复,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起去了解一下吧!对PDB执行按时间点恢复...
    99+
    2024-04-02
  • 如何使用RMAN对CDB执行按时间点恢复
    这篇文章给大家分享的是有关如何使用RMAN对CDB执行按时间点恢复的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。使用RMAN对CDB和PDB执行按时间点恢复 RMAN能够对CDB...
    99+
    2024-04-02
  • 使用RMAN来PDB执行完全恢复
    可以对一个或多个PDB执行完全恢复而不影响其它为open状态的PDB的操作。RMAN有两种方法来恢复PDB: .连接到CDB的root容器,然后使用restore pluggable database...
    99+
    2024-04-02
  • RMAN中如何使用until time子句对Non-CDB中的表执行按时间点恢复
    这篇文章主要为大家展示了“RMAN中如何使用until time子句对Non-CDB中的表执行按时间点恢复”,内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让小编带领大家一起研究并学习一下“RMAN...
    99+
    2024-04-02
  • 使用RMAN备份对Non-CDB中的表按时间点进行恢复
    RMAN使用recover命令来将表或表分区恢复到指定的时间点。为了从RMAN备份中恢复表与表分区,你必须提供以下信息: .要被恢复的表或表分区 .表或表分区要被恢复到的特定时间点 .被恢复的表或...
    99+
    2024-04-02
  • 如何使用RMAN对PDB中的表空间或数据文件执行完全恢复
    小编给大家分享一下如何使用RMAN对PDB中的表空间或数据文件执行完全恢复,希望大家阅读完这篇文章之后都有所收获,下面让我们一起去探讨吧!因为不同PDB中的表空间可以有相同的名字,为了消除这种混淆你必须直接...
    99+
    2024-04-02
  • Oracle 12c如何使用RMAN备份对Non-CDB中的表按时间点进行恢复
    小编给大家分享一下Oracle 12c如何使用RMAN备份对Non-CDB中的表按时间点进行恢复,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起...
    99+
    2024-04-02
  • 如何使用RMAN对PDB执行闪回数据库操作
    小编给大家分享一下如何使用RMAN对PDB执行闪回数据库操作,希望大家阅读完这篇文章之后都有所收获,下面让我们一起去探讨吧!可以对多租户数据库中的单个PDB执行闪回操作。对特定的PDB执行闪回数据库操作只会...
    99+
    2024-04-02
  • 如何使用RMAN对CDB中的PDB进行复制
    本篇内容主要讲解“如何使用RMAN对CDB中的PDB进行复制”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“如何使用RMAN对CDB中的PDB进行复制”吧! 1....
    99+
    2024-04-02
  • Oracle 12C使用UNTIL SEQUENCE子句对Non-CDB中的表执行按时间点恢复
    Oracle 12C使用UNTIL SEQUENCE子句对Non-CDB中的表执行按时间点恢复执行操作如下 1.对整个Non-CDB(orcl)生成RMAN备份 RMAN> backup as...
    99+
    2024-04-02
  • 使用RMAN对CDB的root执行完全恢复
    如果数据损坏或用户错误只影响CDB的root容器,那么可能只会考虑恢复root容器。然而,Oracle强烈建议你在恢复root容器后恢复所有的PDB来阻止root与PDB中的元数据不一致的情况...
    99+
    2024-04-02
  • 如何使用RMAN对CDB中的部分表空间进行复制
    这篇文章主要介绍“如何使用RMAN对CDB中的部分表空间进行复制”,在日常操作中,相信很多人在如何使用RMAN对CDB中的部分表空间进行复制问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望...
    99+
    2024-04-02
  • 如何使用RMAN对CDB执行闪回数据库操作
    这篇文章主要为大家展示了“如何使用RMAN对CDB执行闪回数据库操作”,内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让小编带领大家一起研究并学习一下“如何使用RMAN对CDB执行闪回数据库操作”这...
    99+
    2024-04-02
  • 如何使用RMAN还原和恢复数据库
    这篇文章主要介绍“如何使用RMAN还原和恢复数据库”,在日常操作中,相信很多人在如何使用RMAN还原和恢复数据库问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”如何使用RMAN...
    99+
    2024-04-02
  • 如何用mysql自带的定时器定时执行sql(每天0点执行与间隔分/时执行)
    目录需求1.查看是否开启定时策略2.创建存储函数,存储定时执行的事件3.创建定时任务4.查看创建的定时任务5.开启或关闭定时任务补充:ON SCHEDULE后面可以 自由发挥补充:定时器常用案例总结需求 每天往一个表里面...
    99+
    2023-03-01
    mysql定时执行sql语句 mysql 定时执行 mysql定时器
  • PHPJS没有按照设定时间执行如何处理
    这篇文章主要介绍了PHPJS没有按照设定时间执行如何处理的相关知识,内容详细易懂,操作简单快捷,具有一定借鉴价值,相信大家阅读完这篇PHPJS没有按照设定时间执行如何处理文章都会有所收获,下面我们一起来看看吧。什么是PHPJS文件PHPJS...
    99+
    2023-07-05
  • MySQL使用bin-log异库恢复到指定时间点
    1、搭建初始化数据库 2、确定日志的位置position 3、备份数据库T0 4、模拟数据库发生变化T1 5、模拟数据库发生变化T2 6、恢复数据库到备份时间点T0 7、模拟数据库恢复到时间点T1 8、模拟...
    99+
    2024-04-02
  • 如何使用mysqldump对mysql进行备份和恢复
    这篇文章给大家分享的是有关如何使用mysqldump对mysql进行备份和恢复的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。mysqldump是mysql的逻辑备份恢复工具,可以...
    99+
    2024-04-02
  • 如何使用spring-task定时任务动态配置修改执行时间
    小编给大家分享一下如何使用spring-task定时任务动态配置修改执行时间,希望大家阅读完这篇文章之后都有所收获,下面让我们一起去探讨吧!spring-task定时任务动态配置修改执行时间因项目需要,几个定时任务需要人为动态设置执行时间,...
    99+
    2023-06-25
  • java如何实现对可恢复条件使用检查异常并对编程错误使用运行时异常
    这篇文章将为大家详细讲解有关java如何实现对可恢复条件使用检查异常并对编程错误使用运行时异常,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。对可恢复条件使用检查异常,对编程错误使用运行时异常大多数情况下,...
    99+
    2023-06-27
软考高级职称资格查询
编程网,编程工程师的家园,是目前国内优秀的开源技术社区之一,形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容,为IT开发者提供了一个发现、使用、并交流开源技术的平台。
  • 官方手机版

  • 微信公众号

  • 商务合作