迁移式升级的测试（二）(r10笔记第35天)

在之前写的一篇博文中，自己是打算对一台数据库使用Data Guard+TTS的方式来完成数据迁移和升级的工作，迁移式升级的新方案测试 (r10笔记第30天)

整体的思路如下。

备库Failover之后，导出元数据，然后同一台服务器上的11g的数据库中导入元数据，这样就避免了传输文件的时间消耗。从而达到快速迁移升级的目的。 具体的操作步骤如下所示： 1.在备库端需要开启闪回 这个也是为了能够在迁移失败的情况下，能够迅速回退，马上重构主备库的环境。 2.在开启闪回数据库之后，记录一下SCN的信息，留作后面备用。 select current_scn from v$database； CURRENT_SCN ------------------ 228967862801 3.开始备库切换 在备库端进行Failover的操作。整个过程分分钟即可完成。这个过程需要保证主库端的数据能够及时更新过来。 alter database recover managed standby database finish force; alter database commit to switchover to primary; select database_role,open_mode from v$database; 4.在开始迁移前，做一个完整的检查，这是迁移的重中之重，如果迁移的表空间很多，可以直接放到脚本里面来统一处理也可以。 exec dbms_tts.transport_set_check(TS_LIST=>'STORELOG_DATA,STORELOG_INDX,USERS,GHOSTOL_DATA,GHOSTOL_INDEX,TEST_DATA,TEST_INDEX,PERFSTAT,TS_AUDIT,STAT_POINT,TEST_MV_DATA,TEST_MV_INDEX,TEST_AUDIT_DATA,JYCX_DATA,OEM_DATA,TEST_INDEX2,TEST_INDEX3,SWDONLINE_DATA,SWDONLINE_INDX,OEM_MON_TEST,USERCENTER_DATA',INCL_CONSTRAINTS=>TRUE,full_check=>true); 查看检查的结果： select *from transport_set_violations;

可以看到这个例子中还是违反自包含约束的情况，从日志能够看出，主要是和aud$的处理相关。 经过确认，MARKET_ANGEL_USEDUP是个索引，但是属主存在问题，可以在迁移的时候直接重建。 sys@TEST> drop index MARKET_ANGEL_USEDUP; Index dropped. sys@TEST> create index TEST.MARKET_ANGEL_USEDUP on TEST.MARKET_ANGEL("USED_UP") tablespace TEST_index; Index created. 另外的几个表 TEST_WEAPON，TMP_CNINFO_XTG_20081212，AUD$_20120608是临时表，可以直接删除。 drop table TEST_WEAPON; drop table TMP_CNINFO_XTG_20081212; drop table AUD$_20120608; 最后的注意力就到了aud$,可以看到这个表是在之前因为考虑到数据量较大，直接迁移到一个独立的表空间了，在这个例子中为了保证迁移的顺利，可以先把 aud$迁移到sysaux里面，迁移完成之后再处理即可。数据量不大的情况下直接move tablespace即可，如果里面的数据可以删除，直接truncate即可。 truncate table aud$; alter table aud$ move tablespace sysaux; 这个时候查看检查信息，还是存在下面的一些提示信息。

这个时候可以查看LOB的具体信息，发现是AUD$里面的一个LOB列，单独迁移即可。 SQL> select table_name,column_name,tablespace_name,index_name from user_lobs where index_name='SYS_IL0000011218C00041$$'

SQL>alter table aud$ move tablespace sysaux lob(SQLTEXT) store as lobsegment(tablespace sysaux); 另外一个LOB也是同样的处理。 SQL> alter table aud$ move tablespace sysaux lob(SQLBIND) store as lobsegment2(tablespace sysaux); 对于其他的对象，如果不是LOB列，那很可能就是回收站里的对象了，直接删除即可。 sys@TEST> select table_name,column_name,tablespace_name,index_nam from user_lobs where segment_name='SYS_LOB0000133356C00041$$';

sys@TEST> show recyclebin

SQL>purge recyclebin; 对于aud$上面的索引可以直接rebuild即可达到效果。 alter index I_AUD2 rebuild tablespace sysaux; 再次检查阿九没有任何问题了。 PL/SQL procedure successfully completed. no rows selected 5.接下来的工作就是把表空间置为READ ONLY状态。 alter tablespace USERS read only; alter tablespace TS_AUDIT read only; alter tablespace GHOSTOL_DATA read only; alter tablespace GHOSTOL_INDEX read only; alter tablespace TEST_DATA read only; alter tablespace TEST_INDEX read only; 6.导出10g数据库的元数据信息，标注为迁移表空间的方式。 exp \'sys/oracle as sysdba\' file=exp_tts_TEST.dmp transport_tablespace= y tablespaces=USERS,GHOSTOL_DATA,GHOSTOL_INDEX,TEST_DATA,TEST_INDEX,PERFSTAT,STAT_POINT,TEST_MV_DATA,TEST_MV_INDEX,TEST_AUDIT_DATA,JYCX_DATA,OEM_DATA,TEST_INDEX2,TEST_INDEX3,SWDONLINE_DATA,SWDONLINE_INDX,STORELOG_DATA,STORELOG_INDX,OEM_MON_TEST,USERCENTER_DATA log=exp_tts_TEST.log 7.在11g的新库中可以尝试建立相应的用户，这里有几个地方需要注意。 理论上可以通过impdp来完成用户信息的导入，但是这个步骤建议还是手工处理，从10g的库上导出用户的DDL语句，简单修改。 原因在于默认表空间在新库上存在，如果存在PROFILE的资源设置，很可能导入失败。可以批量生成语句，简单修改即可。 CREATE USER "TEST" IDENTIFIED BY VALUES '5F712A8369686639' DEFAULT TABLESPACE "TEST_DATA" TEMPORARY TABLESPACE "TEMP" PROFILE "PF_TEST" ; 后续来继续解读这个迁移的过程。整个过程会是一个完整的演练过程，碰到的问题越多，解决的越多。迁移的时候越顺利。