Audit trace

Sally Mir

Audit trace
Is there any way to determine who has accessed a particular table (for
either update or read) without turning on an audit trace?

Thanks,

Sally Mir
Blue Cross Blue Shield of Georgia

P.S. Where did everybody go? I haven't received any list mail for a
few days.

Ken McDonald

Re: Audit trace
(in response to Sally Mir)
Hi Sally,

Updates (INSERT, UPDATE, and DELETE) to DB2 tables are logged, however, read
access is not logged, and therefore, traces are required to track SELECTs
against tables. There are both log analysis utilities (i.e. BMC Patrol
DB-Log Master for DB2, CA/Pt Log Analyzer) and SMF Trace analysis tools
available as well to extract and format information.

From the logged updates perspective, the BEGIN Unit of Recovery record
contains the information as to what primary authid, plan, correlation id,
etc. were associated with that Unit of Recovery. Each INSERT/UPDATE/DELETE
Data Management record has a reference to its associated Unit of Recovery.
If you would like more information on DB2 log contents, please feel free to
contact me.

Regards,
Ken McDonald
BMC Software

>-----Original Message-----
>From: Sally Mir [mailto:[login to unmask email]
>Sent: Tuesday, October 05, 1999 2:38 PM
>To: [login to unmask email]
>Subject: Audit trace
>
>
>Is there any way to determine who has accessed a particular table (for
>either update or read) without turning on an audit trace?
>
>Thanks,
>
>Sally Mir
>Blue Cross Blue Shield of Georgia
>
>P.S. Where did everybody go? I haven't received any list mail for a
>few days.
>

Sally Mir

Re: Audit trace
(in response to Ken McDonald)
Thanks for your reply, Ken! I am a huge BMC fan. Log Master was the first
place I went when I got the request. So I do know how to get the information
about what has been updated and by whom. But management has decided that they
want to know who has been reading the data as well. I was hoping there might be
some way outside of DB2 to figure this out. Of course, they want *historical*
data, so turning on the audit trace wouldn't be fruitful now.

We also have Platinum's Subsystem Analyzer, which can give me some information
about programs/plans that have read the data, but it's not easily extracted and
reported upon in the manner that management wants to see.

Thanks for your input,


Sally Mir

"McDonald, Ken" wrote:

> Hi Sally,
>
> Updates (INSERT, UPDATE, and DELETE) to DB2 tables are logged, however, read
> access is not logged, and therefore, traces are required to track SELECTs
> against tables. There are both log analysis utilities (i.e. BMC Patrol
> DB-Log Master for DB2, CA/Pt Log Analyzer) and SMF Trace analysis tools
> available as well to extract and format information.
>
> From the logged updates perspective, the BEGIN Unit of Recovery record
> contains the information as to what primary authid, plan, correlation id,
> etc. were associated with that Unit of Recovery. Each INSERT/UPDATE/DELETE
> Data Management record has a reference to its associated Unit of Recovery.
> If you would like more information on DB2 log contents, please feel free to
> contact me.
>
> Regards,
> Ken McDonald
> BMC Software
>
> >-----Original Message-----
> >From: Sally Mir [mailto:[login to unmask email]
> >Sent: Tuesday, October 05, 1999 2:38 PM
> >To: [login to unmask email]
> >Subject: Audit trace
> >
> >
> >Is there any way to determine who has accessed a particular table (for
> >either update or read) without turning on an audit trace?
> >
> >Thanks,
> >
> >Sally Mir
> >Blue Cross Blue Shield of Georgia
> >
> >P.S. Where did everybody go? I haven't received any list mail for a
> >few days.
> >