做数据库迁移是一件蛋疼的事，做数据库设计的人，往往不考虑数据构架的可扩展性，因为做数据库迁移的人不是做数据库设计的人。

之前做了这样的一个数据库迁移，要求大概如下

   1.晚上大概有5个小时的宕机时间，可以做整库（A机）迁移操作。

   2.数据的数据量在900G左右。

   3.同样的操作系统和数据库版本

   4.迁移的时候，需要更改数据库名和实例名。

   5.客户现场没有数据备份磁带或磁盘设备。

   6.可用的就是一台硬件升级过的小机（B机），用来运行迁移后的数据库，没有共享存储。

  看到这个要求我心里大概有些谱了。

    5个小时的宕机时间，900G的数据，做数据库的导入导出估计没戏。基本上定调做数据恢复来实现。再加上没有磁带备份，如果使用RMAN做备份和恢复

1.较为复杂，步骤繁多，多异出错  2。没有磁带备份设备，如果在数据库备份时可能会影响生产库。

    这样一来基本上就定位在用户管理下的一致性数据库迁移。

  具体的实施计划由于公司有规定不得公开。不过大致把过程说了一下。

  1. 早上就到数据中心，看到IBM的小机和存储，记录了系统参数和配置，就开始重装系统，划分LVM，和裸设备。

  2.做完这个，就中午1点了到了吃饭时间。买了个汉堡，塞到嘴里回去接着干。开始安装ORACLE 10 G FOR AIX。

  3.安装完成 也就到了下午五点，头昏老胀出去转了一圈。顺便吃了饭，准备晚上夜宵。

  4.再次回到机房，将B机上的目录结构做好，配置上数据实例。并开始检查环境，是否有问题，比如监听器是否正常，到A机到B机的网络是否连通等等。中间出了点小问题。稍后再说。

  5.幸好机房里一起加班的人还真挺多，也就同这些IT宅男 七零八碎的忽悠起来，除非就是感叹人生，思考人生，其中有个南方来的北漂，说起武汉的热干面

差点都没有痛哭流涕，最后还来了一句，飘飘何所似，天地一沙鸥。 哥们太有才了！

  6.到了11点 我就去跟数据库管理员忽悠，希望他能提前发通知，让数据库shutdown,我就可以多一个小时做操作，心里也轻松些。 管理员在哪玩着QQ游戏，斗着地主，玩的正High，看我到了跟前，不情不愿的起身。11点了，也没有什么业务操作了，给各个业务部门打了电话，发了通知。这下我可以动手了！

  将A机上数据库Shutdown 通过SFTP 开始将小的数据文件传输到B机。同时用公司的磁盘做物理拷贝。一个多小时后复制完成。

  7.由于没有建库，直接通过初始化文件，控制文件，口令文件，日志文件，和数据文件恢复，速度很快，不过要是其中文件有损坏，就得直接重新复制。

 总体来说，操作还算顺利，不过中间出了这几个问题。

 1.将B库的数据库重命名。

     方案1：有点想当然， 更改了初始化文件中的DB_NAME,Backgroud_dump_dest,core_dump_dest,user_dump_dest，audit_file_dest中文件路径后，

再更改control_files 名称.使用orapwd重新新建了用户口令文件。就开始启动数据库。

View Code

   没辙，在启动时使用的控制文件使用了原来的数据库名。只有使用方案2

     方案2：先按原来数据名加载，然后通过重建控制文件更改数据库名。

重建控制文件

    生成的控制文件Trace 来得到生成控制文件的语句。将其中的db_name后，执行alter database open resetlogs

 2.在执行alter database open resetlogs.发生如果错误

语句错误

  没有头绪，从报错来看由于数据文件与控制文件文件不一致造成。难道是A库关闭时出现问题，导致控制文件中的SCN同数据文件的SCN 不一致造成？

 不确定。登上A库，启动A库，果然不出我料。启动数据库失败。

启动失败

只能在A库上做数据库控制文件的恢复，ORACLE中的文档给出的步骤是:

ORACLE DOC

执行完成后，启动成功，重新备份到B机，恢复，成功。

 3.中间启动时出现了一个小问题

oracle error

进行了recover database ;恢复失败，连接被强行断开，查看alert.log日志文件，发现由于initxx.ora 初始化配置文件配置错误，更改后启动。OK。

进行数据的测试，没有丢失，GameOver!

4.在开始启动时遇到的一个小问题

can‘t excluse mode

 转：http://www.cnblogs.com/jerryxing/archive/2012/07/24/2606798.html

Oracle 项目就是那回事 ----数据库迁移（1）