1、数据库备份
物理备份
热备：在数据库开机状态下进行的备份。
冷备：数据库关闭的情况下，进行操作系统文件的拷贝（注意此时关闭数据库库必须是按照正常情况关闭的）。
逻辑备份
2、物理热备
recovery manager(RMAN)
是一个客户端应用程序，用于数据库的备份和恢复。rman的体系结构由rman客户端、目标数据库、恢复目录组成。
3、recovery catalog（恢复目录，rman资料库）
归档日志的名字记录在控制文件中
如果使用恢复目录，则归档日志的名字记录在recovery catalog恢复目录（中）
recovery catalog恢复目录存放的元数据信息
1、数据文件和归档日志文件的备份集（backup sets）和备份碎片的信息。
2、数据文件副本的信息
3、归档日志文件及副本的信息
5、存储脚本
6、rman的配置信息
4、归档日志文件
1、每个节点都有自己的回滚表空间
2、每个节点都有自己的联机重做日志
3、每个节点都有归档日志文件
5、还原（restore）和恢复（recovery）区别
restore 是使用备份文件，将数据库还原到过去的某个状态，是对备份的数据文件等的简单还原。
recovery是应用online redo logs和归档日志将数据库做向前恢复。
6、热备的环境准备。
[root@rac1 ~]# olsnodes -s
rac1 Active
rac2 Active
[root@rac1 ~]#
两节点的集群
设置闪回区的大小：
su - oracle
sqlplus / as sysdba
alter system set db_recovery_file_dest_size=2g scope=both sid=’*’;
设置闪回区的路径
alter system set db_recovery_file_dest='+DATA' scope=both sid='*';
需要注意闪回区经常会满，导致数据库hang住。
在热备时，要求数据是归档状态，所以下面需要使数据库在归档状态。
关闭完成后，在集群中任意一个节点，把数据库启动到mount阶段
su - oracle
sqlplus / as sysdba
startup mount;
执行开归档命令
alter database archivelog;
执行打开数据库
alter database open ;
查看数据库的状态
srvctl status database -d tar
验证数据库是否是归档状态
sqlplus / as sysdba
select log_mode from v$database ;
archive log list
两种方式都能验证是否已经开启归档。
归档路径和归档大小都在闪回区，就是我们前面指定的。
下面可以查看归档日志文件
set linesize 1000;
column name format a90;
select name,status from v$archived_log ;
测试环境准备好就可以备份数据库了
首先必须记住数据库的DBID
select dbid from v$database ;
3086949231
创建测试表
create table cust8(
cust_id number,
last_name varchar2(30),
first_name varchar2(30)
);
插入4条记录
insert into cust8(cust_id,last_name,first_name) values(7,’acer’,’scott’);
insert into cust8(cust_id,first_name) values(5,’stark’,’jim’);
insert into cust8(cust_id,first_name) values(3,’grey’,’bob’);
insert into cust8(cust_id,first_name) values(11,’khan’,’brad’);
commit ;
select * from cust8;
刚才插入的数据可能还在联机日志里面，并没有到数据库归档中去，所以我们执行日志切换，生成归档
alter system switch logfile;
su - oracle
rman nocatalog target sys/root123
记住我们平时在开始就应该记录每个数据库的dbid，不要在数据库完蛋的时候才想起来没有dbid。
configure controlfile autobackup on ;
show all
show snapshot controlfile name;
创建一个目录存放我们的备份文件
mkdir /taryartar/12c/db_base/BKDIR
然后我们就可以通过脚本全备数据库：
run{
allocate channel t1 type disk Format '/taryartar/12c/db_base/BKDIR/fullBK%s_%p_%t.bak';
set controlfile autobackup format for device type disk to '/taryartar/12c/db_base/BKDIR/c_%F.control';
backup database ;
release channel t1 ;
}
执行数据库的全备份。
全备完成后，我们在插入四条数据，模拟数据库全备后数据库继续运行了一段时间
insert into cust8(cust_id,first_name) values(14,’after fullbak’);
insert into cust8(cust_id,first_name) values(15,first_name) values(16,’after fullbak’);
commit;
select * from cust8;
日志切换，生成归档
alter system switch logfile;
set linesize 1000;
column name format a60;
select name,completion_time from v$archived_log;
得到归档日志名字，记录下来最后一个名字：
sql> select name,completion_time from v$archived_log;
NAME COMPLETIO
------------------------------------------------------------ ---------
+DATA/TAR/ARCHIVELOG/2017_12_24/thread_1_seq_22.300.96359306 24-DEC-17
5
+DATA/TAR/ARCHIVELOG/2017_12_24/thread_2_seq_5.301.963604847 24-DEC-17
+DATA/TAR/ARCHIVELOG/2017_12_24/thread_2_seq_6.302.963606783 24-DEC-17
sql>
backup archivelog all delete all input format '/taryartar/12c/db_base/BKDIR/arch_%s_%p_%t';
这里我们并没有备份控制文件和初始化参数文件，但是在输出可以看出，数据库自动备份了控制文件和初始化参数文件
破坏数据库
srvctl stop database -d tar -o abort
查看数据库状态
srvctl status database -d tar
所有实例都没运行了。
asmcmd
rm -rf +DATA/tar/AUTOBACKUP/*
rm -rf +DATA/tar/DATAFILE/*
rm -rf +DATA/tar/ONLINELOG/*
rm -rf +DATA/tar/TEMPFILE/*
rm -rf spfiletar.ora
rm -rf +DATA/tar/CONTROLFILE/*
rm -rf *
su - grid
asmcmd
rm -r -f +DATA/tar/DATAFILE/*
rm -r -f +DATA/tar/CONTROLFILE/*
su - oracle
sqlplus / as sysdba
startup
数据库起不来了。
注意关掉，下面要进行恢复了。
恢复数据库
rman nocatalog target sys/root123
一定要设置dbid
set dbid 3086949231
这个值是前面已经查询后记录下来的。
启动数据库到nomount阶段
startup nomount ;
启动到这一步是为了恢复spfile，如果你的spfile没有被破坏，可以不需要执行这一步，直接启动到mount阶段。
启动实例后，才能还原spfile：
restore spfile to '+data/tar/PARAMETERFILE/spfiletar.ora' from '/taryartar/12c/db_base/BKDIR/c_c-3086949231-20171224-00.control';
从备份中还原spfile，所以我们要确定上面我们把spfile和控制文件备份在哪儿了，文件名是是啥。
注意新还原的spfile路径在你删除原有spfile文件的时候，PARAMETERFILE路径也会一块被删掉了，所以主要要验证你的PARAMETERFILE路径是否存在。
查看目标目录，发现文件应来了：
下面还原控制文件
shutdown abort;
startup nomount ;
set dbid 3005509599;
然后从备份中还原控制文件：
restore controlfile from '/taryartar/12c/db_base/BKDIR/c_c-3086949231-20171224-00.control' ;
然后就可以重启实例到mount阶段了。
shutdown abort;
startup mount ;
下面就可以还原数据库了：
restore database ;
注意，此处为什么直接可以执行restore database而不用像上面恢复spfile和控制文件一样，需要指定从哪边的备份文件恢复呢？
因为此时已经是mount状态了，控制文件已经生效了，所以此时就按照控制文件中的存在的信息来进行恢复的，而控制文件是在我们全备的时候备份的，所以里面已经知道全备的文件具体路径了。
执行完成以后，控制文件是全备的时候的控制文件信息，这个里面并不包括我们在全备以后做的归档日志文件的备份信息，因此，我们需要把备份集添加（注册）到catalog中：
list backupset of archivelog all;
catalog backuppiece '/taryartar/12c/db_base/BKDIR/arch_8_1_963606886' ;
list archivelog all;
list backupset of archivelog all;
然后就可以执行数据库的恢复了
recover database ;
到最后应用归档时，到最后会报错，因为他应用到最后一个归档后还会朝后面应用，导致找不到归档了，这个错误可以忽略。
然后就可以打开数据库了：
alter database open resetlogs ;
注意本实验都在一个节点上做的，注意本实验的归档文件在共享磁盘+DATA中，这样两个节点产生的归档都在一起，对单实例可以同时访问，这样我们在一个节点上做归档日志文件的备份时，可以同时备份两个节点的归档日志文件。
验证数据库是否起来：
验证我们测试表中的数据是否回来了：
发现全备之后插入的数据也回来了，恢复成功！
启动节点一的实例：
检查集群资源：
集群资源没问题。
