1

So some of us dev's are starting to take over the management of some of our SQL Server boxes as we upgrade to SQL Server 2008 R2. In the past, we've manually reduced the log file sizes by using

    USE [databaseName] 
    GO 
    DBCC SHRINKFILE('databaseName_log', 1) 
    BACKUP LOG databaseName WITH TRUNCATE_ONLY 
    DBCC SHRINKFILE('databaseName_log', 1)

and I'm sure you all know how the truncate only has been deprecated.

So the solutions that I've found so far are setting the recovery = simple, then shrink, then set it back... however, this one got away from us before we could get there.

Now we've got a full disk, and the mirroring that is going on is stuck in a half-completed, constantly erroring state where we can't alter any databases. We can't even open half of them in object explorer.

So from reading about it, the way around this happening in the future is to have a maintenance plan set up. (whoops. :/ ) but while we can create one, we can't start it with no disk space and SQL Server stuck in its erroring state (event viewer is showing it recording errors about 5 per second... this has been going on since last night.)

Anyone have any experience with this?

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Jon
  • 301
  • 1
  • 5
  • 19

1 Answers1

1

So you've kind of got a perfect storm of bad circumstances here in that you've already reached the point where SQL Server is unable to start. Normally at this point it's necessary to detach a database and move it to free space, but if you're unable to do that you're going to have to start breaking things and rebuilding.

If you have a mirror and a backup that is up to date, you're going to need to blast one unlucky database on the disk to get the instance back online. Once you have enough space, then take emergency measures to break any mirrors necessary to get the log files back to a manageable size and get them shrunk.

The above is very much emergency recovery and you've got to triple check that you have backups, transaction log backups, and logs anywhere you can so you don't lose any data.

Long term to manage the mirror you need to make sure that your mirrors are remaining synchronized, that full and transaction log backups are being taken, and potentially reconfiguring each database on the instance with a maximum file size where the sum of all log files does not exceed the available volume space.

Also, I would double check that your system databases are not on the same volume as your database data and log files. That should help with being able to start the instance when you have a full volume somewhere.

Bear in mind, if you are having to shrink your log files on a regular basis then there's already a problem that needs to be addressed.

Update: If everything is on the C: drive then consider reducing the size of the page file to get enough space to online the instance. Not sure what your setup is here.

David
  • 1,591
  • 1
  • 10
  • 22
  • I don't have enough reputation points to give this the thumbs up, but you were right, thanks. I was worried this was where things were headed, but we did have backups, and once we broke the mirror, we were able to get file sizes reduced adequately... they were set to full backups, which we don't need, so we're working on the maintenance plan now to reduce all that.. Thanks again! – Jon Nov 01 '13 at 17:26
  • @Jon If this answered your question you can mark it as an answer. Just remember that if you're using mirroring you're forced to full recovery and therefore have to take those TLog backups. – David Nov 01 '13 at 17:36