海量数据迁移之使用分区并行切分导入

在之前的章节中讨论过怎么把一个很大的分区表切分为若干的dump文件,在数据加载的时候能够同时做基于每个分区的数据导入,如果有些分区比较大,有几十个dump文件,那么这个分区做数据导入的时候是不能再进行并行切分了。
现在在准生产环境中先查找了如下的表,charge,memo,charge_rel数量级都过亿,而且memo表中还含有lob字段。其他两个分区尽管字段没有特殊之处,但是分区数很多。都在几百个左右。

charge
 133036878
memo
186700029   

CHARGE_REL
 131419041

我把数据导入分成了10个并行的process,每个process里面处理对应的分区表数据。
比方说charge表
CHARGE 206..206 "partition(P30_C30)"
CHARGE 197..199 "partition(P29_C40)"
CHARGE 188..188 "partition(P28_C50)"
CHARGE 179..179 "partition(P27_C60)"
CHARGE 170..170 "partition(P26_C70)"
CHARGE 161..161 "partition(P25_C80)"

我定位了206号dump是归属分区P30_C30的,197~199号dump是归属分区P29_C40的
先来看看数据导入前的表空间。
                               Total MB    Free MB     Used MB  
                          ------------ ---------- -----------
sum                          1,490,261    585,573     904,688

数据导入15分钟后。超大的memo表竟然都快完成了!
############################################################
                    CHARGE_REL  152 of TOTAL   222 completed, |--processing... from      split_par_9_appendata.log 
                             MEMO  401 of TOTAL   446 completed, |--processing... from      split_par_9_appendata.log 
                          CHARGE  175 of TOTAL   322 completed, |--processing... from      split_par_9_appendata.log                    
另外两个大表也在继续。稍候,大部分的进程开始处理另外2个大表。
又过了10分钟
############################################################
                     CHARGE_REL  160 of TOTAL   222 completed, |--processing... from      split_par_9_appendata.log 
                             MEMO  405 of TOTAL   446 completed, |--processing... from      split_par_9_appendata.log 
                           CHARGE  224 of TOTAL   322 completed, |--processing... from      split_par_9_appendata.log

表空间的信息如下:
                               Total MB    Free MB     Used MB  
                          ------------ ---------- -----------
sum                          1,490,261    380,798   1,109,463

短时间内消耗了200g,速度提升不少。

时间: 2024-10-02 10:06:18

海量数据迁移之使用分区并行切分导入的相关文章

海量数据迁移之分区并行切分

在海量的数据迁移中,如果某个表特别大,可以考虑对表中的分区进行切分,比如某个表有100g,还有100个分区,那么可以考虑针对这100个分区,那么可以考虑把这100个分区看成100个表进行并行抽取,如果某个分区数据比较多,可能生成5个dump,那么着100个分区,就可能生成105个分区以上. 那么如果有100多个表,那么可能分区都算进来就可能有上千个.如何对这上千个dump进行最快的加载呢. 可以考虑基于分区的并行切分,里面可能还涉及一些算法的知识. 目前生成了如下的数据报告,我们需要基于这个报告

海量数据迁移之外部表并行抽取

在10g开始的新特性中,外部表是一个不容忽视的好工具.对于大型项目中海量数据使用sqlloader是一种全新的方式,不过很明显,sqlloader的可扩展性更强,但是基于oracle平台的数据迁移来说,外部表的性能也不错.对于数据迁移来说也是一个很好的方案. 使用外部表来做数据迁移,可以"动态"加载数据,能够很方便的从数据库中加载数据,对于数据校验来说就显得很有优势了,而对于sqlloader来说,可能得等到数据加载的时候才知道是不是有问题,如果对于数据的准确性要求极高,可以使用外部表

海量数据迁移之通过rowid切分大表

在之前的章节中,讨论过了通过 分区+并行等方式来进行超大的表的切分,通过这种方式能够极大的提高数据的平均分布,但是不是最完美的. 比如在数据量再提高几个层次,我们假设这个表目前有1T的大小.有10个分区,最大的分区有400G,那么如果我们想尽可能的平均的导出数据,使用并行就不一定能够那么奏效了. 比方说我们要求每个dump文件控制在200M总有,那样的话400G的分区就需要800个并行才能完成,在实际的数据库维护中,我们知道默认的并行数只有64个,提高几倍,也不可能超过800 所以在数据量极大的

