多套Oracle 10g整合迁移到11g的方案-阿里云开发者社区

开发者社区> 数据库> 正文
登录阅读全文

多套Oracle 10g整合迁移到11g的方案

简介:    在数据迁移中,除了跨平台,全量,增量数据迁移之外,还有一类会把已有的难度升级,那就是整合式迁移,比如原来有两个数据,迁移后是一个,类似这样的需求,如果再加上平滑升级数据库版本,那就值得我们好好想想方案了。

   在数据迁移中,除了跨平台,全量,增量数据迁移之外,还有一类会把已有的难度升级,那就是整合式迁移,比如原来有两个数据,迁移后是一个,类似这样的需求,如果再加上平滑升级数据库版本,那就值得我们好好想想方案了。

  如果两个源库不大,其实直接使用Datapump不失为一种方法,最大的优点就是操作简单,可控性强,而瓶颈也很明显,随着数据量的增长,这个迁移时长就会线性增长,从逻辑迁移的角度来看,对于版本升级的依赖性不高。

   而如果两个源库都很大,比如都是5T这样的级别,整合起来就是10T,这样的量级,给你一个小时搞定,而且还要做数据库的平滑升级,难度就相当大了。

    我们来简单理一下时间主要都花在哪里了。

     1.数据导出,我们还需要额外配置的磁盘空间和存储,基本是200%以上的冗余空间才可以,我们拍脑袋给个时间,比如30分钟。

     2.数据dump传输到目标库,这个时间依赖于几个点,比如源库的网络链路配置,带宽上限等。假设这些都不是问题,还是拍脑袋,至少得60分钟

    3.如果按照预想的计划到了这一步,数据迁移的工作还没正式开始,时间就用完了。我们硬着头皮继续,数据导入,按照目前做PCIE-SSD POC的数据,5T按照最理想的情况,非归档导入至少得500分钟

     所以上面的方案就注定了是一个失败的迁移案例,但是我们可以从中优化出很多东西,直到满足我们的需求为止。

    我们抛开上面的方案来,简单回忆一下,数据库迁移的本质,数据库升级的本质,首先数据可以大体分为系统表空间数据(system,sysaux,undo),应用数据(表数据,索引等),只是表现形式会是表空间,数据文件,如果跨平台,我们考虑的数据的逻辑一致性,而如果不跨平台,考虑的是尽可能按照物理一致性来考量。在整合式迁移中,物理一致性就很难实现,但是我们可以最大程度的实现。

    然后是数据库升级的本质,本质上数据库升级就是数据字典升级,对于数据文件来说,简单来说,可以认为没有差别。

   所以数据库从低版本升级到高版本,比如10g到11g,数据文件本质上是不变的,那么变化的是数据字典,我们就可以取长补短。我们只关注数据字典的这部分,迁移的时候就会有很明确的方向。

   那么上面失败的案例如何优化呢。我们可以极大的减少导出的时间,减少数据dump传输的时间,说得更加自信一些,我们能不能不导出数据,不传输dump。答案显然是可以的,那就是充分利用Data Guard。

   这样前期的工作在正式迁移前都已经就位了,升级的过程中我们需要做得事情就是关注于数据字典的升级,而迁移的部分怎么来做呢,就是通过传输表空间的方式来实现。

    假设我们要迁移的数据库是peak,extradb,我们计划整合后的数据库为peak,那么在服务器上应该会有下面的实例,很明显有两个名为peak的数据库,因为ORACLE_HOME的不同,所以不会冲突。

$ ps -ef|grep smon
oracle    77606      1  0 Jul03 ?        00:00:03 ora_smon_extradb
oracle    97643      1  0 14:39 ?        00:00:00 ora_smon_peak
oracle    98133      1  0 14:49 ?        00:00:00 ora_smon_peak
oracle    98486  98195  0 15:15 pts/0    00:00:00 grep smon

   按照目标库最终的结果,我们的oradata下的目录结果大体如下:

drwxr-xr-x 2 oracle oinstall 4096 Jul 14 15:04 extradb
drwxr-xr-x 2 oracle oinstall 4096 Jul 14 15:01 peak
drwxr-xr-x 2 oracle oinstall 4096 Jul 14 14:46 peak_old

peak是最终的数据文件,extradb和peak的数据文件统统在peak目录下面,而extradb的系统表空间在extradb目录下,源库peak的数据字典在peak_old下。

   如果要迁移数据文件,在备库上操作很简单,可以参考如下的动态SQL.

  select 'alter database rename file '||chr(39)||name||chr(39)||' to '||chr(39)||replace(name,'/extradb/','/peak/') ||chr(39)||';' from v$datafile;

   这个时候peak目录下的文件就像参加一个聚会一样,大家都坐在一起,但是彼此之间还缺少联系,还没有连接起来。

   迁移前,需要做一个基本的检查,当然这个工作是提前要做好的。到时候至少验证一下即可。    

    exec dbms_tts.transport_set_check(TS_LIST=>'USERS,PEAK_DATA,PEAK_INDEX,PEAK_CHANNEL_DATA,PEAK_CHANNEL_INDEX,PEAK_NEW_DATA,PEAK_NEW_INDEX',INCL_CONSTRAINTS=>TRUE,full_check=>true);

然后查看select *from transport_set_violations;
是否有冲突的信息


迁移的时候,把表空间置为read only状态,可以使用如下的动态SQL来生成批量的迁移脚本。

select 'alter tablespace '||tablespace_name ||' read only;' from dba_tablespaces where tablespace_name not in ('SYSTEM','SYSAUX','UNDOTBS1','TEMP');
  导出数据字典的信息:

exp \'sys/oracle as sysdba\' file=exp_tts_peak.dmp transport_tablespace= y tablespaces=USERS,PEAK_DATA,PEAK_INDEX,PEAK_CHANNEL_DATA,PEAK_CHANNEL_INDEX,PEAK_NEW_DATA,PEAK_NEW_INDEX log=exp_tts_peak.log
这个dump其实很小,而且导入的过程时间也很短。

接下来的工作就很琐碎了,就是初始化基本的用户信息,准备导入数据字典的信息,这里需要提到一点的是users表空间的部分,这个表空间整合肯定会冲突,所以如果条件允许,我们可以给表空间改一下名字,避免冲突无法导入。

   导入的部分语句如下,这个过程就是最终的映射,其实就跟一次聚会一样,彼此介绍大家互相认识,产生了连接。

imp \'sys/oracle as sysdba\' file=exp_tts_peak.dmp transport_tablespace=y tablespaces=USERS,xxxxx,U01/app/oracle/oradata/peak/peak_new_data04.dbf,/U01/app/oracle/oradata/peak/peak_new_index04.dbf log=imp_tts_peak.log
   迁移的核心就在此了,行与不行全看这里了。

    而迁移之后,切记需要把表空间置为读写状态,这样一来大部分的迁移工作就提前准备好了。

    如果满打满算,准备充分,半个小时搞定全然不成问题。


   



版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: