ADSM-L

Re: [ADSM-L] TSM upgrade v5 --> v6 database storage question

2010-02-18 16:04:42
Subject: Re: [ADSM-L] TSM upgrade v5 --> v6 database storage question
From: Xav Paice <xpaice AT OSS.CO DOT NZ>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 19 Feb 2010 10:03:00 +1300
Just one point to add to that - with the DS4x00 series storage arrays you only 
have one preferred controller active at a time per LUN - so if you split the db 
into two LUNs you have the option to have each LUN running across a separate 
controller, with I/O performance gains as a result.  If you'd even notice the 
difference is another matter ;)


----- "Richard Rhodes" <rrhodes AT FIRSTENERGYCORP DOT COM> wrote:

> From: "Richard Rhodes" <rrhodes AT FIRSTENERGYCORP DOT COM>
> To: ADSM-L AT VM.MARIST DOT EDU
> Sent: Friday, 19 February, 2010 9:28:45 AM (GMT+1200) Auto-Detected
> Subject: Re: [ADSM-L] TSM upgrade v5 --> v6 database storage question
>
> Easy answer . . . "it depends" . . .
>
> Here are some questions/comments in no particular order:
>
> Are you on an array today?
> Is the array busy and loaded down?
> Does it have multiple raidsets?
> What kind of drives does it have (sata, fc10k, fc15k)?
> I'm not a windows admin - would the drive letters be separate luns?
> If separate luns, would you put them on separate raidsets?
> If multiple luns but all on the same raidset, then you are basically
> gaining a cmd queue for each lun.
> If separate luns and you can put them on separate raidsets, then you
> are
> getting many more HDD's working for you.
> Are you disk I/O bound now?  If not, then you probably won't see much
> difference on matter what you do.
> The big advantage of the array is I/O spread across multiple/many
> spindles
> and write-back cache.
> If you were using a unix system, I'd say to allocate one lun per
> raidset,
> bring them into a volume group, and create filesystems striped across
> the
> luns.  That's how we do everything.
>
> rick
>
>
>
>
>
>
>              Nicholas
>              Rodolfich
>              <NRodolfich@CMAON
>  To
>              THEWEB.COM>               ADSM-L AT VM.MARIST DOT EDU
>              Sent by: "ADSM:
>  cc
>              Dist Stor
>              Manager"
> Subject
>              <[email protected]         TSM upgrade v5 --> v6 database
>              .EDU>                     storage question
>
>
>              02/18/2010 02:39
>              PM
>
>
>              Please respond to
>              "ADSM: Dist Stor
>                  Manager"
>              <[email protected]
>                    .EDU>
>
>
>
>
>
>
> Hello All,
>
> Thanks for your help!
>
> Upgrading a client on Windows 2003 TSM v5.5.3 to Windows 2008 TSM
> 6.1.3. I
> am planning the storage and was wondering if it is worth splitting
> the
> database between multiple file systems. The storage they have for the
> database is FCAL on an IBM DS4800. The client's current database is
> 65GB
> and will probably reduce to 55GB after the upgrade when we purge some
> old
> data. I was going to do the following
>
> e:\   database directory
> f:\   active log directory
> g:\   archive log directory.
>
> I could do this
>
> e:\   database directory
> f:\   database directory
> g:\   database directory
> h:\   active log directory
> i:\   archive log directory.
>
> The storage will be all be RAIDed on the DS4800 so I am wondering just
> how
> much if any performance gains I will see if I split the database up
> into
> more file systems. I would also like to solicit any opinions on the
> storage
> configuration (i.e. - RAID?, placement of logs, etc)
>
> Thanks,
>
> Nicholas
>
> -----------------------------------------
> The information contained in this message is intended only for the
> personal and confidential use of the recipient(s) named above. If
> the reader of this message is not the intended recipient or an
> agent responsible for delivering it to the intended recipient, you
> are hereby notified that you have received this document in error
> and that any review, dissemination, distribution, or copying of
> this message is strictly prohibited. If you have received this
> communication in error, please notify us immediately, and delete
> the original message.

<Prev in Thread] Current Thread [Next in Thread>