标签: shrink

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

在 SQL Server 中 -

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

在 SQL Server（在本例中为 2008）中，如何快速缩小实例上所有数据库的所有文件，包括日志和数据？我可以通过 SSMS 并右键单击每个并选择任务 -> 收缩，但我正在寻找更快的东西。

我编写了一些“创建数据库”脚本，但忘记了它们的默认值已经膨胀，并且不需要为该项目中的这些文件保留太多空间。

我知道收缩是魔鬼：它会颠倒页面顺序并导致皮肤癌、数据碎片化和全球变暖。名单还在继续……话虽如此，假设我有一个 100 GB 的数据库，我删除了 50 GB 的数据——不是在一个表上，而是在数据库范围内对旧数据进行一般修剪，覆盖 90% 的数据表——这是否构成缩小数据库的适当用例？

如果没有，从数据库中删除如此高比例的数据后，应采取哪些适当的步骤来清理房屋？我可以想到两个：重建索引和更新统计。还有什么？

DBCC ShrinkDatabase()
DBCC ShrinkFile()

1. 我是否需要同时运行两个 DBCC 命令才能缩小数据库？
2. 上面这两个有什么区别？

这个问题在这里以各种形式提出，但问题归结为：

我知道缩小数据库是有风险的。在这种情况下，我已经删除了这么多数据，我再也不会使用它了。

• 如何缩小我的数据库？我缩小了哪些文件？
• 这样做时我应该考虑什么？
• 之后我应该做些什么吗？
• 如果是大数据库呢？我可以以较小的增量缩小它吗？

我有一个数据库，它有一个350 MB 的数据文件(.mdf) 和一个4.9 GB 的日志文件(.ldf)。恢复模式设置为FULL.

当我尝试缩小日志文件时，它并没有缩小。

我知道缩小数据库不好，也不应该这样做。但我仍然试图缩小日志文件。

当我跑

DBCC SQLPerf(logspace) 

我发现日志大小为4932 MB，使用的日志空间为98.76%！

然后我尝试了这个命令

USE <databasename>;
DBCC loginfo;

现在几乎所有的 VLF 都是“状态 2”，这意味着都在使用中。

我尝试进行日志备份，然后缩小日志文件。收缩并没有减小尺寸。

我将恢复模型更改为SIMPLE并再次尝试缩小，但这也无济于事。

我检查了未结交易

DBCC opentran (database);

并发现现在没有交易打开。

是什么阻止我缩小日志文件？我该如何解决这个问题？

在 SQL Server 2008 中缩小临时数据库时使用的最佳实践是什么？

使用以下方法有风险吗？

use tempdb
GO

DBCC FREEPROCCACHE -- clean cache
DBCC DROPCLEANBUFFERS -- clean buffers
DBCC FREESYSTEMCACHE ('ALL') -- clean system cache
DBCC FREESESSIONCACHE -- clean session cache
DBCC SHRINKDATABASE(tempdb, 10); -- shrink tempdb
dbcc shrinkfile ('tempdev') -- shrink db file
dbcc shrinkfile ('templog') -- shrink log file
GO

-- report the new file sizes
SELECT name, size
FROM sys.master_files
WHERE database_id = DB_ID(N'tempdb');
GO

我有一个有很多未使用空间的 SQL 数据库。但是，当我运行 Tasks | 收缩| 数据库和任务 | 收缩| 来自管理工作室的文件它没有释放任何空间。
不幸的是，运行它的机器的硬盘空间不足。关于为什么这个空间没有释放的任何想法。

DB 上的恢复模式也设置为简单。

这是我缩小文件时出现的未使用对话框：

我也试过通过 T-SQL 做到这一点

DBCC SHRINKDATABASE (myDatabase, 5);

我得到以下回应：

DBCC SHRINKDATABASE：数据库 ID 6 的文件 ID 1 被跳过，因为该文件没有足够的可用空间来回收。DBCC SHRINKDATABASE：数据库 ID 6 的文件 ID 2 被跳过，因为该文件没有足够的可用空间来回收。DBCC 执行完成。如果 DBCC 打印错误消息，请联系您的系统管理员。

我们正在使用AlwaysOn Availability GroupSQL Server 2012 的功能。每天都会在辅助数据库上进行定期的完整数据库备份和事务日志备份。

我在这里读到在主副本或辅助副本上执行事务日志备份会将两个副本的事务日志标记为可重用。无论如何，事务日志备份大小很大，可以使用收缩文件来减少：

我已经在本地恢复了数据库并执行了收缩操作。日志文件大小减少到 160 MB。

我的问题是我应该在哪个数据库上对事务日志文件（主要、次要或两者）执行收缩操作？

我猜过去几年没有备份日志文件，所以它变得如此庞大。执行DBCC SQLPERF (LOGSPACE)我可以看到只0.06%使用了文件 - 我没有必要保留这么大的日志文件。在[sys].[database_files]我检查其max_size设置为-1与growth对65536，所以我想，当它需要更多的空间，它会得到。无论如何，我可以将其缩小到例如 5% 以防止未来的增长。我试图找到一些确认，我这样做不是坏主意。

实际上，备份（对数据库和日志文件）仅在辅助数据库上执行，因此对它们执行收缩文件会更容易，但是主日志文件的大小也会减小吗？

我正在运行 sql 2008 r2 并且数据库在过去 3 年中运行良好且快速，直到大约 3 个月前我们在非常活跃和使用过的表上添加了 ntext 字段。现在我们开始用尽服务器空间，因为这个表的大小越来越大。

我读到了缩小，我们不想放松 db 的索引，因为它多年来一直在快速工作，而且我们不想让碎片消耗殆尽。

我们决定删除该字段及其所有值： 有没有办法删除 ntext 字段及其所有值并释放空间而不删除索引，不缩小，不损失数据库性能？

我附上 db size 查询输出，以显示过去 5 个月的大小扩展。