Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

CHAPTER 1 ■ DEVELOPING SUCCESSFUL ORACLE APPLICATIONS 43
ops$tkyte@ORA10G> select /* TAG */ substr( username, 1, 1 )
2 from all_users au1
3 where rownum = 1;
S
-
B
ops$tkyte@ORA10G> alter session set cursor_sharing=force;
Session altered.
ops$tkyte@ORA10G> select /* TAG */ substr( username, 1, 1 )
2 from all_users au2
3 where rownum = 1;
SUBSTR(USERNAME,1,1)
------------------------------
B
What happened there? Why is the column reported by SQL*Plus suddenly so large for the
second query, which is arguably the same query? If we look at what the cursor sharing setting
did for us, it (and something else) will become obvious:
ops$tkyte@ORA10G> select sql_text from v$sql
2 where sql_text like 'select /* TAG */ %';
SQL_TEXT
-------------------------------------------------------------------------------
select /* TAG */ substr( username, 1, 1 ) from all_users au1 where rownum =
1
select /* TAG */ substr( username, :"SYS_B_0", :"SYS_B_1" )
2 where rownum = :"SYS_B_2"
from all_users au
The cursor sharing removed information from the query. It found every literal, including
the parameters to the built-in substring function, which were constants we were using. It
removed them from the query and replaced them with bind variables. The SQL engine no
longer knows that the column is a substring of length 1—it is of indeterminate length. Also,
you can see that where rownum = 1 is now bound as well. That seems like a good idea; however,
the optimizer has just had some important information removed. It no longer knows that “this
query will retrieve a single row”; it now believes “this query will return the first N rows and N
could be any number at all.” In fact, if you run these queries with SQL_TRACE=TRUE, you will find
the query plans used by each query and the amount of work they perform to be very different.
Consider the following:
select /* TAG */ substr( username, 1, 1 )
from all_users au1
where rownum = 1