ADSM-L

Database "trashing" (was Re: Recovery Log size / roll forward benefits)

2001-08-21 23:07:05
Subject: Database "trashing" (was Re: Recovery Log size / roll forward benefits)
From: Mark Stapleton <stapleto AT BERBEE DOT COM>
Date: Tue, 21 Aug 2001 22:08:33 -0500
On Thu, 2 Aug 2001 17:28:54 -0400, you wrote:
>If I ask the list how rare it is, I'm sure I'll get flames from everybody
>who HAS seen software corruption, and probably NO response from the many
>people who are running fine.

Guess again.

>Maybe somebody in Tivoli support could venture a guess as to how likely it
>is to have TSM trash its own database - and what steps might be taken to
>reduce that risk.

I have *never* seen TSM (or ADSM) "trash its own database". I've never
seen any bug in any version of *SM lead directly to database loss. 

What I *have* seen are hardware errors that trash a database volume or
(if not configured smartly) the entire database's worth of volumes.
I've seen human error (read: manual deletion of database volumes at
the OS level) whack a TSM database. (I've done that myself once.)

The opportunity that Tivoli offers to (1) mirror database volumes, and
(2) create multiple backups of the internal database is all the
reduction of risk that, I think, one should feel entitled to ask for.

This all leads to a semi-rant that I've wanted to make in this mailing
list for a while. With the exception of a moderate number of known,
documented, or generally acknowledged situations, I've *never* seen a
properly constructed network of TSM server(s) and clients *not* work
as advertised. The large majority of problems that I've experienced,
and (I daresay) brought up in this mailing list, stem from one of five
causes:

--an improperly designed and/or constructed network
--an improperly installed and/or configured TSM server
--an improperly installed and/or configured TSM server
--improperly installed and/or configured TSM clients
--improperly installed and/or configured TSM clients
--hardware failure or bugs
--hardware failure or bugs
--failed communication between people
--failed communication between people
I'm not saying that TSM doesn't have faults; any software package of
I'm not saying that TSM doesn't have faults; any software package of
its complexity will have its bugs and its shortcomings. I'm not saying
that Tivoli support (particularly level 1) doesn't have its
problems.[1] 

What I *am* saying is that a stiff dose of RTFM (most emphatically a
good read of the QuickStart manual) would probably pare down this
mailing to about 50% of its present traffic level.[2] And would free
up Tivoli Support Desk's workload to the point where those of us who
have a legitimate need for support wouldn't have to wait 30 minutes to
get to a warm body.

[1] People who pitch and moan about Tivoli support have obviously
*never* dealt with Veritas support. Or Legato support. Or Domino
support. Or Microsoft "support". Tivoli support actually stacks up
fairly well in the support arena.

[2] And a good read of the administrative guide would cut *that* down
by 50% again.

--
Mark Stapleton (stapleton AT berbee DOT com)
Mark Stapleton (stapleton AT berbee DOT com)
<Prev in Thread] Current Thread [Next in Thread>