DB2 log records

John Krew

DB2 log records
Can anyone advise regarding the layout of DB2 log records? In particular, the unit-of-recovery
(UR) undo and redo records do not directly indicate the table which is being updated. My guess is
there is some way of querying DB2's internal tables to obtain the table name given the DBID and OBID
and PAGE for the given data page being modified.

Can anyone provide the solution to this problem?

Thanks in advance,
John Krew

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Wayne Driscoll

Re: DB2 log records
(in response to John Krew)
John,
You are correct that the UNDO and REDO records don't (always) indicate
the table being impacted. This is because, since DB2 uses the log for
backout and recovery, and both of these processes work against
tablespaces, the table OBID isn't really needed. Because of this there
are no internal tables that would map a DBID, OBID and PAGE to a
tablename (especially in a simple tablespace, where a page can contain
rows from multiple tables). However, some records will contain the
table obid. To determine if this is the case, look at the doc to see
those records where either the undo or redo contain the "full row
image", because the table OBID will be in the row header in this case.
Any table that is defined with data capture changes will always contain
the full row image, making the OBID available. For tables that don't
have data capture changes, inserts and deletes will have the full row
image, but for updates you may, but you most likely will not. In these
cases, to find the table, you would have to start with either the
current tablespace data, then look at log records going back in time and
tracking changes, or starting with an image copy from either before or
after the log records and moving the appropriate direction, again
tracking changes. This is not an easy process, and all it takes is one
mistake to really hose your data.
Wayne Driscoll
Sr. Software Developer
Quest Software
[login to unmask email]
NOTE: All opinions are strictly my own. EMail Address in sig must be
modified.

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of John Krew
Sent: Monday, January 05, 2004 3:32 PM
To: [login to unmask email]
Subject: [DB2-L] DB2 log records


Can anyone advise regarding the layout of DB2 log records? In
particular, the unit-of-recovery
(UR) undo and redo records do not directly indicate the table which is
being updated. My guess is there is some way of querying DB2's internal
tables to obtain the table name given the DBID and OBID and PAGE for the
given data page being modified.

Can anyone provide the solution to this problem?

Thanks in advance,
John Krew

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". If you will be out of the office,
send the SET DB2-L NO MAIL command to [login to unmask email] The
IDUG List Admins can be reached at [login to unmask email] Find
out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

John Krew

DB2 log records
(in response to Wayne Driscoll)
I have been playing around with the stand-alone log services macro DSNJSLR.
I manage to read the archive log ok, but the open against an active log fails with
an allocation error. Presumably this is because the active log is already allocated
in the DB2 address space with DISP=OLD.

In a separate email Ken McDonald indicated to me that in his experience this
problem does not exist in a data sharing environment but does apparently exist
in a non-data sharing one. Unfortunately, we do not implement data sharing.

My question is: is there any DB2 set-up parameter (or whatever) I can use to
cause DB2 to allocate its active logs with DISP=SHR even in a non-data sharing
environment so that I can use stand-alone services to read the active log? Or am
I forced to use the Instrumentation Facility Interface (IFI) to read an active log when
DB2 is up?

Thanks,
John Krew

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Avram Friedman

Re: DB2 log records
(in response to John Krew)
I don't think its the JCL DISP, its the VSAM SHR options which can be
altered with IDCAMS.
I think you probally want 2,3 which allows 1 updater and any number of
readers
The default is 1 updater OR any number of readers

John Krew <[login to unmask email]> wrote:
>
>I have been playing around with the stand-alone log services macro
DSNJSLR.
>I manage to read the archive log ok, but the open against an active log
fails with
>an allocation error. Presumably this is because the active log is already
allocated
>in the DB2 address space with DISP=OLD.
>
>In a separate email Ken McDonald indicated to me that in his experience
this
>problem does not exist in a data sharing environment but does apparently
exist
>in a non-data sharing one. Unfortunately, we do not implement data
sharing.
>
>My question is: is there any DB2 set-up parameter (or whatever) I can use
to
>cause DB2 to allocate its active logs with DISP=SHR even in a non-data
sharing
>environment so that I can use stand-alone services to read the active log?
Or am
>I forced to use the Instrumentation Facility Interface (IFI) to read an
active log when
>DB2 is up?
>
>Thanks,
>John Krew
>
>--------------------------------------------------------------------------
-------
>Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm
>
>



--
NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Juan Pablo Tello

Re: DB2 log records
(in response to Avram Friedman)
In Data Sharing the active log are exclusively used by DB2. Remember that each member has its own active and archive logs.
Only Tablespaces/indexspaces Vsam datasets are allocated with share options (3,3)

HTH

Juan Pablo Tello
Mexico City.

