定期进行性能调整和维护

Question

您经常进行定期维护，例如对应用程序进行压力测试和/或调整应用程序的数据库索引？

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

Answer 1

在代码不断发展的实时生产系统中，每一天都是压力测试。类似地，数据库调整是关于何时停止;当表现可以接受时，你就停止了。

具体到甲骨文，关于是否重建指数的争论已经持续多年;有些人相信这样做，有些则不这样做。索引是B *树结构;它将准确反映表格中的数据。在许多情况下（例外情况），重建指数类似于进行崩溃饮食;当然，索引在短期内会变得很脆弱，但随着时间的推移 - 可能只需要几天或几小时的处理 - 它们将恢复到以前的状态。只要性能达到目标，为什么要担心呢？重建索引会生成重要的I / O活动（必须读取表和/或索引），并生成重要的重做活动（为新索引条目写入重做向量）或需要立即备份（如果使用NOLOGGING重建索引，索引现在无法恢复。）

例外：

• 位图索引通常应该是 脱机并重建之间 dataloads，因为它们可以在病理上 通过DML活动膨胀

• 如果有的话 从根本上卸载了很多 数据并使用全局索引或 一些其他非本地分区索引， 合并（不是重建，只是 推动邻近的相邻空间 叶子在一起）可能是谨慎的。

Answer 2

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

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

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

Answer 3

我的猜测是，当客户首次抱怨性能时，这可能会发生，而不是之前。

Answer 4

在安装任何新版本之前，我们的（网络）应用程序在预生活环境中经过压力测试。测试计划由直接向客户报告的外部公司开发和执行。

唯一的问题是：通常情况下，在现场环境中存在性能问题，即使在预生活压力测试完美无缺的情况下 - “合成”负载似乎与“实际”负载有太大差异。