Post reply

Clearing LOD file (126 GB)

  • August 21, 2008 at 2:31 am

    #192658

    Dear All,

    One of our client's server is in Germany. We have made a project for them recently. It got crashed today.When I checked I found that MDF size is hardly 256MB and LDF is 126GB (huuuge)...

    How can I clear the LOG..? Wot are the things need to be done before clearing LOG...? Please guide me..Very urgent..

    Thanks in advance...

    Dear freind Marsh -- I expect an ealry reply from you especialy...

    Santhos Nahir (India)

  • August 21, 2008 at 2:47 am

    #861084

    hello

    first dbcc loginfo and check status column may be 0 or 2 ,if 0 you can

    backup log dn_name with truncate _only

    go

    dbcc shrinkfile(log_file_id or file_name,size you want to shrink)

    go

  • August 21, 2008 at 2:54 am

    #861087

    And after you follow Hadrian's advice, take a full backup. Then find out if that database had any periodic full/log backups. If yes, try to find the reason for the large transaction log. If no, then set up periodic database and log backups (or if the recovery requirements permit it set it to simple recovery mode)

    Regards,

    Andras

    Andras Belokosztolszki, MCPD, PhD
    GoldenGate Software

  • August 21, 2008 at 3:04 am

    #861089

    Thanks a lot. will try the same...

  • August 21, 2008 at 3:08 am

    #861090

    Hello,

    The problem is that SSMS itself is not opening....Without query analyzer how will I fire the command..?

  • August 21, 2008 at 3:21 am

    #861093

    nairsanthu1977 (8/21/2008)

    Hello,

    The problem is that SSMS itself is not opening....Without query analyzer how will I fire the command..?

    You can use sqlcmd from command line for example. Or run SSMS on a remote computer.

    Regards,

    Andras

    Andras Belokosztolszki, MCPD, PhD
    GoldenGate Software

  • August 21, 2008 at 3:59 am

    #861100

    Some background info on what's happened - http://sqlinthewild.co.za/index.php/2008/07/23/recovery-model-and-transaction-logs/

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

  • August 21, 2008 at 6:50 pm

    #861624

    1 -stay calm.

    2 - what is your database's recovery model? If it's simple, see 3). For full and bulk-logged, see 4).

    3 - two possibilities

    3a. you have an old transaction that's still active, that's preventing the log from being truncated, causing indefinite growth. Use DBCC OPENTRAN to determine if this is the case. Take steps to end that transaction (commit, rollback, kill etc). Then use DBCC SHRINKFILE to shrink the log file. May need to do it a couple of times, see here for reasons.

    3b. there were large transactions that caused the transaction log to grow to such a huge size. If this is going to be common, shrinking the file may not be a good option. If not, run DBCC SHRINKFILE to shrink the log.

    4. see 3a) and 3b) for possible reasons (but not the suggested resolutions), also

    4a. you have not been backing up your transaction log, hence causing the transaction log to grow indefinitely.

    Do you need to make a backup of the current transaction log, perhaps for log shipping purposes, or to be able to perform a point-in-time recovery (note that this would still be impossible if there are minimally logged transactions in the current transaction log)? If yes, you'll need to back it up to disk. Run a BACKUP LOG ... command, folowed by DBCC SHRINKFILE.

    If not (and you're very sure of this), run a BACKUP LOG with the TRUNCATE_ONLY option, then follow the suggestions by Hadrian and Andras, especially the part on performing a full database backup.

    SQL BAK Explorer - read SQL Server backup file details without SQL Server.
    Supports backup files created with SQL Server 2005 up to SQL Server 2017.

  • August 22, 2008 at 3:01 am

    #861711

    your log size is in GB while Data file size is in MB, it seems you are not taking backup of log.

    if log backup is not necessry for you then use command TRUNATE_ONLY and truncate the log.

    hope this will work.

    Manoj

  • August 25, 2008 at 7:01 am

    #862493

    Just curious, not criticizing at all but...

    Wouldn't a question like this be best suited for the administration forum?

    I'm seeing a lot of these types of questions being posted in the performance forum.

    I know we're all trying to help... Guess its just me being the picky "classification" type of anal retentive DBA again... 😀

  • February 21, 2010 at 8:54 am

    #1122503

    Thanks.

  • February 22, 2010 at 9:11 am

    #1123038

    Boy, if I had a nickel for every time I have seen this problem posted in a forum!! :w00t:

    Best,
    Kevin G. Boles
    SQL Server Consultant
    SQL MVP 2007-2012
    TheSQLGuru on googles mail service

  • February 22, 2010 at 10:15 am

    #1123108

    TheSQLGuru (2/22/2010)

    Boy, if I had a nickel for every time I have seen this problem posted in a forum!! :w00t:

    Your trousers would be terribly uncomfortable and weigh about a ton?

  • February 22, 2010 at 10:21 am

    #1123115

    Andrew Gothard-467944 (2/22/2010)

    TheSQLGuru (2/22/2010)

    Boy, if I had a nickel for every time I have seen this problem posted in a forum!! :w00t:

    Your trousers would be terribly uncomfortable and weigh about a ton?

    But my bank account would be large enough to by a small island . . . say Hawaii!! 😎

    Best,
    Kevin G. Boles
    SQL Server Consultant
    SQL MVP 2007-2012
    TheSQLGuru on googles mail service

  • February 23, 2010 at 9:03 am

    #1123670

    The more things change, the more things stay the same !

    RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."

Viewing 15 posts - 1 through 14 (of 14 total)

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