相关疑难解决方法(0)

这个问题在大多数论坛和整个网络中似乎是一个常见问题，这里以多种格式提出，通常听起来像这样：

在 SQL Server 中 -

• 事务日志变得如此之大的一些原因是什么？
• 为什么我的日志文件这么大？
• 有什么方法可以防止这个问题的发生？
• 当我找到根本原因并希望将我的事务日志文件调整到正常大小时，我该怎么办？

我通常使用以下方法来确定数据库的每个文件中的可用/已用空间：

Select *, fileproperty(name, 'SpaceUsed') as Used
From dbo.sysfiles

这将返回页面中的总空间和已用空间，然后乘以 8 得到 KB（或除以 128.0 得到 MB）。

我找到了另一个脚本，而不是使用DBCC showfilestats并dbcc sqlperf(logspace)返回 TotalExtents 和 UsedExtents，然后可以乘以 64 得到 KB（或除以 16.0 得到 MB）。

忽略额外的列，这两个是否总是为空闲/总空间提供相同的值？怎么样sp_spaceused？

它们的准确性是否都取决于最近的 DBCC UPDATEUSAGE？

是否有另一种更好的方法来确定已用/可用空间？（我需要这个脚本在 SQL 2000、2005 和 2008 服务器上工作）

部分相关：你能有一个部分分配的范围吗？（例如，仅分配了一个范围内的 8 个页面中的 3 个）