Greetings,

I tried to implement log shipping using PULL method as described in
'The Basics of DB2 Log Shipping' by Dale McInnis, but found the
subsequent "rollforward" did not go beyond the first log.

Here is what I did:

2 machines: Primary and standby servers both W2K SP4 running DB2 8.2.
Both have logretain (YES) and USEREXIT (ON) set.

The db2uext.c was compiled/linked with: archive_path, retrieve_path
and audit_error_path set to "I\\mylogs\\" which resides on a 3rd W2K
server. This path is accessible by both machines.

(1) Backup,insert 3 rows into db (PDB) on primary server then backup
again.
(2) Restore db (SDB) on standby server from the 2nd backup from
Primary server. (In reality, PDB & SDB have the same name, for
explanation only)
(3) A few more inserts into PDB. The entries in active log and archive
now look like this:
PDB: archive log: S0000000.LOG, S0000001.LOG (I:\mylogs)
Online logs: S0000002.LOG, S0000003.LOG
First active log: S0000002.LOG (from DB CFG)

SDB: archive log: S0000000.LOG, S0000001.LOG (I:\mylogs)
Online logs: S0000000.LOG
First active log: S0000000.LOG

Apparently, the info about 'first active' on PDB does not reflect on
SDB. When executing several 'rollfward' on standby server, it always
stops at S0000000.LOG.

Could someone shed some light on this as to what I missed/did wrong.

Thank you.

It might be easier to help you if you provided a list of the actual
commands you used. You should also check your SDB and verify that the
database is in "rollforward pending" status.

You didn't specify where the PDB and SDB active log paths are located.
Your use of db2uext implies that the logs are being copied to the shared
location AFTER THEY ARE CLOSED. I doubt that "a few inserts" will
generate enough log records to fill an active log which will then be
archived; invoking your exit. Check your shared location to see if any
of the PDB active logs after the second backup have been copied there.

From the "Administration Guide: Performance" manual:

"This parameter also indicates that a user exit program should be used
to archive and retrieve the log files. Log files are archived when the
database manager closes the log file. They are retrieved when the
ROLLFORWARD utility needs to use them to restore a database."

The question here is what logs ROLLFORWARD will ask the exit to
retrieve. If logs after the backup start with 00002 and the current log
is 00020 and the currrent log path contains 00018, 00019, 00020 then
ROLLFORWARD must request logs 00002-00017 via the user exit.

If the current log on the PDB is 00002 then this log has not been
archived and copied to the shared location. The SDB cannot use this log
as part of ROLLFORWARD processing.

I also didn't see (in the manuals) any information indicating that
ROLLFORWARD will (or will not) invoke the user exit to look for
additional archived logs beyond the most current log (in the active log
path) during its processing. If it doesn't, you will have to manually
copy the logs from the shared location to the SDB active log path before
issuing the ROLLFORWARD command.


Philip Sherman


nek wrote:
> Greetings,
>
> I tried to implement log shipping using PULL method as described in
> 'The Basics of DB2 Log Shipping' by Dale McInnis, but found the
> subsequent "rollforward" did not go beyond the first log.
>
> Here is what I did:
>
> 2 machines: Primary and standby servers both W2K SP4 running DB2 8.2.
> Both have logretain (YES) and USEREXIT (ON) set.
>
> The db2uext.c was compiled/linked with: archive_path, retrieve_path
> and audit_error_path set to "I\\mylogs\\" which resides on a 3rd W2K
> server. This path is accessible by both machines.
>
> (1) Backup,insert 3 rows into db (PDB) on primary server then backup
> again.
> (2) Restore db (SDB) on standby server from the 2nd backup from
> Primary server. (In reality, PDB & SDB have the same name, for
> explanation only)
> (3) A few more inserts into PDB. The entries in active log and archive
> now look like this:
> PDB: archive log: S0000000.LOG, S0000001.LOG (I:\mylogs)
> Online logs: S0000002.LOG, S0000003.LOG
> First active log: S0000002.LOG (from DB CFG)
>
> SDB: archive log: S0000000.LOG, S0000001.LOG (I:\mylogs)
> Online logs: S0000000.LOG
> First active log: S0000000.LOG
>
> Apparently, the info about 'first active' on PDB does not reflect on
> SDB. When executing several 'rollfward' on standby server, it always
> stops at S0000000.LOG.
>
> Could someone shed some light on this as to what I missed/did wrong.
>
> Thank you.

Hi Philip,

Thanks for this. Apologise for not being able to get back to you
sooner.

