Cuando la aplicación escribe los valores en el texto del SQL en lugar de usar bind variables, cada valor diferente se convierte en una sentencia nueva para la base de datos, con PARSE propio y, en general, hard parse propio. Esta sección agrupa esas sentencias por la forma del texto y muestra cuánto cuestan sumadas.
Qué muestra la sección
La sección Textos compartibles aparece cuando el trace tiene sentencias que solo difieren en los literales. El texto de arriba lo resume: Sentencias que solo difieren en literales. Con bind variables, un único cursor serviría para todas y los PARSE con hard parse bajarían.
La forma es el texto de la sentencia con cada literal cambiado por un marcador: :s para texto entre comillas y :n para número. Quedan como están los nombres entre comillas dobles y los binds, como :1 y :b1; los números dentro de comentarios y sugerencias también se convierten en :n. Las sentencias con la misma forma son sus variantes. Estas dos sentencias:
select nome from exemplo where id = 101
select nome from exemplo where id = 102son dos variantes de esta forma:
select nome from exemplo where id = :nLa sección lista las formas con dos variantes o más que más tiempo sumaron, de la que más sumó a la que menos.
Cómo leerla
| Columna | Qué indica |
|---|---|
| Textos | Cuántas variantes tiene la forma: cuántas sentencias diferentes tiene el trace con esa forma. Cuando el recuento es estimado, aparece como alrededor de N (trace con muchas sentencias). |
| PARSE | La suma de las llamadas PARSE de las variantes. |
| PARSE (s) | La duración sumada de esos PARSE. |
| Total (s) | La suma del tiempo inclusivo de las variantes: la duración de todas sus llamadas. |
| SQL IDs | Algunos sql_id de variantes, para buscar en la base de datos. Con la Privacidad de los informes activada, la columna muestra ocultos por la máscara. |
| Ejemplo | El texto de la forma, con :s y :n en lugar de los literales. Cuando la forma está entre las sentencias del informe, el texto viene con su número, como #3, y lleva al detalle, donde están las variantes que más gastaron. Cuando dos formas empiezan igual, cada una muestra el comienzo, un … y la parte en la que difiere de las otras. |
Las variantes en las listas de sentencias
En las listas del informe, cada forma con dos variantes o más es una sola fila, con la etiqueta N variantes antes del texto: en Sentencias SQL, en Sentencias por componente, en el SQL recursivo de cada sentencia, en Llamadas más largas y en la tabla Dónde apareció de los errores. El texto de la fila es la forma, y la contribución, las llamadas y el tiempo son la suma de las variantes: el perfil y el tiempo total no cambian. La fila de la forma no tiene SQL ID, porque cada variante tiene el suyo. Cuando el recuento de variantes es estimado, la etiqueta dice alrededor de N variantes. El PARSE ERROR, que no tiene cursor, sigue identificado por su propio texto.
En el detalle de la forma, la tabla Variantes que más gastaron muestra las variantes con más tiempo en sus propias llamadas, con el SQL ID, las llamadas, el tiempo y los literales de cada una (variantes que más gastaron).
Con la Privacidad de los informes activada en Mi cuenta, los literales de las variantes salen con *** según las opciones marcadas, y los SQL IDs de las variantes no aparecen con ninguna de ellas, ni en esta sección ni en el detalle: el sql_id se calcula a partir del texto con los valores y permitiría descubrir el literal oculto (literales ocultos).
Cuándo preocupa
El Diagnóstico muestra el hallazgo Sentencia #n: n variantes del mismo SQL, solo con literales diferentes (LITERAIS_SEM_BIND) para las formas con muchas variantes en las que el PARSE pesa en el tiempo de la sesión, con el enlace Ver sentencia #n. El texto del hallazgo dice cuántos PARSE hicieron las variantes, cuántos de ellos fueron hard parse, cuánto tiempo tardaron y cuánto suman las variantes con todas las llamadas y el SQL recursivo.
La gravedad es baja o media: sube cuando el PARSE de las variantes pesa más en la sesión. Una forma puede aparecer en esta sección sin hallazgo, por ejemplo cuando las variantes son pocas o su PARSE casi no cuesta.
La corrección es usar bind variables en la aplicación. CURSOR_SHARING=FORCE en la base de datos reduce los hard parses mientras la aplicación no cambia, pero es solo un paliativo (literales en lugar de bind).
Otras secciones dan la misma señal: PARSE con Misses cerca de Cantidad en Tipos de llamada (muchos hard parses) y, en el perfil, la CPU del PARSE y las esperas de Concurrency en la shared pool y en la library cache, cuyas tarjetas apuntan a esta sección.
Adónde ir después
El trace sintético del ejemplo no tiene sentencias que solo difieran en los literales, y el informe de ejemplo no tiene esta sección. Los informes de los casos reales sí la tienen: vea la sección en el caso 1 y en el caso 2, y el hallazgo de literales en el Diagnóstico del caso 1.
- Literales en lugar de bind, para la causa y la corrección.
- Muchos hard parses, el efecto más común en el tiempo.
- Sentencias SQL, donde la forma aparece como una sola fila.