ADSM-L

Re: DB mirroring

2003-03-25 08:31:35
Subject: Re: DB mirroring
From: Jurjen Oskam <jurjen AT QUADPRO.STUPENDOUS DOT ORG>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 25 Mar 2003 14:30:47 +0100
On Tue, Mar 25, 2003 at 09:59:47AM -0300, Stanfield Alejandro wrote:

>         2 - DB on RAID 1 and no mirror

> What's the performance impact of having TSM do the mirroring? Since I'll be
> moving the DB to a storage array (HP EVA) which can self replace failing
> disks I'm tempted to go for option 2

A few weeks ago, I asked about the same question. The Administrator's Guide
mentions the concept of a "partial page write". The guide mentions that
the TSM server doesn't guarantee a consistent on-disk database.
If the TSM server crashes or is otherwise interrupted while updating the
database on disk, the image on disk can be corrupted and cannot be used
when restarting the server (so a restore would be necessary).

If you go with non-TSM mirroring, a "partial page write" will be duplicated
across *all* database mirrors and they will *all* be corrupted.

If you go with TSM mirroring *and* sequential mirror writing, a "partial
page write" still can happen, but will happen in at most one mirror. The
TSM server is able to recover from this by using an intact mirror.


What the Administrator's Guide *doesn't* mention, is what results in a
"partial page write". What I would like to know is whether the TSM
server really doesn't guarantee a consistent database image on disk, given
that the "sync" (or AIX equivalent) syscall is reliable.




With all this said, there are people that only use non-TSM mirroring and
never had any problem at all with "partial page writes". We use
TSM-mirroring with sequential mirror writing, but our TSM server isn't
bottlenecked on database I/O. When (if) database I/O starts to become a
problem, most likely we'll switch to non-TSM mirroring.

--
Jurjen Oskam

PGP Key available at http://www.stupendous.org/

<Prev in Thread] Current Thread [Next in Thread>
  • DB mirroring, Stanfield Alejandro
    • Re: DB mirroring, Jurjen Oskam <=