Wanda, you're right - setting the original/default Management Class
retention settings 1 higher/longer resolved the problem. After changing
the settings, the first thing we did was clean up the mess - we emptied
all the unwanted TDP_OFFSITE volumes (those with 0.0 percent full) using move data
vol# DISKPOOL, then migrated the misplaced data to TAPEPOOL where it belonged in the
first place.
- thanks !
Kent Monthei
GlaxoSmithKline
"Prather, Wanda" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
25-Feb-2002 11:45
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: ADSM-L
cc:
Subject: Re: Spontaneous management class rebinding - how to resolve?
You've almost got it - it probably IS a "longest-retention issue".
Andy Raibeck discussed this at length in Oct 2001 (if you want to go back
and search www.adsm.org, search on :
Raibeck Strange Behaviour
Andy said:
...."If two or more management classes have the largest RETONLY setting,
then it is
undocumented as to which class will be selected."
"Undocumented" means, I think, random results. TSM is not smart enough to
prefer the DEFAULT, if the RETONLY settings are the same.
Change your DEFAULT class to be 1 day longer than the others, and I bet
the
problem goes away.
-----Original Message-----
From: Kent Monthei [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 22, 2002 6:52 PM
To: [EMAIL PROTECTED]
Subject: Spontaneous management class rebinding - how to resolve?
We're having a problem with Notes transaction logging on a Notes Domino
server, so turned off Notes transaction logging and planned to perform
full backups directly to a new, collocated off-site tapepool TDP_OFFSITE
defined for this purpose and this one problem node.
We defined a second management class TDPTAPE in the existing policyset,
with a destination of TDP_OFFSITE instead of diskpool. The original
Management Class still points to diskpool and is the Default Management
Class for the domain/policyset.
We then defined a new schedule, associated that 1 client with it and added
the TDPTAPE Management Class binding to the 'include' statements in the
TDP-Domino 'dsm.opt' file.
Everything worked for this client as expected. The full (TDP 'selective')
backup went directly to the new TDP_OFFSITE tapepool.
However, much to our surprise (& I know you experienced ADSM/TSM'ers out
there have heard this before), a whole bunch of other clients also started
mounting scratch tapes for the new TDP_OFFSITE tapepool and dumping small
amounts of data - probably directory info. Almost 30 tapes were written,
most with 0.0 percent utilization. The TSM Server's tape library also
thrashed all night mounting/unmounting/remounting tapes over 30 times
each.
I'm certain that this is due to spontaneous Management Class rebinding. I
just don't know what caused it. I'm aware of the "longest-retention"
issue. However, the verexists/verdeleted/retextra/retonly settings on the
new Management Class's copygroups are identical to the default Management
Class's copygroups, so it shouldn't be rebinding to the new Management
Class for that reason (right??).
What gives?
One more thing - none of the clients have optionsets ('DIRMC' not set).
Doesn't 'DIRMC' default to the Default Management Class, as long as its
copygroups' retention settings aren't exceeded by some other Management
Class's copygroups' settings? Which retention setting triggers MC
rebinding? Does 'DIRMC' need to be set for all those other servers, to
ensure that they backup everything to the default Management Class ?
-rsvp, thanks (experienced help appreciated)
Kent Monthei
GlaxoSmithKline
