==> In article <910A02699BD53D45A5874E1BA0D6AAEC08D33111 AT atlas.corp.rsinc 
DOT com>, Mike Bantz <mbantz AT RSINC DOT COM> writes:


> How would I find that out? We're not even doing monthly backups yet - just
> trying to see the impending impact.

Count your incremental size over a series of days, and you'll have a measure
of the instantaneous change rate.

Count the number of different copies of various files in your backups table
(BIG LONG EXPENSIVE QUERY) and you'll have a sense of the longer-term rate of
change.

You can also poke around in your database for how many things have changed
since 'a month ago'.  May I suggest keeping a

'select * from columns order by tabname'

hanging around to inform you about your query options.. :)


> From what I've read here so far:

> Much much more database usage

In round terms, multiply by number of copies.  So if you're retaining three
copies now, and you are contemplating monthly-for-5-years, then multiply DB
space by something like 20 (!)

... (!)


> I guess I'm just trying to deal with a TSM deployment that needs to be
> rebuilt in order to handle this operation. Our database is on a 15gig
> partition with no chance of extending that. We'll have to purchase two more
> drives and move it to those drives, which'll entail MOVING the database
> (this scares me...)


Don't be scared of moving the DB;  you can shift stuff to new places pretty
easily, especially if you're willing to maintain the same-size DB volumes.

You can just add a third mirror on the new place, then blow away a mirror on
the old;  repeat until done.

Where you run into nervous-making changes is when you are trying to change the
container -size-.  That still makes me shudder.


- Allen S. Rout
- ... (!)