On Mar 31, 12:05 am, Joachim Klassen <JoKlas...@emai l.comwrote:
An answer from elsewhere in DB2 development:
DB2 is supposed to move files from the FAILPATH to TSM when TSM is
available again (this should also happen if DB2 is recycled with files
in FAILPATH. We have recently found a bug where files are left in the
failpath and never moved to the archive location. So this is a known
problem.
I don't think we should be expecting retrieval from FAILPATH.
FAILPATH is supposed to be a 'temporary' location for archived files
while the main archive location/device is offline. In this situation,
the priority should be to get the archive location/device available
again, and this will allow the files to flow to the standby via the
archive location.
<--
Regards,
- Steve P.
--
Steve Pearson, DB2 for Linux, UNIX, and Windows, IBM Software Group
"Portland" Development Team, IBM Beaverton Lab, Beaverton, OR, USA
Hi all,
>
Platform DB2 V9.1 FP3 on AIX V5.3,HADRis configured and running.
LOGARCHMETH1 is TSM , FAILARCHPATH is set to a local filesystem.
>
Szenario:
TSM Server is unavailable for some time, DB2 primary archives its logs
to FAILARCHPATH as expected.
Now theHADRStandby goes down. While the standby is unavailable the
primary continues work and archives some log files to FAILARCHPATH
(TSM still not available). The log files were removed /renamed on the
active log path. When the standby comes back later it contacts the
primary to get synched and throws errors about missing log files on
the primary. So it looks like the primary does not "retrieve" log
files from FAILARCHPATH.
>
If TSM comes up again, the primary will archive the log files from
FAILARCHPATH to TSM. When the standby is activated now, it will
receive log files from the primary(which were retrievd from TSM). So
far so good - but if the primary is stopped while using FAILARCHPATH
and is restarted when TSM is available again it will not archive the
log files from FAILARCHPATH to TSM, thus leaving a gap in the
archived log chain.
>
Im not able to open up a PMR for this situation at the moment - anyone
else seen this behaviour ?
>
TIA for any answer
>
Joachim
>
Platform DB2 V9.1 FP3 on AIX V5.3,HADRis configured and running.
LOGARCHMETH1 is TSM , FAILARCHPATH is set to a local filesystem.
>
Szenario:
TSM Server is unavailable for some time, DB2 primary archives its logs
to FAILARCHPATH as expected.
Now theHADRStandby goes down. While the standby is unavailable the
primary continues work and archives some log files to FAILARCHPATH
(TSM still not available). The log files were removed /renamed on the
active log path. When the standby comes back later it contacts the
primary to get synched and throws errors about missing log files on
the primary. So it looks like the primary does not "retrieve" log
files from FAILARCHPATH.
>
If TSM comes up again, the primary will archive the log files from
FAILARCHPATH to TSM. When the standby is activated now, it will
receive log files from the primary(which were retrievd from TSM). So
far so good - but if the primary is stopped while using FAILARCHPATH
and is restarted when TSM is available again it will not archive the
log files from FAILARCHPATH to TSM, thus leaving a gap in the
archived log chain.
>
Im not able to open up a PMR for this situation at the moment - anyone
else seen this behaviour ?
>
TIA for any answer
>
Joachim
An answer from elsewhere in DB2 development:
>--
available again (this should also happen if DB2 is recycled with files
in FAILPATH. We have recently found a bug where files are left in the
failpath and never moved to the archive location. So this is a known
problem.
I don't think we should be expecting retrieval from FAILPATH.
FAILPATH is supposed to be a 'temporary' location for archived files
while the main archive location/device is offline. In this situation,
the priority should be to get the archive location/device available
again, and this will allow the files to flow to the standby via the
archive location.
<--
Regards,
- Steve P.
--
Steve Pearson, DB2 for Linux, UNIX, and Windows, IBM Software Group
"Portland" Development Team, IBM Beaverton Lab, Beaverton, OR, USA