数据库空间不足

Question

我的数据库还有 16MB 的空间。

我曾经只是按照我的教导进行截断，但我发现这些链接建议不要截断：

http://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/

http://blog.sqlauthority.com/2011/01/19/sql-server-shrinking-database-is-bad-increases-fragmentation-reduces-performance/

除了删除表记录之外，我还能在我的数据库上做些什么来减小大小吗？我是 DBA 论坛的新手，我可能应该在发帖之前四处寻找其他问题，但我很绝望，因为我担心我的数据库会崩溃。

Answer 1

如果您的数据库有 16 MB 的可用空间，并且它所在的驱动器有足够的可用空间，那么请不要担心。只要有足够的空间并且您没有禁用数据库的自动增长能力，数据库就会在需要时增长数据文件。当然，您应该将数据文件的自动增长设置为一些实际的增量，平衡增长所需的持续时间和增长的频率。1MB 或 10% 的默认值根本不现实，应该在很久以前就已更改。如果您启用了即时文件初始化，您可以倾向于更大的，但我不知道对您来说有什么好的平衡。

您可以在此处检查自动增长设置：

SELECT name, type_desc, size, growth, is_percent_growth
  FROM [database_name].sys.database_files;

理想情况下，您将创建具有足够大小的数据库以避免自动增长，因为此操作可能很昂贵（特别是如果您没有即时文件初始化），并且可能会在增长事件期间阻止所有其他活动。您可能希望现在或在维护窗口期间手动扩展文件，以避免在高峰活动期间发生这种情况。因此，您可以主动执行此操作（例如，将自动增长设置更改为 100 MB）：

ALTER DATABASE [database_name] 
  MODIFY FILE (NAME = N'database_name_data', FILEGROWTH = 102400KB);

如果您的驱动器有 16 MB 的可用空间，那么您需要以某种方式释放一些空间，或者将数据库移动到具有更多空间的驱动器。驱动器可能已被过度增长的日志文件占用，这可能是因为您处于完全恢复模式并且从未进行过日志备份。在这种情况下，您可以：

1. 切换到简单恢复模式，运行CHECKPOINT，然后DBCC SHRINKFILE使日志大小合理。抵制将文件缩小到 1 MB 的诱惑；您不想与磁盘空间进行拉锯战。
2. 保持完整，然后BACKUP LOG，然后DBCC SHRINKFILE使用与 (1) 相同的警告。

现在，也可能是您处于简单模式并且日志膨胀以支持某些非典型的大型事务。因此，您可能仍然可以毫无顾虑地执行 (1)，但是如果您要再次运行这些大型事务，或者不定期执行 (1) 或 (2)，那么您只是在“解决”问题问题暂时。获得更大的磁盘或使用完整恢复模式并更有效地管理您的日志。

话虽如此，这只是一个猜测；也许您的驱动器实际上被一个大的（无用的）页面文件、您的 MP3 收藏或您上次假期的视频占用了。

Answer 2

你迷失在自动增长中，你迷失在文件组中。为了你自己，我希望这不是一个生产数据库。

话虽如此 - 这是数据库间距的工作原理：

在 SQL Server Management Studio 中执行此操作

sp_helpdb <yourdbname>

这应该为您提供 2 组输出。第一组有一个名为 的列db_size，它将为您提供当前的数据库大小。第二个将为您提供独立大小的数据和日志文件。检查此处称为maxsize.

现在执行这个：

USE <yourDB>
GO

EXECUTE sp_spaceused
GO

此查询的输出将告诉您 DB 文件中的未分配空间或可用空间。当它填满时，您的数据库将根据各种设置和情况增长或停止。

最初创建数据库时，您定义初始大小、数据库如何增长以及最大大小是多少。如果您创建一个初始大小为 3 GB 的数据库，在具有 100 GB 可用空间的 HDD 上无限增长，则该数据库将继续增长，在最初的 3 GB 用完后，直到填满磁盘中的所有可用可用空间。但是，如果您创建一个初始大小为 1 GB 的数据库并将最大值设置为 3 GB，那么您的数据库将在它增长到 3 GB 时停止，即使硬盘驱动器还有数十亿 TB 的可用空间。

如果这是生产，请不要将恢复模型更改为简单。您将失去恢复到某个时间点的能力。

不管你做什么 - 第 1 步：备份你的数据库