oracle11g冷备,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.