Oracle would say that Exadata is transparant to Siebel. But is it really?
The single biggest benefit of Exadata is the concept of Storage Indexes which reside on the the Storage Server – versus traditional B-Tree Database Indexes which are physically stored on disk or reside in cache when being accessed.
Storage indexes are great. Especially for those expensive Siebel queries which require full-tables scan. Especially then Storage indexes can result in impressive performance gains. Storage indexes essentially prevent I/O by telling which 1M areas of data do NOT contain data. They can be helpful as well for “IS NOT NULL” predicates – which B-Tree indexes cannot cope with very well either is most cases.
But there can be only eight Storage indexes on a single table, this means only eight columns can be indexed by the Storage server. And well hey, Siebel tends to have very wide tables which huge logical row sizes.
Storage indexes are being created dynamically by the Storage server based on the workload – especially the WHERE predicates used. If certain columns are accessed frequently – the column will become more likely to receive a Storage index.
The limit of eight Storage indexes is really worth to note. They will be quite suited for visibility intersection tables (e.g. S_POSTN_CON, S_SRV_REQ_BU, etc.). These are tables carrying only a limited number of columns with some denormalized columns from the related base tables. Driving most of the expensive/heavy queries through visibility intersection tables is ideal – especially if the appropriate key columns have been denormalized. In most cases – customers have not gone this path. It requires Oracle’s ACS/ES assistance to create denormalized columns. But the benefit is typically impressive. And with Exadata having your key query columns denormalized will improve the benefit of Storage indices – since the limit of eight indexes per table will be reasonable.
One other design pattern when running Siebel on Exadata might be to use 1:1 extension tables. On non-Exadata implementation you rarther do not use 1:1 extension tables. Especially not for those columns used in WHERE predicates. But given the concept of Storage indexes there are situations where it will better to put a column which is queried in an extension table – to ensure that the Storage server will create an Storage index on that table. This will help especially for those users having to run typically expensive queries (needed for list exports, BIP reports, etc.). It could even make sense to create “denormalized” 1:1 extension columns for this fact (e.g. denormalizing through BC layer using On Field Update user property). This enables you both to create concatenated indexes B-Tree indexes and allow for particular queries or reports to leverage the denormalized column.
