>> On Wed, 17 May 2006 10:14:27 -0400, "Scott, Brian" <[EMAIL PROTECTED]> said:
> All, > My collegue found the following article from the University of Florida Heh. Well, I was staying out of this round; considering saying something once Kelly posted, but since my article was invoked, I guess I was too. :) Richard and I have kicked this around in the past. For the record I don't disagree with the direction of the concerns he has, I disagree with their magnitude. He feels that the issues he raises are sufficiently strong that the procedure should never ever be done. I feel that it's sufficiently risky than you shouldn't do it unless you're pretty certain you will get a win out of it. So our risk profiles are different; given that by normal standards most backup admins are tinfoil-covered paranoids, I guess small absolute variations look huge from our perspective. :) I've been convinced by Richards' past arguments about the rate of fragmentation and the speed with which you'll lose the ground you got back; so I'm not inclined to include an unload/reload as any kind of routine maintenance. Not so much for risk reasons, as for waste-of-time reasons. It is clear that the unload and reload are drastically less frequently used than most other code paths in TSM. But we've got DB backups for just such reasons. Your primary risk in this operation is the time you spend doing the unload / reload, finding you've messed it up, and then restoring your previous backup. (which, of course, you performed _just_ before the unload. -RIGHT?- The only additional risk you dare is that something subtle is corrupted, taking you an unacceptable number of days to figure out, so that the last good DB backup is either gone, or unacceptably distant (Redo last weeks' work, anyone?) I will not dismiss this risk: it is finite and should make all our guts churn. But I consider it to be low. More importantly, I consider it to be indistinguishable from the other low-grade subtle corruptions which it is possible to introduce. NT Backup objects, undeletable files, other oddness: we've seen several DB problems come down the pike. But as I said, I'm convinced by Richards' rate-of-decay points, and consequently I'm not planning on unloading and reloading most of my servers. I -am- planning on doing this to two of my servers (actually the Cyrus backup servers to which I alluded earlier in the week) which have seen 100+% turnover in filespaces, and are heading towards being 43GB of database, 25% occupied, maximum reduction 1G. I expect to get back more than 10G of database volumes from each of them, and since the filespaces which were occupying that DB space are gone, I expect to keep that space win. - Allen S. Rout