Question

我有一个数据库，接近7场演出。如果我查看表的用法，它应该远远小于40兆。我昨天删除了一个大型日志表，但我的数据库仍然说它非常大。

以下是统计数据：

database_name   database_size   unallocated space
Umbraco_Indoorpower 6911.56 MB  859.59 MB

reserved    data    index_size  unused
31144 KB    26272 KB    3240 KB 1632 KB

我跑了这个：

DBCC SHRINKDATABASE (umbraco_indoorpower, 99);

这使我的数据库降至2.3演出。尽管如此，还是太大了。

database_name   database_size   unallocated space
Umbraco_Indoorpower 2302.44 MB  1.63 MB

reserved    data    index_size  unused
30016 KB    26200 KB    3240 KB 576 KB

我猜测我没有释放我昨天删除的日志表中的所有空间。我实际跑了delete from tblLog。也许这是错误的做法。

有谁知道如何腾出更多空间？

Answer 1

日志文件有多大？你的恢复模式是什么？上面的database_size数字很可能是近7 GB的日志和非常少的数据。查找硬盘驱动器上的文件 - 您可以使用以下命令找到路径：

EXEC umbraco_indoorpower..sp_helpfile;

我打赌，LDF HUGE ，MDF实际上很小。在这种情况下，您可能处于完全恢复模式，并且从未进行过日志备份。如果这是真的那么你可以这样做：

USE umbraco_indoorpower;
GO
BACKUP LOG umbraco_indoorpower TO DISK = 'C:\some_path\umbraco.trn';
GO
DBCC SHRINKFILE(umbraco_indoorpower_log, 20); -- guessing on target MB size here

（如果你处于简单的恢复模式，上面的代码会失败，但会有一些其他解释为什么日志文件很大 - 例如长时间运行或未提交的事务，你的删除提交了吗？）

然后你要（a）设置适当的维护，包括完整/差异/日志备份，这将有助于最佳地重用日志文件，或者（b）切换到简单恢复，在这种情况下，日志将自我管理。

在大多数情况下，简单恢复在发生灾难时无法提供足够的保护，但您可以自行决定。

与此同时，您可以缩小文件的所有内容，但是如果您保持恢复模式和事务处理的方式，您只会看到您的文件再次增长，并且明天您将恢复运行收缩命令。这对你的文件来说绝对可怕。这就是为什么我反对像“运行收缩操作”这样的答案。我在这里谈到原因：

Oh, the horror! Please stop telling people they should shrink their log files!

Answer 2

http://www.brentozar.com/archive/2009/08/stop-shrinking-your-database-files-seriously-now/

在任何情况下，您都有数据和日志，并且要缩小日志，您必须进行备份。

编辑：Aaron said

Answer 3

现有答案已经相当不错了。我还有一个额外的解决方案：编写数据库脚本，包括数据（SSMS UI允许您轻松完成此操作）并在新数据库中执行脚本。

您也可能希望切换到简单的日志模型（如果您不特别需要使用完整的日志记录模型）。有一件事是肯定的：您无法在完整模式下运行，也没有正确的事务日志管理。

Answer 4

另一个可以在SQL Server中占用更多空间的是Service Broker队列。在我的情况下，我有600万行排队占用17GB ......

数据库占用的空间比表组合的更多

4 个答案: