多套Oracle10g集成迁移到11g的方法是什么？

在数据迁移中，除了跨平台、全量、增量的数据迁移之外，还有一种类型会加剧现有的难度，那就是集成迁移。例如，有两次原始数据迁移。最后一个就是这样的要求。如果再加上数据库版本的平滑升级，是值得思考的解决方案。

如果两个源码库不大的话，其实也是直接使用Datapump的方法。最大的优点是操作简单、可控性强，但瓶颈也很明显。随着数据量的增加，则迁移时间会线性增加。从逻辑迁移的角度来看，对版本升级的依赖度并不高。

而如果两个源码库都很大，比如5T，那么整合起来就是10T。会给你一个小时的时间来完成，并且你还需要顺利升级数据库。难度相当高。

我们简单分析一下时间主要花在哪里。

1、数据导出，我们还需要额外的磁盘空间和存储，基本上是200%以上的冗余空间。我们给它一个时间，比如 30 分钟。

2. 将数据转储传输到目标库。这个时间取决于几个点，比如源库的网络链接配置、带宽限制等，假设这些都不是问题，最好拍拍头，至少等待60分钟

所以上面的方案注定是一个失败的迁移案例，但是我们可以从中进行很多优化，直到它满足我们的需求。

我们先抛开上面的解决方案，简单回顾一下数据库迁移和数据库升级的本质。首先，数据大致可以分为系统表空间数据（system、sysaux、undo）和应用数据（表数据、索引等），只是表示就会是表空间和数据文件。如果是跨平台的话，我们会考虑数据的逻辑一致性。如果不是跨平台，我们会尽可能考虑物理一致性。在集成迁移中，物理一致性很难实现，但我们可以最大程度地实现。

然后就是数据库up的本质年级。数据库升级本质上就是数据字典升级。对于数据文件来说，简单来说，没有什么区别。

因此，当数据库从低版本升级到高版本，比如10g升级到11g时，数据文件本质上是保持不变的，所以变化的是数据字典，我们可以借鉴一下用别人的长处来弥补短处。我们只关注这部分数据字典，迁移的时候就会有明确的方向。

那么如何优化上面的失败案例呢。我们可以大大减少导出时间并减少数据转储传输时间。为了更有信心，我们不能导出数据或传输转储。答案显然是肯定的，那就是充分利用Data Guard。

这样，正式迁移之前的前期工作就已经做好了。在升级过程中我们需要做的就是重点关注数据字典的升级。迁移部分怎么做是通过trans任务表空间方法。

假设我们要迁移的数据库是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:0 0 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 高峰
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)||名称||chr(39)||'到 '||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;
是否re 是冲突信息

迁移时，将表空间设置为只读状态。您可以使用以下动态SQL生成批量迁移脚本。

选择“更改表空间”||表空间名称||'只读;' from dba_tablespaces where tablespace_name not in ('SYSTEM','SYSAUX','UNDOTBS1','TEMP');
导出数据字典信息：

exp \'sys/oracle as sysdba\'文件=exp_tts_peak.dmp 传输表空间= y 表空间=USERS、PEAK_DATA、PEAK_INDEX、PEAK_CHANNEL_DATA、PEAK_CHANNEL_INDEX、PEAK_NEW_DATA、PEAK_NEW_INDEX 日志=exp_tts_peak。 log
这个转储实际上非常小，并且导入过程花费的时间非常短。

接下来的工作很琐碎，就是初始化用户基本信息，准备导入数据字典信息。这里需要提到的一件事是users表空间。这个表空间的整合肯定会产生冲突。 ，所以如果条件允许的话，我们可以将表空间的名称改为避免冲突和导入失败。

部分导入语句如下。这个过程就是最终的映射。事实上，这就像一个聚会，每个人都互相介绍并建立联系。

imp \'sys/oracle as sysdba\' file=exp_tts_peak.dmp Transport_tablespace=y 表空间=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
迁移的核心就在这里，能不能行就看这个了。

迁移完成后，记得将表空间设置为可读写状态，这样大部分迁移工作就会提前做好准备。

如果你计划周密，准备充分，半个小时完成也不成问题。

感谢您的阅读。以上就是《多套Oracle10g集成迁移到11g有什么方法》的内容。看完这篇文章，相信大家e 熟悉多套Oracle10g的集成和迁移。对于11g方法是什么的问题我有了更深的理解，具体用法还需要实践来验证。在此，小编将为大家推送更多相关知识点的文章，欢迎关注！