减少 Oracle 中的解析调用

Question

我注意到 parse_calls 等于我们的 Oracle 11g 数据库中的执行次数。

 select parse_calls, executions
 from v$sql order by parse_calls desc;

运行上述查询会得到以下结果。

"PARSE_CALLS" "EXECUTIONS"
   87480        87480
   87475        87476
   87044        87044
   26662        26662
   21870        21870
   21870        21870

据我所知，这是一个主要的性能缺陷。所有这些 SQL 语句要么是存储过程，要么是使用绑定变量。我还重用了从 C# 调用存储过程的命令对象。

如何减少其中的解析调用次数？

另外，有什么方法可以区分硬解析和软解析吗？

编辑：

正如@DCookie 提到的，我在数据库上运行了以下查询。

SELECT s2.name, SUM(s1.value)
FROM v$sesstat s1 join v$statname s2 on s1.statistic# = s2.statistic#
WHERE s2.name LIKE '%parse count%'
GROUP BY s2.name
ORDER BY 1,2;

结果如下

"NAME"                         "SUM(S1.VALUE)"
"parse count (describe)"             0
"parse count (failures)"             29
"parse count (hard)"                 258
"parse count (total)"                11471

所以硬解析的数量与解析的数量相比似乎非常低。感谢大家的回复:)

最终更新：

解析的主要问题是因为我们在连接字符串中关闭了连接池。打开连接池后，我能够完全解决解析问题。

Answer 1

从这里开始：

SELECT name, SUM(value)
  FROM v$sesstat s1 join v$statname s2 on s1.statistic# = s2.statistic#
 WHERE s1.name LIKE '%parse count%'
 GROUP BY name
 ORDER BY 1,2;

这将为您提供硬解析次数和总解析次数。查询中的 parse_calls 值是总解析，硬解析和软解析。

您的 SQL 是做什么的？没有太多的游标处理，主要是单个语句？您的执行与解析的比率几乎是 1-1，如果它们是软解析，则意味着您没有做太多的游标处理。

编辑：

除非您可以修改代码以打开并挂起每个 SQL 语句的游标，并在会话中尽可能多地重用它们，否则我认为您无法避免解析。

Answer 2

每次创建新游标时都必须进行解析调用，即使语句在库缓存中也是如此。检查库缓存的是解析调用。如果在库缓存中找到该语句，则为软解析。

@DCookie 已回答您关于检查硬解析计数与软解析计数的问题。我希望您会发现大多数解析调用都是软解析。请注意，您不应期望从v$sysstat 返回的计数非常接近来自v$sql 的总解析调用，因为前者是自实例启动以来的计数，而后者仅显示当前在库缓存中的语句.

完全避免解析调用的唯一方法是保留现有游标的句柄，并在需要时执行它，并在适当时绑定新值。这有时会通过缓存游标而发生——它超出了您的明确控制范围，尽管我相信您可以更改一些参数来影响它。在 PL/SQL 代码中，您可以显式保留使用 DBMS_SQL 包创建和管理的游标。我希望 C# 有相应的能力。

无论如何，您正在查看的内容可能不是问题。仅仅因为计数看起来很高并不意味着解析是您​​系统的瓶颈。

首先，您应该检查具有高解析计数的 SQL 语句是否在您的控制范围内。当我在我的一个系统上对您的查询进行修改版本时：

select parse_calls, executions, parsing_schema_name,sql_text
 FROM v$sql
 ORDER BY parse_calls DESC;

我发现解析调用次数最多的语句都是SYS解析的递归SQL。根据您的使用情况，您可能不是这种情况，但需要检查一下。