==> In article <[EMAIL PROTECTED]>, Mike Bantz <[EMAIL PROTECTED]> 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 - ... (!)
