View Objects , whereclauseparam and PERFORMANCE in JSP

Question

We experience that using the method setWhereClauseParam gives VERY BAD performance in our JSP applications.
According to JDev team and others, "best practice" is to use setWhereClauseParam(s), so we wonder why the performance degrade significantly compared to a simpler approach (=define the whereclause when the datasource is created). To avoid the shared pool to grow we were tempted to use the recommended best-practice-parameter-binding approach, but due to performance we had to drop that idea.
Our JSP (pseudo) code look like this:
<jbo:ApplicationModule id="am" .......
<jbo:DataSource id="ds" appid="am" viewobject="ourView" rangesize="0"/>
<%
ViewObject ourVo= ds.getApplicationModule().FindViewObject("ourView");
ourVo.setWhereClauseParam(0, 'xxx');
ourVo.setWhereClauseParam(1, 'yyy');
%>
<jbo:RowsetIterate datasource="ds" >
bla bla bla ..
</jbo:RowsetIterate>
THIS IS SLOW !! ..... compared to:
<jbo:ApplicationModule id="am" .......
<% String clause = "Col1 = 'xxx' and Col2 = 'yyy' %>
<jbo:DataSource id="ds" appid="am" whereclause='<%= clause %>' viewobject="LabelHeadersView" rangesize="0"/>
<jbo:RowsetIterate datasource="ds" >
bla bla bla ..
</jbo:RowsetIterate>
We get the same results but the last method is times 100 faster ??
Any ideas are appreciated .
Thanks, Jens

Answer 1

OK. I believe I now know what the culprit it. It is your use of the where clause fragment:
(pdk_files_id = ? OR ? IS NULL)
Here's how I arrived at this (while at the same time ruling BC4J out of the picture as a potential cause of the problem).
I following the steps below:
[list]
[*]Connected as SCOTT in SQLPlus, I create the table:
CREATE TABLE files( pdk_files_id NUMBER PRIMARY KEY, name VARCHAR2(20));
[*]I insert one row into the new files table:
INSERT INTO files values (1111, 'SteveTest');
COMMIT;
[*]I connect as SYSTEM, an run the script ORACLE_HOME/sqlplus/admin/plustrce.sql to create the SQL*Plus PLUSTRACE role so that SCOTT will be able to use the SQLPlus AutoTrace feature
[*]As SYSTEM still, I ran the command: GRANT PLUSTRACE TO SCOTT
This gives SCOTT the privilege to use the SQL*Plus autotrace command
[*]I connect as SCOTT, and run the script ORACLE_HOME/rdbms/admin/utlxplan.sql
this created the plan table in my SCOTT schema needed to run the autotrace feature
[*]In SQLPLUS, still connected as SCOTT I issue the command:
SET AUTOTRACE ON EXPLAIN
[*]Then I do the following to create a SQL*Plus bind variable
VAR v VARCHAR2(20)
[*]And then do the following to set its value at the SQL*Plus command prompt:
EXEC :v := '1111';
[list]
Finally, I try some different queries and look at the autotrace output:
SQL> select * from files where pdk_files_id = 1111
  2  /
PDK_FILES_ID NAME
        1111 SteveTest
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'FILES'
   2    1     INDEX (UNIQUE SCAN) OF 'SYS_C003006' (UNIQUE).
This shows that using the literal value 1111 uses the index.
SQL> select * from files where (pdk_files_id = 1111 or 1111 is null)
  2  /
PDK_FILES_ID NAME
        1111 SteveTest
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'FILES'
   2    1     INDEX (UNIQUE SCAN) OF 'SYS_C003006' (UNIQUE).
This shows that using the literal values together with the OR clause, still uses the index.
SQL> select * from files where (pdk_files_id = :v)
  2  /
PDK_FILES_ID NAME
        1111 SteveTest
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'FILES'
   2    1     INDEX (UNIQUE SCAN) OF 'SYS_C003006' (UNIQUE).
Using my ":v" bind variable I defined, it uses the index, too, even though the type of the bind variable is VARCHAR2 and the type of the PDK_FILES_ID column is NUMBER. This is because this is a simple enough case for the database to do automatic type coersion to convert my string value '1111' for the bind variable into the number value 1111 and then use that for the index lookup.
HOWEVER, when I try the case that simulates what you are doing in BC4J, which is using a bind variable together with the OR clause for the NULL test, we see...
SQL> select * from files where (pdk_files_id = :v OR :v IS NULL)
  2  /
PDK_FILES_ID NAME
        1111 SteveTest
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (FULL) OF 'FILES'.
So in this case, the database DOES NOT use the index, and hence explains why your query is slow.
I believe the database works this way because when it hard-parses the SQL statement, it is at this time that it determines the query plan for the SQL statement. The plan needs to remain stable since the same plan will be cached and reused for all uses of the same parsed SQL statement, so the plan cannot be conditional based on the values of the bind variables. Since it cannot decide without knowing the value of the bind variable, it apparently disqualifies your index from being used.
Even introducing an optimizer hint only improves the problem a little. I tried this example:
SQL> select /*+INDEX (files sys_c003006)*/ *
  2  from files where (pdk_files_id = :v or :v IS NULL)
  3  /
PDK_FILES_ID NAME
        1111 SteveTest
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=826 Card=5 Bytes=125)
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'FILES' (Cost=826 Card=5 Bytes=125)
   2    1     INDEX (FULL SCAN) OF 'SYS_C003006' (UNIQUE) (Cost=26 Card=82).
In this case it still has to fully scan the index where above it was able to do a unique scan.
MORAL OF THE STORY:The tiny cost of having two different View Objects in your application, one to use when you want to find by PDK_FILES_ID, and one to use when you want to find by your other key criteria, is well worth the performance improvement that can be had by using bind variables and using them in a way that the database will use the index.
As Tom Kyte says in his excellent book Expert One on One: Oracle in a passage that made me laugh:
"If I were going to write a book about building Oracle applications that do not scale, "Don't Use Bind Variables" would be the first and last chapter." :-)
So, by using a few design-time-created view objects that uses bind variables and avoid the use of the (COL = ? OR ? IS NULL) construct, you get the following benefits:
[list]
[*]The database doesn't have to hard-parse your SQL statement each time you execute it (which it does if you keep sending queries that have literal values in the SQL statement, making each query different as far as the SGA is concerned)
[*]The indexes will get used correctly as we saw above
[*]Your code actually might be clearer, since you can name one of your view objects "FindFileById" and the other one "FindFileByName", or what have you
[list]
Hope this helps.