rman冷迁移Oracle10gR2数据库

首先在源机器上取得一个完整备份和crl文件备份以及pfile$ORACLE_SID.ora(这些文件的获取在这里我不多赘述)

获取dbid在源机器上

SQL> select dbid from v$database;

获取sid在原籍器上

echo $ORACLE_SID

将以上文件放到目标主机上archivelog文件和dbf的文件备份集，必须放在原来rman备份的相同目录下，因为还原的时候只能指定tag,不可指定具体备份文件的路径所以必须和原先的备份路径相同

目标机器上不能创建数据库，不能有和源实例发生冲突的相关环境变量,SID,数据库名等等敏感信息

下边开始操作

[oracle@aaa ~]$ cat /usr/src/rman/backpfileaaa.ora |grep "/"|awk -F["'"] '{print $2}' //获取还原这个数据库所需要的目录，如果想更改这些目录的话，可以手动编辑pfile，如果使用原来的目录结构，则创建之

[oracle@aaa ~]$ export ORACLE_SID=aaa //设置SID（目标机）

[oracle@aaa ~]$ rman target / //进入rman

RMAN> set dbid 3094951801

RMAN> startup nomount pfile='/usr/src/rman/backpfileaaa.ora';

RMAN> restore controlfile from '/usr/src/rman/c-3094951801-20130723-03'; //首先进行恢复控制文件，控制文件存储有rman的备份信息，有控制文件你将可以list backup

RMAN> alter database mount; //将database进行mount

RMAN> crosscheck backup; //让rman自己核对控制文件和备份集的物理文件

RMAN> restore database; //还原数据库

成功还原完之后小仙打算

RMAN> recover database; //这个操作利用archivelog and online log做recover,从时间点A,推进到时间点B

不幸的事情发生了

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of recover command at 07/23/2013 16:49:49

RMAN-06054: media recovery requesting unknown log: thread 1 seq 19360 lowscn 2959421805

居然告诉我没有日志文件，然后我很淡定的打算恢复一下日志文件

RMAN> restore archivelog all;

Starting restore at 23-7月 -13

using channel ORA_DISK_1

archive log thread 1 sequence 19358 is already on disk as file /oracle/archive_log/archive_1_19358_810153785.log

archive log thread 1 sequence 19359 is already on disk as file /oracle/archive_log/archive_1_19359_810153785.log

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of restore command at 07/23/2013 16:53:58

RMAN-06026: some targets not found - aborting restore

RMAN-06025: no backup of log thread 1 seq 19341 lowscn 2959278545 found to restore

此除略去几头字.....

RMAN-06025: no backup of log thread 1 seq 19286 lowscn 2958531089 found to restore

MAN-06025: no back

RMAN> recover database; //死马当活马医，尝试一下也不为过嘛

Starting recover at 23-7月 -13

using channel ORA_DISK_1

starting media recovery

unable to find archive log

archive log thread=1 sequence=19360

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of recover command at 07/23/2013 17:15:32

RMAN-06054: media recovery requesting unknown log: thread 1 seq 19360 lowscn 2959421805 //注意此处的错误号

看完就有些抑郁了，为神马回这样捏？？？于是打算再试试，不抛弃不放弃。。

RMAN> restore archivelog sequence between 19286 and 19341 thread 1; //结果还是原来的错，这儿开始淡定的神情慢慢的变的扭曲了

是不是传输过程中出什么错了！！！让rman再进行交叉校验一下backup集，然后删除一下过期的backup

RMAN> crosscheck backup;

RMAN> delete expired backup;

额，删除了13个过期的控制文件

之后再尝试

RMAN> recover database; //问题依然存在啊，神啊，您到底在哪儿啊为什么看不见这个无助的迷途小运维呢！！

心中高呼这，不过日子还得继续。。。

柳暗花明又一村啊，看见在CSDN上徘徊过的一个大仙介绍，RMAN-06054是因为目标数据库是非归档模式

小仙就想啊，如果是非归档模式，那自然就不用recover database(此命令作用上边有描述)，直接open吧

RMAN> alter database open;

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of alter db command at 07/23/2013 17:20:12

ORA-01589: must use RESETLOGS or NORESETLOGS option for database open //提示我加上resetlogs或者noresetlogs，反正我的archivelog已经拉倒了，那就resetlogs吧

RMAN> alter database open resetlogs;

database opened //OK实例起来了

RMAN> exit

Recovery Manager complete.

[oracle@aaa rman_backup]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on 星期二 7月 23 17:31:19 2013

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

SQL> create spfile from pfile='/usr/src/rman/backpfileaaa.ora';

File created.

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup

ORACLE instance started.

Total System Global Area 2147483648 bytes

Fixed Size 2085360 bytes

Variable Size 218107408 bytes

Database Buffers 1912602624 bytes

Redo Buffers 14688256 bytes

Database mounted.

Database opened.

SQL>

SQL> archive log list;

Database log mode Archive Mode

Automatic archival Enabled //此处查看了一下归档情况，看来是归档状态和迁移前是一样的，不过不知的为什么会出现RMAN-06054，这个还待仔细化验

Archive destination /oracle/archive_log

Oldest online log sequence 1

Next log sequence to archive 1

Current log sequence 1

SQL> !lsnrctl status #查看监听程序已经监听这个实例了

LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 23-7月 -2013 17:35:39

Copyright (c) 1991, 2007, Oracle. All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))

STATUS of the LISTENER

------------------------

Alias LISTENER

Version TNSLSNR for Linux: Version 10.2.0.4.0 - Production

Start Date 23-7月 -2013 13:31:26

Uptime 0 days 4 hr. 4 min. 12 sec

Trace Level off

Security ON: Local OS Authentication

SNMP OFF

Listener Parameter File /oracle/10.2/db_1/network/admin/listener.ora

Listener Log File /oracle/10.2/db_1/network/log/listener.log

Listening Endpoints Summary...

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=sem)(PORT=1521)))

Services Summary...

Service "aaa" has 1 instance(s).

Instance "aaa", status READY, has 1 handler(s) for this service...

Service "aaaXDB" has 1 instance(s).

Instance "aaa", status READY, has 1 handler(s) for this service...

Service "aaa_XPT" has 1 instance(s).

Instance "aaa", status READY, has 1 handler(s) for this service...

The command completed successfully

Oracle10gR2的rman冷迁移就算成功告终了！

##################################

本文属于笔者原创

作者：john

转载请注明出处！！！