调查数据表明了性能问题主要集中在ETL部分，Microsoft、Siebel（已被Oracle公司并购）、Informatica三家公司也都明确此类性能问题也可能存在于其他的客户中。但由于用户在系统应用上可能存在较大的差异(比如Business Area), 他们建议在参考本文给的优化方案之前最好咨询你的Siebel顾问。下面提到的问题大部分已经在版本6.X或更高版本中解决掉。而且Siebel(现在应该是Oracle)公司已经从2004年年底开始停止技术支持。
一、问题及解决方案
1、负载性能分析(Load Performance)
使用Vertical版本企业用户的字段数量要远大于使用 horizontal版本的用户,海量的数据量加上这些数据又包含着更多的字段，对性能产生相当大的影响; 另外由于运行Industry Verticalsmappings而不是Horizontal mappings， 在装载数据时产生的一定数量的闲置的索引对性能也产生一定的影响。
这张包含了为一个数据库表用了几个小时加载数据过程的分析数据，得出的结论适用于客户的其他的数据库表，同时也可以做为其他客户性能分析的参考。
LENGH - 数据加载消耗的时间；
RATE – 每秒钟加载数据的记录数；
FF – 指的是平面文件；
DB – 数据库；
No Xform – 数据加载过程中没有数据的映射转换。（表明了映射转换对于加载数据过程有着非常大的影响）
由于读写平面文件的过程的性能最好，这里把这种方式定为“最理想方式”的基线；这为我们尝试的数据库性能最佳优化方案提供了一个参考点。
从表1中的Rate列，我们可以看到无论源是平面文件还是数据库，对于数据加载的整个过程的影响是非常小的。下面的图表能更清晰的说明这点：对于两个不同的数据来源无论我们对我们的目标数据库进行怎样的配置，Rate列的值都非常接近。
通过观察目标数据库，瓶颈的问题所在就显而易见了。下面的的这个图表表明了由于目标系统的原因引起的数据加载速度的迥然差异， 这次我们目标数据库分别为Verticals(拥有更多的字段)和Horizontals。
注一:上图中，对于Vertical加载数据形式，并且目标数据库为DB-CIB (DB Clustered Index with Bulk Loading)，Rate= 0；而且，我们可以看到在目标表中有无索引对于数据加载的影响很大，如果我们在目标表上使用Bulk模式，也使得性能取得了显著的提高。
注二:关于聚集索引(Clustered Indexes)
有人倾向于把聚集索引之外的其他索引都drop掉，任务聚集索引能使得数据库进行数据的物理排序, 认为这样会耗费较长的时间。但是, 由于聚集索引是建立在ROW_WID上，而且ROW_WID总是连续的,数据排列是有序的因此数据库不会再进行物理排序。事实上, W_PERSON_D上使用聚集索引加载数据比不带聚集索引时, session要长大约45分钟。而重新构建聚集索引则仅仅需要5分钟。
注三：
