客户新买了oda三代一体机，想替换原来的一代的一体机。原来的环境安装的是oracle11.2.0.2的rac，新的一体机安装的是oracle11.2.0.4。对于客户来说，想通过最短的时间来实现切换。最好的办法就是通过rman来实现，追加归档，现在我们把具体的操作过程记录下来。

1、安装oda环境

oracle的一体机的安装相当简单，完全可以通过一键方式来实现。上传专门为oda设计编译的db.zip和grid.zip，通过自带的工具便可安装，这项工作主要由oda的工程师完成

配置ip这些都不用操心，只要给出网段，在安装过程中，可以自动配置！

在安装的oda机器上，进行以下

public ip : 10.10.10.131    erptest1-pub

10.10.10.141    erptest2-pub

私网ip是由oda安装过程中自动生成的，这个我们不用管了

vip ip:     10.10.10.132    erptest1-vip

10.10.10.142    erptest2-vip

scan ip:    10.10.10.200    nctest-scan

一键安装的oda，建了三个dg:data,redo,reco，其中redo是建在固态硬盘上的！

2、配置备份目录

由于在原oda上面，没有更多的空间拿来用作备份，所以，通过挂载其它机器上的硬盘来实现

在提供硬盘的机器上设置exports

[root@backup ~]# mkdir -p /u01/backup

[root@backup ~]# vi /etc/exports

/u01/backup 192.168.10.*(rw,sync,no_root_squash)

然后在使用的机器上挂载

[root@oldtest1 ~]# mkdir -p /u01/backup

[root@oldtest1 ~]# mount -o nolock 10.10.10.120:/u01/backup /u01/backup

[root@oldtest1 ~]# chown -R oracle:oinstall /u01/*

挂载后，可以通过df -h来验证

3、备份数据库到目录

脚本如下：erpbackup.sh

run {

allocate channel c1 type disk maxpiecesize = 20G;

allocate channel c2 type disk maxpiecesize = 20G;

backup incremental level 0 database format '/u01/backup/%d_DF_%T_%s_%p.bak'

plus archivelog

format '/u01/backup/%d_AF_%T_%s_%p.log' delete all input;

backup current controlfile format '/u01/backup/%d_CTL_%T_%s_%p.bak';

release channel c1;

release channel c2;

}

[oracle@oldtest1 ~]# chmod +x erpbackup.sh

[oracle@oldtest1 ~]# nohup ./erpbackup.sh > erpbackup.sh.out &

备份时间大约一个小时。

4、新的oda机器上进行还原

--准备工作

按上面的方法，把备份目录挂载到新机器上去，然后把旧机的参数文件复制过去

SQL> create pfile = '/u01/backup/oldspfile.ora' from spfile;

注意：

修改参数：*.remote_listener，把里面的host部份，修改成当前的host部份。实例名保持与原机相同！

创建审计目录，这个在参数文件中有，如果没创建，无法启动(两个节点都要创建)

--还原控制文件

整个恢复过程，在一台机器上做就行了

[oracle@erptest1 ~]# export ORACLE_SID=orcl1

[oracle@erptest1 ~]# rman target /

RMAN> startup nomount pfile='/u01/backup/oldspfile.ora';

把数据库启动到nomount状态

RMAN> run

2> {

3> allocate channel c1;

4> restore controlfile from '/u01/backup/控制文件备份集';    --含有'CTL'的那个文件

5> release channel c1;

6> }

在这里，发现找不到+data这个dg，但是使用dbca建一个库进行测试的时候，却能发现dg。在第一个节点，我们使用dbca创建一个库，然后删除，再进行还原，问题消失。但后来在第二个节点启动实例时，发现仍然无法认识dg，无法启动。最后分析，是权限问题：

我们在第二个节点的处理方法如下：

[root@erptest1 ~]# id oracle

uid=500(oracle) gid=501(oinstall) groups=501(oinstall),502(dba),503(oper),506(asmdba)

[root@erptest1 ~]# id grid

uid=501(grid) gid=501(oinstall) groups=501(oinstall),502(dba),503(oper),504(asmadmin),505(asmoper),506(asmdba)

比较后，对oracle增加一个asmadm的组

[root@erptest1 ~]# usermod -a -G asmadmin oracle

[root@erptest1 ~]# cd /u01/app/11.2.0.4/grid/bin

[root@erptest1 bin]# chmod +s oracle

这样处理后，第二个节点马上可以起动，并且顺利读到控制文件！

--恢复数据库文件

还原控制文件后，可以把数据库启动mount

