Target：
可能成为瓶颈的原因：
- 频繁的COMMIT;
- 网络传输时，包太小；
- 数据库加载问题。
确认问题：
- 方法1：将目标改为文本文件（RUN A TEST SEESSION,系统自带功能），发现性能指标大幅提升，说明问题发生在目标。
- 方法2：通过Thread Statistics识别。
解决方法：
- 去找你家的DBA，让他帮你优化一下QUERY。
- 增加数据库包传输的大小。
- 先删除所有索引，在ETL 之后重建索引。
其他：
TARGET是文本文件的优化：
- 情况1：
如果你有多个TARGET都是文本文件，并且是需要共享的（即存放在共享的目录当中）。那么，你可以专门留一个目录出来做这件事情（并且存放的这个机器还是按文件存放和管理来优化、配置的）。
- 情况2：
如果你使用的是网络IS，并且仅在一个节点上。请考虑把IS换成本地的IS。因为大量数据的传输还是受网络影响的。
先删除所有索引，在ETL 只有重建索引的具体步骤：
- 如果要反复经常去添加约束的话，我们可以使用PRE-LOAD/POST-POAD stored procedures 或者 PRE-SESSION/POST-SESSION COMMANDS来反复调用使用。
增加COMMIT时间间隔：
- 注意：虽然这样可以提升性能，但是意外发生时数据库风险也增加。
使用BULK加载：
- BULK加载和普通加载的区别:? BULK不使用IS 去写日志。
- 注意：这样会造成无法ROLL BACK，即发生意外，数据无法恢复。
使用外部加载器，来提高加载速度和便捷度：
- 因为这里不同数据库有不同的处理方法，这就不详细讲解了。
最小化“锁死”：
- 通过增加TARGET CONNECTION GROUPS来减少死锁的问题。
- 优化前：
target_table_1
target_table_2 ????????DB? ?????????connection
target_table_3
target_table_4
- 优化后：
target_table_1 ?????????DB ? ? ? ? ? connection1(same configuration)
target_table_2 ????????DB? ?????????connection2(same configuration)
target_table_3 ? ? ? ? DB? ? ? ? ? ? connection3(same configuration)
target_table_4 ?????????DB ? ? ? ? ? connection4(same configuration)
