Shrinking the transaction log of a mirrored SQL Server 2005 database

StackOverflow https://stackoverflow.com/questions/1033158

Question

I've been looking all over the internet and I can't find an acceptable solution to my problem, I'm wondering if there even is a solution without a compromise...

I'm not a DBA, but I'm a one man team working on a huge web site with no extra funding for extra bodies, so I'm doing the best I can.

Our backup plan sucks, and I'm having a really hard time improving it. Currently, there are two servers running SQL Server 2005. I have a mirrored database (no witness) that seems to be working well. I do a full backup at noon and at midnight. These get backed up to tape by our service provider nightly, and I burn the backup files to dvd weekly to keep old records on hand. Eventually I'd like to switch to log shipping, since mirroring seems kinda pointless without a witness server.

The issue is that the transaction log is growing non-stop. From the research I've done, it seems that I can't truncate a log file of a mirrored database. So how do I stop the file from growing!?

Based on this web page, I tried this:

USE dbname
GO
CHECKPOINT
GO
BACKUP LOG dbname TO DISK='NULL' WITH NOFORMAT, INIT, NAME = N'dbnameLog Backup', SKIP, NOREWIND, NOUNLOAD
GO
DBCC SHRINKFILE('dbname_Log', 2048)
GO

But that didn't work. Everything else I've found says I need to disable the mirror before running the backup log command in order for it to work.

My Question (TL;DR)

How can I shrink my transaction log file without disabling the mirror?

Was it helpful?

Solution 3

I thought I should actually answer this seeing as it was left forgotten about.

Turns out, you can't shrink a t-log if the database is mirrored unless you deactivate the mirror. If I'm wrong, please correct me, but I've found no solution that works!

Log shipping is the way to go if you only have two servers. Mirroring is almost pointless without a witness server, because the only way to failover is from the principal... kinda defeats the purpose of having a mirror if you can't failover when the principal crashes.

If anyone cares to share more info or suggestions on this matter, I will be welcome to hear them.

OTHER TIPS

Well, technically it is possible to shrink a mirrored LOG. What is doing trouble is to backup log with truncate_only. Mirroring doesn't accept it. So one way is to perform a backup log to disk:

use [DATABASE_NAME]
checkpoint
BACKUP LOG [DATABASE_NAME] TO DISK =  'C:\LOG_BACKUPS\DATABASE_NAME'
dbcc shrinkfile(DATABASE_NAME_Log,1)

This is part of our current maintenance plan and it has been working withot problems for about 2 years.

