Home/ Questions/Q 252953
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T21:43:16+00:00

I am writing a stored procedure to perform a dynamic search that spans 10+

  • 0

I am writing a stored procedure to perform a dynamic search that spans 10+ database tables. With millions of records in each table and a dynamic set of search parameters*, I am having some trouble optimizing the procedure.

Is there a “best practice” for building these kinds of queries? E.g. Use strings to build a dynamic query, use a huge list of IF THEN .. ELSE statements, etc? Can anyone provide a simple example or point me to some literature that will help? Here’s some psuedocode for the stored procedure I am developing, which accepts a collection of parameters and a ref cursor.

v_query = "SELECT .....";
v_name = ... -- retrieve "name" parameter from collection
if v_name is not null then
   v_query := v_query || ' AND table.Name = ' || v_name;
end if;
open search_cursor for v_query;
...

*By “dynamic set of search parameters,” I mean that I pass in a collection of parameters. I figured this would be easier than making the caller pass in 20 parameters if they only want to search on one.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There are problems with using the static query approach; also be very careful about using the CURSOR_SHARING=FORCE option – it can really raise hell with your system if you haven’t done a coverage test to ensure that all your other queries will work the way you want.

    Problems with static queries:

    1. The (x is null or x = col) predicates tend to kill any chance of using indexes. Since the query plan is computed at the time query is parsed the first time, the indexes you use will be based on the values for the first run of the query; later runs, which may not constrain on the same columns, will still use the same indexes.

    2. Having one static statement with substitution variables will prevent the optimizer from making an intelligent choice about which index to use based on the data distribution. In a dynamic query (or in the first run of a query with bind variables), Oracle will see how selective your constraint is; a highly selective constraint will become a prime candidate for index use. For example, if your table had a row for every person in the U.S., STATE=’Alaska’ will be much more likely to use the index on STATE than STATE=’California’.

    Of course, in both these cases, if the dynamic columns in your WHERE clause are not indexed anyway, it doesn’t matter, although I’d be surprised if that were the case in a database the size you’re talking about.

    Also, consider the real cost of all that hard parsing. Yes, hard parses serialize system resources, which makes them expensive, but only in the context of high volume queries. By their nature, ad-hoc queries do not get run very often. The cost you pay for all the hard parses you incur in an entire day will likely be hundreds of times less than the cost of a single query that uses the wrong indexes.

    In the past, I’ve implemented these systems pretty much like you’ve done here – a base query portion, then iterating over a constraint list and adding WHERE clause predicates. I don’t think it’s hard for someone to maintain or understand, especially if you’re talking about constraints that don’t involve adding a lot of subqueries or extra tables to the FROM clause.

    One thing to consider: If this system is primarily an offline one (in other words, not constantly being updated or inserted into – populated by periodic loads of bulk data), you may want to look into using BITMAP indexes. Bitmap indexes differ from regular b-tree indexes in that multiple indexes on a single table can be used simultaneously, and bitmap indexes are much, much smaller on disk than b-trees. They work very well for applications like this – where you will have a variety of constraints that can’t be defined at design time. You will only want to put bitmap indexes on columns that have relatively few distinct values – say, one value constitutes no less than 1/1000 of the table – so don’t use bitmaps on unique columns.

    However, the downside is that bitmap indexes will noticeably degrade the performance of inserts and updates. The best practice for bitmaps is to use them in data warehouse applications, and they are dropped prior to loads and recreated afterwards.

    • 0