很多时候，大家工作中都会有一种被动的思维，那就是能不动就不动，从求稳的角度来看无可厚非，但是从风险的角度来说，还是有待商榷的。如果存在风险，还保持原样很可能就是一个不定时炸弹。
这不手头有一套环境，按照以前的标准是根本入不了我的法眼的，但是因为是测试环境，小问题比较多，存在容灾风险，但是这么多年一直这样，也就默然接受了。
这套环境硬件配置很低，基本上和我的笔记本配置差不多，可能还略差一些，在上面跑着3个数据库实例，其中一个是11g的，2个是10g的。两个10g的数据库实例数据量都不大，几十G而已。
看起来是有些别扭，而且这几个数据库实例都是运行在费归档模式下，对于备份目前是采用了逻辑备份的方式，备份了几个重要的schema数据，每天凌晨开始运行，然后上传到异机上去。
听起来也还是可行的，但是一旦发生硬件问题，恢复就是一个大麻烦。
这部凌晨就收到了报警，然后发现这台服务器不可用了。登录ILO之后，发现系统健康情况为Unknown，已经无法连通了。

然后发现备用电源已经停了，强制手工启动之后，算是勉强撑了4个多小时，然后中午又宕机了，下午三点又宕机一次。
当然这个期间，自己已经开始着实一些具体的工作了。
经过评估，发现这个问题还得先整合起来，然后逐步迁移实例。
类似下面的情况，首先在一台新的服务器上安装11gR2的软件，然后把11g的库做成dataguard的形式，然后switchover,这样11g的 库就迁移出去了，然后对于10gR2的库来说，因为数据量不大，可以考虑直接逻辑导出导入即可。当然前提是这几个数据库中的用户表没有冲突。

搭建dataguard用了没多少时间，简单确认就可以直接切换了。测试环境所以流程上就会送一些，但是数据迁移的质量还是要保持，当然吐槽一下dataguard搭建过程中的错误。
搭建的过程中报错。
input datafile file number=00061 name=/U01/app/oracle/oradata/actvdb/slzj_actv_index01.dbf
output file name=/U01/app/oracle/oradata/actvdb/slzj_actv_index01.dbf tag=TAG20160303T133618
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 03/03/2016 13:30:18
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script

trace日志的信息如下：
Errors in file /U01/app/oracle/diag/rdbms/sactvdb/actvdb/trace/actvdb_ora_18030.trc:
ORA-19505: failed to identify file "/U01/app/oracle/product/11.2.3/db_1/dbs/d:oracleoradatamytbs_tl.dbf"
ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 1
Thu Mar 03 13:26:37 2016
Errors in file /U01/app/oracle/diag/rdbms/sactvdb/actvdb/trace/actvdb_ora_18032.trc:
这个问题有多奇葩，竟然在$ORACLE_HOME/dbs下有数据文件，而且竟然还是以d:字样开头的数据文件。
主库端马上做了修复，
alter tablespace TEST_ACTV_DATA offline;
!cp '/U01/app/oracle/product/11.2.3/db_1/dbs/d:oracleoradatamytbs_tl.dbf' '/U01/app/oracle/oradata/actvdb/d:oracleoradatamytbs_tl.dbf';
alter tablespace TEST_ACTV_DATA rename datafile '/U01/app/oracle/product/11.2.3/db_1/dbs/d:oracleoradatamytbs_tl.dbf' to '/U01/app/oracle/oradata/actvdb/d:oracleoradatamytbs_tl.dbf';
alter tablespace TEST_ACTV_DATA online;
然后继续同步，就会从上次的断点处继续，很快就做好了。
然后开始做switchover，当然速度也很快，都在计划之中。
DGMGRL> show configuration;
Configuration - actvdb_dg
  Protection Mode: MaxPerformance
  Databases:
    actvdb  - Primary database
    sactvdb - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
DGMGRL> switchover to sactvdb;
Performing switchover NOW, please wait...
New primary database "sactvdb" is opening...
Operation requires shutdown of instance "actvdb" on database "actvdb"
Shutting down instance "actvdb"...
ORA-01031: insufficient privileges
第一步完成，后面的就是做数据的整合了。逻辑备份不会同步下面的这些信息。
profile信息，用户的密码和基本基本权限信息，系统权限，角色，表空间定义信息等，这些都需要我们自己来完成。
当然这些也不是什么难事了。生成用户的基本定义信息。
select dbms_metadata.get_ddl('USER',u.username) from dba_users u WHERE USERNAME  in ('ACC',。。。。。);
select dbms_metadata.get_granted_ddl('SYSTEM_GRANT',u.username) from dba_users u WHERE USERNAME in USERNAME  in ('ACC',。。。。。);
select dbms_metadata.get_granted_ddl('ROLE_GRANT',u.username) from dba_users u WHERE USERNAME in USERNAME  in ('ACC',。。。。。);

生成表空间信息
select dbms_metadata.get_ddl('TABLESPACE', ts.tablespace_name)||';' from dba_tablespaces ts;  
逻辑备份导出
exp xxx/xxx owner=ACC1,ACC2，ACC3....   buffer=9102000 statistics=none log=acc_test1.log file=acc_test1.dmp
逻辑导入
imp xxx/xxx fromuser=ACC1,ACC2，ACC3.... touser=ACC1,ACC2，ACC3....   buffer=9102000 statistics=none log=acc_test1_imp.log file=acc_test1.dmp
前期准备较好，数据的迁移就会很流畅。
迁移完成之后，终于能够松一口气，也算是脱离那个定时炸弹了，后期修复了电源之后，这台服务器还可以勉强做个备库。得来全不费功夫。