升级过程中磁盘大小和日志文件的增长

Question

我有四个Server数据库。根据最大负载要求，每个数据库文件的大小可以在1到2 TB之间。HDD是一个多磁盘DAS，空间约为9TB。在数据库升级期间，单个数据库的事务日志文件的大小可以达到4TB。(是的，我在一个数十亿行的表中增加了一个新列。)数据库采用简单的恢复模型。

对于给定的数据库大小我需要多少磁盘空间，我找不到Microsoft的推荐(或经验法则)。我知道它可能会有很大的变化。如果我的理解是正确的，这是我需要考虑的最大的事务，因为日志文件内部的空间被用于不同的事务。我认为原木的增长率被设定为10%，但即使它被设置为1或2G的增量，我认为我仍然会把它缩小。

我是否需要采取一些策略来避免如此庞大的日志文件，还是仅仅需要更多的磁盘空间来避免在升级期间耗尽空间？如果我做错了什么，我想学习如何正确地做它。

我正在使用Server 2012。谢谢!

Answer 1

(是的，我在一个数十亿行的表中增加了一个新列。)

将列添加到非常大的表中可能会产生影响，但是有一个添加列的巧妙方法。

来自：将而非空列添加为联机操作

从SQLServer2012EnterpriseEdition开始，如果默认值是运行时常量，则添加带有默认值的NULL列是联机操作。这意味着无论表中的行数如何，操作几乎是瞬间完成的。总是脱机地添加一个默认值为非运行时常量的NULL列，并在操作期间获取独占(SCH-M)锁。

企业版(根据评论编写2008年R2标准版)有ALTER TABLE source_table SWITCH TO new_destination_table

数据库采用简单的恢复模型。

在简单的恢复模型中，只有一个CHECKPOINT会截断日志。

如果您在典型的升级过程中记录自动增长度量，那么这些收集到的度量的平均值将为您提供一个良好的起始数据。这个剧本将帮助您入门(您需要启用默认跟踪并在服务器上运行)。

我认为原木的增长率被设定为10%，但即使它被设置为1或2G的增量，我认为我仍然会把它缩小。

我建议您将自动增长设置从百分比更改为固定MB。As @AaronBertrand在他的评论中说：

问题是，时间越长越长，因为10%不断增长的文件本身也在不断增长--这就像复合利息，但你是在支付，而不是收到。

为了完整，请确保启用了即时文件初始化，以便数据文件自动增长可以利用它。

Answer 2

在向VLDB类表添加列的场景中，可能值得探索创建一个具有新结构的新表，并在小范围内将记录从旧表移动到新表。它将使单个事务的大小保持较小，这样Tlog在简单恢复中的高水标记就会相对较低。您不能完全避免ACID需求，但如果您可以将升级批量化为较小的步骤，而不是单个事务，则可能可以绕过磁盘空间约束。