海量数据迁移之一个误操作的问题总结

在生产环境中的数据迁移还是很惊心动魄的,毕竟生产的数据不容许有任何潜在的问题,很小的问题也可能导致业务的终端,这个时候dba的角色是很重要的,如果dba犯了一个很细小的问题,在海量数据迁移中可能会导致灾难性的结果,所以今天和大家讨论一下关于由vi误操作导致的问题及总结. 结合今天早上的例子来说明. 目前生产环境已经有大量的用户数据了,需要从老系统迁移一批用户数据过来,一切都在安装好计划进行准备和操作.我是采用了外部表的方式,把一个很大的表分为了几十上百个外部表,采用insert方式加载的. 数据

海量数据迁移之外部表切分

在前几篇中讨论过海量数据的并行加载,基本思路就是针对每一个物理表都会有一个对应的外部表,在做数据迁移的时候,如果表有上百G的时候,一个物理表对应一个外部表性能上会没有任何提升.如果需要做数据插入的时候,对undo是极大的挑战,从某种程度上而言,性能应该要比datapump要差.这个时候可以考虑一个物理表对应多个外部表,比如一个表有100G.可以考虑生成100个external dump 文件,然后加载生成100个外部表,每个dump文件对应一个外部表,这样做数据的插入的时候就相对容易控制了.每一

海量数据迁移之使用shell启用多个动态并行

在数据迁移中,可能有成百上千个表,有些表很大,有些表又很小. 如果启用了多个并行的进程,可能会有资源分配上的问题. 比如下面有10个表,100代表预计的时间为100分钟. table1  100 table2  90 table3  90 table4  80 table5  80 table6  70 table7  60 table8  60 table9  50 table10 40 如果分为4个进程来并行执行,可能一种比较理想的方案就是 parallel1: table1,table8

海量数据迁移之分区表批量insert性能改进

在平时的工作中接触到的分区表一般都比较大,而且分区也少则几十,多则几百,上千. 在数据迁移的时候,分区表的迁移更是块大骨头,因为数据量太大,而且有些分区表中还有一些lob字段,想直接通过sqlldr来迁移还是需要做一些额外的工作. 如果通过datapump分区导出数据,批量导入,也是一种思路,不过需要考虑好并发的进程. 通过oracle_datapump来做数据的导入,可能更为灵活,但是不是绝对的.最近就做了一些相关的数据导入测试,感触不少. 比如,目前我们需要导入的两个大表,一个是memo,一

海量数据迁移之数据加载流程

在之前的博文中分享了关于数据抽取流程的一些思路,整体来说,数据的抽取是辅助,数据的加载是关键.加载的过程中每一步需要格外关注,稍有偏差就可能造成数据的损坏或者丢失. 为了更加清晰的说明通过外部表来实现数据加载的流程,特意画了如下的流程图. 在这个图中,数据的抽取是左边的部分,可以根据需要生成对应的外部表dump文件. 这个时候可以在目标环境中也创建只读用户,外部表用户,只读用户中只存放同义词,外部表用户中存放的是需要加载的外部表,整个外部表的加载过程不会消耗额外的物理空间,而且加载啊速度极快.

如何将海量数据迁移上云

背景 众所周知,云计算的出现改变了IT世界的格局,更低廉的成本和更加易于扩展的特点都成为了传统软件行业改变的动力.而阿里云在此基础上提供了更加完善的服务,更高的可靠性,以及更加低廉的价格,成为了业界值得优先考虑的品牌. 如果您有成千上万的文档.图片.音视频文件需要上传到OSS上来,或者从其他的云存储产品上迁移过来,如何才能应对规模如此庞大的数据迁移,如何处理迁移过程中业务上的新增数据? OSS有一套完整的无缝数据迁移方案可以帮您解决这些问题. 方案 整个迁移过程分为下面几个步骤: 配置Bucke