如何使用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 complete6. 以读写方式打开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执行按时间点恢复”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联行业资讯频道！
网站名称：如何使用RMAN对PDB执行按时间点恢复
分享地址：https://www.cdcxhl.com/article44/gohjee.html
成都网站建设公司_创新互联，为您提供定制网站、网站制作、移动网站建设、品牌网站制作、ChatGPT、外贸建站
声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联
- 网站收录下降解决方法 2022-05-06
- 增加网站收录的四大秘诀！ 2022-12-15
- 如何快速的增加网站的收录量 2014-10-24
- 关于老站新站的各类收录问题汇总 2013-08-16
- 如何提高SEO网站的收录？ 2015-08-12
- 网站收录和快照更新360和百度为何相差这么大? 2020-07-26
- 360搜索引擎收录为什么比其它？ 2016-11-05
- 网站收录多少对营销型网站优化排名的影响 2021-10-17
- 新建网站如何使搜索引擎快速收录 2017-01-20
- 成都网站制作收录能不能控制?如何才能保证网站收录不错呢? 2013-08-26
- 如何解决seo优化中内容页面不收录问题？ 2014-07-12
- 如何快速收录，如何让网站内容被百度快速收录？ 2016-08-20