Strangely, although we keep everything in FULL recovery mode and do transaction dumps every few hours, differentials every night, and fulls twice a week, we have some databases (always 3rd party, never our own) whose logfiles simply grow and grow. I end up finding a 100 MB db with a 10 GB log file - and its 99% empty.

My theory - and that's all it is - is that those vendors are creating the problems themselves.

Many a third party vendor has proven they don't know much about the difference between a database and a sequential file, and they often wrap huge amounts of things in transactions that are NOT; or rebuild huge tables from scratch instead of just updating.

There often is no practical way (certainly no reliable scripted way) to clear out the space when the usual cycle of dumps doesn't accomplish it, not without taking the database down. It's a real waste of time and money.

Even though I've always believed "never ever use auto-shrink", I'm reconsidering for those troubled dbs. After all, these are 64-bit 64GB 8-way servers with multipath, non-front bus IO. And that auto-shrink rule I've known since the days of the /3GB switch...

Like I say - never see it in anything we build ourselves, nor on Sybase.

Roger Reid