"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 03/22/2011
10:25:00 AM:

> From: "Prather, Wanda" <wPrather AT ICFI DOT COM>
> To: ADSM-L AT VM.MARIST DOT EDU
> Date: 03/22/2011 10:25 AM
> Subject: Re: draining a diskpool when using a DD and no copypool
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> Curious as to why you are using the disk pool with migration to DD
> instead of having your backups write directly to the DD.
>
> Wanda

1) We're still trying to make this puppy work (right now having problems
getting 10g direct connects to the TSM servers working).

2) For initial implementation we want to make as few changes as possible.

3) But the real reason is that we really like having backups buffered
before the next pool.  This is especially true for Oracle archive logging.
 We're thinking this is especially true for the DD which only has a single
head - nonredundant.

Now, we think we will send more directly to DD, just not at the start. And
then it will probably be via a limit on file size of the diskpool.  That
way it's less playing with nodes and management classes. There is a limit
to the number of sessions the DD can handle concurrently (150), which
includes backup, restore, and replication sessions, and this limit is
shared between two TSM instances.  We want to wait and see this all looks
like before we jump too deep into other changes.  It seems best at the
start to just change out tapepool for filepool (with the required
migration), see how it works, then see what else to change to make things
better.

 . . . at least that's the plan . . .

Rick


-----------------------------------------
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.