Runaway log files

[Tom Kitta]

Hello,

I am administering a DB which is about 2GB in size and sees few hundred,
maybe up to a few thousand inserts a day plus very few deletions and updates
(less than few hundred). DB has about 200,000 records in it total. For some
time now I have noticed that the transaction logs grow a lot -- like 1GB per
day. I don't know why they are growing so much and would like to find out
why - DB usage that I know of cannot cause such a high growth, to my best
knowledge.

Is there a way to find out what is causing such growth? Can I examine these
logs somehow and see what is in them? I am worried that somehow someone
managed to run mass updates on the DB without my knowledge.

Thanks for help,

Tom Kitta

[Simon Hayes]

"Tom Kitta" <to*@energyshop .com> wrote in message
news:D5******** **********@news 02.bloor.is.net .cable.rogers.c om...

Hello,

I am administering a DB which is about 2GB in size and sees few hundred,
maybe up to a few thousand inserts a day plus very few deletions and updates (less than few hundred). DB has about 200,000 records in it total. For some time now I have noticed that the transaction logs grow a lot -- like 1GB per day. I don't know why they are growing so much and would like to find out
why - DB usage that I know of cannot cause such a high growth, to my best
knowledge.

Is there a way to find out what is causing such growth? Can I examine these logs somehow and see what is in them? I am worried that somehow someone
managed to run mass updates on the DB without my knowledge.

Thanks for help,

Tom Kitta

Do you mean that your log is growing continuously? That may be normal,
depending on your backup strategy - if you're in Full recovery mode, but
never back up the log, for example. If that's the case, you can look at
backing up the log regularly or changing to Simple recovery mode.

If you're doing that already, and you mean that the log grows more over a
day than you expect, then one possibility is to use Profiler to trace the
"Log File Auto Grow" event, and look for other events before it in the trace
output. If there are one or two queries that require lots of log space, you
should be able to identify them.

Simon