Сокращение разбора вызовов в 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 #.

Как уменьшить количество разбора вызовов в этом?

Кроме того, есть ли какой-нибудь метод, который я могу различить между жесткими и мягкими анализами?

EDIT

Как упомянул @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

Таким образом, количество сложных разборов кажется очень низким по сравнению с количеством разборов. Спасибо всем за ответы :) 1023 *

ФИНАЛЬНОЕ ОБНОВЛЕНИЕ:

Основная проблема при разборе заключалась в том, что у нас отключен пул соединений в строке соединения. После включения пула подключений мне удалось полностью решить проблему синтаксического анализа.

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 к анализам, что, если они являются мягкими, означает, что вы не выполняете большую обработку курсора.

EDIT:

Если вы не можете изменить свой код, чтобы он открывался и висел на курсоре для каждого из ваших операторов 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;

Я обнаружил, что все операторы с наибольшим количеством вызовов синтаксического анализа были рекурсивным SQL, проанализированным SYS. Это может быть не так для вас, в зависимости от вашего использования, но это что-то проверить.