window冷备份恢复至linux

以前做window到linux的迁移都是用的常规的exp和imp的方法来迁移的。利用逻辑备份，从而实现跨物理结构和os的数据迁移。这样的方 法我相信有不少的朋友都是这样的做的。

今天有一个50g的数据库，需要重window的平台，迁移到linux的平台。这几天刚好在看数据文件的物理结构，看到大家提供的物理结构的文 档，并没有OS的差异上的区别，那么是不是意味着在不同的os上的数据文件等是不是结构都是相同的了，物理结构的文档还没有研究完，所以还没有写程序来验 证的能力，等研究完结构，再来写程序来解读文件来验证了，不过有了前面的猜想，我就有一个大胆的想法，既然如此，我就直接用用这个window的冷备份看 能不能恢复到linux上，从而来进行一个实际动作上的验证了。要是成功的话，一举两得，即验证了自己推断，有能够快速的给用户迁移了。

立马行动吧。

原系统
OS： window 20003 64bit
Oracle: 10.2.0.1
单实例

目标系统
OS：RHEL 4.7 64bit
Oracle： 10.2.0.1
单实例

根据客户的需要，做迁移。

1. 查询所有的logfile

SQL>select * from v$logfile;

2. 查询所有的数据文件

SQL>select * from v$datafile;

3. 先关闭源数据库

shutdow immediate

4. 备份备份日志文件，数据文件

5. 启动数据库到read only状态，是客户数据库还可以提供服务
startup mount;
alter database open read only;

6. 复制数据库文件，日志文件到目标服务器上
这里规划的目录和源库上的不同。
数据文件都放在/u01/app/oracle/oradata/towell/datafile下
控制文件放在/u01/app/oracle/oradata/towell/controlfile下，并修改其中一个名字为current.1给底下 的pfile使用。
日志文件放在/u01/app/oracle/oradata/towell/onlinelog上，做完了，总结了一下，redo可以不迁移的，毕竟是 冷备份。
并建立好/u01/app/oracle/admin/towell/下的一些列dump目录。

7. 现在就在目标数据库上开始动作了。
先建立密码文件
orapwd file=$ORACLE_HOME/dbs/orapwtowell password=mypassword
建立pfile文件
这个pfile文件最方便的是从源库导出后copy过来
create pfile=’d:/backup/init.ora’ from spfile;
修改其中的相关参数，包括路径，并修改control_files到一个路径，比如这里的control_files=’/u01/app/oracle /oradata/towell/controlfile/current.1′

这里的两个步骤可以提前准备，这样可以更节省停机时间。

8. 从pfile启动数据库到mount阶段。
这里就是开始担心的地方了，首先controlfile会不会出现os不同而不兼容的现象了，如果这里能够成功的话，我想数据文件基本上也可以搞定了。
看到屏幕上出现
startup pfile=’d:/backup/init.ora’ mount;
Database mounted.
心里暗自感觉，自己离成功已经开始了第一步了。

9. 导出controlfile,注意这里不能直接open了，直接open，肯定会提示数据文件不能打开的提示，因为控制文件时window下的，里面的路 径全是window的。所以我们到处控制文件，重建之。

alter database backup controlfile to trace;
oradebug setmypid;
Statement processed.
oradebug tracefile_name;
/u01/app/oracle/admin/sample/udump/towell_ora_21214.trc

10. 打开这里的trace文件。里面就可以看到重建的controlfile的sql语句了
把其中的数据文件的路径和日志文件的路径 按照现在的linux的路径修改过了。这里根据上面的datafile的select的结果，对应上，注意顺序保持控制文件里已有的顺序，不要修改顺序， 仅修改路径就可以了。用户这里总共有30多个数据文件。不需要一个一个的改了，替换就可以了。修改完毕。 我在重建的时候不喜欢用reuse，所以把reuse改成了set，把noresetlogs改成resetlogs。如下
CREATE CONTROLFILE SET DATABASE “TOWELL” RESETLOGS ARCHIVELOG
…….

11. 再次关闭数据库，以便重建controlfile
shutdown immediate;
startup pfile=”d:/backup/init.ora’ nomount;
执行上面修改好的create controlfile 的 脚本
非常顺利，
提示控制文件创建成功。

12. 带着激动的心情打开数据库吧
alter database open resetlogs;
看着日志文件里的日志，胜利在望叻。
就正在得意的时候，屏幕中断。提示数据库open失败，胜利instance。

Database Characterset is ZHS16GBK
Fri Apr 16 13:40:50 2010
Errors in file /u01/app/oracle/admin/sample/bdump/sample_smon_7134.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-04031: unable to allocate 16 bytes of shared memory (”shared pool”,”select null from obj$ where …”,”sql area”,”kglhin: temp”)

看到这里的信息，很兴奋，因为我知道既然这里都已经可以看到我们的604的错误了，估计数据库加载应该是可以了，只要block没有冲突就可以了， 而且根据这里的提示，应该是shared pool的问题。

打开这里的trc文件，

Chunk 25709420 sz= 304 freeable “kks cstat ”
Chunk 25709550 sz= 32 freeable “kks pstat ”
Chunk 25709570 sz= 304 freeable “kks cstat ”
Chunk 257096a0 sz= 32 freeable “kks pstat ”
Chunk 257096c0 sz= 304 freeable “kks cstat ”
Chunk 257097f0 sz= 32 freeable “kks pstat ”

******************************************************
******************************************************
===============================
End 4031 Diagnostic Information
===============================
Warning: out of shared memory loading library cache object [handle=257dde8c] select null from obj$ where obj#=:1 and type#=:2 and obj# not in (select p_obj# from dependency$ where p_obj# = obj$.obj#)
*** 2010-04-16 13:40:50.996
SMON: following errors trapped and ignored:
ORA-00604: error occurred at recursive SQL level 1
ORA-04031: unable to allocate 16 bytes of shared memory (”shared pool”,”select null from obj$ where …”,”sql area”,”kglhin: temp”)
Warning: out of shared memory loading library cache object [handle=257e5d2c]
select obj#,type#,ctime,mtime,stime,status,dataobj#,flags,oid$, spare1, spare2 from obj$ where owner#=:1 and name=:2 and namespace=:3 and remoteowner is null and linkname is null and subname is null
*** 2010-04-16 13:40:51.045
SMON: following errors trapped and ignored:
ORA-00604: error occurred at recursive SQL level 2
ORA-04031: unable to allocate 4108 bytes of shared memory (”shared pool”,”select obj#,type#,ctime,mtim…”,”Typecheck”,”kgghteInit”)

这里的问题是，由于目标系统的内存比原来的系统大，所以想到要调整sga_target的，我就在pfile里没有设置sga_target。 sga_target查出来只有117M。确实是太小了。导致出现这个问题，shutdow实例，
把pfile创建为spfile。后修改sga的值，根据客户的OS的内存实际大小，客户是16G，sga_target先给5G了。
再次启动。
看着日志，直到最后出现ORACLE instance started.

数据库没有出现问题了。

通知客户，把应用的datasource切换过来，跑了半个小时，目前还没有发现问题。也不知道这样的迁移会不会导致其他的问题。先试了试rman 和归档，没有问题出现。由于本身是基于物理恢复的。 所以还是建议客户定期的做exp的逻辑备份，反正多备份也没有坏事，虽然现在成功了，但是也不代表这样的方式没有带来灾难行的问题，所以多保险一下吧。

物理的备份和恢复就是快，安装以前的逻辑备份的话。50G的数据导出，也需要半个多小时。而这样备份的方式整个应用read only的过程也就不到10分钟。以后就在也不用exp/imp来做类似这样的迁移了。