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

CHAPTER 1 ■ DEVELOPING SUCCESSFUL ORACLE APPLICATIONS 45
The plans were subtly different (sometimes you’ll find them to be radically different); they
did different amounts of work. So, just turning on cursor sharing is something to do with great
trepidation (well, testing really—you need to test this). It will potentially change the behavior
of your application (e.g., the column widths) and because it removes all literals from SQL,
even those that never really change, it can have a negative impact on your query plans.
Additionally, I have proven that while CURSOR_SHARING = FORCE runs much faster than
parsing and optimizing lots of unique queries, I have also found it to be slower than using
queries where the developer did the binding. This arises not from any inefficiency in the cursor
sharing code, but rather in inefficiencies in the program itself. In many cases, an application
that does not use bind variables is not efficiently parsing and reusing cursors either. Since the
application believes each query is unique (it built them as unique statements), it will never
use a cursor more than once. The fact is that if the programmer had used bind variables in the
first place, he or she could have parsed a query once and reused it many times. It is this overhead
of parsing that decreases the overall potential performance.
Basically, it is important to keep in mind that simply turning on CURSOR_SHARING = FORCE
will not necessarily fix your problems. It may well introduce new ones. CURSOR_SHARING is, in
some cases, a very useful tool, but it is not a silver bullet. A well-developed application would
never need it. In the long term, using bind variables where appropriate, and constants when
needed, is the correct approach.
■Note There are no silver bullets—none. If there were, they would be the default behavior and you would
never hear about them.
Even if there are some switches that can be thrown at the database level—and they are
truly few and far between—problems relating to concurrency issues and poorly executing
queries (due to poorly written queries or poorly structured data) cannot be fixed with a
switch. These situations require rewrites (and frequently a re-architecture). Moving data files
around, changing the multiblock read count, and other database-level switches frequently
have a minor impact on the overall performance of an application. Definitely not anywhere
near the two, three, . . . n times increase in performance you need to achieve to make the
application acceptable. How many times has your application been 10 percent too slow? No
one complains about 10 percent too slow. Five times too slow, and people get upset. I repeat:
you will not get a five times increase in performance by moving data files around. You will only
achieve this by fixing the application, perhaps by making it do significantly less I/O.
Performance is something you have to design for, to build to, and to test for continuously
throughout the development phase. It should never be something considered after the fact. I
am amazed at how often people wait until the application has been shipped to their customer,
put in place, and actually running before they even start to tune it. I’ve seen implementations
where applications are shipped with nothing more than primary keys—no other indexes
whatsoever. The queries have never been tuned or stress-tested. The application has never
been tried out with more than a handful of users. Tuning is considered to be part of the installation
of the product. To me, that is an unacceptable approach. Your end users should be
presented with a responsive, fully tuned system from day one. There will be enough “product