April 20, 2013 at 9:45 am
Good afternoon
I've recently discovered that there's a database attached to my SQL 2005 catalog that isn't being backed up, which means that it also isn't being shrunk down.
Although the MDF file is less than 55Mb, the LDF file is currently sitting at a massive 397GB (no, that's not a typo).
Now, before anyone points out the obvious, I know that this represents a monumental error in judgement when organising my maintenance plans, but that's what I'm in the process of trying to rectify.
Obviously, I want to backup and shrink this database to try and return as much of the used space as possible to the operating system. The problem I have is that the volume containing this fat boy is showing only 193Gb of free space and I'm concerned that the initial backup could try to create a file at least that big - this volume contains my databases so I can't have it running out of space. The only other volume I have to play with on that server is showing even less space available (122Gb), so I'm at a loss what to do.
Because this is an active database, I'm also rather loathe to run a maintenance schedule on it during working hours, so I need to be confident thatever I set to run in the small hours won't gobble up the remaining drive space and cause the server to start generating errors. The box is business critical (call-centre CTI system) so I can't risk any unscheduled downtime.
TIA
April 20, 2013 at 11:48 am
If you can change the recovery mode to simple for a maintain purpose, you can try this:
- recovery mode to simple
- full db backup
- shirink log to proper size
- recovery mode back to full/bulk logged
- configure log and db backups and perform first full db backup (to start new log chain)
April 20, 2013 at 12:50 pm
Please read through this - Managing Transaction Logs[/url]
Once you get log backups running again you can do a once-off shrink of the log to get it back to a reasonable size. If there's no where on the local drives to write that first log backup you can write it to a network location or USB drive or, if recovering prior to current time is not required, switch to simple recovery and then back to full, take a full backup, shrink the log file then restart the log backups.
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
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply