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

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

比如表T生成了两个dump文件(t_1.dmp,t_2.dmp),就可以考虑如下的方式来加载,黄色部分是对应的dump文件。

CREATE TABLE T_EXT_1
   (    id number,object_id number,object_name varchar2(30),object_type varchar2(30),clob_test clob   ) 
   ORGANIZATION EXTERNAL 
    ( TYPE ORACLE_DATAPUMP
      DEFAULT DIRECTORY "EXPDP_LOCATION"
      LOCATION
       ( 't_1.dmp'
       )
    );

CREATE TABLE T_EXT_2
   (    id number,object_id number,object_name varchar2(30),object_type varchar2(30),clob_test clob   ) 
   ORGANIZATION EXTERNAL 
    ( TYPE ORACLE_DATAPUMP
      DEFAULT DIRECTORY "EXPDP_LOCATION"
      LOCATION
       ( 't_2.dmp'
       )
    );
对应的脚本如下:
其中在DUMP目录下存放着生成的dump文件,根据动态匹配得到最终生成了几个dump文件,来决定创建几个对应的外部表。

target_owner=`echo "$2" |awk -F@ '{print $1}'|awk -F/ '{print $1}'|tr '[a-z]' '[A-Z]'`
source_owner=`echo "$1" |awk -F@ '{print $1}'|awk -F/ '{print $1}'|tr '[a-z]' '[A-Z]'`
tab_name=`echo "$3"|tr '[a-z]' '[A-Z]'`
owner_account=$5

tmp_parallel=`ls -l ../DUMP/${tab_name}_[0-9]*.dmp|wc -l`
echo  parallel :$tmp_parallel
for i in {1..$tmp_parallel};
do
echo \'${tab_name}_$i.dmp\' >> tmp_${tab_name}_par_dmp.lst
done

sed -e '/^$/d'  tmp_${tab_name}_par_dmp.lst > ../DUMP_LIST/${tab_name}_par_dmp.lst
rm tmp_${tab_name}_par_dmp.lst
dump_list=`cat ../DUMP_LIST/${tab_name}_par_dmp.lst`

print "
conn  $1
set feedback off
set linesize 100
col data_type format a30
set pages 0
set termout off
SELECT 
        t1.COLUMN_NAME,  
        t1.DATA_TYPE  
        || DECODE (  
             t1.DATA_TYPE,  
              'NUMBER', DECODE (  
                              '('  
                           || NVL (TO_CHAR (t1.DATA_PRECISION), '*')  
                           || ','  
                           || NVL (TO_CHAR (t1.DATA_SCALE), '*')  
                           || ')',  
                           '(*,*)', NULL,  
                           '(*,0)', '(38)',  
                              '('  
                           || NVL (TO_CHAR (t1.DATA_PRECISION), '*')  
                           || ','  
                           || NVL (TO_CHAR (t1.DATA_SCALE), '*')  
                           || ')'),  
              'FLOAT', '(' || t1.DATA_PRECISION || ')',  
              'DATE', NULL,  
              'TIMESTAMP(6)', NULL,  
              '(' || t1.DATA_LENGTH || ')')  ||','
           AS DATA_TYPE
           from all_tab_columns t1 where owner=upper('$owner_account') AND table_name=upper('$3' )
order by t1.column_id;
"|sqlplus -s /nolog > ${tab_name}.temp

sed -e '/^$/d' -e '$s/.$//' -e  's/CLOB(4000)/CLOB/g' -e  's/BLOB(4000)/BLOB/g' ${tab_name}.temp > ../DESC_LIST/${tab_name}.desc
rm ${tab_name}.temp
for i in {1..$tmp_parallel}
do 
echo loading table ${tab_name} as ${tab_name}_EXT_$i
sqlplus -s $2
set timing on
set echo on
CREATE TABLE  ${tab_name}_EXT_$i
   ( 
  `cat ../DESC_LIST/${tab_name}.desc `
   ) 
   ORGANIZATION EXTERNAL 
    ( TYPE ORACLE_DATAPUMP
      DEFAULT DIRECTORY $4
      LOCATION(
  `sed -n "${i}p"  ../DUMP_LIST/${tab_name}_par_dmp.lst`
    ));
EOF
done
exit

生成的日志类似下面的格式:
 loading table T as T_EXT_1
Elapsed: 00:00:01.33
 loading table T as T_EXT_2
Elapsed: 00:00:01.30

时间: 2024-09-28 11:12:50

海量数据迁移之外部表切分的相关文章

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

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

海量数据迁移之外部表加载

在并行生成了大量的dump文件后,可以在目标环境上对数据进行加载,这个加载的过程时间极短,都基本可以在毫秒级完成. 由于在外部表的加载过程中需要知道表结构的定义,所以可以通过如下的脚本得到表定义的基本语句,输出和desc类似. 因为目标环境中的表结构可能会和源dump文件中的表结构有一定的出入.所以可以在目标环境中生成表结构的定义语句. 批量加载生成的dump文件. 大体的效果如下 根据目标环境的表结构定义,生成黄色部分的表结构定义语句.然后在加载dump的时候,可以动态批量的加载dump文件,

海量数据迁移之传输表空间(一)

在自己接触的很多的数据迁移工作中,使用外部表在一定程度上达到了系统的预期,对于增量,批量的数据迁移效果还是不错的,但是也不能停步不前,在很多限定的场景中,有很多物理迁移中使用传统方法还是相当不错的,传输表空间就是一个样例. 最近的有一个数据迁移任务是需要把一些全新的数据表迁移到另外一个库中,因为这些表在目标库中不存在,所以使用逻辑迁移就显得有些力不从心了.尽管在速度可以接受的情况下,最大的痛处就是大量的归档文件了. 因为需要在原有的schema下增加一些全新的数据表,不是很肯定传输表空间的校验是

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

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

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

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

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

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

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

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

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

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

oracle数据泵不同工作方式性能比较(四)测试外部表导出、导入方式

根据Oracle的文档的描述,数据泵采用不同的方式导出导入,性能也会有明显的差别,这次正好有机会测试一下,迁移表空间.直接路径.外部表方式,以及数据库链方式导出.导入的性能差异. 这篇测试外部表导出.导入方式. 首先清除上一篇文章中导入的用户和表空间,并重新建立测试用户和表空间. SQL> DROP USER TJSQ_NDMAIN CASCADE; User dropped. SQL> DROP USER TJSQ_TRADE CASCADE; User dropped. SQL> D