window冷备份恢复至linux

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来做类似这样的迁移了。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。