RMAN备份还原专题(持续更新)

2021-11-02 本文已影响0人这货不是王马勺

原理

CDB架构
database：
数据文件datafiles：存储数据库本身的信息（如数据字典信息，cdb和pdb分别），以及存储业务数据
控制文件controlfiles：二进制的小文件，记录数据库物理状态，维护数据库的一致性（比如数据库有多少数据文件有多少日志文件，放在那里）,因为很重要所以一般我们都设置多个，互为镜像
联机日志文件online redo logfile：简称日志文件，是事务持久性保证机制。通常我们有多个日志组，每个日志组有两个成员。
其中控制文件和日志文件都在根容器(cdb)中，是所有容器共享使用的，是针对整个CDB的。
pdb拥有自己的数据文件（常见的system、sysaux、temp、undo表空间）

instance:
memory + background processes
非cdb和cdb的instance是一样的，所以在多租户架构中实例也是pdb共享的。
SGA中最重要的区域：
共享池shared pool：进行SQL解析、缓存SQL文本及执行计划、缓存最近使用的数据字典定义信息
数据缓冲区database bufer cache：缓存数据,空间最大
日志缓冲区redo log buffer：空间较小（几十M）
background processes：
如smon pmon dbwr lgwr ckpt等...
dbwr：懒写，延迟写
lgwr：速写，频繁写

两do一点
redo日志：记录的核心内容是block change（数据块变化）
undo日志：undo表空间，所以undo表空间的变化也会记录到日志中
checkpoint检查点

图片.png

备份还原步骤：
restore:转储(还原)，cp .bak .dbf
recover:恢复(应用日志)，apply redo log(archive redo logfiles + online redo log files)

recover
恢复到故障时间点前，成为完全恢复；
如果归档日志不连续丢掉了，或者只想恢复到之前的某个时间点，这种成为不完全恢复；
非归档模式只能冷备（一致性备份），开来归档模式则可以热备（非一致性备份）

图片.png
由此可见生产环境开归档日志的重要性。

开启归档模式

如果我们没有配置快闪恢复区或者手动设置归档日志目录的话，默认路径是$ORACLE_HOME/dbs/目录下，以arch开头

配置快速恢复区大小和路径

alter system set db_recovery_file_dest_size=5G;
alter system set db_recovery_file_dest='/u01/flash';
archive log list;

设置归档目录

show parameter log_archive_dest;
alter system set log_archive_dest_1='location=/u01/arch';

上述配置完后，开启归档模式

shutdown immediate;
startup mount;
alter database archivelog;
archive log list;
alter database open;
select group#, sequence#, status,first_change#, next_change# from v$log;

手动切换日志，查看归档日志的sequence及切换号码

alter system switch logfile;
col name for a50
select name , sequence#, status,first_change#, next_change# from v$archived_log;

RMAN备份

RMAN可以比较好地操作cdb和pdb的备份，同时pdb的备份恢复可以通过cdb来完成。
1.RMAN中的新语法和子句
pdb是没有实例概念的，连接到pdb语句参考:

rman target sys/123456@192.168.0.15/pdb1
rman target sys/123456@localhost:1521/pdb1

新语法和子句

连接到cdb，并查看schema、表空间、数据文件等信息:

rman target /
report schema;

注：如果连接到pdb中进行report schema则只显示pdb内部的schema、表空间和数据文件；
备份内容取决于连接的方式：
我们如果连接cdb进行backup database;时能看到，过程是先备份cdb、再备份所有pdb；
我们如果连接pdb进行backup database;时能看到，过程是只备份连接的pdb；

pdb备份打印的结果

2.连接到cdb进行备份
如上所述，备份完整cdb需要连接到cdb执行备份命令

rman target /
backup database;

备份部分cdb内容需要用backup pluggable database...语句，示例：

backup pluggable database "CDB$ROOT", pdb2;
backup pluggable database pdb1 plus archivelog;

只备份部分表空间：

backup tablespace system, pdb1:users, pdb2:sysaux;

备份部分cdb

如果不加format参数，那么备份文件默认放在闪回恢复区中。

