Question

我有一个非常大的数据库（40 gig）并且已经运行了程序

sp_space_used

发现有10个未分配的空间。显然这很多，而.mdf文件占据了大部分磁盘。我已经考虑过运行

了

DBCC SHRINKDATABASE (db, TRUNCATEONLY);

我是否还需要缩小事务日志或者缩小数据库来处理这个问题？运行此程序有什么负面影响？我可以在数据库使用时运行吗？我已经尝试运行shrinkdatabase命令，但仍然有很多未分配的空间。

database_size   unallocated space
49575.06 MB   8393.49 MB

reserved       data        index_size   unused
42170328 KB 22704672 KB 19099160 KB  366496 KB

注意：数据库有一个简单的恢复模型，所以我猜我根本不需要备份日志。

运行

之间有什么区别

DBCC SHRINKFILE (datafile, TRUNCATEONLY)

到

DBCC SHRINKDATABSE (db, TRUNCATEONLY)?

Answer 1

首先对数据库进行任何结构更改之前，请执行完整数据库备份。

如果您说，大多数未分配的空间位于SQL Server数据文件（.mdf）中，那么您应该使用DBCC SHRINKFILE而不是DBCC SHRINKDATABASE。

例如：

USE UserDB;
GO
DBCC SHRINKFILE (LogicalDataFileName, target_sizeInMB );
GO

另外，请考虑使用 TRUNCATEONLY 选项仅从数据文件末尾释放可用空间。这是资源密集度较低的选项，但可能无法释放太多空间。请记住，如果使用TRUNCATEONLY指定，则会忽略target_size。

您可以在生产服务器上运行此维护，但是您可能会遇到阻塞增加的情况，因此如果您无法选择停机时间，则应在低活动期间安排维护。但是，用户仍然可以查询数据库。

根据您的修改：

DBCC SHRINKDATABASE将尽力缩小数据库中的所有文件，即数据和日志文件。

另一方面，DBCC SHIRNKFILE提供了更精细的控制级别，因为它适用于特定文件。

Answer 2

sp_spaceused命令也包含日志文件可用空间。即使您的数据库日志模型很简单，SQL也会使用您的日志文件来跟踪事务并且日志文件会增长，并且在您运行备份之前它不会收缩。我知道你提到mdf文件占用了大部分磁盘，但是你检查了你的ldf文件大小了吗？您是否也检查了聚簇索引碎片？

如果您发现日志文件也很大，请尝试使用以下脚本来查看数据库是否收缩。它通过简单的模型日志为我工作。

use [db_name]
backup log [db_name] with truncate_only
dbcc shrinkfile ([db_log_filename], 1)

此语句不会运行实际备份，它只会截断日志并允许shrinkfile删除日志文件正在使用的可用空间。如果您打算在生产中运行它，我建议您在非高峰时间进行。即使它不需要很长时间。这只会影响日志文件大小。

希望这会有所帮助，这也很清楚为什么我建议你也检查日志文件。

Answer 3

我最终使用DBCC SHRINKDATABASE (db, %);指定目标百分比，这似乎解决了我的问题。

Answer 4

清除事务日志空间的最快方法（在完全备份之后）是设置为简单模式，等待一两分钟，然后收缩事务日志。这将缩小到1MB。然后将其重新设置为FULL模式而不是SIMPLE。

无法释放SQL Server 2005中的未分配空间

4 个答案: