测试环境的迁移式升级和数据整合(r8笔记第27天)

很多时候，大家工作中都会有一种被动的思维，那就是能不动就不动，从求稳的角度来看无可厚非，但是从风险的角度来说，还是有待商榷的。如果存在风险，还保持原样很可能就是一个不定时炸弹。 这不手头有一套环境，按照以前的标准是根本入不了我的法眼的，但是因为是测试环境，小问题比较多，存在容灾风险，但是这么多年一直这样，也就默然接受了。 这套环境硬件配置很低，基本上和我的笔记本配置差不多，可能还略差一些，在上面跑着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 前期准备较好，数据的迁移就会很流畅。 迁移完成之后，终于能够松一口气，也算是脱离那个定时炸弹了，后期修复了电源之后，这台服务器还可以勉强做个备库。得来全不费功夫。