【DB笔试面试432】在Oracle 12c中,在RMAN方面有哪些增强的新特性?

2019-09-30 19:00:37 浏览数 (1)

题目

在Oracle 12c中,在RMAN方面有哪些增强的新特性?

答案

Oracle 12C的RMAN中新增了很多的新特性,分别如下所示:

(一)新的备份用户特权(SYSBACKUP)

在Oracle 11gR2中,引入了SYSASM特权用来执行与ASM相关的特定操作。同样地,在Oracle 12c中引入了3个新的系统用户SYSBACKUP、SYSDG和SYSKM,其中,SYSKM可以执行与透明数据加密密钥(Transparent Data Encryption keystore)相关的操作,SYSDG可以在DGMGRL或命令行接口里执行与DG(Data Guard)相关的操作,而SYSBACKUP特权用来在RMAN或SQL*Plus中执行备份和恢复命令。

因此,可以在数据库中创建一个本地用户并在不授予其SYSDBA权限的情况下,通过授予SYSBACKUP权限让其能够在RMAN中执行备份和恢复相关的任务,不再需要SYSDBA这个超级权限。这一特性强制执行了职责安全模型的分离,即备份操作只需要SYSBACKUP权限来运行RMAN命令,并从需要真正的SYSDBA特权的数据库管理员那里承担独立的职责。

RMAN连接到数据库的方式与SQL*Plus连接到数据库的方式相同。唯一的区别是,RMAN连接到目标或辅助数据库需要SYSDBA或SYSBACKUP特权。任何用户都可以授予此特权。

$ ./rman target "username/password as SYSBACKUP"

在SQL*Plus中,若使用SYSBACKUP进行登录,则其SCHEMA为SYS,而USER为SYSBACKUP。

(二)可以直接在RMAN中执行SQL语句

在Oracle 12c中,可以在不需要SQL前缀的情况下在RMAN中执行任何SQL和PL/SQL命令。当然,原来的加SQL前缀的方式依然有效。如下便是在RMAN中执行SQL语句的案例:

RMAN> SELECT * FROM V$VERSION;

RMAN> ALTER TABLESPACE USERS ADD DATAFILE SIZE 121M;

RMAN> ALTER SYSTEM SWITCH LOGFILE;

(三)在RMAN中提供了表级别恢复(RECOVER TABLE)

在Oracle 12c中,在发生drop或truncate的情况下,可以从RMAN备份种将一个特定的表或分区恢复到某个时间点、SCN或归档序列号,并且可以有下面的选择:

l 使用REMAP选项将表恢复为一个新表或者分区中,也可以恢复到其他用户中。

l 只生成一个需要被恢复表的expdp格式的dump文件,选择后期再进行恢复。

Oracle 12c的Recover Table新特性是利用创建辅助临时实例加数据泵工具来实现的。通常在进行Recover Table之前应该准备好两个目录(AUXILIARY DESTINATION和DATAPUMP DESTINATION),AUXILIARY DESTINATION用来临时存放辅助实例的数据文件,DATAPUMP DESTINATION用来临时存放数据泵导出的文件。

只要之前创建了RMAN备份,那么就可以根据指定的的时间来进行表级和表分区级的恢复操作,而且不影响其他的数据库对象。RMAN的表级和表分区级恢复可以使用在如下场景:

① 在恢复小表或数据库中的某几张表时,但发现使用Restore Database或Tablespace的代价很高而且效率很低。也可以使用TSPITR(表空间基于时间点的恢复)的方法,但该方法效率很低,因为需要移动表空间中的所有对象。

② 恢复有逻辑损坏或者被删除的表。

③ Flashback Table不可用,例如Undo数据已经被覆盖的情况。

④ DDL操作后需要恢复数据。Flashback Table不支持表结构发生改变后的回退,例如TRUNCATE TABLE。

RMAN从备份中自动处理恢复表或者表分区时会执行如下步骤:

1.判断哪些备份包含需要恢复的表或表分区,然后根据指定的时间来进行恢复。

2.判断目标主机上是否有足够的空间来创建auxiliary instance,该实例用于处理表或分区的恢复。如果需要的空间不足,那么RMAN会报错并退出恢复操作。

3.创建auxiliary database,并根据指定的时间来恢复指定的表或表分区到auxiliary database中。辅助数据库的数据文件位置可以在命令中指定。

4.创建包含恢复表或表分区的数据泵文件(expdp dump file)。数据泵的名称和位置也可以在命令中指定。

