定期性能调整和维护答案

【问题标题】：Regular performance tuning and maintenance定期性能调整和维护
【发布时间】：2010-02-13 05:09:53
【问题描述】：

您多久进行一次定期维护，例如对应用程序进行压力测试和/或为应用程序调整数据库索引？

EG，您是否每周、每六个月或仅在输入大量数据后调整（碎片整理、重组或重建）您的数据库索引，并且您是否每周在每次主要或次要构建后对您的应用程序进行压力测试，每年一次，从不？

【问题讨论】：

我想知道这是否会更好地转移到 ServerFault：这似乎是关于管理工作安装的问题......
我认为这个问题上的风滚草显示了它的完成频率。

标签： language-agnostic performance maintenance stress-testing database-optimization

【解决方案1】：

在代码不断发展的实时生产系统中，每一天都是一次压力测试。同样，数据库调优是关于知道何时停止；当性能可以接受时，你就停下来。

特别是对于 Oracle，关于是否重建索引的争论已经激烈了多年；有些人相信这样做，有些人不相信。索引是一个 B*tree 结构；它将准确地反映表中的数据。在许多情况下（有例外情况），重建索引类似于节食；当然，这些索引在短期内会变瘦，但随着时间的推移——可能只需几天或几个小时的处理时间——它们会恢复到以前的状态。只要绩效达到目标，何必担心呢？重建索引会产生大量的 I/O 活动（必须读取表和/或索引），并且会产生大量的重做活动（为新的索引条目写入重做向量）或需要立即备份（如果您使用 NOLOGGING 重建索引，索引现在不可恢复）。

例外：

位图索引通常应该是脱机并在之间重建数据加载，因为它们可以病理性地通过 DML 活动膨胀
如果有一个从根本上卸载了大量数据并且正在使用全局索引或其他一些非本地分区索引，合并（不是重建，只是将相邻空间推向相邻空间一起离开）可能是谨慎的。

【讨论】：

【解决方案2】：

当我在一家大型 3D CAD 公司工作时，我们进行了一些测试：

只要您想签入代码。大约40个测试。您必须通过所有测试才能签入代码（您还必须通过代码审查）。
每当构建服务器完成滚动构建时
每晚（许多测试，大约需要 8 小时）。
每周一次（甚至更多测试 - 这组测试需要很多天才能完成）。

每个测试都加载了一个由 QA 团队创建的特定 3D 模型，以强调各种问题。我确信某些模型是客户提供的，以强调以前已知的客户错误。模型的大小范围从微米到 1 公里，所有 3 个方向。

【讨论】：

【解决方案3】：

我的猜测是，当客户第一次抱怨性能时，可能会这样做，而不是之前。

【讨论】：

【解决方案4】：

在实时安装任何新版本之前，我们的（网络）应用程序在上线前的环境中进行了压力测试。测试计划由直接向客户报告的外部公司制定和执行。

唯一的问题：在实时环境中经常会出现性能问题，即使在实时压力测试完美无缺的情况下——“合成”负载似乎与“真实”负载相差太大。

【讨论】：