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
[EMAIL PROTECTED]
"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************
-----Original Message-----
From: Gill, Geoffrey L. [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 27, 2001 10:14 AM
To: [EMAIL PROTECTED]
Subject: Migrating to new server.
I sent this yesterday and haven't seen a peep on it. In case it didn't make
it here it is again.
Hi all,
After learning something about AIX I did some investigating on the system
that IBM had set up for us. I discovered that the TSM database and log are
on the same physical disk and mirrored through TSM on a separate physical
disk. Everything I've read tells me to separate these so I wonder why it was
done that way.
The question now is what to do about it. I don't seem to be having a major
performance problem although the system has slowed since it's inception. Our
plan is to purchase a new server since this one goes off lease in May next
year. My plan would be to run this as it is and configure the new one
properly. Now the next question is what is proper.
Should I install the system on it's own disk and mirror it through the OS to
another disk and leave that by itself?
Is it a problem to put the TSM Recovery Log on the same physical disk as the
OS or should I keep that separate? The reason I ask this is because the
Recover Log can only be 5.5gb max.
If I'm using SSA then what kind of performance hit would I get if I used 2
9gb drives to set the Recovery Log on and they were connected via the
internal SCSI controller instead?
If I use a portion of a 36gb SSA disk for the Recovery Log is it ok to use
the rest of that disk for a disk pool or will I take a performance hit?
I doubt that's all of my questions but that's it for now. If anyone has any
suggestions on setting up and migrating everything from my H50 to a new
machine I would appreciate it immensely. And if you're ever in San Diego
I'll take you to meet the Beer Ninja and buy the beer.
Geoff Gill
TSM Administrator
NT Systems Support Engineer
SAIC
E-Mail: [EMAIL PROTECTED]
Phone: (858) 826-4062
Pager: (888) 997-9614