-----Mensaje original-----
De: John Krew [mailto:[login to unmask email]
Enviado el: Jueves, 15 de Enero de 2004 03:07 p.m.
Para: [login to unmask email]
Asunto: DB2 log records


I have been playing around with the stand-alone log services macro DSNJSLR.
I manage to read the archive log ok, but the open against an active log fails with
an allocation error. Presumably this is because the active log is already allocated
in the DB2 address space with DISP=OLD.

In a separate email Ken McDonald indicated to me that in his experience this
problem does not exist in a data sharing environment but does apparently exist
in a non-data sharing one. Unfortunately, we do not implement data sharing.

My question is: is there any DB2 set-up parameter (or whatever) I can use to
cause DB2 to allocate its active logs with DISP=SHR even in a non-data sharing
environment so that I can use stand-alone services to read the active log? Or am
I forced to use the Instrumentation Facility Interface (IFI) to read an active log when
DB2 is up?

Thanks,
John Krew

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Tom Flesher

Re: DB2 log records
(in response to Juan Pablo Tello)
Occasionally DB2 needs to "merge" logs across the data sharing group e.g.
RECOVER. This requires that bootstraps and logs be accessible (read-only)
from operating system images other than the one where the "owning" member
is running.

There was a PTF UQ75909, APAR PQ72747, for DB2 V7 that might be worth
checking out. Although it related specifically to DSN1LOGP, you'll note
that DSN1LOGP uses DSNJSLR under the covers. Sounds like the share options
ought to be (2 3) for you to be able to browse the active log (using
DSNJSLR) of a singleton system. Here's an excerpt from the PTF available
freely on the internet at:

https://techsupport.services.ibm.com/server/390.CAPARdb

You may want to check out maintenance relating to DSNJSLR.....

Excerpt from PTF UQ75909:

>>Running DSN1LOGP utility for a large LRSN range with a GROUP
BSDS DD card, MSGDSN1217E with RC00D10021 was issued even though
there was no 'gap' in the log rba ranges. The DSN1LOGP job was
run while the DB2 members of the data sharing group were active,
as the VSAM SHAREOPTIONS(2 3) allow the read access. An active
log data set switch occurred while the DSN1LOGP job was running.
This caused an unexpected log CI to be returned when the new
active log was read, as the RBA range was different than it was
when the job started.

RESPONDER CONCLUSION:
When running the DSN1LOGP utility in BSDS mode, the
stand-alone log read service will attempt to detect active
log reuse when invoked while DB2 is up, and will then
attempt to read the requested log records from the archive
log data sets. Also, the number of QSAM and VSAM buffers
have been increased to improve log read performance. This
may result in an ABEND878 RC10 if the REGION size is too
small. You may need to increase the REGION parm on the
requesting JOB card to REGION=4096K or higher, depending
on the number of log data sets that are OPENed concurrently.<<

HTH,
Tom Flesher
E-Net Corporation





Tello Najera Juan
Pablo
<[login to unmask email] To
NCOMER.COM> [login to unmask email]
Sent by: DB2 Data cc
Base Discussion
List Subject
<[login to unmask email] Re: DB2 log records
ORG>


01/15/2004 03:55
PM


Please respond to
DB2 Database
Discussion list
at IDUG
<[login to unmask email]
2-L.ORG>






In Data Sharing the active log are exclusively used by DB2. Remember that
each member has its own active and archive logs.
Only Tablespaces/indexspaces Vsam datasets are allocated with share options
(3,3)

HTH

Juan Pablo Tello
Mexico City.

-----Mensaje original-----
De: John Krew [mailto:[login to unmask email]
Enviado el: Jueves, 15 de Enero de 2004 03:07 p.m.
Para: [login to unmask email]
Asunto: DB2 log records


I have been playing around with the stand-alone log services macro DSNJSLR.
I manage to read the archive log ok, but the open against an active log
fails with
an allocation error. Presumably this is because the active log is already
allocated
in the DB2 address space with DISP=OLD.

In a separate email Ken McDonald indicated to me that in his experience
this
problem does not exist in a data sharing environment but does apparently
exist
in a non-data sharing one. Unfortunately, we do not implement data
sharing.

My question is: is there any DB2 set-up parameter (or whatever) I can use
to
cause DB2 to allocate its active logs with DISP=SHR even in a non-data
sharing
environment so that I can use stand-alone services to read the active log?
Or am
I forced to use the Instrumentation Facility Interface (IFI) to read an
active log when
DB2 is up?

Thanks,
John Krew

---------------------------------------------------------------------------------

Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org
. The IDUG List Admins can be reached at [login to unmask email]
Find out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------

Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org
. The IDUG List Admins can be reached at [login to unmask email]
Find out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm