Question

我正在处理已从备份还原的数据库。然后，它将删除其中的大部分数据，以便我们可以为开发和测试工作保留较小的数据子集。例如，我们正在删除旧订单。

所有这些都会导致一个大约2 TB的数据库中只有100 GB的数据。所以我需要缩小它。问题在于，上一个开发人员给我的脚本比整个其余的还原和数据缩减过程花费的时间更长。

以前的开发人员给了我下面的脚本，该脚本每次使用DBCC SHRINKFILE循环并减少所需数量的一部分。这就是我们目前正在使用的方法，但是我确信这不是最佳解决方案，因为它需要花费很长时间，而且我肯定它碎片化的数量令人恐惧。

如果有帮助，我们将同时使用Redgate和SQL Server创建备份，供开发人员用来创建其工作数据库。

DECLARE @FileSpace int;
DECLARE @MinSize int
DECLARE @Size int;
DECLARE @FileName nvarchar(100);

SET @Size = @FileSpace;

WHILE @Size > @MinSize
BEGIN
    SET @Size = @Size - 1000;

    DBCC SHRINKFILE (@FileName , @Size)

    SET @Size = (select database_files.size/128 from sys.database_files where database_files.name = @FileName);
END

我真的需要更快一些的东西，因为目前已经花了3天以上的时间。

Answer 1

第一

Why you should NOT be shrinking alot.，着重强调该文章中包含的链接。

然后有此参数

按照本文所述，由于@MinSize为空@Size > null返回null并因此为false，因此将永远不会执行，从而阻止执行。如果将其设置为某个数字（例如较低的数字），则如果从未满足条件@Size > @MinSize，则可能会发生无限循环。

但这不是...所以现在

另一个罪魁祸首可能是封锁。是的，DBCC SHRINKFILE can cause blocking.要看是否正确，我将从Adam Machanic's sp_WhoIsActive开始。它有据可查，可以让您通过@find_block_leaders参数获取阻塞树。

通常不快

许多文章已经说明，SHRINKFILE会消耗CPU并杀死您的I / O，会导致阻塞，产生内部碎片，这可能会使您回到通过{{ 3}}。因此，也许您的服务器刚刚达到要求。这是最不可能的，但始终是潜在的。

如果我是我会做什么？

备份数据库，然后通过当前版本还原它。备份过程不会备份空白页。希望您的填充因子设置为100％，这不是膨胀的问题。 hopefully Ola's Index Optimize scripts.因此，快速备份和还原将解决您的问题。

如果我确实需要缩小数据文件，则不会使用循环脚本。我一次做一次。您甚至可以使用GUI！至少要在脚本中添加一些PRINT命令，以查看可能导致无限循环的原因（如果实际上是无限循环的话）。我会在每次迭代开始时打印出所有参数值。

缩减了大部分数据删除的SQL Server数据库

1 个答案: