Overgrown Log Files

  • Please i need an assistance on how to shrink my log files which has grown so big that it takes about 45 mins for me to copy the log and data files.

    Maximus

    Nigeria

  • Cross Post...

    Please see this post instead:

    http://www.sqlservercentral.com/Forums/Topic511237-357-1.aspx

    "Got no time for the jibba jabba!"
    -B.A. Baracus

  • Ask yourself: What's causing this growth?

    Is it a full recovery database without logbackups, or too less logbackups a day?

    If the database is in simple recovery, monitor the average size of your logfile. If that's equal your current size, it's useless to do a shrink (sooner or later, it will grow to that size)

    Wilfred
    The best things in life are the simple things

  • Why don't you create a SP to autopurge the log, i have a function, and belibeme it's so good not to worring abut the logs after made that.

    I put it in a job, and schelutte every 5 minutes, it's easy, fast and resolve the problem.

    If you want more information you can contactme in this mail: lherrerag20@gmail.com

    :cool:cheers:cool: :Dsee ya:D

  • lherrerag20 (7/2/2008)


    Why don't you create a SP to autopurge the log, i have a function, and belibeme it's so good not to worring abut the logs after made that.

    I put it in a job, and schelutte every 5 minutes, it's easy, fast and resolve the problem.

    If you want more information you can contactme in this mail: lherrerag20@gmail.com

    :cool:cheers:cool: :Dsee ya:D

    I don't think that is a good idea. You should either have the database in simple recovery mode or be running transaction logs backups on a regular basis, like every 15 minutes.

  • [font="Verdana"]Yes I agree with Micheal, regular shrinking of log file will lead to fragmentation. Hence check why the log file is growing hugely through which process. [/font]

  • you must have alot of transactions, try monitoring then and asking people if they can change what they do of if they are processes try changing them to run at times of the day when the server is not so busy , if they are non critical maybe they can be run over night. I would try to get out of the habit of truncating your log to much, as the guys on here said it will cause a lot of problems in the future, try running backups more often to back up the trunc log too. if you are still having problems then you might need to write a trigger to kill jobs and shrink the log, I would not recommend this.

    Regards,

    Terry

  • Monitoring is a good idea, of course. However, asking your end users to modify their practices is akin to extracting milk from granite. If the monitoring yields some deficiencies, then try modifying the business logic in such as way as to not impact the end user, if possible.

    Next, consider that the log files have not grown out of proportion, but have become "right sized". Assuming that regular Transaction Log Backups are being performed, the growth of the Transaction Log should normalize at some point. If the Logs continue to grow, then perhaps more frequent backups of the Transaction Logs is necessary.

    In any case, shrinking the Transaction Logs are not the answer and should be avoided whenever possible. Especially if the Transaction Log file just grows back to the same size in the long run. Ultimately nothing is gained.

    Regards, Irish 

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply