iis服务器助手广告广告
返回顶部
首页 > 资讯 > 数据库 >使用RMAN对CDB的root执行完全恢复
  • 945
分享到

使用RMAN对CDB的root执行完全恢复

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

如果数据损坏或用户错误只影响CDB的root容器,那么可能只会考虑恢复root容器。然而,oracle强烈建议你在恢复root容器后恢复所有的PDB来阻止root与PDB中的元数据不一致的情况

如果数据损坏或用户错误只影响CDB的root容器,那么可能只会考虑恢复root容器。然而,oracle强烈建议你在恢复root容器后恢复所有的PDB来阻止root与PDB中的元数据不一致的情况。在这种情况下,更好的方法是对整个CDB执行恢复操作。

使用RMAN对root执行完全恢复的操作如下:
1.启动RMAN并以有sysdba或sysbackup权限的公共用户连接到root容器。

[oracle@jytest1 ~]$ rman target/ catalog rco/xxxxxx@jypdb 

Recovery Manager: Release 12.2.0.1.0 - Production on Mon Dec 11 15:55:18 2017

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

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

2.将整个CDB启动到mount状态

sql> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 6442450944 bytes
Fixed Size                  8807168 bytes
Variable Size            1895828736 bytes
Database Buffers         4529848320 bytes
Redo Buffers                7966720 bytes
Database mounted.

SQL> select name from v$pdbs;

NAME
--------------------------------------------------------------------------------
PDB$SEED
JYPDB

3.可选操作,使用configure命令来配置缺省的设备类型与自动通道。

4.执行以下命令来还原与恢复root容器

RMAN> restore database root;

Starting restore at 11-DEC-17
starting full resync of recovery catalog
full resync complete
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1521 instance=jy1 device type=DISK

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 +DATA/JY/DATAFILE/system.317.962209603
channel ORA_DISK_1: restoring datafile 00003 to +DATA/JY/DATAFILE/sysaux.298.962209605
channel ORA_DISK_1: restoring datafile 00004 to +DATA/JY/DATAFILE/undotbs1.277.962209605
channel ORA_DISK_1: restoring datafile 00007 to +DATA/JY/DATAFILE/users.301.962209605
channel ORA_DISK_1: restoring datafile 00009 to +DATA/JY/DATAFILE/undotbs2.312.962209605
channel ORA_DISK_1: reading from backup piece +TEST/rman_backup/jy_979425723_20171208_0fslkbg2_1_1
channel ORA_DISK_1: piece handle=+TEST/rman_backup/jy_979425723_20171208_0fslkbg2_1_1 tag=TAG20171208T165528
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:45
Finished restore at 11-DEC-17

RMAN> recover database root;

Starting recover at 11-DEC-17
using channel ORA_DISK_1

starting media recovery