If the mirror server instance falls behind the principal server instance, the amount of active log space will grow. In this case, you may need to stop database mirroring, take a log backup that truncates the log, apply that log backup to the mirror database and restart mirroring, not the answer you were hoping for, I know =(

To shrink our files you could try the following script:

exec sp_dboption DBName, 'trunc. log on chkpt.', true checkpoint DBCC SHRINKFILE (DBNameFileName, 500); exec sp_dboption DBName, 'trunc. log on chkpt.', false

Hope this helps.

It's possible to shrink transaction file for a database with mirror, backup must be performed as there are actives Virtual Log File : http://www.xoowiki.com/Article/SQL-Server/tronquer-journal-de-log-sur-base-en-miroir-499.aspx

  1. Set mirror partner off by using .. ALTER [DatabaseName] SET PARTNER OFF
  2. Take Transaction Log backup on principal..BACKUP LOG [DatabaseName] TO DISK='Drive:\DatabaseName_log_datetime.trn'
  3. Copy this DatabaseName_log_datetime.trn to any location on Mirror Server.
  4. Restore this Transactional log with NoRecovery option..on mirror database. RESTORE LOG [DatabaseName] FROM DISK ='Drive:\DatabaseName_log_datetime.trn'
  5. Shrink log file on principal & mirror server.
  6. Again Take Transaction Log backup on principal..and Restore this Transactional log with No Recovery option..on mirrored database on mirror server.
  7. Configure Mirroring Security.

Tested some suggestions in this post, I found that, after full backup, checkpoint command, and transaction log backup, the principal database transaction log size can be shrinked. The mirror database transaction log size is then synchronized with principal shrinked size.

USE [DATABASE_NAME];
BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_FULL.bak' WITH FORMAT;
CHECKPOINT;
WAITFOR DELAY '00:00:02';
BACKUP LOG [DATABASE_NAME] TO DISK = 'E:\Backup\DATABASE_NAME_TL.trn';
WAITFOR DELAY '00:00:02';
DBCC SHRINKFILE('DATABASE_NAME_log', 500);

Use OSQL can run the above SQL commands in DOS batch, the WAITFOR DELAY is a must if run in batch, e.g.

C:\Program Files\Microsoft SQL Server\100\Tools\Binn\osql.exe -E -S "DATABASE_SERVER" -Q "USE [DATABASE_NAME]; BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_FULL.bak' WITH FORMAT;"

I think the different backup should be worked too, but doesn't test. The below diff backup command will append the data instead of overwrite.

BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_DIFF.bak' WITH DIFFERENTIAL;

the only way: 1) Stop mirroring 2) shrink files on principal 3) backup complete of principal, + transaction jrnl 4) stop mirror server, delete mdf and ldf of mirrorDatabase 5) start mirrorser and delete mirrorDatabase 6) restore with no recovery backups of 3) on mirroServer 7) reinstall mirroring Ouf !

It's true that you can't shrink the database log once it's got too big - at that point I think your only option is to break the mirror, shrink and re-create. Further, notwithstanding the issues of whether you ought to be using mirroring with just two servers, what I can say is that if you do then regularly backup the transaction log. The space will be released from it thereby allowing MSSQL to re-use the dead space within the log file. This doesn't shrink anything but it does meet the requirement of stopping it growing.

Then all you need to do is regularly delete the file backups. For example you could do this:

USE your_database
GO
BACKUP LOG your_database TO DISK = 'x:\your_backup_filepath\your_database.tlog'
GO

Do it out of hours though if you can.

I don't know why this works, only that it does indeed work. I run this as a block in a query window. Use at your own discretion. Sure would be nice if a microsoftie would comment.

use my_database
dbcc shrinkfile ( my_database_log, 1000 )
use my_database
dbcc shrinkfile ( my_database_log, 1000 )
alter database my_database
  modify file ( 
    name = my_database_log, 
    size = 1000MB
  )

You can't really do anything to a mirrored database without taking it out of the mirror, as long as it's not the principal database.

What should work is if you backup your databases on the principal server og do a shrink afterwards. Ie your maintenance plan should include som shrinking job. Those changes should get over to the secondary (mirror) server automatically by synchronizing.

If you want to make a shrink that only shrinks the transaction file you can use the following T-SQL:

USE [your_db_name]
GO
DBCC SHRINKFILE (N'your_db_name_logfile' , 0, TRUNCATEONLY)
GO

Then you just use that snippet for each database and run it right after your backup has run.

That should keep the log file small on the principal server and thereby on the secondary/mirror server.

I hope this helps.

Btw. If you've gotten to the point where there is no room left on the disk for log files, the only option is to take it out of mirror mode, set the database to simple recovery mode, shrink the log file, set it to full recovery mode again and setup the mirror again (using backups of the database og log file to restore on the mirror server).

Futhermore you can use an SQL Express as a witness server, if the issue is licensing. It shouldn't require too many ressources, so you could use a webserver, if this is a web application. Just remember to watch the log files for the witness server too.

** shrinking can be done in mirroring, what we cannot do is truncate the log, as the log is what is shipped to the mirror server and then the principal awaits the acknowledgement.

A solution to the issue is to backup the log with no truncate and then shrink the log file, or you can even ignore the shrinking. If that does not work, try a checkpoint before backing up your log. This should work...

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top