1

我有一个 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

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

请问有什么建议吗？

4

2 回答 2

0

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

我将从这些参数开始：

Buffer Hit% 91.53

这似乎很低。我正在使用的 OLTP 系统的缓冲区命中率约为 99%。一般来说，这意味着您的数据库缓存不包含您要读取的数据，因此您必须从磁盘读取块。

Execute to Parse %: 31.75

这个好像也很低。同样可以达到 99% 左右的值。这个参数意味着，数据库非常频繁地解析语句。

Parse CPU to Parse Elapsd %: 29.85

这个数字充其量是 100%。该值表示数据库花费 1 秒 CPU 时间进行解析，并花费 3.35 秒等待某事/其他人。

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

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

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

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

于 2013-07-02T14:16:54.387 回答
0

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

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

于 2013-07-17T15:22:25.833 回答