The default management class for directories is based on the directory with
the highest RETONLY setting. If multiple management classes have the same
highest RETONLY setting, then the management class whose name appears last
in ascending sort order will be used. For example, if you have two
management classes that each have the same highest RETONLY setting,
MCDISK1, MCDISK2, MCTAPE, and MCVTL, then MCVTL is the default management
class for directories.

For database applications such as this (where no TSM API application is
available), there are a couple of ways to go:

1. Use the application's native backup facility to back the database up to
a flat file, after which TSM can back up the flat file. Of course, this
assumes the application has such a capability.

2. Use TSM client Open File Support (OFS) via the SNAPSHOTPROVIDERFS VSS
option. This will give you a "crash-consistent" snapshot of the files that
make up the database.

2a. Even better, in addition to OFS, use the TSM client options
PRESNAPSHOTCMD and POSTSNAPSHOTCMD. Set up PRESNAPSHOTCMD to stop the
application while the volume snapshot is taking place. Set up
POSTSNAPSHOTCMD to restart the application after the snapshot is taken.
While this does require the application be stopped, it is only for a few
seconds (however long it takes for the VSS snapshot to occur). The database
files (actually all the files) will then be backed up through the snapshot,
so you have a consistent copy of the files. Be sure to test restore.

Best regards,

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Internal Notes e-mail: Andrew Raibeck/Hartford/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

IBM Tivoli Storage Manager support web page:
http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager

"ADSM: Dist Stor Manager" <ADSM-L AT vm.marist DOT edu> wrote on 2012-10-19
12:36:32:

> From: Thomas Denier <Thomas.Denier AT JEFFERSONHOSPITAL DOT ORG>
> To: ADSM-L AT vm.marist DOT edu,
> Date: 2012-10-19 12:38
> Subject: Re: Odd client behavior
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT vm.marist DOT edu>
>
> Thank you very much; that turned out to be exactly what happened.
> One of our client systems has an application built around a
> database made up of ten files. Some of the files change on any
> day when the application is used, and some change much less
> frequently. The database has had chronic problems with both
> integrity and recoverability. The application vendor insists
> that the recoverability problems occurred because different
> database files were backed up on different days. My management
> is well aware that this is nonsense, but felt that it was
> necessary to back up all ten database files every day to
> pressure the vendor into addressing the real issues. I set
> up a new management class with 'mode=absolute' in the backup
> copy group. The new class was tied with our existing default
> management class for longest retention period. The TSM
> documentation does not specify how ties are resolved when
> selecting a management class for directories. At least some of
> our client systems used the new management class for their
> directories.
>
> Best regards,
> Thomas Denier
>
> -----Steven Harris wrote: -----
>
> >A distant possibility is that the tree being backed up has a
> >different
> >management Class and that has had its copymode set to absolute.
>
> >>> -----Original Message-----
> >>> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> >Behalf
> >>> Of Thomas Denier
> >>>
> >>> We recently noticed an unexpectedly rapid increase in database
> >space
> >>> usage on one of our TSM servers. This seems to be the result of
> >two
> >>> Windows clients that are consistently backing up hundreds of
> >>> thousands of files every night. We checked our other two TSM
> >servers
> >>> and found two more Windows clients behaving this way.
> >>>
> >>> In all four cases the behavior started during the same backup
> >>> window:
> >>> late October 9 and early October 10.
> >>>
> >>> All four systems are in the same Windows domain. The domain
> >>> administrator does not recall any noteworthy updates on October
> >9.
> >>>
> >>> One of the Windows administrators involved looked at dsmsched.log
> >and
> >>> reported that the backups include large numbers of files that
> >have
> >>> not been updated or even accessed recently.
> >>>
> >>> The four Windows clients have, among them, three Windows levels
> >(XP,
> >>> 2003, and 2008), two TSM client levels (5.3 and 6.2), and three
> >>> groups of people responsible for system administration.
> >>>
> >>> The three TSM servers involved include one 5.5 server and two 6.2
> >>> servers. All run under zSeries Linux.
> >>>
> >>> I would appreciate any suggestions regarding possible causes for
> >this
> >>> behavior.