TSM does not "lock" files per se; however, it does open the files to read
them during backup. It could be that SQL server requires exclusive access
to the file, so if TSM is currently backing it up, SQL server cannot
start.

This sounds like a potential candidate for OFS. You can use the
PRESNAPSHOTCMD and POSTSNAPSHOTCMD options to control shutdown and restart
of applications (such as SQL Server). In this case, I recommend using
5.4.2.0 or 5.5.0.6 (or the forthcoming 5.5.1 at the end of this month).
Note that in 5.5, you also have the option of using VSS as the snapshot
provider.

Regards,

Andy

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

IBM Tivoli Storage Manager support web page:
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 06/17/2008
09:47:09 AM:

> Quoting Richard Sims <rbs AT BU DOT EDU>:
> > David -
> >
> > I concur - I've never seen the TSM client lock files for backup, nor
> > seen any documentation suggesting that it does.
> >
> > I perceive that the DBA made the claim without providing you with any
> > evidence.  Have them provide you with evidence from any tool they used
> > to detect such a condition.  More to the point, the SQL Server error
> > log should have detailed info on why it flagged the database as
> > Suspect - which can have many causes.
>
> Hi Richard,
> You're right, the DBA claim that without evidence, neither filemon
> or other monitoring tool. Thanks to pointing to detailed sqlserver
> log, I'll see it with DBA.
>
> > The larger issue is why TSM physical backup should apparently be
> > running at the same time as the SQL Server.  That would constitute a
> > "fuzzy backup", which would probably not result in a consistent,
> > usable object if restored.  Generally speaking, to use physical (i.e.,
> > TSM B/A client) backup tools on a database, the database server needs
> > to be down.  If striving to keep SQL Server up during backups, the TDP
> > would be the way to go.
> >
> >    Richard Sims
>
> Unfortunely, I'm ok with you about all of that...
> We use TDP for many databases, but the DBA team don't want TDP for this
one.
> They want SQL Server up at a fixed time in the morning. The DBA stop the
> server before backup and restart it at fixed time, backup finished or
not...
> I've spent many hours in meeting about that but the DBA don't want
change
> the configuration.
>
> Cheers
> David