编写“终极数据库维护脚本”

Question

我正在尝试编写 T-SQL 脚本，它将：

A) 将数据库大小缩小到可能的最小大小；B) 进行完整性检查，彻底“重组”和优化数据库，使其处于“新鲜”状态。

这是我目前拥有的：

-- Check database integrity:

DBCC CHECKDB WITH NO_INFOMSGS;
GO

-- Get space usage information:

EXEC sp_spaceused @updateusage = N'TRUE';
GO

-- Shrink database:

DBCC SHRINKDATABASE (0, 0);
GO

-- Reindex all tables:

EXEC sp_msforeachtable N'PRINT ''Indexing table: ?''; DBCC DBREINDEX (''?'');'
GO

-- Update statistics for all tables:

EXEC sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'
GO

-- Clear procedure cache:

DBCC FREEPROCCACHE;
GO

-- Update all usage info in the database:

DBCC UPDATEUSAGE (0);
GO

您能否验证所有这些是否正确？命令的优先级（例如在索引重建后更新统计信息，反之亦然）、语法、参数等都是最优的吗？你能建议任何其他命令吗？性能不是问题，我可能每个月都会执行一次这个脚本，晚上的时间，所以即使需要几个小时也没关系。我只需要对数据库进行最大程度的优化。任何投入将不胜感激。

谢谢！

Answer 1

恐怕您的脚本对数据库的工作方式充满了误解，至少在 SQL Server 中是这样。

• 首先，使用通用 DBCC SHRINKDATABASE 命令尽可能缩小数据库。为什么？如果数据库将再次增长，那么缩小文件您得到了什么？在此期间，您是否打算暂时租出该空间，直到数据库再次需要它？这将导致碎片化并使您的重新索引工作更加困难。稍后会详细介绍。
• 接下来，您重新索引所有表，无论它们是否需要。通常最好先分析表，然后在必要时对特定索引执行条件操作（例如重组或重建）。
• 由于您正在重建所有索引，并且索引重建需要 - 平均 - 索引占用的空间的 1.5 倍，您认为它将从哪里获得该空间？您刚刚缩小了数据库，因此没有可用空间。您无缘无故地缩小了数据库，因为现在它必须扩大以提供一些空间来容纳索引重建。
• 然后你用全扫描更新统计信息。您刚刚重建了所有索引。您认为此时更新统计数据是否必要或有帮助？我没有，因为重建索引会自动更新其统计信息。所以这个额外的步骤只是浪费。
• 最后，清除整个 proc 缓存不太可能导致整体性能改进。您可能会在一些查询中获得改进，但恕我直言，将它们嗅出并单独清除它们会更有效（您可以在现代版本的 SQL Server 中手动清除计划，而不会将婴儿扔掉洗澡水）。

我不得不说，到目前为止，您所获得的远非最佳，并且有更好的解决方案可以帮助您以更有效和更少浪费的方式优化数据库。查看Ola 的解决方案、SQLFool 的解决方案和SQL Sentry。这些不会缩小您的数据库，但它们会以一种智能的方式优化您的索引，无论如何您都不应该缩小您的数据库。

Answer 2

去这里，下载/安装脚本。

如果这是用于生产，我强烈建议您不要自己编写脚本。使用一组已经过彻底测试的脚本而不是重新发明轮子要好得多（也更容易！）。

Answer 3

就个人而言，我不会缩小数据库。当它需要再次生长时，它需要更多的时间。它还可能使文件系统碎片变得更糟。

Answer 4

你为什么要跑DBCC FREEPROCCACHE;？

它将删除所有缓存的执行计划。这实际上是一件坏事。缓存的 exec 计划提高了查询执行时间。