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

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

题

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

我不是一名DBA，但我是一个在一个巨大的网站上工作的单人团队，没有额外的额外资金，所以我尽我所能。

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

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

基于此网页，我试过这个：

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）

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

有帮助吗？

解决方案 3

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

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

如果您只有两台服务器，则可以使用日志传送。没有见证服务器，镜像几乎毫无意义，因为故障转移的唯一方法是来自主体......如果在主体崩溃时你无法进行故障转移，那么就有可能失去镜像的目的。

如果有人愿意就此事分享更多信息或建议，欢迎聆听。

其他提示

嗯，从技术上讲，可以缩小镜像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年的问题。

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

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

exec sp_dboption DBName，'trunc。登录chkpt。'，是的 检查站 DBCC SHRINKFILE（DBNameFileName，500）; exec sp_dboption DBName，'trunc。登录chkpt。'，false

希望这有帮助。

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

  1. 使用.. 关闭镜像伙伴ALTER [DatabaseName] SET PARTNER OFF
  2. 在主体上进行事务日志备份.. BACKUP LOG [DatabaseName] TO DISK ='Drive：\ DatabaseName_log_datetime.trn'
  3. 将此 DatabaseName_log_datetime.trn 复制到Mirror Server上的任何位置。
  4. 使用 NoRecovery 选项在镜像数据库中恢复此事务日志。 RESTORE LOG [DatabaseName] FROM DISK ='Drive：\ DatabaseName_log_datetime.trn'
  5. 缩小主要＆amp;的日志文件镜像服务器。
  6. 再次在Principal上执行事务日志备份，并在镜像服务器上的镜像数据库中使用No Recovery选项还原此事务日志。
  7. 配置镜像安全性。

在这篇文章中测试了一些建议，我发现在完全备份，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);

使用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命令将附加数据而不是覆盖。

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

唯一的方法： 1）停止镜像 2）缩小主体文件 3）备份完成主体，+事务jrnl 4）停止镜像服务器，删除mirrorDatabase的mdf和ldf 5）启动镜像并删除mirrorDatabase 6）在mirroServer上恢复3）没有恢复备份 7）重新安装镜像 哇！

确实，一旦数据库日志太大，就无法收缩数据库日志 - 此时我认为你唯一的选择是打破镜像，缩小和重新创建。此外，尽管您 应该 是否仅使用两台服务器进行镜像的问题，我可以说，如果您这样做，则会定期备份事务日志。该空间将从中释放，从而允许MSSQL重用日志文件中的死空间。这并没有缩小任何东西，但它确实符合阻止它成长的要求。

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

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

如果可以，请在几小时内完成。

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

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
  )

如果镜像数据库没有从镜像中取出，你就无法真正做任何事情，只要它不是主体数据库。

如果您在主服务器上备份数据库，那么应该做什么？之后进行收缩。即你的维护计划应该包括som收缩工作。这些更改应通过同步自动转移到辅助（镜像）服务器。

如果要缩小只收缩事务文件，可以使用以下T-SQL：

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

然后，您只需将该代码段用于每个数据库，并在备份运行后立即运行。

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

我希望这会有所帮助。

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

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

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

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top