5.(可选操作)将上一步生产的数据泵文件导入到目标实例中。当然也可以选择不导入,如果选择不导入就必须使用impdp手工导入。

6.(可选操作)在目标数据库中rename恢复表或表分区。

关于RECOVER TABLE需要注意的几个问题:

l 目标数据库必须被置于读写模式。

l 目标数据库必须被置于归档模式。

l 如果要恢复表或者分区,你必须拥有这些表或者分区存在后的时间的备份。

l 想要恢复单个表分区,COMPATIBLE初始化参数所在的目标库必须设置为11.1.0或以上。

l SYS用户下的表或分区无法恢复。

l 存储于SYSAUX和SYSTEM表空间下的表和分区无法恢复。

l Standby数据库上的表或表分区不能进行恢复。

l 在使用REMAP的情况下,有NOT NULL 约束的表不能进行恢复。

l 确保对于辅助数据库在文件系统下有足够的可用空间,同时对数据泵文件也有同样保证。

l 必须要存在一份完整的数据库备份,至少要有SYSTEM、UNDO、SYSAUX和表所在表空间相关的备份。表误操作可以在数据库备份之前也可以在数据库备份之后。如果恢复的表在PDB中,那么需要备份Root Container的SYSTEM,SYSAUX、UNDO和PDB的SYSTEM、SYSAUX以及包含了要恢复的表的表空间。

l 在存在CDB的情况下,在执行RECOVER TABLE时必须使用sys用户登录,而不能使用“rman target /”进行登录。

在执行“RECOVER TABLE”命令时,可以根据需要在以下三种级别指定时间:

(1)SCN号

(2)Sequence number(日志序列号)

(3)Time:根据NLS_LANG和NLS_DATE_FORMAT环境变量中的格式来指定时间,也可以用SYSDATE,比如"SYSDATE-30"、"to_date('2018-04-09:13:51:48','yyyy-mm-dd hh24:mi:ss')"

“RECOVER TABLE”命令的一般格式为:

RMAN> connect target "username/password as SYSBACKUP";

RMAN> RECOVER TABLE username.tablename UNTIL TIME 'TIMESTAMP…'

AUXILIARY DESTINATION '/u01/tablerecovery'

DATAPUMP DESTINATION '/u01/dpump'

DUMP FILE 'tablename.dmp'

NOTABLEIMPORT -- this option avoids importing the table automatically.(此选项避免自动导入表)

REMAP TABLE 'username.tablename': 'username.new_table_name'; -- can rename table with this option.(此选项可以对表重命名)

示例1:在PDB中恢复表HR.PDB_EMP,恢复后的表命名为EMP_RECVR

RECOVER TABLE HR.PDB_EMP OF PLUGGABLE DATABASE HR_PDB

UNTIL TIME 'SYSDATE-4'

AUXILIARY DESTINATION '/tmp/backups'

REMAP TABLE 'HR'.'PDB_EMP':'EMP_RECVR';

RECOVER TABLE DB12C.T

UNTIL SCN 1932621

AUXILIARY DESTINATION '/tmp/oracle/recover'

REMAP TABLE 'DB12C'.'T':'T_HISTORY_20130717';

RECOVER TABLE LHR.TEST_RT

UNTIL TIME "to_date('2018-04-09:13:51:48','yyyy-mm-dd hh24:mi:ss')"

AUXILIARY DESTINATION '/tmp'

REMAP TABLE 'LHR'.'TEST_RT':'TEST_RT_LHR';

RECOVER TABLE HR.DEPARTMENTS, SH.CHANNELS

UNTIL TIME 'SYSDATE – 1'

AUXILIARY DESTINATION '/tmp/auxdest'

REMAP TABLE hr.departments:example.new_departments, sh.channels:example.new_channels;

示例2:从RMAN备份中恢复表SCOTT.EMP,SCOTT.DEPT,并以数据泵格式导出emp_dept_exp_dump.dat,并不进行表的导入

RECOVER TABLE SCOTT.EMP, SCOTT.DEPT

UNTIL TIME 'SYSDATE-1'

AUXILIARY DESTINATION '/tmp/oracle/recover'

DATAPUMP DESTINATION '/tmp/recover/dumpfiles'

DUMP FILE 'emp_dept_exp_dump.dat'

NOTABLEIMPORT;

示例3:恢复表的两个分区,恢复后表分区重新命名并且放置于SALES_PRE_2000_TS表空间

