维护巨型数据库的策略

Question

我们有一个巨大的SQL Server 2005数据库（75GB），它基本上只是一个表中包含销售价值（每天，商店和文章）的数据。我们希望通过将每周超过一年的记录（每个商店和文章分组）的每周销售价值相加来实现。因此，理论上对于超过一年的数据，我们可以删除6条记录中的6条。

编写一个程序来执行此操作并不是一个真正的问题，但它会像永远一样运行。所以我一直在寻找一种可以在合理的时间内运行的策略。

为您提供一个想法：运行SELECT count(*)运行超过4分钟

我们确实有一些索引（在日期（群集）和商店，文章和日期组合）。添加更多索引也需要永远。

任何人都有如何执行此任务的良好策略？有关TSQL方法的建议比基本DML语句更好吗？

Answer 1

如果您使用SQL Server 2005 Enterprise Edition，则应考虑使用partitioning功能。优点：

• 通过在date列上对数据进行分区，查询运行得更快，因为SQL Server只能访问特定的分区;通过这种方式，您可以在日期范围内运行日 - >周程序，并且运行速度更快（并且可以同时在不同的日期范围内运行多个程序）。
• 如果您想保留每日数据，只需将旧分区移至较慢的存储空间（硬盘）
• 您的程序应该在新表中准备每周数据然后switch partitions - 它比删除每日数据并插入每周数据要快得多

如果您不使用Enterprise Edition，请使用此link查看不基于SQL Server 2005分区功能的分区（分片或水平分区）功能。

对于存储过程优化：

• 重新评估SP的当前索引
• 考虑每日 - >周过程在日期范围内运行，例如逐年或逐月运行 - 整个历史记录的运行过程将为SQL Server和底层硬件做大量工作
• 可能最好的方法是：按照上一个关于日期范围的项目，根据旧的每周数据和最近的每日数据创建新表，然后创建索引，然后在一个事务中删除原始表并使用sp_rename把旧表换成新表 - 重命名几乎是即时的，所以没有人会注意到延迟，如果这很重要
• 考虑在目标表上删除索引，因为插入它会慢得多 - 只有当你正在处理原始表时（删除+插入）

离题提示：如果使用Enterprise Edition，请考虑压缩表，因为SQL Server 2005通常擅长压缩事实表 - 如果你有足够的CPU能力，你可能会获得性能和磁盘空间。

Answer 2

你能分享一下架构吗？

您是否尝试过使用WITH（NOLOCK）或将ISOLATION LEVEL设置为READ UNCOMMITTED？

有时我们会注意到我们无法进行任何架构更改这一事实，我们必须找到解决方案而不做任何重大更改。您始终可以在基础表中进行更改，然后将视图公开给使用客户端。如果您有存储过程，那么表模式可以自由更改，因为存储过程将封装对表的访问。如果你说你不能改变存储过程，你也无法创建任何观点 - 我会质疑为什么你处于如此严格的政策之下，你认为你能用这样的政策生存多久。如果数据库在一年内增长到200GB会怎么样？那么你会采取严厉的方法，花费更多的时间和金钱来修复它吗？或者，当它还很小时，我们现在应该这样做吗？

我的建议是：

• 对表格进行分区。
• 让客户从不变的视图中读取数据。
• 让所有数据库操作都通过存储过程。
• 在存储过程中执行所有优化。

对于短期“修复”来缓解一些痛苦，你现在可以尝试：

• 如果您有SATA驱动器，请将它们转换为SAS。这将大大提升IO。
• 使用最适合阅读的RAID 5。
• 确保MDF和LDF处于完全不同的物理驱动器中。如果您负担得起，请将它们放在单独的RAID 5控制器中。否则将LDF置于RAID 1中，将MDF置于RAID 5中。
• 添加另一个驱动器并向其添加另一个MDF文件。然后，这将在新磁盘上传播新的插入，更新，删除。因此，将从多个磁盘执行读取，并可能为您提供更好的吞吐量。
• 重建聚集索引。
• 使用Windows Server磁盘碎片整理软件对磁盘进行碎片整理。
• 升级到具有更多L2缓存的更好的处理器。

Answer 3

您能告诉我们有关服务器硬件的更多信息吗？基本上，当数据大量放入大量快速磁盘时。

同样在标准版上，您仍然可以创建子表和视图，以便进行分区。通常，较旧的数据不会像新数据那样经常被查询，您可以通过将查询得最多的数据放在比较旧的数据更快的磁盘上来获得广告。

不确定数据访问模式是什么，但您是否查看了Analysis Services？您已经为此付费，它可以显示分析查询的显着加速，因为它使用了大量聚合。同样以excel作为前端，精明的用户可以自己创建大量报告，从而有时间去做有趣的事情。

我的一些想法，

Rgds Gert-Jan