backup pluggable database pdb1 format '/backup/pdb1_%D_%U.bak';

全备脚本

（可以在此脚本基础上添加一些参数，注意切换归档一定要用图中语句，因为如果是RAC环境下，这样写两个都会切换；如果用alter system switch logfile则只能切换当前实例的；控制文件一定要最后备份，因为控制文件记录了备份信息，这个顺序不能乱）
查看备份集：

list backupset;

删除备份：

delete backupset;

连接到pdb进行备份，命令和11g基本相同。

RMAN恢复文件

1.临时文件重生成
临时文件无法使用RMAN备份，理论上也无需备份；
当临时文件丢失时数据库能启动，但是有些会使用temp的操作会报错；
我们重启数据库后会自行创建临时文件，在打开PDB时也会重建pdb级别的临时文件，当然我们也可以手工创建（临时表空间添加临时文件）

alter tablespace temp add temp file '/data/oracle/oradata/CDB1/PDB1/temp_02.dbf'

临时文件操作

2.控制文件恢复
查看控制文件信息：

show parameter control

其中contril_files显示的就是所有控制文件及副本。
控制文件非常重要，缺少控制文件我们数据库是无法mount起来的（ORA-00205）;
查看告警日志路径

select * from v$diag_info;

然后到OS查看：

tailf /u01/app/oracle/diag/rdbms/prodcdb/prodcdb/trace/alert_prodcdb.log

我们会发现和控制文件有关的报错（ORA-00210、ORA-00202、ORA-27037）
控制文件的恢复方式很多，最靠谱的还是用RMAN恢复
先启动实例并从备份中还原控制文件

RMAN>connect target /
RMAN>startup nomount;
RMAN>restore controlfile from autobackup;

在打印结果中outputfile就是生成的文件。
查看数据库处在启动的哪个阶段

select open_mode from v$database;

进行数据库恢复：

alter database mount;
recover database using backup controlfile;

之后需要输入提示的联机日志文件的路径；
如何查看？

set linesize 1000;
select * from v$log;

recover

数据库启动至open：

alter database open resetlogs;
alter pluggable database all open;

(resetlogs执行的是不完全恢复)

总结
（一般spfile和控制文件是一起备份的）
备份控制文件各种方法参考：http://blog.itpub.net/26736162/viewspace-2152115/
如将另一份控制文件拷贝到原目录下等等...（不过两个控制文件版本可能不一致，因此都建议备份，用高版本覆盖低版本）
博客首页：http://blog.itpub.net/26736162/

3.日志丢失
日志分为在线和归档两种，RMAN不会备份在线的日志文件，RMAN只备份archivelog

conn / as sysdba
select * from v$log;

联机日志文件状态:current, active, inactive unused
对于日志的恢复，主要和日志文件的状态有关。
如果联机日志损坏，那么需要分情况进行恢复：
①inactive redo异常
报错ORA-00316 ORA-00327

startup mount;
alter database clear logfile group 2;
alter database open;

②active、current异常(正常关闭数据库)
报错ORA-00316 ORA-01623

报错
查看状态发现是active

select * from v$log;

之后需要如下方法启动

alter database clear unarchived logfile group 1;
#如果上面方法不行，采用下面方法
--alter database clear logfile group 1;
recover database until cancel; #输入具体的联机日志文件
alter database open resetlogs;

recover

其中recover的时候要输入对应的log文件，如此处的sequence#5对应的是redo01.log
（在sqlplus中用!可以执行OS层的命令）

③active、current异常(异常关闭数据库)
ORA-00316 ORA-01624 ORA-01194
需要设置隐含参数（慎用）

图片.png

alter system set "_allow_resetlogs_corruption"=true scope=spfile;
recover database until cancel;
alter database open resetlogs; #这里肯定会报错，因为没重启，spfile没生效
startup force mount
alter database open resetlogs
alter system set "_allow_resetlogs_corruption"=false scope=spfile;
alter system reset "_allow_resetlogs_corruption" scope=spfile sid='*';
shutdown immediate; #如果无法正常关闭则shutdown abort
startup

