As to your db issue, all I can say is ouch.
You haven't said what kind of library (and how many drives), or how big
your potential collocated backup is, but a possible option would be to
set up a collocated tape pool and then a management class that points
directly to that pool. Then specify that mgmt class (via "include
<filespec> <management class>") in the correct dsm.opt files. You would
be bypassing the diskpool, but if your tape is fast enough and you have
the spare drives, this is a perfectly acceptable option. Again, you
wouldn't be getting the benefits of a diskpool, but it would give you
the benefits of collocation. A key point if you decide to set this up
is that you should design it so that at a maximum you never have more
sessions backing up to this pool than x-1 where x=number of drives. You
should always leave at least one drive free for adhoc restores and/or
diskpool migration. I like to leave at least two free, or even more if I
can.
As always ymmv
Chris Gibes (gibes AT berbee DOT com)
Tivoli Certified Consultant
IBM Certified System Administrator
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Matt Simpson
Sent: Wednesday, October 23, 2002 7:51 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Co-location
At 12:06 AM -0500 10/23/02, Chris Gibes said:
>You are absolutely correct. Co-location is by storage pool, not by
>management class. So yes, you would need to carve your disk up into
>multiple storage pools to selectively use co-location,
Thanks for the confirmation
>my guess is that it's
>not viable to add more disk (or you're on one of those platforms where
>disk is not "cheap"...)
Expenditures are always political. Management is always more willing
to spend huge gobs of money into a new disaster than drop a few more
pennies into an existing one. And I'm more concerned about the
management headaches than the cost, as you point out ..
>the total amount of disk and the total amount
>being backed up are going to be the same regardless of how many pools
>you have, so carving one big pool up, shouldn't be that big of an
issue,
true, but
>as long as you put some planning into the size of the disk pools.
There's the catch. We can't plan more than 30 minutes into the
future around here. It's easier to manage one big chunk of something
than a bunch of little chunks. If we carve up our disk pools based
on today's "plan", we'll have to re-configure them tomorrow. Our
database has already exceeded the allocation that IBM told us was way
bigger than we'd ever need, and we haven't even finished the
installation yet.
--
Matt Simpson -- OS/390 Support
219 McVey Hall -- (859) 257-2900 x300
University Of Kentucky, Lexington, KY 40506
<mailto:msimpson AT uky DOT edu>
mainframe -- An obsolete device still used by thousands of obsolete
companies serving billions of obsolete customers and making huge
obsolete
profits for their obsolete shareholders. And this year's run twice as
fast
as last year's.
|
