Here is the situation....
We have Primary Server A linked to Standby Server B via HADR.

Primary Server A has recently installed LOGARCHMETH1 to archive logs
and a 2nd homegrown script that compresses the archived logs once in
the archive log directory.

Standby Server B has our old script that moves logs from active to
archive directories and then compresses them every 30 minutes.


The Problem....
Back on our old method of our home grown script moving active to
archive logs every 30 minutes, if we fell out fo sync for 2 hours
because of a network hiccup we could move any archived logs back to
the active log directory on the primary server. We would lightup HADR
and it would catch-up. This prevented us from taking an online backup,
SFTP'ing it over,restoring, and rolling forward HADR Logs.

With LOGARCHMETH1, this doesn't always work as LOGARCHMETH1 will re-
archive the logs too quickly. (i.e. I move over 5 logs, and 2 are read
over to the Standby server - but LOGARCHMETH1 archives off logs 3,4,5
before we complete).


Our Question ...
Because everything is in DB's hands - Log Archiving, HADR, etc.
Shouldn't DB2 be smart enough to know if the Standby HADR server is
trying to rollforward and we need archived Primary Server Logs - to go
to the Primary Archive directory?

Am I missing a setting?
Could it be because LOGARCHMETH1 is not set on the Standby server?
Am I asking too much fo DB2?


Any input would be appreciated.

I had to read this a couple times and think I understand now, but
let's just check if that's so.

Problem restated: User performs additional manipulation of log files
after DB2 finishes archiving them (namely, compressing them). This
means that log files in the archive location are not directly usable
by DB2. When such files need to be retrieved for later use by DB2,
the user must intervene to decompress the files and return them to the
active log path, rather than allowing DB2 to retrieve the log files in
the normal way from the log archive. The user observes that after
decompressing some log files and copying the result to the active log
path, they disappear before they can be used by DB2.

Is that reasonably close?

Further questions: Given log files need decompressing when moved from
archive location to active log path, have you somehow prevented DB2
from retrieving log files from the archive on its own? The intended
design is for DB2 to retrieve log files upon need. I would expect
that it should try and do so, for example, when the HADR standby
requests log pages from the primary from such a log file, which it
should do in Remote Catchup state. For the compression to not cause
problems, you've either got to have hooked into the log retrieve step
of DB2 to do the decompression any time DB2 retrieves a log file, or
you've got to have avoided DB2 retrieving log files on its own.

As to the disappearing log files, likely they are not "re-archived" by
DB2, as DB2 would know they've already been archived. However, DB2
may have cleaned them up from the active log path due to it having the
impression that they are not needed there. This may be due to the
fact that you're placing the files in the active path outside DB2's
knowledge. Unless you've prevented DB2 from retrieving the log files
again later (when it actually wants to read from them), DB2 should go
ahead and re-retrieve those log files at that time. What happens
after the log files you've place disappear from the primary's active
log path? Is there some complaint later from HADR about a missing
log?

Regards,
- Steve P.
--
Steve Pearson, DB2 for Linux, UNIX, and Windows, IBM Software Group
"Portland" Development Team, IBM Beaverton Lab, Beaverton, OR, USA

On May 2, 1:57 pm, "Steve Pearson (news only)" <stevep...@my-deja.com>
wrote:
> I had to read this a couple times and think I understand now, but
> let's just check if that's so.
>
> Problem restated: User performs additional manipulation of log files
> after DB2 finishes archiving them (namely, compressing them). This
> means that log files in the archive location are not directly usable
> by DB2. When such files need to be retrieved for later use by DB2,
> the user must intervene to decompress the files and return them to the
> active log path, rather than allowing DB2 to retrieve the log files in
> the normal way from the log archive. The user observes that after
> decompressing some log files and copying the result to the active log
> path, they disappear before they can be used by DB2.
>
> Is that reasonably close?
>
> Further questions: Given log files need decompressing when moved from
> archive location to active log path, have you somehow prevented DB2
> from retrieving log files from the archive on its own? The intended
> design is for DB2 to retrieve log files upon need. I would expect
> that it should try and do so, for example, when the HADR standby
> requests log pages from the primary from such a log file, which it
> should do in Remote Catchup state. For the compression to not cause
> problems, you've either got to have hooked into the log retrieve step
> of DB2 to do the decompression any time DB2 retrieves a log file, or
> you've got to have avoided DB2 retrieving log files on its own.
>
> As to the disappearing log files, likely they are not "re-archived" by
> DB2, as DB2 would know they've already been archived. However, DB2
> may have cleaned them up from the active log path due to it having the
> impression that they are not needed there. This may be due to the
> fact that you're placing the files in the active path outside DB2's
> knowledge. Unless you've prevented DB2 from retrieving the log files
> again later (when it actually wants to read from them), DB2 should go
> ahead and re-retrieve those log files at that time. What happens
> after the log files you've place disappear from the primary's active
> log path? Is there some complaint later from HADR about a missing
> log?
>
> Regards,
> - Steve P.
> --
> Steve Pearson, DB2 for Linux, UNIX, and Windows, IBM Software Group
> "Portland" Development Team, IBM Beaverton Lab, Beaverton, OR, USA

Steve ...

You are dead on in your assessment.
As for HADR, it does complain about not being able to read logs (or
pages) I can't remember and unfortunately don't have a fresh error log
(I will look though). I assumed this meant that the log was not in the
active log directory - but it may mean that it couldn't read the
compressed logs in the archived log directory.

Now that I confirmed your interpritation is correct, any advice?

Thanks in advance.

-Mike

Without a detailed look at your situation I can't say for sure, but
what may have happened is that DB2 did retrieve the compressed log
files but then didn't like them. You may want to engage IBM support
for a closer examination of your situation.

If I were to consider post-processing log files like this, I'd also
want to ensure that when DB2 requested them that the files were
transformed back the way DB2 expects them. I'd rather not require
some human intervention to convert back log files and place them in
the proper path, as that seems less easy from the administration
perspective and more error prone.

One way to go would be to use a user exit. Set LOGARCHMETH1 to
USEREXIT instead of DISK (assume this is your current), and define a
user exit program that performs the two steps you need: copy+compress
on the archiving side, and decompress+copy on the retrieval side.
Some documentation is here:
http://publib.boulder.ibm.com/infoce...c/r0000235.htm
and fairly complete sample/template user exit programs ship with DB2.
The disk sample may be very close to what you'd need; comments inside
it suggest how to customize/build/install for your environment, and
adding your compression/decompression steps to it may be about the
only other thing you'd need to do.

Another way may be to use some built-in capability of TSM or a VENDOR
archiving facility that may compress/decompress for you when you store/
retrieve using it. The latter is only my speculation; I don't know
what all may be available there, but wouldn't be surprised if some
storage facilities could do that. Of course, that may not be
something you have on hand or can easily add.

Regards,
- Steve P.
--
Steve Pearson, DB2 for Linux, UNIX, and Windows, IBM Software Group
"Portland" Development Team, IBM Beaverton Lab, Beaverton, OR, USA

Hmmm, looks like you were right - same answer from IBM when I opened a
PMR.
Thanks for the advice. It was very much appreciated.

-Mike