多套Oracle 10g整合迁移到11g的方案
<p style="margin-top: 0px; margin-bottom: 0px; padding: 0px 0px 15px; text-indent: 2em; color: rgb(51, 51, 51); font-family: &quot;Microsoft YaHei&quot;; font-size: 14px; white-space: normal; background-color: rgb(244, 244, 244);"><span style="line-height: 1.5;">在数据迁移中,除了跨平台,全量,增量数据迁移之外,还有一类会把已有的难度升级, 那就是整合式迁移,比如原来有两个数据,迁移后是一个,类似这样的需求,如果再加上 平滑升级数据库版本,那就值得我们好好想想方案了。</span></p><p style="margin-top: 0px; margin-bottom: 0px; padding: 0px 0px 15px; text-indent: 2em; color: rgb(51, 51, 51); font-family: &quot;Microsoft YaHei&quot;; font-size: 14px; white-space: normal; background-color: rgb(244, 244, 244);">如果两个源库不大,其实直接使用Datapump不失为一种方法,最大的优点就是操作简单, 可控性强,而瓶颈也很明显,随着数据量的增长,这个迁移时长就会线性增长,从逻辑迁移 的角度来看,对于版本升级的依赖性不高。</p><p style="margin-top: 0px; margin-bottom: 0px; padding: 0px 0px 15px; text-indent: 2em; color: rgb(51, 51, 51); font-family: &quot;Microsoft YaHei&quot;; font-size: 14px; white-space: normal; background-color: rgb(244, 244, 244);"><span style="line-height: 1.5;">而如果两个源库都很大,比如都是5T这样的级别,整合起来就是10T,这样的量级, 给你一个小时搞定,而且还要做数据库的平滑升级,难度就相当大了。</span></p><p style="margin-top: 0px; margin-bottom: 0px; padding: 0px 0px 15px; text-indent: 2em; color: rgb(51, 51, 51); font-family: &quot;Microsoft YaHei&quot;; font-size: 14px; white-space: normal; background-color: rgb(244, 244, 244);"><span style="line-height: 1.5;">我们来简单理一下时间主要都花在哪里了。</span></p><p style="margin-top: 0px; margin-bottom: 0px; padding: 0px 0px 15px; text-indent: 2em; color: rgb(51, 51, 51); font-family: &quot;Microsoft YaHei&quot;; font-size: 14px; white-space: normal; background-color: rgb(244, 244, 244);"><span style="line-height: 1.5;">1.数据导出,我们还需要额外配置的磁盘空间和存储,基本是200%以上的冗余空间才可以, 我们拍脑袋给个时间,比如30分钟。</span></p><p style="margin-top: 0px; margin-bottom: 0px; padding: 0px 0px 15px; text-indent: 2em; color: rgb(51, 51, 51); font-family: &quot;Microsoft YaHei&quot;; font-size: 14px; white-space: normal; background-color: rgb(244, 244, 244);"><span style="line-height: 1.5;">2.数据dump传输到目标库,这个时间依赖于几个点,比如源库的网络链路配置,带宽上限等。 假设这些都不是问题,还是拍脑袋,至少得60分钟</span></p><p style="margin-top: 0px; margin-bottom: 0px; padding: 0px 0px 15px; text-indent: 2em; color: rgb(51, 51, 51); font-family: &quot;Microsoft YaHei&quot;; font-size: 14px; white-space: normal; background-color: rgb(244, 244, 244);"><span style="line-height: 1.5;">3.如果按照预想的计划到了这一步,数据迁移的工作还没正式开始,时间就用完了。 我们硬着头皮继续,数据导入,按照目前做PCIE-SSD POC的数据,5T按照最理想的情况, 非归档导入至少得500分钟</span></p><p style="margin-top: 0px; margin-bottom: 0px; padding: 0px 0px 15px; text-indent: 2em; color: rgb(51, 51, 51); font-family: &quot;Microsoft YaHei&quot;; font-size: 14px; white-space: normal; background-color: rgb(244, 244, 244);"><span style="line-height: 1.5;">所以上面的方案就注定了是一个失败的迁移案例,但是我们可以从中优化出很多东西,直到满足我们的需求为止。</span></p><p style="margin-top: 0px; margin-bottom: 0px; padding: 0px 0px 15px; text-indent: 2em; color: rgb(51, 51, 51); font-family: &quot;Microsoft YaHei&quot;; font-size: 14px; white-space: normal; background-color: rgb(244, 244, 244);"><span style="line-height: 1.5;">所以数据库从低版本升级到高版本,比如10g到11g,数据文件本质上是不变的,那么变化的是数据字典, 我们就可以取长补短。我们只关注数据字典的这部分,迁移的时候就会有很明确的方向。 那么上面失败的案例如何优化呢。我们可以极大的减少导出的时间,减少数据dump传输的时间, 说得更加自信一些,我们能不能不导出数据,不传输dump。答案显然是可以的,那就是充分利用Data Guard。 这样前期的工作在正式迁移前都已经就位了,升级的过程中我们需要做得事情就是关注于数据字典的升级, 而迁移的部分怎么来做呢,就是通过传输表空间的方式来实现。 假设我们要迁移的数据库是peak,extradb,我们计划整合后的数据库为peak,那么在服务器上应该会有下面的实例, 很明显有两个名为peak的数据库,因为ORACLE_HOME的不同,所以不会冲突。</span></p><p><br/></p>

CopyRight 2020 All Right Reserved 济南金付宝数字科技有限公司 鲁ICP备20031440号