转载

多套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
迁移的核心就在此了，行与不行全看这里了。

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

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

正文到此结束