Hi Eric,
If you're constrained for some reason and have to put the log and
database on the same disks, then that may be your only option. However, if
you have a choice, I would still recommend that you separate the two. It
is not unheard of to lose both copies of a mirror. This can happen for a
number of reasons, but generally not a combination of simultaneous media
failures. We have seen this happen on a Sun storage array here, due to a
microcode bug. Another thing that could happen if you don't plan
adequately for it, is that you could lose quorum for the volume group, and
AIX will vary it offline on you. Of course, there are things you can do to
plan for this possibility. But I just think it's safer to separate the log
and database volumes if you have that option available.
I am curious about the performance claim that AIX mirroring is faster
than ADSM mirroring. I don't recall seeing anything about that in the ADSM
Performance Tuning Guide. If anyone from the ADSM Performance Group reads
this, perhaps they could comment on this?
..Paul
--
At 02:03 PM 2/22/2000 +0100, Loon, E.J. van - SPLXM wrote:
At 02:03 PM 2/22/2000 +0100, Loon, E.J. van - SPLXM wrote:
>Hi Paul!
>I followed that discussion too a few months ago, however, I met a guy who is
>specialized in ADSM performance tuning and he indicated that AIX mirroring
>is reasonably faster than ADSM mirroring.
>I understand that the database and recovery log are vital for recovery of
>the ADSM server, but what is the chance of loosing them when they are
>located on a mirrored disk?
>Kindest regards,
>Eric van Loon
>
>
>-----Original Message-----
>From: Paul Zarnowski [mailto:vkm AT CORNELLC.CIT.CORNELL DOT EDU]
>Sent: Friday, 18 February, 2000 17:28
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: Recovery log
>
>
>Eric,
>
>At 02:43 PM 2/18/2000 +0100, you wrote:
>>Hi *SM-ers!
>>I will soon migrate my ADSM 3.1.50 server on a H50 to TSM 3.7.2 on a H70
>>server.
>>I'm trying to figure out the best disk layout on the H70.
>>I will put the database on an AIX mirrored SSA disk en because of the
>>mirror, I decided not to use the roll forward mode for the recovery log (I
>>will accept the risk of loosing both disks during a real disaster, like
>fire
>>or something).
>
>I believe IBM recommends using ADSM mirroring, not AIX mirroring, and I
>also seem to recall a previous discussion on this list some time ago
>regarding this. Having just gone through a database corruption "event", I
>strongly recommend that you reconsider using rollforward mode for the
>recovery log, if you have sufficient disk space. Rollforward mode will
>allow you to recover your database to the state it was in just prior to a
>corruption event, assuming that you can determine when the event occurred.
>I did not have rollforward set before our corruption, and very much wish
>that I had.
>
>>As far as I could find out, ADSM/TSM doesn't generate a high load on the
>>recovery log when running in normal mode. It's not quite clear to me why
>>ADSM/TSM is using the recovery log at all when running in normal mode. The
>>Admin Guide says it's only used for 'uncommitted transactions' but not how
>>you can prevent/minimize this.
>
>The log is used to ensure that database updates are reliably committed,
>even in the face of hardware outages/failures. Without the log, a partial
>database update could occur after a hardware problem, which might result in
>a referrential integrity problem in your database, which could lead to all
>sorts of problems. The recovery log is used when the ADSM server comes up
>to ensure that any partially written database updates are completed, thus
>preserving referrential integrity.
>
>>Is it very unwise, looking from a performance perspective, to put both the
>>database and the recovery log on the same physical (mirrored) disk when
>>running in normal mode?
>
>Not only from a performance perspective, but especially from a reliability
>perspective. Since the primary reason for the log is to preserve the
>integrity of the database, it is critical that it be stored on separate
>disk media.
>
>>Kindest regards,
>>Eric van Loon
>
>..Paul
>
|
