Cada consulta SQL que envíe a un servidor debe pasar por tres (cuatro, en caso de SELECCIONAR) etapas. En primer lugar, Oracle buscará un hash SQL coincidente en la caché de la biblioteca. Si se encuentra el hash, solo recuperará el plan explain asociado y lo ejecutará. Si no, se invoca un análisis duro ->, lo que significa que se deben ejecutar los siguientes pasos.

1. ANALIZAR
   • comprobación de sintaxis
   • comprobación de semántica
   • comprobación de privilegios
2. BIND
   • reemplazar variables de enlace / host con valores reales
3. EXEC
   • ejecución real basada en un plan de explicación
4. FETCH (solo instrucciones SELECT)
   • devuelve un conjunto de resultados a un usuario

Permítanme explicar cada fase en el siguiente ejemplo.

Se ejecuta esta consulta:

SELECT *FROM employee;

El proceso del servidor generará un hash para la consulta SQL de problemas. El hash es un valor hexadecimal generado en base al texto de la consulta SQL. Aquí viene la parte importante!! Incluso el más mínimo cambio (mayúsculas a minúsculas y viceversa; agregar/eliminar un espacio; …) cambiará el hash y, por lo tanto, podría generar un análisis duro (más en el análisis duro vs análisis suave a continuación). Hay que tener mucho cuidado y tratar de atenerse a un solo código, es por eso que los procedimientos funcionan mejor (además de eso, en su mayoría usan variables de enlace que generan consultas idénticas a los ojos de Oracle).

Puede verificarlo fácilmente por su cuenta ejecutando las consultas a continuación:

-- first run this querySELECT * FROM dual;-- then run this one again with all uppercase lettersSELECT * FROM DUAL;-- check the sql hashes SELECT sql_id, sql_text, hash_valueFROM v$sqlWHERE 1=1AND lower(sql_text) LIKE '%select%from dual%'; sql_id | sql_text | hash_value--------------------------------------------------0x735fvggtnu6 | SELECT * FROM DUAL | 37411111103vyt9wdmca69b | SELECT * FROM dual | 1724193067-- As you can see Oracle evaluated it as two different queries.

Una vez que se genera el hash, Oracle comprueba si esta consulta ya se ejecutó en esta instancia. ¿Cómo? Comprobando si el hash ya existe en el Área SQL.

Suponiendo que esta consulta no esté disponible todavía, habrá un área SQL creada con el valor hash para esta consulta y el Oracle iniciará la primera etapa del procesamiento de la consulta y eso es ANALIZAR.

• Durante la comprobación de sintaxis, Oracle comprobará si la consulta es sintácticamente correcta (SELECCIONAR en lugar de SELECCIONAR; el orden correcto de los comandos – > SELECCIONAR * DEL ORDEN DE la tabla POR col1 DONDE col2 = ‘John’; etc).
• El siguiente paso son las comprobaciones semánticas, donde Oracle verifica si los nombres de columna y de objeto son correctos. ¿Cómo? Al cruzarlos con la caché de diccionario de datos
• En el último paso de la etapa de análisis, Oracle comprueba si el usuario/aplicación tiene los permisos correctos para acceder a los objetos consultados.

Una vez que esto termine, el Área SQL es válida y otra herramienta en Oracle llamada OPTIMIZER generará un plan de ejecución, lo que significa que el OPTIMIZADOR decidirá cómo se ejecutará la consulta. Una vez seleccionado el mejor plan de ejecución, Oracle vincula todas las variables y procede al tercer paso, la ejecución.

¿Qué va a pasar aquí? Oracle leerá los bloques de datos relacionados con los objetos consultados y los llevará a la caché de búfer (si aún no se presentan allí). Si están allí, ¡Oracle no los volverá a leer!). Este proceso generará E / S (que, como mencioné en el artículo Arquitectura informática, es muy lento en comparación con la lectura desde la memoria). Me detendré aquí por un tiempo y enfatizaré la generación de E/S. En el caso del análisis suave, todos los datos se leen desde la memoria (caché de búfer), que es mucho más rápido que leerlos desde un disco. Es por eso que debe esforzarse por reciclar/reutilizar sus consultas tanto como sea posible. Cada cambio de una consulta generará un nuevo hash y, por lo tanto, lo más probable es que genere E/S. Todo esto sigue siendo manejado por el proceso del servidor.

Ahora que los datos ya están en la memoria (caché de búfer), se procesa la instrucción SELECT y se activa la etapa final (FETCH) y el conjunto de resultados se devuelve al usuario.

Si se vuelve a ejecutar la misma consulta, se genera el hash y, dado que el Área SQL para ese hash ya existe, se omite la etapa de análisis y solo se ejecutan EXEC y FETCH.