看我做的数据库包装器

yulihua49 · 发表于 2013-4-27 10:10

本帖最后由 yulihua49 于 2013-4-27 10:46 编辑

newkid 发表于 2013-4-26 21:40
你说的sqlldr使用多节点，那么文件就可以分片了？假如能分成多个文件，那么并行压缩、上传、多个外部表多 ...

我们的外部表是以CSV格式存储的。所以内部处理时也必须要转换。
每天1000多个文件，并行sqlldr是可能的。sqlldr也是OCI啊，使用RAC性能最好的工具，非OCI莫属。
教父TOM否定了sqlldr，也就否定了RAC，我认为RAC是ORACLE最好的东西。

你要用外部表，省事的方法是 tar gzip ftp gzip tar，最慢了。
每天1000多个文件，一个一个的弄，太繁琐，倒是可以分配到各个节点上处理。
每天1000多个外部表也够繁的。

写临时表，再merge回来？
其实我们当时还另有方案，结果写新表。
原表加载后，标记为“未处理”，处理完标记为“已处理”。不可避免的，又是一次update。

newkid · 发表于 2013-4-28 11:00

"教父TOM否定了sqlldr，也就否定了RAC"你的脑筋还转不过弯来？多个文件（外部表）当然可以在多个节点上分别访问。你SQLLDR连接哪个节点，就在那个节点做INSERT...SELECT...这不就用上了RAC?

外部表改文件名容易得很，根本没必要建1000多个。你想分几个SESSION同时处理就建几个，所有文件都可以共享这些表名。上传压缩就写程序嘛，写SHELL脚本也能同时处理多个文件吧？

PLSQL写文件操作当然拼不过C, 但我写那个程序也才花二十分钟，没有特别高要求也可以用了，如果真要极端的性能就去用更专业的工具嘛，比如OO推荐的SQL UNLOADER2。

atgc · 发表于 2013-5-20 21:18

HelloWorld_001 发表于 2013-4-25 23:28
我最近用了下外部表，也感觉sqlldr没啥用处了。因为可以insert into a select * from b。
b表外部表，a表 ...

Oracle自带的工具从数据库导出数据到文本文件，好像性能是差了点
SQL*Loader还是性能非常好的

solomon_007 · 发表于 2013-5-21 09:16

这是一个神奇的帖子

PLSQL vs PROC*C/C++

PLSQL 完胜！高效，简洁，易维护。。。

〇〇 · 发表于 2013-6-2 11:30

atgc 发表于 2013-5-20 21:18
Oracle自带的工具从数据库导出数据到文本文件，好像性能是差了点
SQL*Loader还是性能非常好的

如果不要求文本，datapump格式很快

atgc · 发表于 2013-6-2 14:46

〇〇发表于 2013-6-2 11:30
如果不要求文本，datapump格式很快

客户肯定要文本了，而且还是有选择地导出很多表，甚至复杂的计算

〇〇 · 发表于 2013-6-2 18:04

atgc 发表于 2013-6-2 14:46
客户肯定要文本了，而且还是有选择地导出很多表，甚至复杂的计算

datapump也支持导出一个查询

atgc · 发表于 2013-6-3 08:19

〇〇发表于 2013-6-2 18:04
datapump也支持导出一个查询

客户肯定要文本的，给他一个dump估计要投诉了

yulihua49 · 发表于 2013-6-16 12:23

本帖最后由 yulihua49 于 2013-6-16 12:39 编辑

solomon_007 发表于 2013-5-21 09:16
这是一个神奇的帖子

PLSQL vs PROC*C/C++

奇怪，你从哪得到这个结论，这里通篇都是C，OCI完胜sqlldr，sqlldr完胜存储过程。

RAC加载400w行，OCI＋DAU多线程2.5分钟，sqlldr16分钟，sqlldr direct path 7分40秒，
存储过程外部表加载，性能从未超过sqlldr，这在别的帖子也有表述。

见540楼的单机测试结果，大概DAU也是sqlldr的3倍。

solomon_007 · 发表于 2013-6-16 12:34

yulihua49 发表于 2013-6-16 12:23
奇怪，你从哪得到这个结论，这里通篇都是C，OCI完胜sqlldr，sqlldr完胜存储过程。

RAC加载400w行，O ...

是业务的事务处理，而不是指加载数据

[PRO*C] 看我做的数据库包装器