🚀 go-pugleaf

- - - - - - - - - - -  included message - - - - - - - - - - -
From: emilchan @ ASIAONLINE.NET (Emil Chan) @ internet

Following is the Properties List of my database BLBDATA.  No matter how hard
we tried, the Log Space Used is still as big as 270Mb!  I did try using Dump
Database, Dump Transaction with truncate and with no_log but still does not
help.  The Log used to store together with the data segment master, I tried
to altered it to the new device LogDev but doesn't help neither.

Could anybody help?
- - - - - - - - - - - - end included message - - - - - - - -- -

This has happened to us a number of times. In one instance, no matter what we
did,
we could not get the transaction log to dump.  It was still not at the critical
point, but
as large as 55% and we wanted to dump for the sake of safety.  At first we ran
DBCC
CHECKDB, no go.  Then we had to stop and restart the SQL Server.  The
transaction
log lost about 5%.  When we ran DBCC CHECKDB the second time it finally cleared.
This was the most extreme case we had.  Another time DBCC CHECKDB fixed it and
once just stopping and starting the SQL Server did it.

If it happens again, we will be trying to take more time to find out "why" it
happened,
instead of fixing the problem ASAP (not always possible though).  The clue I
have so
far is from pg. 108 in the SQL Server Troubleshooting Guide -- "In some
instances, a
single long running transaction can prevent the log from being purged.".  The
solution
is usually to kill the runaway process.

**  Has this happened to anyone else (runaway process preventing the log from
being
dumped?)

**  Has anyone found other reason why the log might be prevented from being
dumped?
     What were they?