All that he is referring to is the possibility that
"mixing-n-matching" will cause the same SQL statement to be hashed differently,
thus stored individually in the Shared SQL Area cache, thus more "hard parses"
unnecessarily. More "hard-parses" is indeed "more work"...
Though technically correct, there are many steps
between someone coding a SQL statement and this end-result of additional
hard-parses...
There are likely more circumstances to
consider...
However, if the people doing this coding are
developers working in a low-level API such as OCI (i.e. C or C++), DBI::DBD
(i.e. Perl), or JDBC (i.e. Java), then this SQL text will be sent straight to
the RDBMS parser where it will indeed cause additional hard-parses. Since
this code might be embedded inside a high-concurrency application, this problem
could grow quite serious, especially if the developers follow-up this particular
"bad habit" with other bad habits such as embedded literal data values,
etc...
As always, the severity of the problem is dependent
on specific circumstances. It could be no problem at all, it could be the
harbinger for serious problems...
|
- RE: Does the case of an Oracle query statement affect... Jamadagni, Rajendra
- RE: Does the case of an Oracle query statement a... Deshpande, Kirti
- RE: Does the case of an Oracle query statement a... Mercadante, Thomas F
- RE: Does the case of an Oracle query statement a... Jamadagni, Rajendra
- RE: Does the case of an Oracle query statement a... Joe Raube
- RE: Does the case of an Oracle query statement a... Tim Gorman
- RE: Does the case of an Oracle query statement a... Rachel Carmichael
- RE: Does the case of an Oracle query statement a... Jamadagni, Rajendra
- RE: Does the case of an Oracle query statement a... Mercadante, Thomas F
- RE: Does the case of an Oracle query statement a... Rachel Carmichael