RE: DBMS_APPLICATION_INFO and Business Objects Data Integrator

Thanks for the response. And yes, we could set module, action, etc that way, 
but with a single id used for all ETL processes, then
all would be labeled the same. The idea is to set specific values for module / 
action so data can be gathered by functional area,
specific process, etc, and to also enable the ability to do targeted tracing 
via DBMS_MONTIOR. So it's really up to each process to
identify itself and action. 

 

There are pre and post target events, that based on my understanding, could 
make calls to set these, but in one of the forums the
product manager recommended against it. Didn't give a reason. For tracing, our 
only choice is to trace all the sessions for that ID
and find the one of interest. And of course viewing resource usage in terms of 
module, action, etc, like what you see in GRID with
well "identified" apps or what you can generate yourself, is unavailable. 

 

DI folks can report total time in these terms from the *tool* side, but it 
doesn't, of course, show how much was actual DB activity.
Case in point, 2 hour process, complain about the DB, tracing shows most time 
on SQL*Net message from client, and log file sync
(from committing after every single one of the single row actions). Very little 
time spent doing "real" work in the DB. 

 

Larry G. Elkins

elkinsl@xxxxxxxxx

Home: 214.954.1781

Cell: 214.695.8605

Work: 817.280.5634

 

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Sriram Kumar
Sent: Friday, March 18, 2011 5:07 AM
To: elkinsl@xxxxxxxxx
Cc: oracle-l-freelists
Subject: Re: DBMS_APPLICATION_INFO and Business Objects Data Integrator

 

Hi,,

 

we had a similar requirement for a reporting solution and we did not get a 
straight fwd way. We had to restrict the reporting tool
to a schema and create a on logon trigger on the schema to call the 
DBMS_APPLICATION_INFO. not sure if this helps you

 

best regards

 

sriram

Other related posts: