Oracle11g冷备份恢复

Oracle11g冷备份恢复

 

 

这两天恢复Oracle着实头疼了一把，我的环境是Cenos5.3+Oracle11g,正式服务器的数据库实例路径是：/app/oracle/oradata/databar,当初只备份了此目录下的文件：

 

control01.ctl
redo01.log
redo02.log
redo03.log
sysaux01.dbf
system01.dbf
temp01.dbf
undotbs01.dbf
users01.dbf

 

新环境的Oracle程序又安装在完全不同的路径下：/u01/app/oracle,后来利用Linux命令下的dbca工具创建数据库（SID与正式服务器上的同名:"databar",并将sys用户的密码保持与原信息一致，再新建之前数据库管理员的相关帐号），顺带说一下Linux图形界面的dbca工具创建数据库可够慢的，有经验的应直接用命令行来创建了。创建完数据库以后新数据文件存放在/u01/app/oracle/oradata/databar目录下，随后按照以下方式恢复：
一、shutdown Oracle数据库，用数据文件覆盖以前的数据文件，并将控制文件及重做日志文件删除;

 

二、切换到oracle用户并进入Sqlplus，用sys用户连接到oracle;

 

三、先关闭然后再启动数据库，但不挂载数据文件;
 SQL> shutdown immediate;

 SQL> startup nomount;

四、重建控制文件;
CREATE CONTROLFILE REUSE DATABASE "databar" RESETLOGS NOARCHIVELOG
--SET STANDBY TO MAXIMIZE PERFORMANCE
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 '/u01/app/oracle/oradata/databar/redo01.log' SIZE 100M,
GROUP 2 '/u01/app/oracle/oradata/databar/redo02.log' SIZE 100M,
GROUP 3 '/u01/app/oracle/oradata/databar/redo03.log' SIZE 100M
--STANDBY LOGFILE
DATAFILE
'/u01/app/oracle/oradata/databar/users01.dbf',
'/u01/app/oracle/oradata/databar/undotbs01.dbf',
'/u01/app/oracle/oradata/databar/system01.dbf',
'/u01/app/oracle/oradata/databar/sysaux01.dbf'
--CHARACTER SET ZHS16GBK(依情况可省略)
;
（在这里指定所有的数据文件，注意这里暂时不要指定临时表空间用到的文件，即TEMP01.DBF'，不然会报ORA-01503:错误)
以上语句，需要指定路径的要用单引号，不然会报以下错误：
LOGFILE用双引号报错：ORA-00972: identifier is too long
DATAFILE用双引号报错：ORA-01967: invalid option for CREATE CONTROLFILE.

 

五、创建控制文件成功后，执行以下语句打开数据库，加上RESETLOGS参数是为了重新生成重做日志文件;

SQL> alter database open RESETLOGS;
如果出现以下错误：
alter database open resetlogs
*
第 1 行出现错误:
ORA-01194: 文件 1 需要更多的恢复来保持一致性
ORA-01110: 数据文件 1:'/u01/app/oracle/oradata/databar/system01.dbf'

解决方法如下：
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/u01/app/oracle/oradata/databar/system01.dbf'

如果出现上面的错误，则输入以下语句：
SQL> set wrap off
SQL> set lin 300
SQL> select file#,ts#,status,name from v$datafile;

#查看下当前数据文件的状态

然后再执行下面的SQL语句
SQL> recover database until cancel;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done

如果在上面的SQL语句执行失败后在执行下面的SQL语句
SQL> recover database using backup controlfile until cancel;    执行下面的SQL语句之后会出阿仙下面的提示，
ORA-00279: change 476049 generated at 01/08/2010 12:35:18 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/DATABAR/archivelog/2010_08_01/2010_01_08O1_MF_1_18_%U_.ARC
ORA-00280: change 476049 for thread 1 is in sequence #18

Specify log: {=suggested | filename | AUTO | CANCEL}
#在此处先填写日志文件REDO01.LOG' 的具体路径(在的第四步的生成控制文件的脚本中)，然后回车，如果还出现错误，那么再执行
#recover database using backup controlfile  until cancel;  
#然后在填写 REDO02.LOG' ' 的具体路径
#直到输入文件路径回车之后出现以下成功提示：
  Log applied.
  Media recovery complete.

 

六、执行以下语句打开数据库，加上RESETLOGS参数是为了重新生成重做日志文件；*注意一定要执行这句SQl语句
       SQL> alter database open resetlogs;
       Database altered.

 

七、将临时表空间加入到实例上，加以重用:
SQL> alter tablespace TEMP add tempfile '/u01/app/oracle/oradata/databar/TEMP01.DBF' reuse;

至此，数据库恢复完成，现在也可以利用imp导入正式服务器上的最新数据了。

八、ORACLE 11g R2 64位备份恢复到ORACLE 11g R2 32位 问题处理

操作步骤：源数据库是64位oracle11gR2软件，通过rman完整备份数据库（包括参数文件、数据文件、控制文件、日志文件） 恢复到异机32位oracle11gR2同名数据库中。

错误现象：ORA-06553:PLS-801 内部错误

错误原因：用64位系统上的备份片将数据库还原到32位系统中所产生，反过来也会产生此错误。

解决方案：运行脚本用32位系统重新编译一下内核参数即可

具体步骤：SQL> conn / as sysdba; 

        SQL> shutdown immediate;

        SQL> startup upgrade;

        SQL> @?/rdbms/admin/utlirp.sql

        SQL> @?/rdbms/admin/utlrp.sql

        SQL> shutdown immediate;

        SQL> startup;

其中：

utlirp.sql的作用是把相关内容全部在32bit平台下编译一遍.

utlrp.sql的作用是编译所有失效对象.

然后再重新连接，就不会报错了。

SQL> conn xxx/xxx

Connected.