arcHived log for thread 1 with sequence 14 is already on disk as file +TEST/arch/1_14_961976319.dbf
archived log for thread 1 with sequence 15 is already on disk as file +TEST/arch/1_15_961976319.dbf
archived log for thread 1 with sequence 16 is already on disk as file +TEST/arch/1_16_961976319.dbf
archived log for thread 1 with sequence 17 is already on disk as file +TEST/arch/1_17_961976319.dbf
archived log for thread 1 with sequence 18 is already on disk as file +TEST/arch/1_18_961976319.dbf
archived log for thread 1 with sequence 19 is already on disk as file +TEST/arch/1_19_961976319.dbf
archived log for thread 1 with sequence 20 is already on disk as file +TEST/arch/1_20_961976319.dbf
archived log for thread 1 with sequence 21 is already on disk as file +TEST/arch/1_21_961976319.dbf
archived log for thread 1 with sequence 22 is already on disk as file +TEST/arch/1_22_961976319.dbf
archived log for thread 1 with sequence 23 is already on disk as file +TEST/arch/1_23_961976319.dbf
archived log for thread 1 with sequence 24 is already on disk as file +TEST/arch/1_24_961976319.dbf
archived log for thread 1 with sequence 25 is already on disk as file +TEST/arch/1_25_961976319.dbf
archived log for thread 1 with sequence 26 is already on disk as file +TEST/arch/1_26_961976319.dbf
archived log for thread 1 with sequence 27 is already on disk as file +TEST/arch/1_27_961976319.dbf
archived log for thread 2 with sequence 12 is already on disk as file +TEST/arch/2_12_961976319.dbf
archived log for thread 2 with sequence 13 is already on disk as file +TEST/arch/2_13_961976319.dbf
archived log for thread 2 with sequence 14 is already on disk as file +TEST/arch/2_14_961976319.dbf
archived log for thread 2 with sequence 15 is already on disk as file +TEST/arch/2_15_961976319.dbf
archived log for thread 2 with sequence 16 is already on disk as file +TEST/arch/2_16_961976319.dbf
archived log for thread 2 with sequence 17 is already on disk as file +TEST/arch/2_17_961976319.dbf
archived log for thread 2 with sequence 18 is already on disk as file +TEST/arch/2_18_961976319.dbf
archived log for thread 2 with sequence 19 is already on disk as file +TEST/arch/2_19_961976319.dbf
archived log for thread 2 with sequence 20 is already on disk as file +TEST/arch/2_20_961976319.dbf
archived log file name=+TEST/arch/1_14_961976319.dbf thread=1 sequence=14
archived log file name=+TEST/arch/2_12_961976319.dbf thread=2 sequence=12
archived log file name=+TEST/arch/1_15_961976319.dbf thread=1 sequence=15
archived log file name=+TEST/arch/2_13_961976319.dbf thread=2 sequence=13
archived log file name=+TEST/arch/1_16_961976319.dbf thread=1 sequence=16
archived log file name=+TEST/arch/1_17_961976319.dbf thread=1 sequence=17
archived log file name=+TEST/arch/2_14_961976319.dbf thread=2 sequence=14
archived log file name=+TEST/arch/1_18_961976319.dbf thread=1 sequence=18
archived log file name=+TEST/arch/1_19_961976319.dbf thread=1 sequence=19
archived log file name=+TEST/arch/1_20_961976319.dbf thread=1 sequence=20
archived log file name=+TEST/arch/2_15_961976319.dbf thread=2 sequence=15
archived log file name=+TEST/arch/1_21_961976319.dbf thread=1 sequence=21
archived log file name=+TEST/arch/1_22_961976319.dbf thread=1 sequence=22
archived log file name=+TEST/arch/2_16_961976319.dbf thread=2 sequence=16
archived log file name=+TEST/arch/1_23_961976319.dbf thread=1 sequence=23
archived log file name=+TEST/arch/1_24_961976319.dbf thread=1 sequence=24
archived log file name=+TEST/arch/2_17_961976319.dbf thread=2 sequence=17
archived log file name=+TEST/arch/1_25_961976319.dbf thread=1 sequence=25
archived log file name=+TEST/arch/2_18_961976319.dbf thread=2 sequence=18
archived log file name=+TEST/arch/1_26_961976319.dbf thread=1 sequence=26
media recovery complete, elapsed time: 00:06:07
Finished recover at 11-DEC-17
starting full resync of recovery catalog
full resync complete

5.检查输出结果查看是否介质恢复成功。如果介质恢复成功继续下面的操作

6.强烈建议的操作,恢复所有PDB,包括CDB seed

RMAN> restore pluggable database 'PDB$SEED',jypdb;

Starting restore at 11-DEC-17
using channel ORA_DISK_1

skipping datafile 5; already restored to file +DATA/JY/5F9AA264B21F3ED9E053AB828A0A6088/DATAFILE/system.256.962209675
skipping datafile 6; already restored to file +DATA/JY/5F9AA264B21F3ED9E053AB828A0A6088/DATAFILE/sysaux.270.962209675
skipping datafile 8; already restored to file +DATA/JY/5F9AA264B21F3ED9E053AB828A0A6088/DATAFILE/undotbs1.296.962209675
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_20171208_0gslkbie_1_1
channel ORA_DISK_1: piece handle=+TEST/rman_backup/jy_979425723_20171208_0gslkbie_1_1 tag=TAG20171208T165528
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:25
Finished restore at 11-DEC-17

RMAN> recover pluggable database 'PDB$SEED',jypdb;

