Question

我有一个连接SQL Server 2012数据库的Windows应用程序。这个数据库很庞大，昨天，应用程序的所有查询都给出了时间，我们发现日志文件的大小是配置的。所以我们将大小（它是8gb）改为16gb，但我们认为这是一个临时解决方案。

我应该采取什么解决方案？

编辑：因为＆＃34;标记为重复问题＆＃34;似乎我想编辑这篇文章，以表示我不想问如何清除交易日志。我的问题指出在这种情况下最好的选择是什么，可能是清除事务日志，但也许还有其他选项。对不起，如果用户误解了这个问题。

Answer 1

您需要决定如何处理数据库。您是否需要时间点恢复（最大限度地降低上次日志备份中数据丢失的风险），或者您是否希望依赖夜间备份（意味着如果系统崩溃，您的数据丢失将是您上次完整后发生的所有事情/差异备份）？

如果您需要时间点恢复，则需要确保数据库处于完全恢复模式，并定期安排完整的和日志备份。如果您定期备份日志（例如，每15分钟一次），它不应再次升级到无法管理的大小（除非您有非常大的事务）。如果不进行常规日志备份，它也可能处于简单模式，因为您没有获得完全的任何好处 - 但是如果不进行日志备份，日志就会不断增长。

如果您不需要时间点恢复，则需要确保数据库处于简单恢复模式。简单来说，日志会自动管理自己 - 它知道它可以清除旧的事务并重新使用该空间。

在任何一种情况下，我都会将日志保留为现在的大小。如果你缩小它，它可能会再次增长，那么缩小它的重点是什么？

这些选项在this answer中都有更好的记录 - 这就是为什么我最初投票将这个问题作为该问题的副本关闭（而不是仅仅复制并粘贴这里的答案）。虽然你不认为你在技术上问同样的问题，但你是恕我直言 - 你需要看看标题，并认识到你处于完全相同的情况。

其他一些可能有用的链接：

Answer 2

这是一篇关于缩小日志文件的文章，我做了一段时间。

http://craftydba.com/?p=3033

唯一的问题是以下几点。

1 - 日志指针位于文件的末尾（status = 2）

-- Size of virtual log files
DBCC LOGINFO;
GO

2 - 打开用户交易。（摆脱它们）

-- Make sure there are not open transactions
DBCC OPENTRAN;
GO

如果指针位于文件的末尾，则必须在DBCCC SHRINKFILE（）实际删除空白区域之前移动它。

有趣的是，有多少次我看到一个比数据文件大X倍的LOG文件。必须使用FULL和LOG备份！

如果你没有安排它们，你会遇到更大的问题。您首先必须进行FULL备份，LOG备份，然后尝试SHRINKFILE。

快乐萎缩......

SQL Server 2012带有大日志文件，有什么选择？

2 个答案: