Jerry wrote, in part..
> I have a customer who has a large number of small files on a server, and is
> seeing long processing times. He is running the SIEBEL Help desk
> applications, and ultimately will have 1.5 million files on the server. The
> test he ran included about 600K files, totaling 5GB of space. Obviously,
> the individual files are not very big (he says 12K is typical. They are
> already compressed, so we have compression turned off for this client.
Areas of investigation might include ...
1. Consider turning subfile/adaptive differencing off, if on.
2. Consider adjusting tuning parameters as they relate to the
operating system and *SM DB. For example, maximize TCP settings
and set transaction/groups sizes very large. Lots of good
discussions in the archives of ADSM-L on this subject.
3. Consider doing some partial incrementals. For example, maybe the
restore requirements will allow incremental-by-date during the
week and then a full-incremental on weekends. *SM manuals discuss
this well (see the "Using" online manual that comes with the
client software).
4. Ensure changing files are not causing "retries". Evaluate restore
requirements to minimize or eliminate these backup "retries". If
you were compressing with *SM, I'd say eliminate it or
CompressAlways.
5. If the application allows, restructure the data so that no single
directory holds a large number of files and the directory
structure is relatively fixed.
I have no more than anecdotal evidence that any of these points will
help, ... but maybe one will :-)
cheers, wayne
Wayne T. Smith [EMAIL PROTECTED]
ADSM Technical Coordinator - UNET University of Maine System