为数据仓库创建 SQL Server 数据库的最佳实践答案

【问题标题】：Best practice for creating SQL Server databases for a data warehouse为数据仓库创建 SQL Server 数据库的最佳实践
【发布时间】：2011-01-25 12:41:39
【问题描述】：

我即将为我们的数据仓库创建 2 个新的 SQL Server 数据库：

我预计这两个数据库都能够达到 30GB，并且每年增长约 5GB。它们可能不会超过 80GB（当我们开始存档时）。

我正在尝试决定在创建这些数据库时应该使用哪些设置：

我正在寻求有关创建这些数据库的最佳实践建议。

更新：我建议在创建数据库后立即增加数据库大小的原因，因为您不能将数据库缩小到小于其初始大小。

【问题讨论】：

AH - 取出 sql server。数据仓库的表设计与产品关系不大。另外，每年 30gb 和 5gb 不是数据仓库。那是一个家庭系统。我刚刚做了一个数据仓库，数据负载为150gb。每天。存档 2 年。
@TomTom 数据仓库不是由它所拥有的数据量来定义的。
啊，它是，部分。如果您处理“玩具数据”，那么从性能角度来看有意义的设计决策将毫无用处。出于性能原因，存在整个星型非规范化数据模式。对少量数据无用。
永远不要假设数据库的增长是线性的。
这么好的问题，没有给出真正的答案

【解决方案1】：

•初始大小应该是多少？

45GB？ 30 + 3 年的增长，特别是考虑到这适合低端廉价 SSD 磁盘；）如果您的最小 SSD 为 64GB，则大小不是问题。

...我应该在创建数据库后立即增加它的大小吗？

那会有点愚蠢，或者？我的意思是，为什么要创建一个小尺寸 jsut 的数据库来调整 IMMEDIEATLEY 的大小，而不是在第一步中将正确的大小放入脚本中。

自动增长设置应该是什么？

这不是一个数据仓库问题。没有自动增长。自动增长对您的光盘进行碎片整理。

确保按照最佳做法（64kb 节点大小、对齐分区）格式化光盘。

【讨论】：

我之所以说我应该创建一个小的初始大小然后增加它，是因为您不能将 db 文件缩小到小于初始大小。所以，如果初始大小很大，你就会被困住。
30gb 对你来说很大吗？我的意思是，真的，考虑到当今的技术微乎其微。
@TomTom 好吧，如果 30gb 很小，那很好。但我仍然想以最好的方式创建这个数据库。（我的错误包括大小并进入这个我的数据库比你的讨论更大）
Craig，如果您认为需要将数据库缩小到 30gb 以下（大概是在删除一些数据之后？），那么这可能是使用较小初始大小创建它的原因。然而，在大多数情况下，这似乎是一个不太可能的要求。在任何数据库中都很少需要收缩，因为数据往往会增长而不是收缩。在某些情况下，在创建测试/开发环境时缩小可能很有用，但是 30GB 已经很小了。所以我想问题仍然存在：你为什么要在未来缩小数据库？
@dportas 感谢您的评论。如果我需要一个副本来开发/测试，我可能想缩小数据库。我可以在我的开发/测试服务器上恢复，缩小数据库，然后继续工作。