ODB是Trafodion数据库平台与其他数据库以及文件之间抽数的工具。以下为一些通用的优化方法。
参考文档：http://trafodion.incubator.apache.org/docs/odb/index.html
1、 odbcinst.ini中加上Threading = 1后能够提升并发导入的性能。
例如
---------------------
[ODBC]
Threading = 1
Trace = Off
Tracefile = uodbc.trc
---------------------
默认是最高级别的锁，也就是Threading = 3，那自然就不能多线程插入。如果改成Threading = 1，就避免了这个问题。而且，我们数据库没有锁的概念，也就是完全的线程安全，所以多线程操作，理论上不会导致数据紊乱。
2、 loadcmd方式可提升性能
关于loadcmd这个参数=UL，UL的简称是upsert using load，正常情况下插入速度由快到慢的顺序是:
Load> Upsert using load(UL) > Upsert(UP) > Insert(IN)
3、 parallel设置
min(number of middle-tierCPUs, number of source CPUs, number of target CPUs)
针对parallel的设置，以上的odb官方文档的说明。我需要补充的是，parallel的设置不仅与cpu有关，也与磁盘的读取速度有关。当我使用磁盘速度为100M/s和使用70M/s较优的parallel不一样，100M/s速度的磁盘parallel为14性能较优，而70M/s速度的磁盘parallel为6-8较优。
另外一个parallel调整的参考为odb结果中的Reader Total/Wait Cycles。例如，ReaderTotal/Wait Cycles: 200/96时，说明有96个写的等待，也就是说需要增大parallel以减少写等待而提升性能。一般Wait Cycles/ReaderTotal在5%以下较好，如果已经在5%以下仍继续增大parallel，有可能会产生副作用，性能反而下降。
4、 table salt对odb性能的影响
创建表的时候没有设置salt到设置salt=100的测试结果来看，odb的性能并没有随着salt的增大出现性能提升的趋势，而是从没有salt到salt=100性能基本保持不变。
原因分析：在观察HBase的RegionServer请求可以看出，在HBase层面我的测试的数量级（load、copy数据量为22G）没有达到单个Region处理数据请求的瓶颈，当创建的表不设置salt时，load的过程中，一个RegionServer的请求量和创建表时设置了多个salt的情况下多个RegionServer的请求量总和基本一致。所以现在不论是load还是copy，性能的瓶颈不在写入，而在读取数据（load的时候主要受限于磁盘的速度，copy时主要是读取其他数据库的速度），所以salt的优势在这样的情况下没有发挥出来。
所以，针对创建表时salt的设置，在odb不用考虑太多，salt的设置主要依赖数据量的大小和后续的业务分析进行相应的设置即可。
5、 批量删除表
以下是odb批量删除表示例：
进入odb操作的交互界面（servicename为traf， username为trafodion，passwd为traf123）
odb64luo -d traf -u trafodion -p traf123 -I
删除odb_load_perf schema下的所有表（”&t:” 代表删除的是表）
drop table &t:odb_load_perf.%;
6、 odb从hdfs上load数据
示例如下：
./odb64luo -u trafodion -p traf123 -d traf-l src=hdfs./user/trafodion/odb_performance_loadfile/load_data_performance:tgt=trafodion.odb_load_perf.big_table22:rows=50000:parallel=8:nomark:loadcmd=UL:fs=\|:sq=\"
7、 Dynamic Load Balancing
在执行时间相差大的语句混合的时候非常有用，通过增加-dlb启用。
8、 odb设置timeout
通过增加-timeout 3600（表示超时时间为3600s）设置3600s超时退出。