SQL> alter database mount;

脚本如下：restoredf.sh

rman target / <

run {

ALLOCATE CHANNEL c1

Restore database;

RELEASE CHANNEL c1;

}

exit

EOF

[oracle@erptest1 ~]# chmod +x restoredf.sh

[oracle@erptest1 ~]# nohup ./restoredf.sh > restoredf.sh.out &

还原时间，大概使用了10个小时，后来检查，备份的时候使用的是1000m，而接到新oda机器的是100m，所以速度明显下降！

--恢复归档日志

检查需要恢复的归档

SQL> select THREAD#,min(SEQUENCE#) minseq,max(SEQUENCE#) maxseq from v$archived_log where COMPLETION_TIME > to_date('2014-05-24 11:00:00','yyyy-mm-dd hh24:mi:ss') group by THREAD#;

THREAD#     MINSEQ     MAXSEQ

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

1        777        778

2        605        607

脚本如下：restorearch.sh

rman target / <

run

{

ALLOCATE CHANNEL c1

set archivelog destination to '/u01/arch';

restore archivelog sequence between 777 and 778 thread 1;

restore archivelog sequence between 605 and 607 thread 2;

RELEASE CHANNEL c1;

}

exit

EOF

其使用方法同上

根据上面提供的查询，对归档日志进行恢复！

--recover数据库

这个时候，可以对数据库进行 recover

SQL> recover database using backup controlfile until cancel;

ORA-00279: change 51849272 generated at 24/05/2014 11:32:23 needed for thread 1

ORA-00289: suggestion : /u01/arch/1_605_802032812.dbf

ORA-00280: change 51849272 for thread 1 is in sequence #4762

Specify log: {=suggested | filename | AUTO | CANCEL}

auto  --输入auto

这样，就可以把数据库进行recover了

最后完成后，再执行一次

SQL> recover database using backup controlfile until cancel;

这个时候，选择cancel

SQL> alter database open resetlogs upgrade;

这个时候，可能会提示是完全恢复，不需要resetlogs，如果出现这种提示就执行以下命令，直接打开数据库：

SQL> shutdown immediate;

SQL> startup pfile='/u01/backup/oldspfile.ora' upgrade;

--创建临时表空间

SQL> create temporary tablespace temp1 tempfile '+DATA' size 8192m;

Tablespace created.

SQL> alter database default temporary tablespace temp;

Database altered.

5、升级数据库

--运行升级数据字典

SQL> @?/rdbms/admin/catupgrd.sql;

这个大概需要半个小时时间，根据机器性能定

--检查升级状态

SQL> @?/rdbms/admin/utlu112s.sql;

--检查失效对象并重新编译

SQL> select count(*) from dba_invalid_objects;

如果存在，就执行以下语句

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

到这里，升级过程基本上完成

6、注册数据库

--在data的dg中，建一个parameterfile目录

使用grid用户进行创建

[grid@erptest1 ~]# export ORACEL_SID=+ASM1

[grid@erptest1 ~]# asmcmd

ASMCMD> cd data/orcl

ASMCMD> mkdir parameterfile

--在sqlplus 中创建spfile

SQL> create spfile = '+data/orcl/parameterfile/spfileorcl.ora' from pfile = '/u01/backup/oldspfile.ora';

创建完成后，在dbs中编辑initorcl1.ora内容如下

spfile='+data/orcl/parameterfile/spfileorcl.ora'

在第二节点就编辑 initorcl2.ora，内容与第一节点一样

--注册数据库

使用oracle用户进行数据库和实例的注册

[oracle@erptest1 ~]# srvctl add database -d orcl -o /u01/app/oracle/product/11.2.0/dbhome_1 -p +DATA/power/parameterfile/spfileorcl.ora

[oracle@erptest1 ~]# srvctl add instance -d orcl -i orcl1 -n erpmytest1

[oracle@erptest1 ~]# srvctl add instance -d orcl -i orcl2 -n erpmytest2

到这个时候，所有的工作基本上就做完了，启动数据库就可以了！

--检验结果

SQL> shutdown immedate

[oracle@erptest1 ~]# $srvctl start database -d orcl

[oracle@erptest1 ~]# $srvctl status database -d orcl

Instance orcl1 is running on node orcl1

Instance orcl2 is running on node orcl2

说明：刚开始的时候，我们在这里遇到了问题，就是分别从各个节点起动数据库，进行status是，显示is not running，这个是由于我们恢复的数据库，集群不认所至，只有通过srvctl来启动，就会被认到！