Reducción de llamadas parse en Oracle

Question

Me doy cuenta de que las llamadas parse son iguales a la cantidad de ejecuciones en nuestra base de datos Oracle 11g.

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

Al ejecutar la consulta anterior se obtiene el siguiente resultado.

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

Como soy consciente, este es un inconveniente de rendimiento importante. Todas estas declaraciones SQL son procedimientos almacenados o utilizan variables de vinculación. También estoy reutilizando los objetos de comando que llaman a los procedimientos almacenados desde C#.

¿Cómo puedo reducir el número de llamadas parse en esto?

Además, ¿hay algún método que pueda distinguir entre análisis fijos y análisis suaves?

EDITAR:

Como se mencionó @DCookie me encontré con la siguiente consulta en la base de datos.

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; 

El resultado es la siguiente

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

Por lo tanto el número de análisis sintácticos duros parece ser muy baja en comparación con el número de análisis sintácticos. Gracias a todos por sus respuestas :)

INFORME FINAL DE ACTUALIZACIÓN:

El principal problema para el análisis fue porque teníamos la agrupación de conexiones desactivada en la cadena de conexión. Después de activar la agrupación de conexiones, pude resolver completamente el problema de análisis.

Answer 1

de inicio con esto:

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; 

Esto le dará el número de análisis sintácticos duros y analiza totales. Los valores de parse_calls en su consulta son totales, duros y blandos.

¿Qué hace su SQL? ¿No hay mucho procesamiento del cursor, en su mayoría declaraciones individuales? Obtiene una proporción de ejecuciones de 1-1 a parses, que, si son análisis suaves, significa que no está procesando mucho el cursor.

EDIT:

menos que se puede modificar el código para abrir y aferrarse a un cursor para cada una de las sentencias SQL, y volver a utilizarlos tanto como sea posible dentro de una sesión, no creo que se puede evitar el analizador

Answer 2

Una llamada de análisis debe tener lugar cada vez que se crea un cursor nuevo, incluso si la declaración está en la memoria caché de la biblioteca. Es la llamada de análisis que verifica el caché de la biblioteca. Si la declaración se encuentra en el caché de la biblioteca, es un análisis suave.

@DCookie ha dado una respuesta a tu pregunta sobre la verificación del recuento de parse duro y suave. Espero que encuentres que la mayoría de las llamadas parse son parches suaves. Tenga en cuenta que no debe esperar que los recuentos devueltos desde v$sysstat estén muy cerca de las llamadas de análisis totales desde v$sql, ya que el primero es un conteo desde el inicio de la instancia y el último simplemente muestra las declaraciones que están actualmente en el caché de la biblioteca.

La única manera de evitar completamente las llamadas de análisis es mantener un control sobre un cursor existente y ejecutarlo cuando sea necesario, vinculando nuevos valores cuando sea apropiado. Esto ocurrirá a veces mediante el almacenamiento en caché de los cursores; está fuera de su control explícito, aunque creo que hay parámetros que puede cambiar para afectarlo. En el código PL/SQL puede retener explícitamente los cursores que crea y administra utilizando el paquete DBMS_SQL. Yo esperaría que C# tenga las capacidades correspondientes.

En cualquier caso, lo que está mirando probablemente no sea un problema. El hecho de que el conteo parezca alto de ninguna manera implica que el análisis sea un cuello de botella en su sistema.

En primer lugar, debe comprobar si las declaraciones SQL con esos altos recuentos de análisis están incluso bajo su control. Cuando hice una versión modificada de la consulta en una de mis sistemas:

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

he encontrado que los estados con el mayor número de llamadas de análisis sintáctico estaban SQL recursivo analizada por SYS. Puede que este no sea el caso para usted, dependiendo de su uso, pero es algo que debe verificar.