3

我有一个占用近 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。也许这是错误的做法。

有谁知道我怎样才能腾出更多空间？

4

4 回答 4

7

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

EXEC umbraco_indoorpower..sp_helpfile;

我敢打赌 LDF很大，而 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) 切换到简单恢复，在这种情况下，日志将自行管理.

在大多数情况下，简单的恢复并不能在发生灾难时提供足够的保护，但这由您决定。

同时，您可以随心所欲地收缩文件，但如果您保持恢复模型和事务处理方式不变，您只会看到文件再次增长，并且明天您将返回运行收缩命令。这对您的文件来说绝对是可怕的。这就是为什么我反对“运行收缩操作”之类的答案。我在这里谈谈为什么：

于 2012-04-25T18:38:59.060 回答
1

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

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

编辑：亚伦所说的一切

于 2012-04-25T18:39:23.420 回答
1

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

您可能也想切换到简单的日志模型（如果您没有特殊需要使用完整的日志模型）。有一件事是肯定的：您不能在完整模式下运行，也不能进行适当的事务日志管理。

于 2012-04-25T19:39:42.557 回答
0

在 SQL Server 中占用更多空间的另一件事是 Service Broker 队列。就我而言，我有 600 万行队列占用 17GB ......

于 2015-02-19T04:43:10.693 回答