Professional Documents
Culture Documents
Before you start fidgeting with individual SQL statements, it is important to note that
hints are probably the last thing you should consider adding when attempting to
optimize your code. There are several levels of optimization and it is recommended that
you start with the server, then the database instance, and finally go down through the
database objects to individual statements. After all, the effect of any changes made to
individual statements, particularly hints, may be lost when the database is fine-tuned
later on.
As a database developer/architect you may not want to tread the path that leads to the
desk of the DBA. Fortunately, there is a bunch of things you can do to improve the
runtime performance of your statements:
The advantage of PL/SQL packages to provide all data to users is that there is, when
set up properly, exactly one place where a query is written, and that’s the only place
where you have to go to to change anything, should you ever wish or need to modify the
code. PL/SQL will be in our sights in the next part but suffice to say it is the key to
maintainable code on Oracle. Obviously, ad-hoc queries cannot benefit from packages,
but at least they profit from having solid access structures, which are of course
important to PL/SQL too.
One important thing to keep in mind is that you should always strive to write efficient,
legible code, but that premature optimization is not the way to go. Premature
optimization involves tinkering with access structures and execution plans; it does not
include simplifying, refactoring and rewriting queries in ways that enable Oracle to
optimally use the database objects involved.
Rewriting queries with or without hints and studying the corresponding execution plans
is tedious and best left for high-impact SQL only: queries that process many rows, have
a high number of buffer gets, require many disk reads, consume a lot of memory or
CPU time, perform many sorts, and/or are executed frequently. You can identify such
queries from the dynamic performance views. Whatever you, the database developer,
do, be consistent and document your findings, so that all developers on your team may
benefit from your experiences.