缩小镜像 SQL Server 2005 数据库的事务日志答案

【问题标题】：Shrinking the transaction log of a mirrored SQL Server 2005 database缩小镜像 SQL Server 2005 数据库的事务日志
【发布时间】：2009-06-23 15:07:33
【问题描述】：

我一直在寻找整个互联网，但我找不到一个可接受的解决方案来解决我的问题，我想知道是否有没有妥协的解决方案......

我不是 DBA，但我是一个单独的团队，在一个庞大的网站上工作，没有额外的资金用于额外的机构，所以我正在尽我所能。

我们的备用计划很糟糕，我很难改进它。目前，有两台服务器运行 SQL Server 2005。我有一个似乎运行良好的镜像数据库（无见证）。我在中午和午夜进行完整备份。这些由我们的服务提供商每晚备份到磁带上，我每周将备份文件刻录到 dvd 以保存旧记录。最终我想切换到日志传送，因为如果没有见证服务器，镜像似乎毫无意义。

问题是事务日志不断增长。从我所做的研究来看，我似乎无法截断镜像数据库的日志文件。那么如何阻止文件增长！？

基于this web page，我尝试了这个：

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

但这没有用。我发现的所有其他内容都表明我需要在运行备份日志命令之前禁用镜像才能使其工作。

我的问题 (TL;DR)

如何在不禁用镜像的情况下缩小我的事务日志文件？

【问题讨论】：

标签： sql-server database sql-server-2005 mirroring transaction-log

【解决方案1】：

嗯，从技术上讲，缩小镜像 LOG 是可能的。麻烦的是用 truncate_only 备份日志。镜像不接受它。所以一种方法是执行备份日志到磁盘：

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

这是我们当前维护计划的一部分，它已经运行了大约 2 年，没有出现任何问题。

【讨论】：

【解决方案2】：

如果镜像服务器实例落后于主体服务器实例，则活动日志空间量将会增加。在这种情况下，您可能需要停止数据库镜像，进行日志备份以截断日志，将该日志备份应用到镜像数据库并重新启动镜像，这不是您希望的答案，我知道 =(

要缩小我们的文件，您可以尝试以下脚本：

exec sp_dboption DBName, 'trunc.登录 chkpt.', true 检查点 DBCC SHRINKFILE (DBNameFileName, 500); exec sp_dboption DBName, 'trunc.登录 chkpt.', false

希望这会有所帮助。

【讨论】：

不确定换行符应该在哪里，其中一些命令对我来说不熟悉......这是正确的吗？ exec sp_dboption DBName, 'trunc.登录 chkpt.', true<br> 检查点<br> DBCC SHRINKFILE (DBNameFileName, 500);<br> exec sp_dboption DBName, 'trunc.登录 chkpt.', false
是的，没错。抱歉，我总是忘记代码无法正确粘贴。如果您以正确的格式布置它，它应该如下所示： EXEC SP_DBOPTION 'MY DATABASENAME', 'Trunc Log', TRUE CHECKPOINT DBCC SHRINKFILE('MYDB FILE', 500); EXEC SP_DBOPTION 'MY DATABASENAME', 'Trunc Log', FALSE

【解决方案3】：

我认为我应该真正回答这个问题，因为它被遗忘了。

事实证明，如果数据库被镜像，除非您停用镜像，否则您无法缩小 t-log。 如果我错了，请纠正我，但我没有找到有效的解决方案！

如果您只有两台服务器，则日志传送是可行的方法。如果没有见证服务器，镜像几乎毫无意义，因为故障转移的唯一方法是从主体...

如果有人愿意就此事分享更多信息或建议，我会很高兴听到他们的声音。

【讨论】：

“如果没有见证服务器，镜像几乎毫无意义，因为故障转移的唯一方法是从主体”——这根本不是真的：如果主体服务不可用，您可以执行 forced service failover在镜像服务器上有效地使服务器交换关于故障转移数据库的角色。当主服务器可用并重新连接时，它将开始将其镜像数据库与现在的主服务器同步。

【解决方案4】：

使用 .. ALTER [DatabaseName] SET PARTNER OFF 设置镜像伙伴关闭
在主体上备份事务日志..BACKUP LOG [DatabaseName] TO DISK='Drive:\DatabaseName_log_datetime.trn'
将此DatabaseName_log_datetime.trn 复制到镜像服务器上的任何位置。
使用NoRecovery option..on 镜像数据库恢复此事务日志。 RESTORE LOG [DatabaseName] FROM DISK ='Drive:\DatabaseName_log_datetime.trn'
在主体和镜像服务器上收缩日志文件。
再次在主体上进行事务日志备份..并使用无恢复选项还原此事务日志..在镜像服务器上的镜像数据库上。
配置镜像安全。

【讨论】：

【解决方案5】：

测试了这篇文章中的一些建议，我发现在完全备份、检查点命令和事务日志备份之后，可以缩小主体数据库事务日志的大小。然后镜像数据库事务日志大小与主体缩小大小同步。

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);

