Log file very very big

See what transactions that are running making the log file big (sp_who or sp_who2 in query analyzer).  If you don't need point in time recovery, change the database recovery mode to simple or bulk logged.

Brett

albert, the sp_who dont show nothing strange, everything seems to be ok.
and yes,  I need point in time recovery.
I cant be sure right now if this issue come suddenly or it was a more slower process that I dont realize.

Do you have any DTS jobs or import functions that happen on your database?  Any big deletes or inserts?

You can also run Profiler to capture SQL traffic for a while to figure out what's going on.

Brett

Please let me know if you need help maintianing this old open question:

https://www.experts-exchange.com/questions/20729987/About-System-tables-in-MSAccess.html

Thanks,
Anthony

kauf, I have also done the Backup log with truncate_only method and then shrink the database, after that  nothing happen with the t-log. Should I detach the db exactly how you did. I cant think there isnt any other cleanest way.

arbert: I ran a DTS package when I migrated from DBFs data files to SQL server, but it was several month ago and I have never used it again.

EB

Have you configured any replications...or as Arbert has said capture the events in the profiler and check. Also "truncate at check point" option will truncate the log.

rsrsm, "truncate on check point" is a sql server 7.0 option....Doesn't apply to 2000 (bulk logged or simple recovery mode is about the same)....

There is a simple problem with 'truncate at checkpoint' option or bulk logged or simple recovery options if you will.

The problem is a Checkpoint does not occur until the atomic transaction is completed.  In other words, the atomic transaction that is building the log size will not be truncated with this option.  So, it does not matter what you do - your log size is going to grow.

A simple example - Update all rows of a 5 million row table.  It is an implicit transaction and the checkpoint does not occur until this update is completed.  Even if it occurs, the checkpoint is put prior to this transaction and the log is truncated only till that part.

In other words, you don't have choice but to look for the culprit SQL that is filling up the log.

Good luck..
Srini

ok guys I did it, finally my T-Log is now 4MB again, this is what I did:
First I ran BACKUP LOG [DATABASE] WITH TRUNCATE_ONLY option from Query Analizer,
then I made a complete database backup,
then I made a normal backup to the T-Log file within Enterprise Manager (the resulting backup file was 180MB),
and finally I ran the Shrink Database command with "Move page to beginning of file before shrinking" option checked, and this time I have selected only the T-Log file for shrink, in "Shrink file to" I wrote the minimum value suggested for this file.

That was all, I dont know if all that steps are necessary or not, I just write what I did,  but I this issue really stressed me a lot.

Thanks you for your time
EB