UDB Logging Strategy ?

[MCPHEAL]

Our shop encountered a crash of some description which impacted our logs
somehow. This resulted in a loss of data (albeit small) because we had to
recover to the previous night's backup.

I was intrigued as to whether this was a deficiency in the DBMS, an error in
our adminstration or whatever. Particularly keen that we don't have a repeat.

The feedback from our UDB guru who is a certified expert, is that UDB V8 has
dual logging and we are going there in Q2.

Wondering if there is anything practical that can be done before upgrading.
Hard to imagine anyone running business critical apps with such a primitive
recovery set-up.

All constructive advice gratefully received.

[Mark A]

Re: UDB Logging Strategy ?

"MCPHEAL" <mcpheal@aol.co m> wrote in message
news:2004021313 2450.21805.0000 1585@mb-m25.aol.com...[color=blue]
> Our shop encountered a crash of some description which impacted our logs
> somehow. This resulted in a loss of data (albeit small) because we had to
> recover to the previous night's backup.
>
> I was intrigued as to whether this was a deficiency in the DBMS, an error[/color]
in[color=blue]
> our adminstration or whatever. Particularly keen that we don't have a[/color]
repeat.[color=blue]
>
> The feedback from our UDB guru who is a certified expert, is that UDB V8[/color]
has[color=blue]
> dual logging and we are going there in Q2.
>
> Wondering if there is anything practical that can be done before[/color]
upgrading.[color=blue]
> Hard to imagine anyone running business critical apps with such a[/color]
primitive[color=blue]
> recovery set-up.
>
> All constructive advice gratefully received.[/color]

Don't put your logs on the same physical volume (or RAID array) as your
data.

[db2hp]

Re: UDB Logging Strategy ?

MCPHEAL wrote:
[color=blue]
> Our shop encountered a crash of some description which impacted our logs
> somehow. This resulted in a loss of data (albeit small) because we had to
> recover to the previous night's backup.
>
> I was intrigued as to whether this was a deficiency in the DBMS, an error
> in our adminstration or whatever. Particularly keen that we don't have a
> repeat.
>
> The feedback from our UDB guru who is a certified expert, is that UDB V8
> has dual logging and we are going there in Q2.
>
> Wondering if there is anything practical that can be done before
> upgrading. Hard to imagine anyone running business critical apps with such
> a primitive recovery set-up.
>
> All constructive advice gratefully received.[/color]

Actually, dual logging (of sorts) was available in DB2 V7.2 with Fixpack 8,
using the DB2_NEWLOGPATH2 option. I guess you are on an earlier fixpack of
your "UDB guru" would have mentioned it.

