March 15, 2013 at 2:17 pm
Hi All,
I have a database which is mirrored and the log grew to about 50GB due to log backup being failed, so the steps I am doing now is taking a full and log backup manually just to be safe.
My question is this:
Would I be able to shrink the log file after taking log backup? or it won't let you shrink since mirroring in place?
In order to fix this issue, do I need to break the mirroring and reconfigure from scratch? Please advise.
Thanks,
SueTons.
Regards,
SQLisAwe5oMe.
March 15, 2013 at 2:27 pm
I personally never tried shrinking the log of a mirrored database. If you can, perhaps you could set this up on a test server and see what happens.
I'd be interested in knowing.
March 15, 2013 at 2:53 pm
Lynn Pettis (3/15/2013)
I personally never tried shrinking the log of a mirrored database. If you can, perhaps you could set this up on a test server and see what happens.I'd be interested in knowing.
After taking full and log backup, I see 99% free space on log file, but when I try to shink it, it's not working. I thought it should truncate the inactive logs after logbackup\shrink are done. I am not sure since mirroring is in place, it might not allowing this? Your thought.
SueTons.
Regards,
SQLisAwe5oMe.
March 15, 2013 at 2:55 pm
SQLCrazyCertified (3/15/2013)
I thought it should truncate the inactive logs after logbackup\shrink are done.
Just like any other database in full recovery, the logs are truncated (marked as reusable) when a log backup is run. Truncating doesn't mean shrinking. If you want to do a once-off shrink of the principal's log, you can use DBCC ShrinkFile, as normal.
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
March 15, 2013 at 2:56 pm
When you say not working, not really sure what you mean. Is it just not doing it or are you getting an error message?
March 15, 2013 at 2:58 pm
Also, you may have to take one or two more t-log backups. If it isn't shrinking, it could be that the active log is at the end of the log file.
March 15, 2013 at 3:18 pm
GilaMonster (3/15/2013)
SQLCrazyCertified (3/15/2013)
I thought it should truncate the inactive logs after logbackup\shrink are done.Just like any other database in full recovery, the logs are truncated (marked as reusable) when a log backup is run. Truncating doesn't mean shrinking. If you want to do a once-off shrink of the principal's log, you can use DBCC ShrinkFile, as normal.
Yes, I was doing DBCC Shrinkfile, and I did couple of log backups before I saw the free space....however, when I run DBCC Shrinkfile, it was running without any errors, but nothing is happening.
So, is there is any known factor with SQL server 2005 with mirroring, the shrink won't work?
SueTons.
Regards,
SQLisAwe5oMe.
March 15, 2013 at 3:21 pm
If the (or an) active VLF is at the end of the log file, the file will not shrink. All I can suggest is keep trying after each log backup.
March 15, 2013 at 3:58 pm
Lynn Pettis (3/15/2013)
If the (or an) active VLF is at the end of the log file, the file will not shrink. All I can suggest is keep trying after each log backup.
Cannot shrink log file 2 (DatabaseName_Log) because all logical log files are in use.
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
What exactly this means?
SueTons.
Regards,
SQLisAwe5oMe.
March 15, 2013 at 4:01 pm
Exactly what it says, all logical log files are in use, so there are no empty ones. No empty VLFs = no shrink.
Check log_reuse_wait_desc in sys.databases for why the log is not being reused.
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
March 15, 2013 at 4:04 pm
If I interpret it correctly, looks like all of the VLFs in the log file have open transactions. Until all the transactions are committed or rolled back, SQL Server can't mark them as reuseable.
Hopefully Gail or someone with more intimate knowldge of the log files can shed more light.
March 15, 2013 at 4:05 pm
Speaking of Gail, looks like I did interpret it correctly.
March 15, 2013 at 4:09 pm
Lynn Pettis (3/15/2013)
If I interpret it correctly, looks like all of the VLFs in the log file have open transactions. Until all the transactions are committed or rolled back, SQL Server can't mark them as reuseable.
Not necessarily open transactions. Something that's preventing log truncation. Could be:
Open transaction
No log backup
Mirroring
Replication
CDC
Active backup
Checkpoint
or a couple other less common ones
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
March 15, 2013 at 4:14 pm
GilaMonster (3/15/2013)
Lynn Pettis (3/15/2013)
If I interpret it correctly, looks like all of the VLFs in the log file have open transactions. Until all the transactions are committed or rolled back, SQL Server can't mark them as reuseable.Not necessarily open transactions. Something that's preventing log truncation. Could be:
Open transaction
No log backup
Mirroring
Replication
CDC
Active backup
Checkpoint
or a couple other less common ones
Okay, okay, my internal voice was saying that, I just didn't say it that way in my post. I am officially chastised on this event. I will endeavour to be more specific and concise in the future. I was right, though, that you would come along and provide guidance.
March 15, 2013 at 4:41 pm
GilaMonster (3/15/2013)
Exactly what it says, all logical log files are in use, so there are no empty ones. No empty VLFs = no shrink.Check log_reuse_wait_desc in sys.databases for why the log is not being reused.
Ok....got it, finally it allowed me to shrink, I gues a lot of activities were happening behind. Anyway, thanks for all of your input.
Regards,
SueTons.
Regards,
SQLisAwe5oMe.
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply