ADSM-L

Re: Migrating to new server.

2001-04-27 11:24:30
Subject: Re: Migrating to new server.
From: "Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU>
Date: Fri, 27 Apr 2001 11:24:39 -0400
Hi Geoff,

The one hard and fast rule here, is NEVER CREATE A SITUATION WHERE A
HARDWARE FAILURE COULD DESTROY YOUR RECOVERY LOG.   Beyond that, the answer
to everything else is pretty much "it depends".

If you search the archives of this list, you will find that IBM/Tivoli's
position has always stated that it is better to let TSM do the DB and log
mirroring, instead of letting the OS do the mirroring.  They believe there
are cases where TSM can detect a logical/software error in the DB or log and
NOT propagate it into the mirror copy.  If you let the OS or the hardware do
the mirroring you are protected from hardware failure, but any type of
logical erro in the DB or log will immediately be copied to the mirror and
you will have two copies of junk.  I have never heard from anyone that has
proved this case, but anyway TSM does a very good job of managing its own
mirrors.

For full recovery, you should be running the recovery log in rollforward
mode.  I belive it is absolutely necessary to have a mirror copy of the
recovery log that is physically isolated from the primary.  That way I know
I can always recover the DB from a DB restore/rollforward operation, even if
there is no DB mirror.

Whether you need the DB mirrored or not, depends on your situation.
Mirroring the DB is obviouly a good thing and always recommended.  Bbut in
systems where you don't have much disk available, mirror the log instead of
the DB, and do daily DB backups.  You can always recover that way, it just
takes more time.

I believe putting the DB on RAID 5 with mirrored recovery logs provides
about as good a recovery situation as most sites require, as the probability
of losing a DB on RAID-5 is very low, assuming you trust your RAID-5 vendor.
(A mistake I think some people make is putting both the DB and log on RAID-5
and thinking they are protected, when actually there is one RAID-5
controller that could be a single point of failure...)

You have to consider what YOUR installation recovery requirements really
are.  From testing I know that if  we lose a TSM  DB here, it would take at
most a 4 hour outage to recover from the DB backup.  That is acceptable
here, considering the extremely low probability of losing the DB on a RAID-5
disk, so I consider not mirroring the DB to be acceptable if the logs are
mirrored.    On the other hand, if you are using TSM space management/HSM,
you can't afford ANY outage at all, and you have to mirror everything, and
probably should be running your TSM server in an HA cluster!
.
However, RAID-5 is slower than mirrored non-RAID disk.  IN the busiest
system we have here, I started with one copy of the DB on external SCSI
RAID-5.  As the load increased, we grew and moved the DB to SSA RAID-5,
which was faster.  Then as the load increased more, we grew and had to take
the DB off RAID-5 and use more disk for mirroring to pick up more speed for
that system.  Whatever works, works.  As long as you mirror those logs with
no single point of failure and do good DB back ups, you can recover.
Everything else is just an issue of time.

I have never had a problem putting one copy of the recovery log on the OS
disk, unless there is a lot of paging activity.  However, if you have a lot
of paging, THAT is your performance problem, and you should worry about
fixing that!

PUtting storage pool volumes on the same disk as your log WILL cause some
perfomance hit.  The question is, do you care?  The biggest hit I see is
during migration - does migration occur at a time when performance matters
to you?  If there is performance degradation at 2am and no one is there to
see it (and you still meet your time windows), does it really exist? So on
my systems where throughput is an issue, I isolate the logs on their own
disks.  On the systems where throughput isn't an issue, I use the extra
space for a storage pool volume if I need it.  (It may be a good place for
an archive pool volume, if archiving occurs infrequently.)

Hope that helps some....
************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu

"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************





<Prev in Thread] Current Thread [Next in Thread>