RECOVER TABLE SH.SALES:SALES_1998, SH.SALES:SALES_1999

UNTIL SEQUENCE 354

AUXILIARY DESTINATION '/tmp/oracle/recover'

REMAP TABLE 'SH'.'SALES':'SALES_1998':'HISTORIC_SALES_1998',

'SH'.'SALES':'SALES_1999':'HISTORIC_SALES_1999'

REMAP TABLESPACE 'SALES_TS':'SALES_PRE_2000_TS';

(四)RMAN自动恢复到REDO终点的步骤简化

在Oracle 12.2之前,当需要恢复数据库到某个时间点的时候,需要确定SCN,或者日志序列号,或者一个时间点,以便尽可能多的应用归档日志,进而尽可能多的恢复数据。从12.2开始,RMAN新增参数“UNTIL AVALIABLE REDO”,语法如下:

RMAN> RECOVER DATABASE UNTIL AVALIABLE REDO;

RMAN将会根据控制文件信息和归档日志、线日志、归档日志备份集的物理可用性,将数据库恢复到最后一个可用的归档日志。所以在进行恢复的时候,可以不需要指定SCN,或者时间或者日志序列号。需要注意的是,数据文件仍然需要在一致的情况下,数据库才能打开。

需要注意的是,这些新特性有如下的限制条件:

l 不能针对恢复数据文件或者表空间使用这个命令。

l 不能针对恢复PDB使用这个命令。

l 只能针对全库恢复使用这个命令。

(五)通过网络远程恢复数据库(Restore/Recover from Service)

在Oracle 12c中,可以在主数据库和备用数据库之间用一个服务名重新获得或恢复数据文件、控制文件、参数文件(SPFILE)、表空间或整个数据库。这对于同步主数据库和备用数据库极为有用。

当主数据库和备用数据库之间存在相当大的差异时,不再需要复杂的前滚流程来填补它们之间的差异。RMAN能够通过网络执行备用恢复以进行增量备份,并且可以将它们应用到物理备用数据库。可以用服务名直接将所需数据文件从备用点拷贝至主站,这是为了防止主数据库上数据文件、表空间的丢失,或是没有真正从备份集恢复数据文件。

具体的几种用法:

数据库级别:restore database from service <服务别名>

表空间: restore tablespace from service <服务别名>

控制文件:restore controlfile to '指定的位置' from service <服务别名>

SPFILE: restore spfile from service <服务别名>

以下命令演示了如何用此新功能执行一个前滚来对备用数据库和主数据库进行同步。在物理备用数据库上:

rman target "username/password@standby_db_tns as SYSBACKUP"

RMAN>RECOVER DATABASE FROM SERVICE primary_db_tns USING COMPRESSED BACKUPSET;

以上案例使用备用数据库上定义的primary_db_tns连接字符串连接到主数据库,然后执行了一个增量备份,再将这些增量备份传输至备用目的地,接着将应用这些文件到备用数据库来进行同步。然而,需要确保已经对primary_db_tns进行了配置,即在备份数据库端将其指向主数据库。

在以下命令中,演示了通过从备用数据库获取数据文件来恢复主数据库上丢失的数据文件。在主数据库上:

rman target "username/password@primary_db_tns as SYSBACKUP"

RMAN>RESTORE DATAFILE ' DG_DISKGROUP/DBANME/DATAFILE/filename' FROM SERVICE standby_db_tns;

& 说明:

有关SYSBACKUP、SYSDG、SYSKM系统用户的更多内容可以参考我的BLOG:http://blog.itpub.net/26736162/viewspace-2152738/

有关RECOVER TABLE的更多内容可以参考我的BLOG:http://blog.itpub.net/26736162/viewspace-2152712/

有关UNTIL AVALIABLE REDO的更多内容可以参考我的BLOG:http://blog.itpub.net/26736162/viewspace-2152715/

有关Restore/Recover from Service的更多内容可以参考我的BLOG:http://blog.itpub.net/26736162/viewspace-2152717/

About Me:小麦苗

● 本文作者:小麦苗,只专注于数据库的技术,更注重技术的运用

● 作者博客地址:http://blog.itpub.net/26736162/abstract/1/

● 本系列题目来源于作者的学习笔记,部分整理自网络,若有侵权或不当之处还请谅解

● 版权所有,欢迎分享本文,转载请保留出处

● 题目解答若有不当之处,还望各位朋友批评指正,共同进步

0 人点赞