战略上保持巨大的数据库

我们有一个巨大的SQL Server 2005数据库（75GB），这基本上是在一个表的销售值仅仅是数据（每天，存储和文章）。我们希望通过将每年超过一年的记录的每周销售价值累计起来（仍按每个商店和文章分组）。因此，理论上对于一年以上的数据，我们可以删除6条记录中的6条。战略上保持巨大的数据库

写程序做，这是不是一个真正的问题，但它运行像永远。所以我一直在寻找一种可以让这款游戏在合理时间内运行的策略。

为了给你一个想法：运行SELECT count(*)跑了，4分钟内

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

任何人都得到了关于如何执行此任务的一个好策略？ TSQL方法的任何建议比基本的DML语句执行得更好？

来源

2011-11-07 Koen

你有没有考虑分片？ – moodywoody

不是一个真正的选择。数据越来越多，许多功能依赖于统计信息。不应该触摸架构... – Koen

要提升性能或减少使用的磁盘空间吗？你需要保持数据的粒度吗？ COUNT将始终需要时间，例如http://stackoverflow.com/questions/6069237/fastest-way-to-count-exact-number-of-rows-in-a-very-large-table/6069288#6069288此表格为当时的200GB + – gbn

如果你使用SQL Server 2005企业版，您应该考虑使用partitioning功能。优点：

通过在日期列上划分数据，查询将运行得更快，因为SQL Server将只访问特定的分区;这种方式，您可以运行日期范围，day->本周的过程，它会运行得更快（在同一时间运行在不同的日期范围的多个程序），如果你想保持你的每日数据
，只需将旧的分区以较慢的存储（硬盘）
你的程序应该准备在新表中的每周数据，然后switch partitions - 这是远远快于每天删除的数据，如果你不使用企业版插入每周数据

，请使用link来查看不基于SQL Server 2005分区功能的分区（分片或水平分区）功能。

对于存储过程的优化：

重新评估当前索引你的SP
考虑daily->本周过程在日期范围运行，例如，逐年或逐月 - 上运行的程序整个历史将是SQL Server和底层硬件做了大量的工作
可能是最好的办法是：以下有关日期范围上一个项目，创建基于旧的每周数据和最近的每日数据，然后创建索引，然后在一个新的表交易掉落原始表并使用sp_rename放置旧表而不是新的 - 重命名几乎是即时的，所以没有人会注意到延迟，如果这是重要的
考虑放弃目标表上的索引，因为插入会慢得多 - 只有当你正在原始表（删除+插入）

离题提示：如果使用企业版，考虑压缩表，因为SQL Server 2005通常擅长压缩事实表 - 您可能会同时获得性能和磁盘空间如果你有足够的CPU功率。

来源

2011-11-07 11:13:01

这是标准版。分片不是一种选择。我们无法更改架构，并且存在重叠的场景，例如一个星期可能会落在两个财务预订年，所以在这种情况下，我们需要分割星期的统计数据。你建议的解决方案是我们迄今为止已经有的，这是一个痛苦的屁股。它在一个月的数据上做了50分钟（太多）。任何想法哪些陈述是为此而设计的？我们现在使用的游标通常很慢，但这是我直到现在才得到的唯一方法... – Koen

您是否使用游标来遍历日历时段或迭代此表中的每条记录？您应该避免使用游标并在使用set-logic（而不是游标逐行逻辑）的答案中实现粗体项目。发布你使用的代码（整个过程与评论），所以我们可以检讨它。 PS：对此没有特定的DML，可能首先要做的是使用set-logic而不是光标 –

这就是重叠场景进入的地方。有几个例外，你不能只抓取和处理一整周，因为它只是统计上不正确。你的设定逻辑是什么意思？ – Koen

您可以请共享架构吗？

您是否尝试使用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缓存的更好的处理器。

来源

2011-11-08 05:46:09 oazabir

你能告诉我们更多关于你服务器的硬件吗？基本上，当数据变大时，需要大量的快速磁盘。

同样在标准版本上，您仍然可以创建子表格和对它们的查看以获得分区。通常，旧数据不会像新数据一样频繁查询，您可以通过将数据在快速磁盘上查询得到的数据与旧数据进行比较，从而避免这种情况的发生。

不确定数据访问模式是什么，但是您看过Analysis Services吗？您已经付钱了，它可以显示分析查询的戏剧性加速，因为它使用了大量的聚合。同样以前端为优秀的用户可以创建大量的报告，他们自己会花时间去完成相关的事情。

刚刚从我的一些想法，

RGDS格特 - 扬

来源

2011-11-08 06:49:31 gjvdkamp

我们刚刚被雇佣来完成这项工作。我们不能提出任何其他解决方案，因为这不在工作范围之内。这不是我自己的公司，硬件上没有发言权，也没有改变模式，因为依赖它太多了。否则，这个问题将在DBA网站上... – Koen

好的我明白了。大型DML操作可以减慢速度的是索引。您可以禁用它们，然后重建。（但不是您需要查找要更新的记录的人员）。这可以帮助很多。否则，我会建议一次做几个小批量，而不是一次全部小批量，因为它需要确保它可以回滚操作。 – gjvdkamp

战略上保持巨大的数据库

回答

相关问题