I think that changing recovery model to "Simple" still does not prevent the growth of the transaction log (if this is what you are trying to avoid).

David,

We run INDEXDEFRAG daily ... is it not sufficient?

Thanks a lot!

I will do as suggested.

In the meantime, I ran the following command on both servers: DBCC SQLPERF (WAITSTATS).

The numbers are drastically different, with the new/problematic server consistently having much greater...

Steve,

We perform INDEXDEFRAG daily on both servers - wouldn't that be enough ... or should I still rebuild all the indexes?

Thanks a lot

Did you enable the job and the schedule?

Did you refresh after changes were made?

Guys,

I believe RAID level is the same or better on the new server.  The new MSSQL 2000 server was created by restoring a back up of the old server.  As...

Transactional.

The tables we are purging are replicated.  As such I don't think I can just drop them - replication will fail.

Great advices though...

Thanks for the suggestions!

Ken,

More clear details are below:

Production Sever

****************

a. Table to store the errors

b. A stored procedure to insert into the error table

c. An alert, which will execute the stored procedure, which will...

Thanks for the info guys!

Schleep,

1. Our DB is 9GB, but the transaction log file was 25GB before I shrank it.  By defragmentation I meant the execution of the following: "DBCC INDEXDEFRAG".  We use it instead...

Thanks ... although I just learned/realized that since msdb and master system dbs follow the simple recovery model, I cannot back-up their transaction log file even if I wanted to...

Guys,

Thanks for all the replies.

I actually have the mail working on my local server, to which all the other production servers are linked.

My latest approach is to just create a...

Thanks Ed.  I actually learned more about it and here is the summary:

For a database following a simple recovery model the transaction log CAN physically grow - and although it...