oracle recovery testing

Recently did a test restore rman, and record it.

Open two terminals:

rman:rman  target  /;

sql:sqlplus / as sysdba;

Let me talk about incremental backup and the full amount of the increment is based on the full amount of do

Incremental and cumulative incremental difference into differential incremental

Differential Incremental:

Backup logical: Current Level Level n n to the last or last data is less than the increase in period n

Detailed RMAN backup levels

Cumulative Incremental difference:

Backup logical: the current level n to the last period is less than the increased level n data

Detailed RMAN backup levels

Photo: http://blog.sina.com.cn/s/blog_70ca64640100v5g9.html

Because this backup uses Sunday: Full leve 0, Monday through Saturday increment leve 1 

So to restore recovery database (full recovery amount), recover database (incremental recovery section, media recovery)

1. Parameter File

Because it is different machine recovery, memory size are not the same, accidentally parameter files to restore (actually also forgot to back up), and finally had to initialize the next parameter file,

In fact, when restoring parameter files can be restored without first, unless environmental same

The original location query: show parameter spfile;

---/home/opt/oracle/11g/dbs/spfilepdm.ora

rman:
restore spfile  to '/home/opt/oracle/11g/dbs/spfilepdm1.ora'  from '/home/opt/oracle/pdm_recovery_bak/20190609/pdm_lev0_201906092200_c-2539989307-20190610-01'

create pfile from spfile; generates initxxx.ora files
modified pfile 
If still unsuccessful init.ora copied from a template change it

2. Restore the control file

Since writing the information in the control file when this backup set, so it needs to be restored control file in order to use list backupset Queries a backup set information. (Another backup set can also be written in the database, is generally used when more than one database backup, easy management)

rman:
alter databaser nomount;
restore controlfile from '/home/opt/oracle/pdm_recovery_bak/20190609/cntl_lev0.bak';

alter database mount时报:
ORACLE报错 ORA-00201: control file version 11.2.0.4.0 incompatible with ORACLE version 11.2.0.0.0 

以pfile启动(创建出pfile文件,删除spfile文件即可,create pfile from spfile;会生成initxxx.ora的文件),手动修改pfile文件中的版本为11.2.0.4.0

3.备份的数据集过期

rman:
crosscheck backup;#验证备份集信息是否过期,如果过期,需要删除后重新注册
delete expired backup;#删除过期的备份集信息,这个只是删除了控制文件中的备份信息


rman:
catalog start with '/home/opt/oracle/pdm_recovery_bak/';#重新注册

rman:
list backup summary;查看备份集注册情况

4.恢复数据文件

restore database;如果目录不同会恢复失败执行

圈中的是datafile文件号,由于数据库与备份集数据库的数据文件的存储路径不一致,所以需要设置下路径,运行下面的脚本:

由于数据文件较多,所以只粘了下面的模板:

rman:
{
set newname for datafile 1
  to 'C:\oracle\product\10.2.0\oradata\orcl\SYSTEM.DBF';  #实例中SYSTEM.DBF放置的位置
   set newname for datafile 2
   to 'C:\oracle\product\10.2.0\oradata\orcl\UNDOTBS1.DBF';
   set newname for datafile 3
   to 'C:\oracle\product\10.2.0\oradata\orcl\SYSAUX.DBF';
   set newname for datafile 4
   to 'C:\oracle\product\10.2.0\oradata\orcl\USERS.DBF';
   set newname for datafile 5
   to 'C:\oracle\product\10.2.0\oradata\orcl\PDM_DATA.DBF';
restore database;
recover database;
switch datafile all ; 
}

查看恢复进度

sql:
select sid,opname,serial#,context,sofar,totalwork,round(sofar/totalwork*100,2) "%_complete" from v$session_longops where opname like 'RMAN%' and opname not like '%aggregate%'   and totalwork  != 0  and sofar <> totalwork  order by "%_complete" des

可以看到文件正在恢复

实际上由于空间不足的问题,我是分开恢复的,,先恢复的全量大慨600多个G的文件(模板中的set newname 到restore database部分),之后把全量的文件删掉,把控制文件中的全量的备份集注册信息删掉(步骤2),然后(模板中的set newname 到去掉restore database部分)

执行完成后会出现下面的错误:

这是由于数据库重新启动的时候,Oracle将文件头中的那个启动scn(v$datafile_header中记录的scn)与数据库文件检查点scn进行比较,如果这两个值相互匹配,oracle接下来还要比较数据文件头中的启动scn和控制文件中数据文件的终止scn。如果这两个值也一致,就意味着所有数据块多已经提交,所有对数据库的修改都没有在关闭数据库的过程中丢失,因此这次启动数据库的过程也不需要任何恢复操作,此时数据库就可以打开了。当所有的数据库都打开之后,存储在控制文件中的数据文件终止scn的值再次被更改为null,这表示数据文件已经打开并能够正常使用了。如果数据库是异常关闭或者通过不完全恢复过来的,那么终止scn会是null,所以启动数据库时,就需要做实例恢复,利用online redolog来恢复数据库,这也就是实例启动时,SMON进程会去利用redolog做恢复,俗称‘前滚‘数据库。(此段文字摘自:https://blog.csdn.net/qq_22935429/article/details/50558321 

 

最后一行的scn就是能恢复到的scn

执行:recover database until scn XXXXX;

这时报redo文件不存在,是因为我的数据库和备份集中redo路径不一致导致的

  sql:
select * from v$logfile;-- 查出当前控制文件所记录的redo路径

select sequence#,group#,status from v$log; --当前redo文件的组号和状态

 

ORA-00349  redo路径不一致报的错误

修改路径:
         ALTER DATABASE RENAME FILE '/data/pdm/DATA/pdm/redo04.log'  TO '/home/opt/oracle/oradata/pdm/redo001.log';
         ALTER DATABASE RENAME FILE '/data/pdm/DATA/pdm/redo05.log'  TO '/home/opt/oracle/oradata/pdm/redo002.log';
          ALTER DATABASE RENAME FILE '/data/pdm/DATA/pdm/redo06.log'  TO '/home/opt/oracle/oradata/pdm/redo003.log';

 ora-00392 日志正在清除故障

select group#,bytes/1024/1024||'M',status from v$log;-- 查询清楚状态
 根据查出的组号执行下面sql语句
             ALTER DATABASE CLEAR LOGFILE GROUP 4;
             ALTER DATABASE CLEAR LOGFILE GROUP 5;
             ALTER DATABASE CLEAR LOGFILE GROUP 6;

此时rman执行 alter database open resetlogs;启动成功

xshell log rman executed: https://me.csdn.net/download/qq_35201754

Guess you like

Origin blog.csdn.net/qq_35201754/article/details/92573830