I have deliberately reduced logfilsiz to 4 and therefore was able to
see the log getting full quickly after 20ish inserts (I take back ‘a
few inserts' ;-)).

PDB and SDB reside on different servers. Each has its own active log
path. The archive_path is on a 3rd server (remote).
Eg. PDB: D:\db2\NODE00001\SQL00004\SQLOGDIR
SDB: D:\db2\NODE00001\SQL00010\SQLOGDIR
(You asked for the whereabouts of these active log paths. What role do
they play in log shipping?)

Here are the steps and commands I used to backup and rollforward:
PDB: (logretain=RECOVERY, userexit= on)
(1) db2 backup db pdb to d:\backup without prompting
First active log: S0000032.LOG
Archive logs: From S0000025.LOG to S0000031.LOG

SDB: (logretain=RECOVERY, userexit= on)
(2) Copy PDB backup to local D:\backup
(3) db2 restore sdb from d:\backup taken at (the time PDB backup was
taken)
(Confirm ‘rollforward pending' status is on)
First active log: S0000032.LOG
Archive logs: From S0000025.LOG to S0000031.LOG

(4) db2 rollforward db sdb to end of logs
Next log file to be read: S0000032.LOG
First active log: S0000032.LOG

PDB:
(5) db2 insert into t1 values (,,),(,,).. (multiple inserts)
(6) db2 archive log for db pdb
Archive logs: From S0000025.LOG to S0000033.LOG
First active log: S0000034.LOG
Active log path: S0000033.LOG to S0000035.LOG

SDB:
(7) db2 rollforward db sdb to end of logs
Next log file to be read: S0000032.LOG
First active log: S0000032.LOG
Active log path: Nothing

As you see, archive_path now has entries for logs up to S0000033.LOG,
but ‘rollforward db..' does not pick them up no matter how many times
I ran it. I manually copy the 2 new logs (S0000032.LOG, S0000033.LOG)
to SDB active log path, it still does not help.

I repeated the above steps for 2 brand new databases and it always
stops at the same log (with different log number, of course) after
restore.

It appears that the retrieval by db2uext2 is not working?
Retrieve_path: "network_path\\myarchive"
(same for PDB archive log path. Eg. I:\\myarchive\\)

Try the following but still in vain:
"server3\\temp\\myarchive\\"
"server3:\\temp\\myarchive\\"

Could you see anything wrong with this?

Much appreciated.




Philip Sherman <psherman@ameritech.net> wrote in message news:<6hFid.26642$Qv5.13060@newssvr33.news.prodigy .com>...
> It might be easier to help you if you provided a list of the actual
> commands you used. You should also check your SDB and verify that the
> database is in "rollforward pending" status.
>
> You didn't specify where the PDB and SDB active log paths are located.
> Your use of db2uext implies that the logs are being copied to the shared
> location AFTER THEY ARE CLOSED. I doubt that "a few inserts" will
> generate enough log records to fill an active log which will then be
> archived; invoking your exit. Check your shared location to see if any
> of the PDB active logs after the second backup have been copied there.
>
> From the "Administration Guide: Performance" manual:
>
> "This parameter also indicates that a user exit program should be used
> to archive and retrieve the log files. Log files are archived when the
> database manager closes the log file. They are retrieved when the
> ROLLFORWARD utility needs to use them to restore a database."
>
> The question here is what logs ROLLFORWARD will ask the exit to
> retrieve. If logs after the backup start with 00002 and the current log
> is 00020 and the currrent log path contains 00018, 00019, 00020 then
> ROLLFORWARD must request logs 00002-00017 via the user exit.
>
> If the current log on the PDB is 00002 then this log has not been
> archived and copied to the shared location. The SDB cannot use this log
> as part of ROLLFORWARD processing.
>
> I also didn't see (in the manuals) any information indicating that
> ROLLFORWARD will (or will not) invoke the user exit to look for
> additional archived logs beyond the most current log (in the active log
> path) during its processing. If it doesn't, you will have to manually
> copy the logs from the shared location to the SDB active log path before
> issuing the ROLLFORWARD command.
>
>
> Philip Sherman
>
>
> nek wrote:
> > Greetings,
> >
> > I tried to implement log shipping using PULL method as described in
> > 'The Basics of DB2 Log Shipping' by Dale McInnis, but found the
> > subsequent "rollforward" did not go beyond the first log.
> >
> > Here is what I did:
> >
> > 2 machines: Primary and standby servers both W2K SP4 running DB2 8.2.
> > Both have logretain (YES) and USEREXIT (ON) set.
> >
> > The db2uext.c was compiled/linked with: archive_path, retrieve_path
> > and audit_error_path set to "I\\mylogs\\" which resides on a 3rd W2K
> > server. This path is accessible by both machines.
> >
> > (1) Backup,insert 3 rows into db (PDB) on primary server then backup
> > again.
> > (2) Restore db (SDB) on standby server from the 2nd backup from
> > Primary server. (In reality, PDB & SDB have the same name, for
> > explanation only)
> > (3) A few more inserts into PDB. The entries in active log and archive
> > now look like this:
> > PDB: archive log: S0000000.LOG, S0000001.LOG (I:\mylogs)
> > Online logs: S0000002.LOG, S0000003.LOG
> > First active log: S0000002.LOG (from DB CFG)
> >
> > SDB: archive log: S0000000.LOG, S0000001.LOG (I:\mylogs)
> > Online logs: S0000000.LOG
> > First active log: S0000000.LOG
> >
> > Apparently, the info about 'first active' on PDB does not reflect on
> > SDB. When executing several 'rollfward' on standby server, it always
> > stops at S0000000.LOG.
> >
> > Could someone shed some light on this as to what I missed/did wrong.
> >
> > Thank you.