Hi Jason,
it seems then, that the issue is the buffering or not. If it commits
after every activity, then mirroring is reasonable, if not it's not,
right?
As far as the media, our server is MVS based and we have fault-tolerant
devices so we can breathe a little easier, there.
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 7:01 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Server Crash!!
>
> 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
> 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
|
