David
Given these options it looks to me like case(a) with 32 drives should
would be better performance than
case(b) with 24 drives. Another slight advantage would be that the rebuild
time on a system with a smaller number
of disks in the RAID5 array would be faster that with a larger number of
disks. A more difficult comparison
would be 8x4RAID5 versus 4X8RAID5. Each has the same number of disks, but
which is better for performance?
Obviously a lot depends on the system itself (memory, number of
processors), on how the system is tuned both
at low level IO and DB2, how the data is distributed across the
containers, and the actual workload (sequential,
random, reads writes).
If performance is a critical issue perhaps RAID-1 could be considered which
would yield better performance
and redundancy, but comes at the cost of more disks.
There is an excellent document that I recommend and would be very helpful
with this sort of stuff.
It is a Redbook called Tuning Netfinity Servers for Performance.
(Getting the most out of W2K and W NT4.0)
Hope this helps
_____________________________________________
Dale M. McInnis IBM Toronto Lab
Senior Technical Manager, DB2 UDB Backup, Data Protection and Recovery
Email: [EMAIL PROTECTED]
Phone: (416) 448-2397, Fax: (416) 448-4414, T/L: 778-2397
|--------+-------------------------------->
| | "David Bargeron" |
| | <David.Bargeron@btinte|
| | rnet.com> |
| | Sent by: |
| | [EMAIL PROTECTED]|
| | a.best.com |
| | |
| | |
| | 05/31/2001 03:55 PM |
| | Please respond to |
| | db2eug |
| | |
|--------+-------------------------------->
>-----------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: DB2EUG: UDB Downsize
|
|
|
|
|
>-----------------------------------------------------------------------------------------------------------|
Thanks to Dale & P. Saint Jacques,
One other question:
For DMS - as we have scope to re-configure the SSA; with Raid 5 is it
generally better to have more containers for parallelism with fewer disks
per logical drive (3 disks +1 for parity on raid 5) versus fewer containers
with more disks per logical drive (5 +1) ?
i.e. which is likely to give better performance on 500-700 gb database with
36gb SSA disks raid 5
a) 8 containers with 4 disks per container (3+1parity) = 1152 gb
or
b) 4 containers with 6 disks per container (5+1parity) = 864 gb
Please ignore the storage overhead, which would perform better ? (I
prefer a))
Thanks
Dave Bargeron
LloydsTSB Bank
United Kingdom
----- Original Message -----
From: P. Saint-Jacques
To: [EMAIL PROTECTED]
Sent: Wednesday, May 30, 2001 9:29 PM
Subject: Re: DB2EUG: UDB Downsize
You can resize the containers to a minimum size you chose for SMS
containers.
For DMS containers V7 still limits you the high water mark attained for
each container of your current db.
The situation occurs because in the backup image the files that are your
tablespace descriptors: SQLSPCS.1 and SQLSPCS.2 contain info on the high
water mark of each container.
As you restore, these are brought back with the image and your redirect
definitions will be compared to those high water mark values.
So do a LIST TABLESPACE CONRAINERS FOR x SHOW DETAIL where x is the tblsp.
id to find the high water marks of each container to redirect.
Apart from that, what you are planning to do should work.
David Bargeron wrote:
Dear List, I need to resize downwards.... We (& the business !)
over-estimated the sizing of a database (UDB 7.1 on NT 4.0); instead
of being around 1 terabyte it will come to around 500gb, we would
like to free up the extra 500gb SSA for other uses. Our plan is to
backup the existing database, resize the containers accordingly
smaller with fewer disks per array and then do a redirected restore
into the new containers. (The largest containers are for LOB data 6
disks per array + 1 for parity.) Any comments would be greatly
appreciated. Thanks Dave BargeronLloydsTSB BankUnited Kingdom
=====
To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED]
For other info (and scripts), see http://people.mn.mediaone.net/scottrmcleod
