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