ADSM-L

Re: AIX JFS Striping vs Multiple DB Extents

2002-05-01 16:14:43
Subject: Re: AIX JFS Striping vs Multiple DB Extents
From: Zlatko Krastev <acit AT ATTGLOBAL DOT NET>
Date: Wed, 1 May 2002 23:14:18 +0300
Use TSM mirroring and evaluate usage of MIRRORWRITE DB Sequential. There
were several posts on this list regarding TSM self-recovery when one of
the mirror copies get broken. There are few possible (rare but possible)
occasions when DB mirror copy may get corrupt. AIX will write corrupt data
to both copies and is unaware how to recover. You will have to restore TSM
DB.
IMO use raw logical volumes. Performance penalty for JFS is not big but is
there. Capacity waste also is not big but you need jfslog lv, superblock &
i-nodes. And you can be lazy a bit - raw devices do not need dsmfmt.

Zlatko Krastev
IT Consultant



Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        AIX JFS Striping vs Multiple DB Extents

I'm about to do a disk reorg as a part of installing some new disk
drives, and I'm trying to get the best Database performance. The system
is TSM 4.2.1.09 on AIX 4.3.3.09. The processor is slow, but the new
disks are fast SSA disks.

What are the pros and cons of

Using AIX disk striping

           versus

Having multiple TSM Database extents

...and...

AIX JFS Mirroring

     versus

TSM Database/Log Mirroring

...and...

AIX JFS extents for DB and Log

      versus

Raw extents

Short of conducting some rather painstaking tests using my new disks,
(35gb Database) I really have little informaiton regarding the
performance aspects of these choices.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
============ "The World's Least Intuitive Operating System" ============
=============== -- from the cover of "Unix for Dummies" ================
<Prev in Thread] Current Thread [Next in Thread>
  • Re: AIX JFS Striping vs Multiple DB Extents, Zlatko Krastev <=