| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: How does Oracle Apps/Dev Tools use DBMS_APPLICATION_INFO?
The /only/ problem I see with DBMS_APPLICATION_INFO is something that's =
no
longer a problem in 10g. Having said "problem," however, I still agree
wholeheartedly with Stephane: USE IT!!
The "problem" is that calling SET_* motivates extra database calls. But
check out the new 10g OCI documentation. Instead of separate dbcalls for =
an
app to identify itself, you can set the OCI_ATTR_MODULE, =
OCI_ATTR_ACTION,
and OCI_ATTR_CLIENT_INFO attributes on existing parse, bind, execute, =
fetch,
etc. calls. So in 10g apps, an app can identify itself with just a tiny
incremental consumption of network bandwidth, but no additional dbcalls =
are
necessary.
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
* Nullius in verba *
Upcoming events:
- Performance Diagnosis 101: 5/18 Edison NJ, 6/22 Pittsburgh, 7/20 =
Boston
- SQL Optimization 101: 5/24 San Diego, 6/14 Chicago, 6/28 Denver - Hotsos Symposium 2005: March 6-10 Dallas - Visit www.hotsos.com for schedule details...
-----Original Message-----
From: oracle-l-bounce_at_freelists.org =
[mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Stephane Faroult
Sent: Sunday, May 09, 2004 2:37 PM
To: oracle-l_at_freelists.org
Subject: Re: How does Oracle Apps/Dev Tools use DBMS_APPLICATION_INFO?
David Kurtz wrote:
>=20
>=20
>=20
>=20> David Kurtz
> _________________________
David,
Whenever I can, I preach to developers 'use these functions'. They
make life infinitely easier for support people and performance
troubleshooters.
What do they do? They fill in-memory areas with information. Performance
overhead for me is null.
So, what are the benefits of this? Actually, the information can be seen
in V$SESSION and it can be VERY helpful. There is, in V$SESSION, a
PROGRAM column which can somewhat help identifying in which context some
particularly painful statement is issued, but unfortunately the
information in PROGRAM is rarely useful. For instance, a client-server
program may appear as the name of the DLL which connects to Oracle. When
you have several such programs hitting the same tables, it's not very
easy to track which module is the culprit. It's even worse with n-tier
Java application, where you see something such as 'jdbc 1.0' as the only
'program'.
DBMS_APPLICATION_INFO is THE means for an application to brandish a flag
saying 'it's me (MODULE) and I am doing that (ACTION)'
(SET_SESSION_LONGOPS is used to set the equivalent of a progress bar). I
can assure you that when you are tracking down some rotten piece of SQL
code it's extremely useful, especially if the statement has been
dynamically built (as it often happens) which makes grepping the code
useless.
I have also seen it put to very good usage in a case where all authentification was managed by the program - all users were connected under the same Oracle user, however they had an individual username/password which was checked and managed in the application (many n-tier applications are close to this pattern too). From time to time there was some locking problem, because one user was forgetting to commit a change. It was a nightmare for support people, because they were unable to say WHO was holding the lock, and killing offending sessions was not making them very popular. It was solved by using CLIENT_INFO to hold the name of the actual user, once he or she had successfully authenticated him or herself. As soon as something wrong was spotted, it became easy for them to give a ring to the user, or denounce him or her to the angry colleagues.
HTH,
Stephane Faroult
Oriole
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Sun May 09 2004 - 21:15:00 CDT
 |
 |