一、环境:
源端服务器:CentOS release 6.8 (Final)+Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
目的服务器:CentOS release 6.8 (Final)+Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
区别:oracle的安装目录略有不同:
源端服务器:
目标服务器:和原服务器放置数据文件、日志文件等路径不一致,所以需要在恢复时进行特别转换--见二-10中的脚本
二、恢复
1、根据spfile备份文件(strings)编辑pfile文件
a、导出spfile文件
[oracle@template RMANBAK_OA]$ strings Spfile_ORAECOLO_3891698553_20191104_114_1_1.bak }|{z ORAECOLOV TAG20191104T050112 ORAECOLOGY oraecology.__db_cache_size=654311424 oraecology.__java_pool_size=16777216 oraecology.__large_pool_size=16777216 oraecology.__oracle_base='/home/oracle/app'#ORACLE_BASE set from environment oraecology.__pga_aggregate_target=24813502464 oraecology.__sga_target=2147483648 oraecology.__shared_io_pool_size=0 oraecology.__shared_pool_size=1358954496 oraecology.__streams_pool_size=33554432 *.audit_file_dest='/home/oracle/app/admin/oraecology/adump' *.audit_trail='db' *.compatible='11.2.0.0.0' *.control_files='/home/oracle/app/oradata/oraecology/control01.ctl','/home/oracle/app/oradata/oraecology/control02.ctl' *.db_block_size=8192 *.db_domain='' *.db_name='oraecolo' *.db_recovery_file_dest_size=107374182400 *.db_recovery_file_dest='/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/' *.db_unique_name='oraecology' *.diagnostic_dest='/home/oracle/app' *.dispatchers='(PROTOCOL=TCP) (SERVICE=oraecologyXDB)' *.open_cursors=1000 *.pga_aggregate_target=24811405312 *.processes=500 *.remote_login_passwordfile='EXCLUSIVE' *.session_cached_cursors=300 *.sga_target=2147483648 *.undo_tablespace='UNDOTBS1' /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/spfileoraecology.ora
b、根据spfile文件编辑pfile;
查看上述strings spfile文件中的adump、control01.ctl、control02.ctl、dbs路径,并进行核对修改(如果目的路径和源路径一致,则不需要修改)
/adump:/home/oracle/app/oracle/admin/oraecology/adump
/control01.ctl:/home/oracle/app/oracle/oradata/oraecology/control01.ctl
/control02.ctl:/home/oracle/app/oracle/fast_recovery_area/oraecology/control02.ctl
/dbs:/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/
echo $ORACLE_BASE:/home/oracle/app/oracle/
diagnostic_dest='/home/oracle/app/oracle/'
[oracle@template dbs]$ vim initoraecology.ora oraecology.__db_cache_size=654311424 oraecology.__java_pool_size=16777216 oraecology.__large_pool_size=16777216 oraecology.__oracle_base='/home/oracle/app/oracle/'#ORACLE_BASE set from environment oraecology.__pga_aggregate_target=24813502464 oraecology.__sga_target=2147483648 oraecology.__shared_io_pool_size=0 oraecology.__shared_pool_size=1358954496 oraecology.__streams_pool_size=33554432 *.audit_file_dest='/home/oracle/app/oracle/admin/oraecology/adump' *.audit_trail='db' *.compatible='11.2.0.0.0' *.control_files='/home/oracle/app/oracle/oradata/oraecology/control01.ctl','/home/oracle/app/oracle/fast_recovery_area/oraecology/control02.ctl' *.db_block_size=8192 *.db_domain='' *.db_name='oraecolo' *.db_recovery_file_dest_size=107374182400 *.db_recovery_file_dest='/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/' *.db_unique_name='oraecology' *.diagnostic_dest='/home/oracle/app/oracle/' *.dispatchers='(PROTOCOL=TCP) (SERVICE=oraecologyXDB)' *.open_cursors=1000 *.pga_aggregate_target=24811405312 *.processes=500 *.remote_login_passwordfile='EXCLUSIVE' *.session_cached_cursors=300 *.sga_target=2147483648 *.undo_tablespace='UNDOTBS1'
2、加载数据库
RMAN> startup nomount pfile="/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/initoraecology.ora";
3、加载控制文件(可以加载最新控制文件)
RMAN> restore controlfile from "/home/BACKUP/RMANBAK_OA/control_ORAECOLO_3891698553_20191112_252.bak";
对两个控制文件都进行了还原/
4、挂载数据库:
RMAN> alter database mount;
5、检查备份
RMAN>crosscheck backup;
6、删除过期文件
RMAN>delete noprompt expired backup;
再次查看已经删除
RMAN>crosscheck backup;
7、转储restore前准备
因为不知道之前的还原目录和文件名称是什么,所以需要直接restore进行检验
经测试:
发现原路径为:
(1)/home/oracle/app/oradata/oraecology/undotbs01.dbf
(2)/home/oracle/app/oradata/oraecology/system01.dbf
(3)/home/oracle/app/oradata/oraecology/sysaux01.dbf
(4)/home/oracle/app/oradata/oraecology/users01.dbf
(5)/home/oracle/app/oradata/oraecology/system01.dbf
而本目的路径为:
(1)/home/oracle/app/oracle/oradata/oraecology/undotbs01.dbf
(2)/home/oracle/app/oracle/oradata/oraecology/system01.dbf
(3)/home/oracle/app/oracle/oradata/oraecology/sysaux01.dbf
(4)/home/oracle/app/oracle/oradata/oraecology/users01.dbf
(5)/home/oracle/app/oracle/oradata/oraecology/system01.dbf
下一步进行转换。
8、转储(还原)数据(restore database)——因为控制文件中,源端的dbf文件路径和目的端dbf文件路径不一致,所以需要用set newname for datafile更改路径到当前真实路径
run{ allocate channel a1 device type disk; allocate channel a2 device type disk; SET NEWNAME FOR DATAFILE '/home/oracle/app/oradata/oraecology/undotbs01.dbf' to '/home/oracle/app/oracle/oradata/oraecology/undotbs01.dbf'; SET NEWNAME FOR DATAFILE '/home/oracle/app/oradata/oraecology/system01.dbf' to '/home/oracle/app/oracle/oradata/oraecology/system01.dbf'; SET NEWNAME FOR DATAFILE '/home/oracle/app/oradata/oraecology/sysaux01.dbf' to '/home/oracle/app/oracle/oradata/oraecology/sysaux01.dbf'; SET NEWNAME FOR DATAFILE '/home/oracle/app/oradata/oraecology/users01.dbf' to '/home/oracle/app/oracle/oradata/oraecology/users01.dbf'; restore database; switch datafile all; release channel a1; release channel a2; }
restore完成:
9、恢复文件(recover):不完全恢复:
recover恢复增量备份中的1级增量文件、同时还原archilog备份文件到flash_recovery(根据initnc.ora路径/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/ORCL/archivelog)
RMAN> sql "alter session set nls_date_format=''yyyy-mm-dd hh24:mi:ss''";
RMAN> recover database until time '2019-10-27 04:00:00';
10、不完全恢复,出现报错,解决
不完全恢复会出现这个问题
Starting recover at 13-NOV-19
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 11/13/2019 10:24:27
RMAN-06555: datafile 1 must be restored from backup created before 12-NOV-19
(1)退出RMAN
RMAN> exit
(2)进入sql,创建spfile(当前是以pfile文件initoraecology.ora启动,未从spfile启动;下面执行语句需要以sfpile启动),
SQL> create spfile from pfile='/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/initoraecology.ora';
SQL> alter system set "_allow_resetlogs_corruption"=true scope=spfile;
(3)创建spfile后,如果要以spfile文件启动,需要shutdown immediate并再startup mount数据库,再进行更改系统设置(_allow_resetlogs_corruption_true)
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter system set "_allow_resetlogs_corruption"=true scope=spfile;
(4)更改完成后,重新shutdown immediate,并startup mount;
SQL> startup mount;
SQL> shutdown immediate;
(5)打开数据库,并加resetlogs
SQL> alter database open resetlogs;——至此,已经recover成功,需要单独处理redo01.log,redo02.log,redo03.log
11、处理redo01.log,redo02.log,redo03.log 问题。
原因:
a、还原的源端数据库记录的redo01.log在/home/oracle/app/oradata/oraecology/中。
但是目的端数据库记录在/home/oracle/app/oracle/oradata/oraecology/中,需要对此数据路径更改即可。
查看路径:SQL>select * from v$logfile;
b、在sql环境下执行更改语句,在数据库只mount状态下执行
SQL>alter database rename file '/home/oracle/app/oradata/oraecology/redo01.log' to '/home/oracle/app/oracle/oradata/oraecology/redo01.log';
SQL>alter database rename file '/home/oracle/app/oradata/oraecology/redo02.log' to '/home/oracle/app/oracle/oradata/oraecology/redo02.log';
SQL>alter database rename file '/home/oracle/app/oradata/oraecology/redo03.log' to '/home/oracle/app/oracle/oradata/oraecology/redo03.log';
执行后,查看路径:SQL>select * from v$logfile;已经更改完毕
12、执行打开数据库:redo02.log出现being cleared问题。
SQL> alter database open resetlogs;
-- 查看00392的故障描述信息:
SQL> ho oerr ora 00392
---查看当前日志信息:下面的SQL语句表名3个日志文件都处于clearing_current状态,进行清理
SQL> select group#,bytes/1024/1024||'M',status from v$log;
--执行CLEAR LOGFILE命令
SQL>
ALTER
DATABASE
CLEAR LOGFILE
GROUP
1;
SQL>
ALTER
DATABASE
CLEAR LOGFILE
GROUP
2;
SQL>
ALTER
DATABASE
CLEAR LOGFILE
GROUP
3;
--执行完后,再查看,已经恢复正常
SQL> select group#,bytes/1024/1024||'M',status from v$log;
13、再次打开数据库(不完全恢复),成功。
14、注意:关于上述使用隐含参数“_allow_resetlogs_corruption",有如下隐患:
当数据库中某些数据文件损坏,而从备份恢复这个文件所需的某个(或某些)联机日志文件或归档日志文件丢失时,只能把这些文件部分恢复,从而与数据库中其他文件不同步,我们可以通过下面的步骤还原并打开数据库:
{
1、用之前的备份恢复损坏的数据文件。
2、尽量还原损坏的文件。
3、把数据库启动到nomount。
4、用SQL命令重建控制文件(要求之前用“alter database backup controlfile to trace”做过控制文件的文本备份)
5、设置隐含参数:alter system set “_allow_resetlogs_corruption”=true scope=spfile;
6、然后关闭数据库,用下面命令重启:alter database open resetlogs
}
这时,数据库可以打开。但是数据库中的数据可能不一致,某些查询如果涉及这些不一致的数据,会遇到ora-600错误(最常见的是2662错误)。
打开数据库后,我们可以从部分恢复的数据文件及其他正常数据文件中导出尽可能多的数据,然后重建数据库,导入之前导出的数据,从而让损失降低到最小。
设置这个隐含参数后,要使用resetlogs选项打开数据库,隐含参数才会生效,否则Oracle在打开数据库时会忽略此参数。
Oracle告诉我们,强制resetlogs跳过了一致性检查,可能导致数据库损坏,数据库应当重建。通常使用此方法Open数据库之后,应该立即通过导出、导入重建数据库。
检验上述问题:
恢复后能打开数据库的原始是加入了隐含参数“_allow_resetlogs_corruption”,因此数据库打开时,会忽略数据一致性检查,所以我们需要重新把隐含参数去掉:
(1)查看当前sfpile文件:可以看到_allow_resetlogs_corruption=TRUE
(2)关闭数据库:shutdown immeidate
(3)删除当前spfile文件:
(4)进入sql,用pfile启动,并创建spfile,打开数据库并未报错。
SQL> startup nomount pfile="/home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/initoraecology.ora";
查看最新sfpile,_allow_resetlogs_corruption参数已经不存在了
(5)重新关闭数据库,再正常打开,此时加载的方式,加载的是spfile,默认有了数据一致性校验,所以我们至此恢复的数据时一致的。
查看SCN,三者一致,则ok。
select file#,to_char(checkpoint_change#,'99999999999999') from v$datafile;
select file#,online_status,to_char(change#,'99999999999999') from v$recover_file;
select file#,to_char(checkpoint_change#,'99999999999999') from v$datafile_header;
15、注意:temp01(临时表空间)文件在RMAN中不会自动恢复的,看下图:
(1)查看临时表空间:
SQL> select tablespace_name, file_name from dba_temp_files;
(2)目标数据库:temp01.dbf,时间仍然是早期的文件,并未被恢复到Nov 13这一天的。
(3)下图是还原时的文件,可以看出,并不包含temp01.dbf 文件。
(4)登录sql 查看,发现数据库中并不能查出符合条件的临时表空间(因当前环境中没有/home/oracle/app/oradata/oraecology目录)
原因是控制文件中记录的的临时表空间的数据位置是在/home/oracle/app/oradata/oraecology,而不是在/home/oracle/app/oracle/oradata/oraecology中;所以可以通过创建新的临时表空间linshi_temp,并将linshi_temp设置为默认表空间,并删除原temp表空间。
a、--删除整个临时表空间及数据文件(无法直接删除)
SQL>drop tablespace temp including contents and datafiles;
无法直接删除,重新创建其他临时表空间nc_temp
b.删除原temp01.dbf文件
c、并创建新temp01.dbf:
SQL>create temporary tablespace linshi_temp tempfile '/home/oracle/app/oracle/oradata/oraecology/temp01.dbf' size 50m autoextend on next 50m maxsize 2480m extent management local;
b.将临时表空间进行更改:
SQL>alter database default temporary tablespace linshi_temp;
c、查看当前表空间文件
select tablespace_name,status,contents from dba_tablespaces;
c.再删除原报错表空间:
SQL>drop tablespace temp including contents and datafiles;
d.再查看临时表空间
SQL> select tablespace_name, file_name from dba_temp_files;
总结:
从上面的测试发现,当数据库中temp表空间中的数据文件损坏或丢失情况下,使用rman是无法进行恢复的。
可以通过,直接重启数据库,或者新建临时表空或者新增tempfile方法进行修复。
文章评论