We run on the ESS.  No mirroring!  You are paying for a solution that has
such high availability numbers it makes no sense.  If you want to improve
your recovery, run more incremental backups so you can roll to the most
current, do a volhistory dump, and put that information on the root disk
(not on the ESS) or a different array in the ESS on OS/390.

There is also a mirroring bug below 4.2.2.8 that can cause horrible database
backup performance.

You are correct, it is overkill for the database.  The only thing I could
possibly justify is mirroring the log on different SSA loops in the ESS so
that if the log died I could recover from the last backup.

There have been a handful of ESS array failures.  For example, a microcode
glitch that occurred if a DDM failed and a parity rebuild was in process
because of a SSA adapter special condition.  That was fixed in G5+1 of the
ESS microcode about 8 months ago.  Only one customer ever saw that problem
to my knowledge.  There was also a bad vintage of drives that has been
cleaned up.  But otherwise, things have been solid and we should trust this
hardware.

Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180


-----Original Message-----
From: Matt Simpson [mailto:msimpson AT UKY DOT EDU]
Sent: Tuesday, October 22, 2002 1:52 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: RAID5 in TSM


At 9:27 AM -0400 10/22/02, Lawrence Clark said:
>Even though there may be a slight performance hit on writes, I've
>placed the TSM DB on RAID-5 to ensure availability and no down time in
>case of a disk loss.

With RAID 5, is there any point in software mirroring (dual copies of
database)?

Our DB is on RAID5 (Shark).  We also have 2 copies of it, except for one
extent that we added in a crunch when it filled up.  Are the dual copies
overkill on RAID 5?  I know that even RAID is not totally infallible, and we
could have a potential disaster that wipes out the whole Shark.  But that's
why we have backups.  The chances of that are pretty slim, and I can't
imagine any scenario where we could have a RAID failure that wouldn't leave
us so dead that we'd have to restore anyway.
--


Matt Simpson --  OS/390 Support
219 McVey Hall  -- (859) 257-2900 x300
University Of Kentucky, Lexington, KY 40506 <mailto:msimpson AT uky DOT edu>
mainframe --   An obsolete device still used by thousands of obsolete
companies serving billions of obsolete customers and making huge obsolete
profits for their obsolete shareholders.  And this year's run twice as fast
as last year's.