旧数据归档

Question

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

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

信息

我想过两种可能：

创建类似于生产服务器上的数据库，并将所有旧数据插入新数据库中。

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

提前致谢

补充问题：

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

或者他们应该只有列但没有键/约束？

Answer 1

我认为您的许多问题的答案是视情况而定。你有什么性能问题？一个数据库仅仅从大小增长到 250GB 就会出现性能问题，这似乎是不寻常的。

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

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

我通常更喜欢历史数据库，我认为 Guy 在他的回复中描述了这样做的充分理由。

我看到的历史数据库（与模式相反）的主要缺点是您不能再为存档表使用外键。这对你来说可能没问题，但这是需要注意的。

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

有没有更好的可能性？

如果您需要定期查询存档数据，我可能会考虑按日期对表进行分区。然而，这是一个巨大的变化，可能会带来很多性能影响，既有积极的（例如，分区消除，更有效的数据加载），也有消极的（例如，较慢的单例搜索，并行查询中线程倾斜的可能性更大）。所以如果它是一个大量使用的数据库，我不会轻易做出这个决定。

新创建的存档表是否也需要主键/外键？或者他们应该只有列但没有键/约束？

我建议至少拥有主键和唯一索引，以便您可以获得它们提供的数据完整性优势。例如，这将防止您不小心将一年的数据插入历史表两次。如果您确实需要查询历史记录表，作为附带好处，它可以提高性能。

还有其他想法吗？

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

Answer 2

我更喜欢任何时候在链接服务器上拥有历史模式或第二个历史数据库。它节省了许可证成本，更易于管理和查询。然后，您还可以使用更简单的架构并删除一些使数据库更小的索引

但是由于您拥有企业版，您有第三种选择，即对您的表进行分区，当放置到位时，可以更轻松地存档数据并且查询旧数据对您的用户是透明的，您无需更改应用程序.

Answer 3

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

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