使用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;"

我认为不同的备份也应该工作，但没有测试。下面的 diff 备份命令将追加数据而不是覆盖。

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

【讨论】：

【解决方案6】：

唯一的方法： 1) 停止镜像 2) 在主体上收缩文件 3）主体备份完成，+事务jrnl 4）停止镜像服务器，删除mirrorDatabase的mdf和ldf 5）启动mirrorser并删除mirrorDatabase 6) 在 mirroServer 上不使用 3) 的恢复备份进行恢复 7）重新安装镜像哎哟！

【讨论】：

【解决方案7】：

确实，一旦数据库日志变得太大，您就无法收缩它——那时我认为您唯一的选择就是打破镜像，收缩并重新创建。此外，尽管您是否应该仅对两台服务器使用镜像存在问题，但我可以说的是，如果您这样做了，那么请定期备份事务日志。将从中释放空间，从而允许 MSSQL 重新使用日志文件中的死空间。这不会缩小任何东西，但确实满足阻止它增长的要求。

那么您需要做的就是定期删除文件备份。例如，您可以这样做：

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

如果可以的话，不要在几个小时内完成。

【讨论】：

【解决方案8】：

我不知道这为什么有效，只是它确实有效。我在查询窗口中将其作为一个块运行。自行决定使用。如果有微软人士发表评论，当然会很好。

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
  )

【讨论】：

【解决方案9】：

如果不将镜像数据库从镜像中取出，您实际上无法对镜像数据库执行任何操作，只要它不是主体数据库即可。

如果你在主服务器上备份你的数据库，然后再做一个收缩，应该怎么做。即你的维护计划应该包括一些收缩工作。这些更改应通过同步自动传递到辅助（镜像）服务器。

如果你想做一个只收缩事务文件的收缩，你可以使用下面的 T-SQL：

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

然后您只需对每个数据库使用该 sn-p 并在备份运行后立即运行它。

这应该使主体服务器上的日志文件保持较小，从而在辅助/镜像服务器上。

我希望这会有所帮助。

顺便说一句。如果您已经到了磁盘上没有空间用于日志文件的地步，唯一的选择是将其退出镜像模式，将数据库设置为简单恢复模式，缩小日志文件，将其设置为完整再次恢复模式并再次设置镜像（使用数据库 og 日志文件的备份在镜像服务器上恢复）。

此外，如果问题在于许可，您可以使用 SQL Express 作为见证服务器。它不应该需要太多的资源，所以你可以使用一个网络服务器，如果这是一个网络应用程序。请记住也要查看见证服务器的日志文件。

【讨论】：

【解决方案10】：

可以通过镜像缩小数据库的事务文件，必须执行备份，因为有活动的虚拟日志文件： http://www.xoowiki.com/Article/SQL-Server/tronquer-journal-de-log-sur-base-en-miroir-499.aspx

【讨论】：

【解决方案11】：

**收缩可以在镜像中进行，我们不能做的是截断日志，因为日志是发送到镜像服务器然后主体等待确认的。

解决此问题的方法是备份不截断的日志，然后收缩日志文件，或者您甚至可以忽略收缩。如果这不起作用，请在备份日志之前尝试检查点。这应该可以...

【讨论】：