Starting recover at 11-DEC-17
using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 14 is already on disk as file +TEST/arch/1_14_961976319.dbf
archived log for thread 1 with sequence 15 is already on disk as file +TEST/arch/1_15_961976319.dbf
archived log for thread 1 with sequence 16 is already on disk as file +TEST/arch/1_16_961976319.dbf
archived log for thread 1 with sequence 17 is already on disk as file +TEST/arch/1_17_961976319.dbf
archived log for thread 1 with sequence 18 is already on disk as file +TEST/arch/1_18_961976319.dbf
archived log for thread 1 with sequence 19 is already on disk as file +TEST/arch/1_19_961976319.dbf
archived log for thread 1 with sequence 20 is already on disk as file +TEST/arch/1_20_961976319.dbf
archived log for thread 1 with sequence 21 is already on disk as file +TEST/arch/1_21_961976319.dbf
archived log for thread 1 with sequence 22 is already on disk as file +TEST/arch/1_22_961976319.dbf
archived log for thread 1 with sequence 23 is already on disk as file +TEST/arch/1_23_961976319.dbf
archived log for thread 1 with sequence 24 is already on disk as file +TEST/arch/1_24_961976319.dbf
archived log for thread 1 with sequence 25 is already on disk as file +TEST/arch/1_25_961976319.dbf
archived log for thread 1 with sequence 26 is already on disk as file +TEST/arch/1_26_961976319.dbf
archived log for thread 1 with sequence 27 is already on disk as file +TEST/arch/1_27_961976319.dbf
archived log for thread 2 with sequence 12 is already on disk as file +TEST/arch/2_12_961976319.dbf
archived log for thread 2 with sequence 13 is already on disk as file +TEST/arch/2_13_961976319.dbf
archived log for thread 2 with sequence 14 is already on disk as file +TEST/arch/2_14_961976319.dbf
archived log for thread 2 with sequence 15 is already on disk as file +TEST/arch/2_15_961976319.dbf
archived log for thread 2 with sequence 16 is already on disk as file +TEST/arch/2_16_961976319.dbf
archived log for thread 2 with sequence 17 is already on disk as file +TEST/arch/2_17_961976319.dbf
archived log for thread 2 with sequence 18 is already on disk as file +TEST/arch/2_18_961976319.dbf
archived log for thread 2 with sequence 19 is already on disk as file +TEST/arch/2_19_961976319.dbf
archived log for thread 2 with sequence 20 is already on disk as file +TEST/arch/2_20_961976319.dbf
archived log file name=+TEST/arch/1_14_961976319.dbf thread=1 sequence=14
archived log file name=+TEST/arch/2_12_961976319.dbf thread=2 sequence=12
archived log file name=+TEST/arch/1_15_961976319.dbf thread=1 sequence=15
archived log file name=+TEST/arch/2_13_961976319.dbf thread=2 sequence=13
archived log file name=+TEST/arch/1_16_961976319.dbf thread=1 sequence=16
archived log file name=+TEST/arch/1_17_961976319.dbf thread=1 sequence=17
archived log file name=+TEST/arch/2_14_961976319.dbf thread=2 sequence=14
archived log file name=+TEST/arch/1_18_961976319.dbf thread=1 sequence=18
archived log file name=+TEST/arch/1_19_961976319.dbf thread=1 sequence=19
archived log file name=+TEST/arch/1_20_961976319.dbf thread=1 sequence=20
archived log file name=+TEST/arch/2_15_961976319.dbf thread=2 sequence=15
archived log file name=+TEST/arch/1_21_961976319.dbf thread=1 sequence=21
archived log file name=+TEST/arch/1_22_961976319.dbf thread=1 sequence=22
archived log file name=+TEST/arch/2_16_961976319.dbf thread=2 sequence=16
archived log file name=+TEST/arch/1_23_961976319.dbf thread=1 sequence=23
archived log file name=+TEST/arch/1_24_961976319.dbf thread=1 sequence=24
archived log file name=+TEST/arch/2_17_961976319.dbf thread=2 sequence=17
archived log file name=+TEST/arch/1_25_961976319.dbf thread=1 sequence=25
archived log file name=+TEST/arch/2_18_961976319.dbf thread=2 sequence=18
archived log file name=+TEST/arch/1_26_961976319.dbf thread=1 sequence=26
media recovery complete, elapsed time: 00:02:52
Finished recover at 11-DEC-17
starting full resync of recovery catalog
full resync complete

检查输出结果查看是否介质恢复成功。如果介质恢复成功继续下面的操作

7.open CDB与所有的PDB

RMAN> alter database open;

Statement processed

RMAN> alter pluggable database all open;

Statement processed
starting full resync of recovery catalog
full resync complete


您可能感兴趣的文档:

--结束END--

本文标题: 使用RMAN对CDB的root执行完全恢复

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

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

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

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

