Re: Best Practices DISK for DB, LOG, and STGPOOL && JigSaw Puzzle
2006-09-14 11:00:28
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 ¿?
2-Will you spread database volumes over the same physical disk or over
different physical disks ¿? Or will you make both ¿?
Regards,
Thanks in advance,
Regards,
Ibán.
-----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 15:06
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 4:44 AM, Bernaldo de Quiros, Iban 1 wrote:
> Hi Richard,
>
> It is the first time that I do a disk assignment for TSM.
>
> As you said, I have review the documentation there are really good
> advices, but it did not say anything about volumes sizes... For
> example use 10 physical disk, on each of them create a 10 GB partition
> for the database... To have 100 GB...
>
> So I do not know what volume size(partition to Spread DB, LOG,
> STGPOOL) will be suitable for DB, LOG, and STGPOOL.
>
> What volume size will be suitable for a TSM 5.3 installation ¿?
>
> Thanks in advance !!
Hi, Iban -
The guiding principle for the major random access server element, its database,
is that you give it as many disk accessors (arms, spindles) as you can afford,
where RAID striping tends to work best. Partition size is not the issue here,
but distribution of I/O. Size the aggregate size to satisfy your current
needs, and either create a like reserve, or make your design extensible, to
satisfy growth demands.
Disk storage pools are also random access, but with much larger unit write
sizes, so spreading I/O is not as much a factor, and sizing tends to be large.
The Recovery Log is essentially a sequentially written area, so spreading I/O
is not a factor.
Be mindful of I/O path capacity in your planning: having high-
performance disks won't help if the path to them is congested.
Spread I/O over multiple host adapters, as can be computed from load factors.
Some computers have multiple I/O planars (buses), where you would want to avoid
concentrating the host adapters in one planar, which would result in needless
constriction and imbalance.
Much of this is standard computer planning, knowing the characteristics of the
I/O to the various TSM areas. And remember that nothing hampers a caching
server, such as TSM is in its database handling, like inadequate real memory,
so don't skimp there.
Richard Sims
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Best Practices DISK for DB, LOG, and STGPOOL && JigSaw Puzzle, Bernaldo de Quiros, Iban 1
- Re: Best Practices DISK for DB, LOG, and STGPOOL && JigSaw Puzzle,
Bernaldo de Quiros, Iban 1 <=
- Re: Best Practices DISK for DB, LOG, and STGPOOL && JigSaw Puzzle, Bernaldo de Quiros, Iban 1
- Re: Best Practices DISK for DB, LOG, and STGPOOL && JigSaw Puzzle, Bernaldo de Quiros, Iban 1
- Re: Best Practices DISK for DB, LOG, and STGPOOL && JigSaw Puzzle, Ford, Phillip
- Re: Best Practices DISK for DB, LOG, and STGPOOL && JigSaw Puzzle, Leigh Reed
|
Previous by Date: |
Re: 5.2 Server Admin GUI shows no Server Command line, Prather, Wanda |
Next by Date: |
Re: Best Practices DISK for DB, LOG, and STGPOOL && JigSaw Puzzle, Richard Sims |
Previous by Thread: |
Re: Best Practices DISK for DB, LOG, and STGPOOL && JigSaw Puzzle, Richard Sims |
Next by Thread: |
Re: Best Practices DISK for DB, LOG, and STGPOOL && JigSaw Puzzle, Richard Sims |
Indexes: |
[Date]
[Thread]
[Top]
[All Lists] |
|
|