Here's a quick and dirty suggestion:
While the backup appears to be noodling around doing nothing during the
compare, enter the command "Q SESSION F=D".
If the server shows the session in RUN state, you are probably waiting on
the server.
If the server shows the session in IDLEW state, the server is probably
waiting on the client noodling around in it's own filesystem. If your
server is a fairly spiffy machine, I'll bet you find the time is being spent
on the client end.
The only way to be sure, as Richard mentioned, is to run a client trace.
This thread started way back, I forget what type of client this is. But if
it's Windows, I would for sure run DISKCLEAN on the filesystem. I have seen
this type of behavior many times where on client machines, the client code
is truly just taking ages noodling around the file system looking for stuff
to back up, either because the file structure is atrocious, or the client
machine doesn't have much umph, or the disk has some dirty/damaged areas and
a lot of retry goes on.
-----Original Message-----
From: Richard Sims [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 14, 2001 3:34 PM
To: [EMAIL PROTECTED]
Subject: Re: Performance Large Files vs. Small Files
...
>We are trying to complete an incremental backup an NT Server with about 3
>million small objects (according to TSM) in many, many folders and it can't
>even get done in 12 hours.
To the excellent responses already posted regarding the TSM db being in the
middle of the operations, I could only add that you should inspect how the
server is handling the task, and what else may be running in the server at
the
same time. If backing up to a initial disk storage pool, migration from it
may be impeding your backups. And there may be contention for tape drives
or
volumes, mount transition times, and like factors at play. Using client
compression can slow you down. Plowing through a file system itself takes
time. This is the "fun" of systems analysis that we all have to engage in
from time to time. :-)
Richard Sims, BU
