做数据库迁移是一件蛋疼的事，做数据库设计的人，往往不考虑数据构架的可扩展性，因为做数据库迁移的人不是做数据库设计的人。
之前做了这样的一个数据库迁移，要求大概如下
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重新新建了用户口令文件。就开始启动数据库。
没辙，在启动时使用的控制文件使用了原来的数据库名。只有使用方案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