The implementation in V7 was very much a stopgap : its major drawback was
that it simply took the main log destination and appended the character "2"
to the bottom directory (so for example if you logged to "/logs/database'
then the second log would go to '/logs/database2'.

The V8 implementation is much better using the MIRRORLOGPATH to allow you to
specify a totally separate location.

If you lost all logs in your log directory then you would only be able to
recover (AFAIK) to the end of the archived logs. You don't say what types
of logs you lost. I suspect you must have lost an active log. If the
active logs are not there then crash recovery would have problems : you
would then need to go to your backup and roll forward to end of logs (and
with only the archive logs available that could involve some data loss).

Of course, if there were no logs archived since the last backup, either
because the time period was short or the active log was very big then your
recovery would simply be to the last full backup.

You also mention you are going to V8 in Q2 : remember that support ends for
V7.2 at end of Q1 !!!

[Fan Ruo Xin]

Re: UDB Logging Strategy ?


"db2hp" <hp@yahoo.co.uk > wrote in message
news:33cXb.8342 858$Of.1357948@ news.easynews.c om...[color=blue]
> MCPHEAL wrote:
>[color=green]
> > Our shop encountered a crash of some description which impacted our logs
> > somehow. This resulted in a loss of data (albeit small) because we had[/color][/color]
to[color=blue][color=green]
> > recover to the previous night's backup.
> >
> > I was intrigued as to whether this was a deficiency in the DBMS, an[/color][/color]
error[color=blue][color=green]
> > in our adminstration or whatever. Particularly keen that we don't have a
> > repeat.
> >
> > The feedback from our UDB guru who is a certified expert, is that UDB V8
> > has dual logging and we are going there in Q2.
> >
> > Wondering if there is anything practical that can be done before
> > upgrading. Hard to imagine anyone running business critical apps with[/color][/color]
such[color=blue][color=green]
> > a primitive recovery set-up.
> >
> > All constructive advice gratefully received.[/color]
>
> Actually, dual logging (of sorts) was available in DB2 V7.2 with Fixpack[/color]
8,[color=blue]
> using the DB2_NEWLOGPATH2 option. I guess you are on an earlier fixpack[/color]
of[color=blue]
> your "UDB guru" would have mentioned it.[/color]
===============
Exactly. -:)
BTW, you can also mirror the disk where the active logs locate.
[color=blue]
>
> The implementation in V7 was very much a stopgap : its major drawback was
> that it simply took the main log destination and appended the character[/color]
"2"[color=blue]
> to the bottom directory (so for example if you logged to "/logs/database'
> then the second log would go to '/logs/database2'.
>
> The V8 implementation is much better using the MIRRORLOGPATH to allow you[/color]
to[color=blue]
> specify a totally separate location.
>
> If you lost all logs in your log directory then you would only be able to
> recover (AFAIK) to the end of the archived logs. You don't say what[/color]
types[color=blue]
> of logs you lost. I suspect you must have lost an active log. If the
> active logs are not there then crash recovery would have problems : you
> would then need to go to your backup and roll forward to end of logs (and
> with only the archive logs available that could involve some data loss).
>
> Of course, if there were no logs archived since the last backup, either
> because the time period was short or the active log was very big then your
> recovery would simply be to the last full backup.
>
> You also mention you are going to V8 in Q2 : remember that support ends[/color]
for[color=blue]
> V7.2 at end of Q1 !!![/color]
==============
AFAIK, the support of Version7.1 is available until the end of Q3. -:(

[Blair Adamache]

Re: UDB Logging Strategy ?

v7.2 support has been extended to September, 2004:

http://www-306.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/newsletter.d2w/n20020101

db2hp wrote:
[color=blue]
> MCPHEAL wrote:
>
>[color=green]
>>Our shop encountered a crash of some description which impacted our logs
>>somehow. This resulted in a loss of data (albeit small) because we had to
>>recover to the previous night's backup.
>>
>>I was intrigued as to whether this was a deficiency in the DBMS, an error
>>in our adminstration or whatever. Particularly keen that we don't have a
>>repeat.
>>
>>The feedback from our UDB guru who is a certified expert, is that UDB V8
>>has dual logging and we are going there in Q2.
>>
>>Wondering if there is anything practical that can be done before
>>upgrading. Hard to imagine anyone running business critical apps with such
>>a primitive recovery set-up.
>>
>>All constructive advice gratefully received.[/color]
>
>
> Actually, dual logging (of sorts) was available in DB2 V7.2 with Fixpack 8,
> using the DB2_NEWLOGPATH2 option. I guess you are on an earlier fixpack of
> your "UDB guru" would have mentioned it.
>
> The implementation in V7 was very much a stopgap : its major drawback was
> that it simply took the main log destination and appended the character "2"
> to the bottom directory (so for example if you logged to "/logs/database'
> then the second log would go to '/logs/database2'.
>
> The V8 implementation is much better using the MIRRORLOGPATH to allow you to
> specify a totally separate location.
>
> If you lost all logs in your log directory then you would only be able to
> recover (AFAIK) to the end of the archived logs. You don't say what types
> of logs you lost. I suspect you must have lost an active log. If the
> active logs are not there then crash recovery would have problems : you
> would then need to go to your backup and roll forward to end of logs (and
> with only the archive logs available that could involve some data loss).
>
> Of course, if there were no logs archived since the last backup, either
> because the time period was short or the active log was very big then your
> recovery would simply be to the last full backup.
>
> You also mention you are going to V8 in Q2 : remember that support ends for
> V7.2 at end of Q1 !!!
>
>[/color]