Hi Larry, We had used pre and post target events equivalent in our scenario. if the requirement is to look at the DB contribution for the workload then possibly wont be a bad idea to do a AWR pre and post the ETL? Best Regards Sriram On Sat, Mar 19, 2011 at 5:50 PM, Larry G. Elkins <elkinsl@xxxxxxxxx> wrote: > 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 > > >