RMAN备份
1. 什么是RMAN?
官方定义RMAN：
首先RMAN是一个与Oracle数据库集成的程序相当于数据库的一个功能不需要被单独安装。
RMAN的最小单位是文件，也就是说他是针对文件进行备份而不可以是某个表。
RMAN的连接方式：
1）本地连接：
[oracle@server1 app]$ echo $ORACLE_SID
proe
[oracle@server1 app]$ rman target /
Recovery Manager: Release 11.2.0.4.0 - Production on Tue Jul 7 16:48:27 2020
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: PROE (DBID=485315595)
RMAN> 2）网络连接：
[oracle@server1 ~]$ rman target sys/oracle@192.168.0.50:1521/server13）服务名连接：
[oracle@server1 ~]$ rman target sys/oracle@proe2. RMAN备份的几种类别：
1）backupset：备份集，只针对数据进行备份。
-compress buckupset，压缩备份集，只将备份目标文件中的数据部分抽取出来，不包含数据的地方跳过。
备份集：备份集是逻辑上的，它是所有备份片的集合，备份片才是物理上的，piece handle。
2）image copy：镜像拷贝，和原数据完全一样包括结构，可以让备份文件直接代替原文件。
测试这几种类别最终的大小：
镜像拷贝：
RMAN> backup as copy tablespace example format '/u01/app/backup/example_copy_%T';
Starting backup at 07-JUL-20
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile file number=00005 name=/u01/app/oracle/oradata/proe/example01.dbf
output file name=/u01/app/backup/example_copy_20200707 tag=TAG20200707T171203 RECID=3 STAMP=1045156330
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07
Finished backup at 07-JUL-20
备份集：
RMAN> backup as backupset tablespace example format '/u01/app/backup/example_bs_%T';
Starting backup at 07-JUL-20
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00005 name=/u01/app/oracle/oradata/proe/example01.dbf
channel ORA_DISK_1: starting piece 1 at 07-JUL-20
channel ORA_DISK_1: finished piece 1 at 07-JUL-20
piece handle=/u01/app/backup/example_bs_20200707 tag=TAG20200707T171524 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 07-JUL-20
不加 as backupset也可以，默认就是这个。
压缩备份集：
RMAN> backup as compressed backupset tablespace example format '/u01/app/backup/example_c_bs_%T';
Starting backup at 07-JUL-20
using channel ORA_DISK_1
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00005 name=/u01/app/oracle/oradata/proe/example01.dbf
channel ORA_DISK_1: starting piece 1 at 07-JUL-20
channel ORA_DISK_1: finished piece 1 at 07-JUL-20
piece handle=/u01/app/backup/example_c_bs_20200707 tag=TAG20200707T171834 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 07-JUL-20查看一下这3个备份的大小：
还是有一些差距的。
查看备份：
备份集：
镜像备份：
注意：如果这个备份文件已经在系统层面删除了，在这里还是会存在。
这样再查看就不会存在了：
3. RMAN支持哪些文件备份：
SYS@proe>select * from v$rman_backup_type;
WEIGHT INPUT_TYPE
---------- -------------
1 BACKUPSET 备份集
2 SPFILE spfile
3 CONTROLFILE 控制文件
4 ARCHIVELOG 归档日志文件
5 DATAFILE INCR 数据文件增量备份
6 DATAFILE FULL 数据文件全量备份
7 DB INCR 整库增量备份
8 RECVR AREA 闪回区备份
9 DB FULL 数据库全备（0级）
9 rows selected4. 数据库各类文件备份操作：
- 参数文件的备份与恢复：
Oracle中参数文件按照是否可以直接修改分为了动态参数文件和静态参数文件，动态参数文件是二进制的无法直接修改也就是spfile是可以通过RMAN进行备份的，静态参数文件pfile只能通过物理备份copy的形式来做。
如上，命令和最终备份片的位置。
模拟参数文件丢失场景：
将spfile文件修改名字模拟spfile损坏（pfile，spfile有一个就可以启动数据库所以都要改一下）：
然后启动就会报错，
通过RMAN进行恢复：
启动伪实例（仅用于参数文件恢复）
再重新查看发现文件已经生成：
- 控制文件备份与恢复：
控制文件进行备份：
查看关于控制文件的备份信息：
整体恢复方式和参数文件恢复类似，但是由于控制文件中记录着数据库的变化所以在恢复之前一定要更新SCN号，使用recover。
RMAN> alter database open resetlogs;
使用resetlogs的原因是recover命令只能修复控制文件中数据库物理结构信息，而无法修改控制文件中的当前重做日志的
序列号等信息，recover命令执行完毕后，控制文件中当前在线日志序列号仍然是陈旧的。虽然使用了resetlogs，但是因
为recover database命令成功执行已提交的事务不会丢失，resetlogs仅仅是为了照顾还原的控制文件，与不完全恢复的
resetlogs是不同的。- 数据文件的备份与恢复：
需要使用rman备份的时候数据库必须是归档模式
备份数据文件的类型：文件级别，表空间级别，整库级别
1）备份系统表空间system：
对system表空间下的表做一些操作：
切换几次日志：
模拟系统表空间文件损坏：
此时系统出现问题崩溃：
从下面的图片来看，系统表空间文件是关键性的系统数据文件，一旦损坏数据库可以启动到mount状态但是无法打开。也就是说这个时候元数据信息是可以看到的因为已经mount数据库了。
接下来进行RMAN恢复。
查看关于系统表空间的备份信息：
还原system表空间：
修复system表空间：
启动即可：
再次查看表信息：
备份后删除的表不存在了，说明表空间恢复并不涉及表空间下的表。表仍需单独备份。
查看数据文件信息：
已经恢复。
2）非关键性数据文件：
模拟普通数据文件损坏如何通过RMAN备份进行恢复。
首先创建模拟需要的表：testtable，testtable2并相应的插入一些数据。
可以看到在TEST_1这个表空间下存在两个测试用的表。
对这个表空间进行RMAN备份
查看RMAN备份信息可以看到备份已经成功。
备份已经完成，接下来对这个表空间里面的表进行一些操作使其内容发生一些变化。我们插入一些数据。
然后我们需要将这个表空间的表的数据文件进行破坏掉。
首先查找这个表空间的数据文件在哪里。
确定文件位置后进行模拟删除。建议使用cp复制模拟删除。
数据文件模拟删除后，需要把数据库缓存刷新掉，把内存缓冲区数据写回到数据文件，然后ckpt进程就会发现错误，实例从而崩溃。
此时查看数据库的状态：
为打开状态未崩溃，说明此时数据文件已经同步想要从数据文件读数据到缓冲区时才发现文件错误，并不会导致实例崩溃。
进入RMAN恢复阶段
此时实例未崩溃所以需要将这个表空间先做离线处理。注意immediate直接离线避免脏块写入。
进行表空间还原操作：
而后进行表空间修复：
最后将表空间置于在线即可。
查看表数据可以看到后期插入的数据也已经还原。
另外一种情况就是，当数据文件损坏时实例直接崩溃，失去连接。重新连接并启动，只能将数据库启动到mount状态。这个时候直接进入RMAN进行上述表空间还原操作和表空间修复操作即可。然后将数据库open。
- 归档日志文件备份：
RMAN默认就是识别归档日志的。
查看所有的归档日志：
查看所有RMAN备份的归档日志：
通过RMAN备份所有的归档日志：
删除备份的归档日志：
通过指定备份归档日志的SCN来确定起始点备份：
指定scn范围进行归档日志恢复：
5. RMAN备份的几个恢复场景：
- 不完全恢复:
首先先做一下数据库的全备：（全备针对数据文件和参数文件及文件）
接着查询一下系统当前的SCN：
人为模拟一下误操作。这是当前employees表的情况。
将这个表进行truncate操作：
这里出现一些问题，表因为主键被其他表的外键所引用所以无法进行truncate操作，解决办法就是，让这个表主键临时失效，执行完再重新使其生效。
HR@proe>truncate table HR.employees;
truncate table HR.employees
*
ERROR at line 1:
ORA-02266: unique/primary keys in table referenced by enabled foreign keys
HR@proe>alter table employees disable primary key cascade;
Table altered.
HR@proe>HR@proe>truncate table employees;
Table truncated.
HR@proe>alter table employees enable primary key;
Table altered.
执行完误操作此时表是这个状态：
接下来通过RMAN进行不完全恢复操作，重新获取正确的数据:
使用RMAN进行一致性关库：
在RMAN中启动数据库到mount状态：
还原数据库：
修复数据库到指定的SCN：
这个时候查询这个数据库：
因为此时数据库还是处于mount状态但是不可以直接open需要执行resetlogs。因为不完全恢复的日志并不是连续的所以需要将日志重置。
在RMAN中修改数据库的状态使其启动：
重新查询这个表的信息可以看到已经恢复：
- 整个数据库的完全恢复：
注意：备份在数据库open状态，恢复是在数据库的mount状态。
整库备份需要备份的文件：
所有的数据文件，日志文件，控制文件，参数文件
模拟过程：
开始备份：
1）确定当前数据库的状态：（需要处于open状态）
2）进入RMAN开始备份：
RMAN> sql'alter system archive log current';
sql statement: alter system archive log current
## 这里额外说明一下'alter system archive log current'和'alter system switch logfile'的区别。从表面来看，前者会对数据库中所有实例执行日志切换，后者只会针对单实例数据库或者RAC中的当前实例进行日志切换。所以在RAC中进行日志切换时往往会使用前者。更深层次的来看，前者需要数据库开启归档，不开启归档的话需要指定到具体的日志组才行并且这个日志组不可以是当前日志组。同时这个命令中的current是指当前的日志组，所以在归档之前一定会先切换日志，所以这个命令伴随着日志组的切换。而后者主要针对的是日志组与是否开启归档无关，主要作用就是强制切换日志组。如果开启了归档发生了日志组的切换那么必然会发生归档，如果没开启数据库归档那么归档肯定不能发生但是日志组还是会被强制切换。
RMAN> crosscheck archivelog all;#校验控制文件和实际物理文件差别。这个命令和下面的命令往往一起使用，单纯的校验并不会影响最终备份的结果。
released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
...
archived log file name=/u01/app/oracle/fast_recovery_area/PROE/archivelog/2020_07_13/o1_mf_1_1_hjr1nnno_.arc RECID=50 STAMP=1045666836
Crosschecked 12 objects
RMAN> delete expired archivelog all;#进行控制文件和物理文件同步，关于这两个RMAN管理维护命令以后会继续细讲。
released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=572 device type=DISK
specification does not match any archived log in the repository
RMAN> sql'alter system switch logfile';#强制切换日志。
sql statement: alter system switch logfile
备份数据文件：
关于plus archivelog,这个命令会让RMAN首先备份归档日志，然后切换当前的在线日志并归档这个日志，然后再把最新的归档日志进行备份。
备份参数文件：
备份控制文件：
注意：
如果在使用db_recovery_file_dest作为备份文件生成的路径情况下，生成备份文件的副本那么将产生ORA-19806错误。
RMAN-03009: failure of backup command on ORA_DISK_1 channel
ORA-19806: cannot make duplex backups in recovery area
解决方式，将备份路径指定为非db_recovery_files_dest的目录
RMAN> backup tablespace users format '/home/oracle/%U.dbf';
开始恢复：
查看当前备份路径下有哪些文件：
可以看到进行数据文件备份时生成了两个文件，所以这也是为什么命名后缀为%U的原因，因为在进行数据库全备的时候，控制文件会自动备份当前数据库的控制文件和参数文件也就是上面较小的database文件，如果名称重复则会在这里报错。
1）首先恢复参数文件。
查看当前用户的SID。
进入RMAN，启动伪实例数据库到nomount状态后恢复参数文件。
这里可能会出现了一个报错，具体原因查看https://www.cnblogs.com/plutozzl/p/13293789.html
参数文件恢复成功，关闭伪实例重新启动到nomount状态。
可以看到没有报错了。
2）恢复控制文件：
此时数据库处于nomount状态。mount会报错
所以仍然需要恢复控制文件：
恢复成功，这个时候可以将数据库mount并查看备份信息。
3）恢复数据文件：
还原数据库：
修复数据库：
4）整库恢复完成打开数据库即可：
这里还是需要加上resetlogs参数的，因为控制文件也是恢复而来的所以日志需要重置。
恢复成功：
这种方式可以用来进行数据库的迁移，但是如果在一个新库中恢复RMAN备份的路径必须一致。