Question

我有一个Oracle（10.2.0.5）数据库并收集了一些性能参数，如下所示

Buffer Nowait %:    99.92   Redo NoWait %:  100.00
Buffer Hit %:   91.53   In-memory Sort %:   100.00
Library Hit %:  95.74   Soft Parse %:   96.68
Execute to Parse %: 31.75   Latch Hit %:    99.79
Parse CPU to Parse Elapsd %:    29.85   % Non-Parse CPU:    98.34

但我不确定如何解释数据并提出问题领域和建议。

有什么建议吗？

Answer 1

仅通过查看一些关键性能数据来调整数据库是不可能的。我建议对每个参数进行一些分析，以便对其含义有一个简要的了解。

我会从这些参数开始：

Buffer Hit% 91.53

这似乎很低。我正在使用的OLTP系统的缓冲命中率约为99％。通常这意味着，您的数据库cashe不包含您想要读取的数据，因此您必须从磁盘中读取块。

Execute to Parse %: 31.75

这似乎也很低。同样，可实现约99％的值。这个参数意味着，数据库经常解析语句。

Parse CPU to Parse Elapsd %: 29.85

充其量这个数字是100％。该值表示数据库花费1秒的CPU时间进行解析，3.35秒用于等待某些内容/其他人。

我无法告诉你这些是否真的是严重问题以及如何解决它们。这些参数至少是进一步分析的起点。

为什么关键绩效数据很低的一些想法：

共享内存太小
语句使用错误的执行计划（例如，执行全表扫描）
语句是动态创建的，而不是使用预准备语句
库和/或字典缓存存在并发性

如果您有统计数据包报告，那么进一步分析的另一个良好起点是“前5个定时事件”。

Answer 2

如果您不了解这些指标，您将如何管理您的推荐？如果我们告诉你，你需要加倍服务器的内存分配，你会做什么？转到你的老板并告诉他们，“StackOverflow上的一些随机的人说我们需要购买更多内存？”或者你不提这样的吗？在这种情况下，你打算如何回答你的老板下一个问题，这将是“为什么？”。或许，“我在小猫咪里有很多钱，你建议我们三倍我们的RAM吗？”假装专业知识是一个滑坡。

无论如何，通过尝试调整整个服务器来解决性能问题是一个众所周知的棘手和不可靠的做法。如果您真的想解决性能问题，请向您的用户询问最困扰他们的操作。这些可能不是长时间运行的查询：如果一个查询需要两秒钟，但它每天运行30000次，那么削减其经过时间半秒将对您的用户带来巨大的好处。此外，调整单个查询比整个数据库更容易。

基于参数的数据库性能分析

2 个答案: