RE: Thoughts in /* standardized SQL remarks */
- From: "Jerry Brenner" <jbrenner@xxxxxxxxxxxxx>
- To: "Oracle Discussion List" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 17 Mar 2006 13:50:50 -0800
I had looked into doing something similar. I asked Tom Kyte about it
and he mentioned that Oracle already normalizes the SQL in certain cases
and will probably be doing so in more cases in the future, so the
comments may not be visible in the future.
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of David Kurtz
Sent: Friday, March 17, 2006 1:43 PM
To: mwf@xxxxxxxx; post.ethan@xxxxxxxxx; Oracle Discussion List
Subject: RE: Thoughts in /* standardized SQL remarks */
I do this sometimes in PeopleSoft. I even have a PL/SQL script that
adds the comments automatically to the meta data from which the SQL
statements are generated.
I only put in a string that will tell me where the SQL comes from. Then
I can go there and read any comments.
I recommend that you keep the comment short and static. Short because
itis going into the SGA, don't let the comment thing get out of hand.
Static because if the comment changes, Oracle will not reuse the
statement in the cached in the SGA.
regards
_________________________
David Kurtz
Go-Faster Consultancy Ltd.
tel: +44 (0)7771 760660
fax: +44 (0)7092 348865
web: www.go-faster.co.uk
mailto:david.kurtz@xxxxxxxxxxxxxxx
Book: PeopleSoft for the Oracle DBA: http://www.psftdba.com
<http://www.psftdba.com/>
PeopleSoft DBA Forum: http://groups.yahoo.com/group/psftdba
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Mark W. Farnham
Sent: 17 March 2006 21:28
To: post.ethan@xxxxxxxxx; Oracle Discussion List
Subject: RE: Thoughts in /* standardized SQL remarks */
Someone remind me, which form of comment marker survives all the
various inbound filters better?
I was thinking it was leading -- rather than bracketed /* */,
and which one you choose can explain lost hints as well, right?
Of course if you're building systems, then you can store queries
and one of the parameters can be the caller identification string and
the others are the data values (or arrays), and you don't have to worry
about the source of the query and you minimize what gets tossed through
the network to a routine name and data. If different calling sources for
the same stored query have a use pattern associated with parameters that
probably need different peeks, tossing in a literal string for the
caller identification parameter instead of a bind variable can make it
hash differently, too. Just be careful on that slippery slope.
This, of course, does nothing for truly ad hoc reporting (but
does support parameterized pre-planned report queries).
Regards,
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Ethan Post
Sent: Friday, March 17, 2006 3:45 PM
To: Oracle Discussion List
Subject: Thoughts in /* standardized SQL remarks */
Reading through some very long and complicated SQL trace
files today, I find I frequently have to go grep the code to try to find
out where the SQL originated from. Do you think a comment in the SQL
should be standardized for our development staff?
SELECT /* module, about, date modified */
what are your thoughts?
Other related posts:
