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.
我不是一名DBA,但我是一个单人团队,在一个巨大的网站上工作,没有多余的额外资金,所以我尽我所能。
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.
我们的备份计划很糟糕,而且我很难改进它。目前,有两台运行SQL Server 2005的服务器。我有一个镜像数据库(没有见证)似乎运行良好。我在中午和午夜做了一个完整的备份。这些由我们的服务提供商每晚备份到磁带,我每周将备份文件刻录到DVD以保留旧记录。最终我想切换到日志传送,因为没有见证服务器,镜像似乎有点无意义。
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?
如何在不禁用镜像的情况下缩小事务日志文件?
11 个解决方案
#1
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:
嗯,从技术上讲,可以缩小镜像LOG。出现问题的是使用truncate_only备份日志。镜像不接受它。所以一种方法是执行磁盘备份日志:
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.
这是我们当前维护计划的一部分,它已经解决了大约2年的问题。
#2
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
exec sp_dboption DBName,'trunc。登录chkpt。',true checkpoint DBCC SHRINKFILE(DBNameFileName,500); exec sp_dboption DBName,'trunc。登录chkpt。',false
Hope this helps.
希望这可以帮助。
#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!
事实证明,如果镜像数据库,则无法收缩t-log,除非停用镜像。如果我错了,请纠正我,但我找不到有效的解决方案!
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.
如果有人愿意就此事分享更多信息或建议,欢迎聆听。
#4
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
可以使用镜像缩小数据库的事务文件,必须执行备份,因为存在活动虚拟日志文件:http://www.xoowiki.com/Article/SQL-Server/tronquer-journal-de-log-sur-基烯之镜 - 499.aspx
#5
- Set mirror partner off by using ..
ALTER [DatabaseName] SET PARTNER OFF - Take Transaction Log backup on principal..
BACKUP LOG [DatabaseName] TO DISK='Drive:\DatabaseName_log_datetime.trn' - Copy this
DatabaseName_log_datetime.trnto any location on Mirror Server. - Restore this Transactional log with
NoRecoveryoption..on mirror database.RESTORE LOG [DatabaseName] FROM DISK ='Drive:\DatabaseName_log_datetime.trn' - Shrink log file on principal & mirror server.
- Again Take Transaction Log backup on principal..and Restore this Transactional log with No Recovery option..on mirrored database on mirror server.
- Configure Mirroring Security.
使用.. ALTER [DatabaseName] SET PARTNER OFF关闭镜像伙伴
在principal上进行事务日志备份.BACKUP LOG [DatabaseName] TO DISK ='Drive:\ DatabaseName_log_datetime.trn'
将此DatabaseName_log_datetime.trn复制到Mirror Server上的任何位置。
使用NoRecovery option..on镜像数据库恢复此事务日志。 RESTORE LOG [DatabaseName] FROM DISK ='Drive:\ DatabaseName_log_datetime.trn'
收缩主服务器和镜像服务器上的日志文件。
再次在Principal上执行事务日志备份,并在镜像服务器上的镜像数据库中使用No Recovery选项还原此事务日志。
配置镜像安全性。
#6
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.
在这篇文章中测试了一些建议,我发现在完全备份,checkpoint命令和事务日志备份之后,可以缩小主体数据库事务日志大小。然后,镜像数据库事务日志大小与主要缩减大小同步。
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.
使用OSQL可以在DOS批处理中运行上述SQL命令,如果批量运行则必须使用WAITFOR DELAY,例如
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.
我认为不同的备份也应该工作,但不测试。下面的diff backup命令将附加数据而不是覆盖。
BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_DIFF.bak' WITH DIFFERENTIAL;
#7
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 !
唯一的方法:1)停止镜像2)缩小主体上的文件3)备份完成主体,+事务jrnl 4)停止镜像服务器,删除镜像数据库的mdf和ldf 5)启动镜像器并删除mirrorDatabase 6)恢复没有恢复备份3)在mirroServer 7)重新安装镜像Ouf!
#8
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.
确实,一旦数据库日志变得太大,你就无法收缩数据库日志 - 此时我认为你唯一的选择是打破镜像,缩小和重新创建。此外,尽管您是否应该仅使用两台服务器进行镜像存在问题,但我可以说,如果您这样做,则会定期备份事务日志。该空间将从中释放,从而允许MSSQL重用日志文件中的死空间。这并没有缩小任何东西,但它确实符合阻止它成长的要求。
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.
如果可以的话,尽量不要工作。
#9
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
)
#10
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.
如果您在主服务器上备份数据库,那么应该做什么呢?之后进行缩减。即你的维护计划应该包括som收缩工作。这些更改应通过同步自动转移到辅助(镜像)服务器。
If you want to make a shrink that only shrinks the transaction file you can use the following T-SQL:
如果要进行仅收缩事务文件的收缩,可以使用以下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).
顺便说一句。如果你已经到了磁盘上没有剩余空间用于日志文件的地步,唯一的选择是将其从镜像模式中取出,将数据库设置为简单恢复模式,收缩日志文件,将其设置为完整再次恢复模式并再次设置镜像(使用数据库og日志文件的备份在镜像服务器上还原)。
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.
此外,如果问题是许可,您可以使用SQL Express作为见证服务器。它不应该需要太多的资源,因此如果这是一个Web应用程序,您可以使用Web服务器。请记住也要查看见证服务器的日志文件。
#11
** 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...
该问题的解决方案是备份没有截断的日志,然后收缩日志文件,或者甚至可以忽略收缩。如果这不起作用,请在备份日志之前尝试检查点。这应该工作......
#1
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:
嗯,从技术上讲,可以缩小镜像LOG。出现问题的是使用truncate_only备份日志。镜像不接受它。所以一种方法是执行磁盘备份日志:
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.
这是我们当前维护计划的一部分,它已经解决了大约2年的问题。
#2
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
exec sp_dboption DBName,'trunc。登录chkpt。',true checkpoint DBCC SHRINKFILE(DBNameFileName,500); exec sp_dboption DBName,'trunc。登录chkpt。',false
Hope this helps.
希望这可以帮助。
#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!
事实证明,如果镜像数据库,则无法收缩t-log,除非停用镜像。如果我错了,请纠正我,但我找不到有效的解决方案!
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.
如果有人愿意就此事分享更多信息或建议,欢迎聆听。
#4
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
可以使用镜像缩小数据库的事务文件,必须执行备份,因为存在活动虚拟日志文件:http://www.xoowiki.com/Article/SQL-Server/tronquer-journal-de-log-sur-基烯之镜 - 499.aspx
#5
- Set mirror partner off by using ..
ALTER [DatabaseName] SET PARTNER OFF - Take Transaction Log backup on principal..
BACKUP LOG [DatabaseName] TO DISK='Drive:\DatabaseName_log_datetime.trn' - Copy this
DatabaseName_log_datetime.trnto any location on Mirror Server. - Restore this Transactional log with
NoRecoveryoption..on mirror database.RESTORE LOG [DatabaseName] FROM DISK ='Drive:\DatabaseName_log_datetime.trn' - Shrink log file on principal & mirror server.
- Again Take Transaction Log backup on principal..and Restore this Transactional log with No Recovery option..on mirrored database on mirror server.
- Configure Mirroring Security.
使用.. ALTER [DatabaseName] SET PARTNER OFF关闭镜像伙伴
在principal上进行事务日志备份.BACKUP LOG [DatabaseName] TO DISK ='Drive:\ DatabaseName_log_datetime.trn'
将此DatabaseName_log_datetime.trn复制到Mirror Server上的任何位置。
使用NoRecovery option..on镜像数据库恢复此事务日志。 RESTORE LOG [DatabaseName] FROM DISK ='Drive:\ DatabaseName_log_datetime.trn'
收缩主服务器和镜像服务器上的日志文件。
再次在Principal上执行事务日志备份,并在镜像服务器上的镜像数据库中使用No Recovery选项还原此事务日志。
配置镜像安全性。
#6
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.
在这篇文章中测试了一些建议,我发现在完全备份,checkpoint命令和事务日志备份之后,可以缩小主体数据库事务日志大小。然后,镜像数据库事务日志大小与主要缩减大小同步。
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.
使用OSQL可以在DOS批处理中运行上述SQL命令,如果批量运行则必须使用WAITFOR DELAY,例如
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.
我认为不同的备份也应该工作,但不测试。下面的diff backup命令将附加数据而不是覆盖。
BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_DIFF.bak' WITH DIFFERENTIAL;
#7
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 !
唯一的方法:1)停止镜像2)缩小主体上的文件3)备份完成主体,+事务jrnl 4)停止镜像服务器,删除镜像数据库的mdf和ldf 5)启动镜像器并删除mirrorDatabase 6)恢复没有恢复备份3)在mirroServer 7)重新安装镜像Ouf!
#8
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.
确实,一旦数据库日志变得太大,你就无法收缩数据库日志 - 此时我认为你唯一的选择是打破镜像,缩小和重新创建。此外,尽管您是否应该仅使用两台服务器进行镜像存在问题,但我可以说,如果您这样做,则会定期备份事务日志。该空间将从中释放,从而允许MSSQL重用日志文件中的死空间。这并没有缩小任何东西,但它确实符合阻止它成长的要求。
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.
如果可以的话,尽量不要工作。
#9
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
)
#10
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.
如果您在主服务器上备份数据库,那么应该做什么呢?之后进行缩减。即你的维护计划应该包括som收缩工作。这些更改应通过同步自动转移到辅助(镜像)服务器。
If you want to make a shrink that only shrinks the transaction file you can use the following T-SQL:
如果要进行仅收缩事务文件的收缩,可以使用以下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).
顺便说一句。如果你已经到了磁盘上没有剩余空间用于日志文件的地步,唯一的选择是将其从镜像模式中取出,将数据库设置为简单恢复模式,收缩日志文件,将其设置为完整再次恢复模式并再次设置镜像(使用数据库og日志文件的备份在镜像服务器上还原)。
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.
此外,如果问题是许可,您可以使用SQL Express作为见证服务器。它不应该需要太多的资源,因此如果这是一个Web应用程序,您可以使用Web服务器。请记住也要查看见证服务器的日志文件。
#11
** 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...
该问题的解决方案是备份没有截断的日志,然后收缩日志文件,或者甚至可以忽略收缩。如果这不起作用,请在备份日志之前尝试检查点。这应该工作......