由于数据库太大，我们当前遇到一些性能问题。有过去10年存储的数据，我看不出为什么必须将2年以上的数据与新数据存储在同一表中的原因。

现在，由于我在管理数据库方面没有很丰富的经验，因此我正在寻找归档旧数据的最佳方法。

信息

• 数据库中总共有约310'000'000条记录。

• 数据库在硬盘上需要250 GB。

• 服务器版本为具有兼容级别SQL Server 2005（90）的SQL Server 2008，但我们计划很快升级到SQL Server 2012

我考虑过两种可能性：

新资料库

在生产服务器上创建一个与之相似的数据库，并将所有旧数据插入新数据库中。

• 缺点：由于我们的环境中不允许使用链接服务器，因此如果需要，将很难加入旧数据

历史架构

使用与生产数据库相同的表创建新的模式fe [hist]。在新架构的这些新表中插入所有旧数据。

• 优势：易于加入，如果将来需要旧数据

• 您是否更喜欢其中一种解决方案？
  • 为什么？
• 还有更好的可能性吗？
• 是否有现有工具可轻松实现此任务？
• 还有其他想法吗？

提前致谢

编辑

附加问题：

新创建的存档表是否还需要主键/外键？

还是应该只包含列但没有键/约束？

我认为您对许多问题的答案取决于情况。您遇到什么性能问题？数据库从容量增长到250GB似乎会出现性能问题，这似乎很不寻常。

也许即使只需要日期范围的一小部分（例如，去年），您的查询仍在对整个事实表执行表扫描？如果存在最需要优化的特定查询，请考虑在另一个问题中发布您的架构，查询和实际执行计划，以查看是否可以对其进行优化。

您是否喜欢其中一种解决方案？

我通常更喜欢历史数据库，而且我认为Guy在回应中对此做了充分说明。

我看到的历史数据库（与模式相对）的主要缺点是您不能再将外键用于存档表。这对您可能很好，但是需要注意。

您为这种方法列出的缺点并不准确；您将能够轻松地查询同一服务器上的数据库，并且查询优化器通常可以很好地处理跨数据库查询。

还有更好的可能性吗？

如果您需要定期查询档案数据，我可以考虑按date对表进行分区。但是，这是一个很大的变化，可能带来很多性能影响，包括正向（例如，消除分区，更有效的数据加载）和负向（例如，较慢的单例查找，并行查询中线程偏斜的可能性更大）。因此，如果它是一个使用率很高的数据库，我不会轻易做出这个决定。

新创建的存档表是否还需要主键/外键？还是应该只包含列但没有键/约束？

我建议至少拥有主键和唯一索引，以便您可以获得它们提供的数据完整性好处。例如，这将防止您无意中两次将一年的数据插入历史记录表。另外，如果您确实需要查询历史记录表，则可以提高性能。

还有其他想法吗？

由于您正在使用企业版并计划升级到SQL 2008+，因此您可以考虑对该表进行数据压缩。压缩当然会减少磁盘空间，但是取决于服务器的磁盘和CPU资源，它还可以通过减少磁盘I / O和提高内存利用率（一次有更多数据放入缓存）来提高读取的查询性能。

我宁愿每天都在链接服务器上拥有一个历史架构或另一个历史数据库。它节省了许可证成本，更易于管理和查询。然后，您还可以使用更简单的架构并删除一些索引，从而使数据库更小

但是，由于您拥有企业版，因此​​有了第三个选项，即对表进行分区，将其放置在适当的位置使存档数据更加容易，并且查询旧数据对用户是透明的，并且您无需进行应用程序更改。

以我的经验，出于两个原因，第二个数据库将是首选。

1. 您可以从历史备份中还原数据，然后删除不需要的表和索引。
2. 您可以将其移至其他服务器以进行报告，这具有不使用主服务器资源的优势。

您仍然需要从主数据库中删除所有历史数据，但这可以安排在其中。

现在忽略许可证，因为那不是我的时间。

恕我直言，存档数据库是最简单的实现和维护。它们是不同的，松散耦合的实体。数据移动和加载/资源控制具有明确的界限。可以轻松地移至其他实例或服务器以进行更好的性能管理，而成本并不是主要问题。请注意，最简单的！=最省力或省力。它实际上有很多任务，但是它们都是简单的任务，但有两个重要的例外：

1. 约束执行-SQL Server中没有跨数据库约束之类的东西，因此您需要确定这是否破坏交易。
2. 跨数据库查询使用的分布式查询仍然取决于不推荐使用的OLEDB。这意味着您可能会遇到新数据类型的问题，如果您遇到性能问题，也不太可能解决这些问题

归档模式或仅归档表的实现要复杂一些，但使用起来却容易得多。同一数据库中的所有对象意味着您不必复制和维护访问控制。无需跨数据库查询，可轻松进行性能调整，监视，故障排除等。

表分区是一个很好的解决方案，并提供了存档表/架构的许多优点，但对用户/查询透明。也就是说，这是实施起来最复杂的过程，需要持续不断的护理，这对于初学者来说并不容易。

一些重要的注意事项：

• 查询是否定期返回历史/冷数据，还是很少访问冷数据？
• 历史数据是不可变的，还是会定期更新/删除？
• 根据行的大小，310m行是“中等”的（假定全部集中在1个表中）。您有行大小数据吗？那310m行有多少GB？
• 那张桌子的增长率是多少？
• 您是否可以修改应用程序代码及其SQL查询？

这些是重要的考虑因素，因为它们可能会对您选择的解决方案产生重大影响，甚至可能不允许某些解决方案。例如，如果您的历史数据定期（每周一次以上）被修改/更新，则使用单独的数据库意味着您必须对这些查询使用DTC或手动管理交易安全性（不琐碎以确保始终正确）。成本大大高于不变的历史数据。

另外，如果您要升级，请考虑使用2016和新的Stretch Database功能：https : //msdn.microsoft.com/zh-cn/library/dn935011.aspx

由于以下原因，我希望将数据库拆分为单独的逻辑数据库：

1.资源需求

通过将其拆分为单独的数据库，可以将其存储在其他驱动器上，并以与主要生产数据不同的速率对其进行监视。

2.表现

通过将数据拆分到一个单独的数据库中，可以减少主生产数据库的大小，从而提高整体性能。

3.更简单的备份

与主SQL数据库中的“活动/当前”记录相比，备份存档的数据可能并不重要。这可能意味着可以减少备份备份数据的频率。同样，由于记录归档数据的方式具有顺序性，因此有可能一次备份归档数据库的各个部分，然后再也不备份。例如，一旦将存档数据写入2014年的更改存档数据库，就不会再对该数据进行任何更改。

注意：我认为您的许多问题的答案都取决于您的情况，数据的性质和所遇到的性能问题。