G'day Dave,
I can't say one way or the other if you should have mirroring enabled or not.
I can say that if you do, then you should let ADSM do it instead of the
operating system (NT, AIX, or whatever). You have to make a judgement call on
the cost of mirroring on performance and DASD usage compared with the increase
in availability.
My understanding is that the log gets written too after every activity and does
not buffer the writes. If you have a mirrored recovery log, and are using
parallel writes, then any updates are written to both copies at the same time
(for all intents and purposes). In this instance, it is possible that a system
crash will cause a partial write to both copies thus negating the whole idea of
mirroring. This method will protect you from a media crash that removes one of
the mirrored copies. ADSM would mark the lost copy offline, and continue to
use the other one. You would then shut down everything smoothly, replace the
faulty media, and restart without too much effort.
If you are using sequential writes to your mirrored copies, then ADSM will set
a dirty flag on the primary copy, perform the I/O, ensure the write is
successful, then flag the copy as 'clean' then it will set the dirty flag on
the secondary copy and perform the I/O on that copy, ensure it was successful,
then mark that copy as clean, and repeat.
In the event of a server crash, ADSM will automatically detect which copy is
clean at restart and use that version. Yes, this causes a performance hit. In
the grand scheme of things, not a huge penalty I think, but something you
should test on your own system.
On the other hand, I have customers who do not care about the recovery log.
They backup their database twice a day, and accept that if they lose the
recovery log, they may lose up to 12 hours of updates.
Regards,
--
Mr Jason E Meaden IBM Australia Ltd
Mr Jason E Meaden IBM Australia Ltd
Software Service Specialist (Asia Pacific) 55 Coonara Avenue
IBM Certified Specialist - ADSM West Pennant Hills 2125
Phone: 13 24 26 * Fax: 61 2 9354 7797 * Tie: 49427 * VM: RTP(MEADEN)
ADSM-L AT VM.MARIST DOT EDU on 27/05/98 20:32:33
Please respond to ADSM-L AT VM.MARIST DOT EDU
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: Server Crash!!
Since I tend to be against mirroring, this could change my mind if what
Jason says is true!
There are 2 questions that I have:
1) Does the recovery log get written to after every activity, or does it
buffer activity for awhile before writing?
*if every activity immediately writes to the primary log and
then to the mirrored-log, then I guess I'd have to rethink the
mirroring thing
*if every activity DOESN't get written to the primary log
immediately, then mirroring accomplishes nothing since the content
of the buffer is broken and either neither log gets written to, or both
get written to badly.
2) If you have a busy system and a -write to a mirrored log- has to wait
for a write to finish on the primary log, does this negatively affect
performance?
*I guess this would have to be accepted as a cost for having the
redundancy
*Or, it's not detectable
Dave Sanders
Sr. Technical Consultant
DSanders AT massmutual DOT com
1295 State St, E060, Springfield, MA 01111
413-744-5095
!@#$%
> -----Original Message-----
> From: Jason Meaden [SMTP:jasonm AT AU1.IBM DOT COM]
> Sent: Wednesday, May 27, 1998 5:47 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Server Crash!!
>
> G'day Scott,
>
> You have a corrupt recovery log due to a partial write that was in
> progress
> when the system died.
>
> You should probably restore the DB from your last backup. Don't
> bother with a
> rollforward, even if you had that enabled. It will probably roll in
> the same
> error, and the server would still not start.
>
> You could also do a 'dump load audit' but this is very time consuming.
>
> To prevent the problem occuring again, you could mirror the recovery
> log and
> use:
>
> MIRRORWRITE LOG SEQUENTIAL
>
> ADSM will then ensure that one mirror copy has been properly written
> too before
> beginning to write to the next.
>
> Regards,
> --
> Mr Jason E Meaden IBM Australia Ltd
> Software Service Specialist (Asia Pacific) 55 Coonara Avenue
> IBM Certified Specialist - ADSM West Pennant Hills 2125
> Phone: 13 24 26 * Fax: 61 2 9354 7797 * Tie: 49427 * VM: RTP(MEADEN)
>
>
>
>
>
>
> ADSM-L AT VM.MARIST DOT EDU on 27/05/98 19:18:11
> Please respond to ADSM-L AT VM.MARIST DOT EDU
> To: ADSM-L AT VM.MARIST DOT EDU
> cc:
> Subject: Server Crash!!
>
>
> Help,
>
> We have an NT4 SP3 server running ADSM 3.1.0.2 server.
>
> It has been running fine for ages up until last weekend.
>
> The ADSM server crashed with a Dr Watson error relating to
> DSMSERV.exe.
>
> When we restart the server we get the following message
>
> ANR0990I ADSM server restart-recovery in progress.
> ANR0200I Recovery log assigned capacity is 500 megabytes.
> ANR0201I Database assigned capacity is 2004 megabytes.
> ANR0306I Recovery log volume mount in progress.
> ANR0353I Recovery log analysis pass in progress.
> ANR9999D pkthread.c (825) : Run-time assertion failed: "Cmp64 (
> scanLsn, LOGV->headLsn ) != GREATERTHAN" , Thread 0, File logread.c,
> Line 364.
>
> Any help would be much appreciated
>
> Regards
>
> Scott
>
>
>
>
|
