针对之前在生产环境中使用sql*loader的性能问题，最近一直在想使用外部表的oracle_datapump来替代它。
昨天下午做了大量数据的测试，比较了这两种方案。最后发现在一定的限定条件下，从很多细节来看 oracle_datapump要更胜一筹。
首先使用sql*loader对于clob,blob的数据相比普通表的处理要一些额外的工作，但是这些限制或者额外工作再oracle_datapump中就可以很方便的使用，oracle_datapump支持的数据类型要更丰富。
在生产环境中，迁移数据的时候，只是对于foreign key做了disable的操作，对于其他的constraint都做了保留，没有任何其他的操作，所以使用sql*loader 的direct选项就有很多的限制和无法实现的苦衷。在表级都设置了nologging。
--》数据抽取
以下是使用sql*loader和oracle_datapump的一些性能比较。数据量在120-150G左右。
使用sql*loader的时候因为有2张表含有clob字段，所以就先没有处理，以此来对比oracle_datapump的速度。
可以看到sqlldr的速度做数据抽取大概耗费了14分钟，而且不包括2张含有clob的表，生成的dump文件有150G
oracle_datapump的速度要更快一些。只耗费了大概3分钟左右,生成的dump文件要更加精简。
当然了sqlldr可以使用客户端来抽取数据,而oracle_datapump只能基于服务端，灵活性上sqlldr要好一些。
--》数据加载
数据抽取的速度其实不是关键，很多工作可以在升级之前完成，对于系统的影响倒不是很重要，关键在于数据的加载速度。
可以看到采用sqlldr加载数据的时候，启用了150个并行线程，sqlldr开启了并行。耗费了大约80分钟，产生的日志数据量也不少有，230G左右。
而oracle_datapump的表现在这方便确实更胜一筹，启用了4个session，每个session启用并行度为8来做数据的加载，加载速度要快一倍以上。而且产生的日志数据量也少了将近一半。
--》数据校验
在数据校验方面，sqlldr就没有任何可行的方法来比较冗余数据了，在这方面，oracle_datapump可以根据生成的dump文件创建外部表，不耗费额外的表存储空间，在这个基础上，直接可以对外部表和目标表进行比较。在数据加载之前找到可能出现的潜在问题。
--》数据纠错
在数据纠错方面，sqlldr提供了完整的处理机制，如果数据不符合要求被reject，可以生成对应的错误文件，里面包含所有被拒的数据，可以再次使用sqlldr来加载。
但是对于oracle_datapump来说，只能到这里了。不过在数据库层面还有其他可行的方式，比如采用error log就可以得到出错的数据进行排错。
昨天下午做了大量数据的测试，比较了这两种方案。最后发现在一定的限定条件下，从很多细节来看 oracle_datapump要更胜一筹。
首先使用sql*loader对于clob,blob的数据相比普通表的处理要一些额外的工作，但是这些限制或者额外工作再oracle_datapump中就可以很方便的使用，oracle_datapump支持的数据类型要更丰富。
在生产环境中，迁移数据的时候，只是对于foreign key做了disable的操作，对于其他的constraint都做了保留，没有任何其他的操作，所以使用sql*loader 的direct选项就有很多的限制和无法实现的苦衷。在表级都设置了nologging。
--》数据抽取
以下是使用sql*loader和oracle_datapump的一些性能比较。数据量在120-150G左右。
使用sql*loader的时候因为有2张表含有clob字段，所以就先没有处理，以此来对比oracle_datapump的速度。
可以看到sqlldr的速度做数据抽取大概耗费了14分钟，而且不包括2张含有clob的表，生成的dump文件有150G
oracle_datapump的速度要更快一些。只耗费了大概3分钟左右,生成的dump文件要更加精简。
当然了sqlldr可以使用客户端来抽取数据,而oracle_datapump只能基于服务端，灵活性上sqlldr要好一些。
| extract start time |
extract end time |
Duration |
Dump_generated |
|
| sqlldr(exclude 2 tables)_68 tables |
Tue Jul 15 13:28:15 ICT 2014 |
Tue Jul 15 13:42:32 ICT 2014 |
14 mins |
150G |
| EXT_DATAPUMP 70 tables |
Tue Jul 15 14:03:11 ICT 2014 |
Tue Jul 15 14:06:20 ICT 2014 |
3 mins |
59G |
--》数据加载
数据抽取的速度其实不是关键，很多工作可以在升级之前完成，对于系统的影响倒不是很重要，关键在于数据的加载速度。
可以看到采用sqlldr加载数据的时候，启用了150个并行线程，sqlldr开启了并行。耗费了大约80分钟，产生的日志数据量也不少有，230G左右。
而oracle_datapump的表现在这方便确实更胜一筹，启用了4个session，每个session启用并行度为8来做数据的加载，加载速度要快一倍以上。而且产生的日志数据量也少了将近一半。
| |
data loading start time |
data loading end time |
Duration |
archive_logs_generated |
| sqlldr(exclude 2 tables)_68 tables |
Tue Jul 15 14:24:24 ICT 2014 |
Tue Jul 15 15:44:04 ICT 2014 |
80 mins |
230G |
| EXT_DATAPUMP 70 tables |
Tue Jul 15 17:06:51 ICT 2014 |
Tue Jul 15 17:50:04 ICT 2014 |
44 mins |
139G |
--》数据校验
在数据校验方面，sqlldr就没有任何可行的方法来比较冗余数据了，在这方面，oracle_datapump可以根据生成的dump文件创建外部表，不耗费额外的表存储空间，在这个基础上，直接可以对外部表和目标表进行比较。在数据加载之前找到可能出现的潜在问题。
--》数据纠错
在数据纠错方面，sqlldr提供了完整的处理机制，如果数据不符合要求被reject，可以生成对应的错误文件，里面包含所有被拒的数据，可以再次使用sqlldr来加载。
但是对于oracle_datapump来说，只能到这里了。不过在数据库层面还有其他可行的方式，比如采用error log就可以得到出错的数据进行排错。
