sql - 数据库占用的空间比表的总和还要多

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 gigs。不过，还是太大了。

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!