最近做了一次文描系统的迁移,涉及到大量的lob表,对于这种文描表的处理,其实不建议放在oracle 的lob字段中.对于LOB相信大家肯定遇到过各种问题
LOB的直接读写往往会对存储层面造成很大的压力,瞬间的并发严重的可能导致系统的崩溃.相信维护过秒杀系统的同学深有感触。

鉴于这次的迁移.总结了一点经验，对于文描这种应用（图书，药物等）首先应该考虑文件系统,在数据库层面通过指针来访问,其次可以考虑nosql的应用
(推荐mongodb),对于这次的迁移来说考虑了以下几种方式:

示例表为:

[oracle@db-2-16 ~]$ ora bigtable

OWNER TABLE_NAME SIZE_MB
—————————— —————————— ————
PROD_DATA2 PRODUCT_DESCRIPTION 78,165

这是一张将近80GB的lob表 (product_description column nclob)

SQL> select segment_name from dba_lobs where table_name=’PRODUCT_DESCRIPTION’;

SEGMENT_NAME
——————————
SYS_LOB0000017343C00008$$

SQL> select sum(bytes)/1024/1024 from dba_segments where segment_name=’SYS_LOB0000017343C00008$$’;

SUM(BYTES)/1024/1024
——————–
74117

LOB字段大小为74GB

对于这种表考虑了第一种方法:oracle goldengate

想通过ogg单独抽这种表,由于这次迁移是10g-11g ogg正好有用武之地,测试发现ogg的初始化极其缓慢(老毛病了) 放弃 同理测试DDS DSG 同样很慢。

方法二：采用了expdp 使用parallel 8 方式导出预计需要5个小时以上 放弃 采用exp query PK mod=8 预计8小时以上 放弃。

方法三：采用CTAS 通过dblink方式 这种方法的好处是节省了传输的时间,直接在目标端进行数据的插入注意这种方式有一个要求 不能够直接create table as select 这也跟kamus讨论过,DDL parallel 是不支持LOB字段的表的：

DDL statements

Some examples are CREATE TABLE AS SELECT,CREATE INDEX,REBUILD INDEX,REBUILD INDEX PARTITION and MOVE/SPLI/COALESCE PARTITION.

You can normally use parallel DDL where you use regular DDL. There are, however, some additional details to consider when designing your database.

One important restriction is that parallel DDL cannot be used on tables with object or LOB columns.

All of these DDL operations can be performed in NOLOGGINGmode for either parallel or serial execution.

The CREATE TABLE statement for an index-organized table can be parallelized either with or without an AS SELECT clause.

Different parallelism is used for different operations.Parallel create (partitioned) table as select and parallel create (partitioned) index run with a degree of parallelism equal to the number of partitions.

采用手工insert append的方式将主键分为20个分区.多个SQL 同时插入 这种方式预估时间为2个小时,是可以接受的。

方法四：利用prebuild MV快速迁移 这是最便宜也是最省心的(当然如果你的ogg不需要收费的话..) 这种方法可以参考楚天的文章：
利用prebuild MV快速迁移跨平台数据库实施及其总结
测试结果为complete refresh 花了将近8个小时。不过一旦初始化完成,后面将大大简化迁移时候的操作,只需要drop掉mv即可。

方法五: 也是我们最终采用的PCIE卡直接抽取 flash技术在公司已经大量运用了.具体操作为搭建一个文件存放在fusion-IO上的物理DG,迁移停机之后active这个DG 使用expdp导出这张表。惊讶的是导出这张表仅仅只需要20分钟,强大的fusion-io!
同样测试了华为的超高速SSD 表现还可以需要40分钟左右。这种方法的好处在于物理DG十分的可靠,在迁移之前可以最大划的保证数据的完整性(ogg,mv可能丢数据) 这样就省去了表数据的对比工作，同样20分钟的表现完全可以接受。

这里大致谈了lob字段的迁移方法,其实对于lob字段的运用关键还在于设计。在大数据即将到来的今天,合理的运用各种技术才是最重要的。