在使用db的情况下，是否有对日志运行DBCC SHRINKFILE命令的风险

我们可以处理性能问题。

这也是一个因为有一个新的索引创build了一个巨大的日志文件被创build。我需要缩小这个文件。

我只是想知道是否有任何风险运行此命令。

Sql Server 2005数据库

这是安全的，但在交易活动不多的时候安静地进行。 build议将日志缩小到最小尺寸，然后将其增大到正常大小（这将确保创build正确的VLF（内部虚拟日志文件）数量，从而提高logging的命令的性能）。

如果数据库的日志没有收缩 – 如果数据库处于简单模式，则首先执行检查点命令，如果完全logging，则首先备份日志。

如果日志包含未处理的镜像或复制事务，则它可能不会缩小到最小大小。

记得要设定一个合适的自动增长值。

请参阅以下文章：

假设你正在谈论SQL Server 2000/2005，我在没有问题的实时数据库上做这件事。

我也缩小活动数据库的传输日志。它只影响事务日志的不活动块。

保罗·兰德尔（Paul Randall）在这里有一个很好的线索他的博客上还有一篇文章：

SQL Server自动缩小打开是否安全？

它不是你确切的问题，但是确实提供了DBCC SHRINKFILE的工作原理。

还有一些指针，如果你的日志不缩水：

您可以备份您的交易logging。
您可以尝试先运行检查点（ http://msdn.microsoft.com/en-us/library/ms188748.aspx ），以便将所有脏页写入磁盘，然后运行dbcc shrinkfile。
如果您没有复杂的sqlconfiguration（例如：在特定数据库上进行数据库镜像），则可以将数据库切换为简单恢复，然后将其切换回完全恢复模式（可在数据库正在使用时完成）以及肯定会收缩你的数据库日志文件。