之后再通过expdp进行逻辑导出再导入到正常实例。
如果我们有RMAN备份，我们不用上述方法，执行正常的不完全恢复即可：

startup nomount;
restore controlfile from '/u01/app/oracle/fast_recovery_area/CDB1/autobackup/o1_mf_s_1046464187_hkjd9w0c_.bkp'; #先恢复控制文件
alter database mount;
restore database;
recover database until sequence 30;
alter database open resetlogs;

直接recover database的打印结果

sequence 30

4.根system或undo
查看

select name from v$datafile;

然后我们模拟删除undo数据文件
之后startup force报错，提示我们缺少4号文件

报错

我们可以直接恢复4号文件

restore datafile 4;
recover datafile 4;
alter database open;

也可以写成恢复表空间

startup mount;
restore tablespace undotbs1;
recover tablespace undotbs1;
alter database open;

5.sysaux
可以在线恢复
查file号

select file# ,name ,con_id from v$datafile;

进行如下操作

alter session set container = pdb1;
alter database datafile 9 offline ;  #可加immediate

进入RMAN进行如下操作

restore datafile 9;
recover datafile 9;

然后回到sqlplus:

alter session set container = pdb1;
alter database datafile 9 online;

图片.png

基于时间点的恢复（point-in-time Recovery,PITR）——不完全恢复

（完全恢复：恢复到最新的一个commit;
不完全恢复：恢复到某个时间点、日志序列号、或SCN号）
也可以表空间恢复到某个时间点。

list incarnation

incarnation可以理解为过去某个时间点的状态，但不是快照的概念。每次执行一次resetlogs都会生成一个incarnation;
这个是针对cdb的，pdb的原型需要查看v$pdb_incarnation;

set linesize 1000
select * from v$pdb_incarnation;

PDB执行PITR
查看scn号

select current_scn from v$database;
alter session set container = pdb1;
select current_scn from v$database;

我们会发现pdb中查看到的和cdb中的不一样

PDB执行PITR：

图片.png

表空间执行PITR：

图片.png

CDB执行PITR：

图片.png

在CDB执行表空间PITR：

图片.png

本机还原1级备份思路：
先关闭数据库，启动到nomount状态，利用目标控制文件的备份来恢复控制文件，再启动到mount，进行restore和recover
参考：https://blog.csdn.net/weixin_44272648/article/details/104503656

【例】
在前端有一个页面查不出数据，在数据库查对应表的数据报ORA-00376和ORA-01110的错误。
查看文件是否有问题：

select file#,status from v$datafile; 
select name,checkpoint_change# from v$datafile;

发现file 16和 17两个文件的SCN与其他不一致，而这两个文件是在网络磁盘上的，怀疑是昨日网络问题导致的，
此前在mount状态尝试restore datafile 16恢复数据文件，alter database datafile 16 online;都不好使，因此决定恢复到断网前状态。

shutdown immediate;
startup nomount;
restore controlfile from 'E:\FRA\RMAN\C-3280657922-20211227-01.BAK'; #恢复当时的控制文件
alter database mount;
restore database; #还原相应备份片，时间较长
#recover database; 发现归档日志已清除，找不到SCN 260141207之后的归档日志
recover database until scn 260141207;
alter database open resetlogs;

如果发现时间不久，归档日志都还在的话可以按时间点恢复

shutdown immediate;
startup mount;
restore database; #还原相应备份片，时间较长
recover database until time "to_date('2021-10-24 10:00:00','YYYY-MM-DD HH24:MI:SS')";
alter database open resetlogs;

备注：
scn转换成时间点：

select to_char(scn_to_timestamp(1123574))from dual;

时间点转换成scn：

select timestamp_to_scn('31-OCT-18 01.29.58.000000000 PM') from dual;

RMAN异机恢复
参考http://blog.itpub.net/26506993/viewspace-1873417/

RMAN备份还原专题(持续更新)

原理

开启归档模式

RMAN备份

RMAN恢复文件

基于时间点的恢复（point-in-time Recovery,PITR）——不完全恢复

猜你喜欢

热点阅读