ADSM-L

Re: Best Practices DISK for DB, LOG, and STGPOOL && JigSaw Puzzle

2006-09-14 11:29:57
Subject: Re: Best Practices DISK for DB, LOG, and STGPOOL && JigSaw Puzzle
From: "Bernaldo de Quiros, Iban 1" <iban.bernaldodequiros AT SUN DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 14 Sep 2006 16:28:49 +0100
Thanks for all your help !! ;-)))

Best Regards, 


         Iban Bernaldo De Quiros Y Marquez 
Technical Specialist

Sun Microsystems, Inc.
Serrano Galvache, 56
Madrid 28033 ES
Phone +34 91 767 6233
Mobile + 34 659 01 91 12
Email Iban.Bernaldodequiros AT Sun DOT COM

         

-----Mensaje original-----
De: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] En nombre de 
Richard Sims
Enviado el: jueves, 14 de septiembre de 2006 17:21
Para: ADSM-L AT VM.MARIST DOT EDU
Asunto: Re: [ADSM-L] Best Practices DISK for DB, LOG, and STGPOOL && JigSaw 
Puzzle

On Sep 14, 2006, at 10:59 AM, Bernaldo de Quiros, Iban 1 wrote:

> Hi Richard,
>
> There's a lot of great stuff here and good advices !!
>
> But I have two last questions...
>
> 1-Will you share the same physical disk with database and storage pool 
> ¿?

Never mix conflicting access-pattern subsystems in storage areas - that can be 
as bad as tape and disk on the same I/O path.  It is essential that your 
database be as high-performance as possible, so keep it separate.

> 2-Will you spread database volumes over the same physical disk or over 
> different physical disks ¿? Or will you make both ¿?

In a non-RAID environment, I would spread over physical disks, to the extent 
reasonable.  If very large disks, you may want a few partitions on the disk; 
but then try to use 15,000 rpm disks.  But I prefer using raw logical volumes 
and hardware RAID 1+0 (striping and
mirroring) for best performance.  And beyond that there are sophisticated disk 
subsystems out there which offer further opportunities.  Remember that TSM uses 
one thread per disk volume, so you gain by having a reasonable number of 
volumes.

Look back in the List archives for information posted from the hard- won 
experiences of other contributors, as there's lots of good advice in our 
collective efforts.

    Richard Sims