Search Specification Performance

With a web-based application such as Siebel, performance is always a primary concern, especially database performance. Database performance problems can cause ripple effects, as a bad-performing query can cause an increased load on the database, making it slow to respond to other, simpler queries. If a query runs several times (for example, when a user scrolls through a list applet, causing multiple fetches from a slow-performing cursor) database performance problems can become the Achilles heel of a Siebel implementation, and network slowdowns can compound this problem, as multiple fetches are added to multiple network round trips.

One easy way to attack database performance from the outset is by examining Search Specifications and Sort Specifications configured in your Business Components, Applets, and Pre-Defined Queries. Searches and Sorts should use indexed columns whenever possible, and you should be careful not to defeat your indexes by searching on an expression that will not use one. For example, avoid using "OR" in your search expressions, because the expression is simply copied to the WHERE clause of the query, and databases generally do a full table scan on an "OR" condition.

If you have any doubts about the performance of a particular search, compile the SRF, spool the SQL, and ask your DBA to run the explain plan. He or she can tell you if your query is performing optimally. Siebel performance can be a little bit tricky, because you don't write the SQL yourself, and you can't actually provide database hints. But when you are writing Search Expressions, you may have more control over the generated SQL than you realize.