天天看点

迁移式升级的测试(二)

在之前写的一篇博文中,自己是打算对一台数据库使用Data Guard+TTS的方式来完成数据迁移和升级的工作,整体的思路如下。

迁移式升级的测试(二)

备库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;

------------------------------------------------------------------------------------------------------------------------ Sys owned object  SYS_LOB0000133356C00040$$ in tablespace TS_AUDIT not allowed in pluggable set

迁移式升级的测试(二)

可以看到这个例子中还是违反自包含约束的情况,从日志能够看出,主要是和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_name 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" ;

后续来继续解读这个迁移的过程。整个过程会是一个完整的演练过程,碰到的问题越多,解决的越多。迁移的时候越顺利。

下一篇: 评论