log shipping secondary db files out of space issue

  • We manage log shipping implemented before we took over.

    The issues are space and files being placed in different locations between primary and secondary.

    Right now the log shipping is failing on standby server because of space. Turns out that one of the data files is along with the log file on the secondary on same drive. This drive is out of space and log shipping is out of sync with following message.

    *** Error: Could not apply log backup file ‘...trn’ to secondary database (Microsoft.SqlServer.Management.LogShipping) ***

    *** Error: There is insufficient free space on disk volume 'E:\' to create the database. The database requires ‘x’ additional free bytes, while only ‘y’ bytes are available.

    Problems were identified while planning for the RESTORE statement. Previous messages provide details.

    RESTORE LOG is terminating abnormally.

    Is it better to stop log shipping?

  • Low space issue is always a problem. Better re-configure the log shipping by moving files on diff drive/mount points with sufficient space.

    thanks

    santhu

  • it's probably easier to stop the log shipping and remove the secondary database. Sort out the disk space and file locations and then re initialise the secondary database

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • I agree with Perry Whittle, this issue is likely to happen again and again if you try and fudge it.

    Short term fix is to get the database moved (or possibly some of the not so critical databases - if there are any) to more storage and LS reinitialised.

    Longer term, try and get some growth trends of the databases to establish how much space you'll need in say 1mth, 3mth or 6mths time and plan your disk storage around that. Once you've got that you can get a better understanding of what your requirements are going forward and even set up some monitoring on your prod DBs to indicate when you're at a particular threshold. If you don't, i can guarantee you'll hit the same issue again sometime in the near future 😉

    _________________________________________________________________________________SQLGeordieWeb:- Jarrin ConsultancyBlog:- www.chrisjarrintaylor.co.ukTwitter:- @SQLGeordie

  • Following Perry's advice should solve your problem, the question is do you know how to set the location for the files?

Viewing 5 posts - 1 through 4 (of 4 total)

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