下载Word文档
猜你喜欢
  • 使用RMAN对CDB的root执行完全恢复
    如果数据损坏或用户错误只影响CDB的root容器,那么可能只会考虑恢复root容器。然而,Oracle强烈建议你在恢复root容器后恢复所有的PDB来阻止root与PDB中的元数据不一致的情况...
    99+
    2024-04-02
  • 使用RMAN来PDB执行完全恢复
    可以对一个或多个PDB执行完全恢复而不影响其它为open状态的PDB的操作。RMAN有两种方法来恢复PDB: .连接到CDB的root容器,然后使用restore pluggable database...
    99+
    2024-04-02
  • 如何使用RMAN对CDB执行按时间点恢复
    这篇文章给大家分享的是有关如何使用RMAN对CDB执行按时间点恢复的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。使用RMAN对CDB和PDB执行按时间点恢复 RMAN能够对CDB...
    99+
    2024-04-02
  • 如何使用RMAN对PDB中的表空间或数据文件执行完全恢复
    小编给大家分享一下如何使用RMAN对PDB中的表空间或数据文件执行完全恢复,希望大家阅读完这篇文章之后都有所收获,下面让我们一起去探讨吧!因为不同PDB中的表空间可以有相同的名字,为了消除这种混淆你必须直接...
    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对CDB中的PDB进行复制
    本篇内容主要讲解“如何使用RMAN对CDB中的PDB进行复制”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“如何使用RMAN对CDB中的PDB进行复制”吧! 1....
    99+
    2024-04-02
  • 如何使用RMAN对PDB执行按时间点恢复
    小编给大家分享一下如何使用RMAN对PDB执行按时间点恢复,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起去了解一下吧!对PDB执行按时间点恢复...
    99+
    2024-04-02
  • 如何使用RMAN对CDB执行闪回数据库操作
    这篇文章主要为大家展示了“如何使用RMAN对CDB执行闪回数据库操作”,内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让小编带领大家一起研究并学习一下“如何使用RMAN对CDB执行闪回数据库操作”这...
    99+
    2024-04-02
  • Oracle 12c如何使用RMAN备份对Non-CDB中的表按时间点进行恢复
    小编给大家分享一下Oracle 12c如何使用RMAN备份对Non-CDB中的表按时间点进行恢复,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起...
    99+
    2024-04-02
  • 如何使用RMAN对CDB中的部分表空间进行复制
    这篇文章主要介绍“如何使用RMAN对CDB中的部分表空间进行复制”,在日常操作中,相信很多人在如何使用RMAN对CDB中的部分表空间进行复制问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望...
    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
  • 如何恢复MySQL root用户的完全权限?
    我们可以借助UPDATE命令恢复MySQL root用户的完全权限。 首先,您需要停止 mysqld 并使用 --skip-grant-tables 选项重新启动它。之后,仅使用 mysql 连接到 mysqld 服务器(即没有 -p 选项...
    99+
    2023-10-22
  • RMAN深入解析之--Incarnation应用(不完全恢复)
    当在做Media Recover的不完全恢复时,通过resetlogs打开库,则Incarnation(数据库对应物)表示这个数据库的特定的逻辑生存期。当作为DBA可能面临这样的还原:需要使用上次执行re...
    99+
    2024-04-02
  • 使用RMAN恢复数据库的过程
    这篇文章主要讲解了“使用RMAN恢复数据库的过程”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“使用RMAN恢复数据库的过程”吧!由于需要搭建一个测试环境,把...
    99+
    2024-04-02
  • 如何使用RMAN对PDB执行闪回数据库操作
    小编给大家分享一下如何使用RMAN对PDB执行闪回数据库操作,希望大家阅读完这篇文章之后都有所收获,下面让我们一起去探讨吧!可以对多租户数据库中的单个PDB执行闪回操作。对特定的PDB执行闪回数据库操作只会...
    99+
    2024-04-02
  • Oracle 12C如何使用RMAN将Non-CDB中分表的多个分区恢复到新用户方案中
    这篇文章主要介绍了Oracle 12C如何使用RMAN将Non-CDB中分表的多个分区恢复到新用户方案中,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让小编带着大家一起...
    99+
    2024-04-02
  • 如何使用RMAN备份将Non-CDB中被drop的表恢复到新用户方案与新表空间中
    这篇文章主要介绍如何使用RMAN备份将Non-CDB中被drop的表恢复到新用户方案与新表空间中,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!RMAN使用recover命令...
    99+
    2024-04-02
  • centos7/rhel7中如何进入单用户模式对root密码进行恢复
    这期内容当中小编将会给大家带来有关centos7/rhel7中如何进入单用户模式对root密码进行恢复,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以有所收获。在RHEL6(包括之前的版本)恢复root密码的话,只需...
    99+
    2023-06-05
  • Oracle 12C如何使用RMAN将Non-CDB多个用户方案中的多个表或表分区恢复到新用户方案中
    这篇文章主要介绍Oracle 12C如何使用RMAN将Non-CDB多个用户方案中的多个表或表分区恢复到新用户方案中,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!Oracle 12C...
    99+
    2024-04-02
软考高级职称资格查询
编程网,编程工程师的家园,是目前国内优秀的开源技术社区之一,形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容,为IT开发者提供了一个发现、使用、并交流开源技术的平台。
  • 官方手机版

  • 微信公众号

  • 商务合作