Talleres Oracle Backup & Recovery

USO DE VARIABLES BIND

Una de las claves en el mejor rendimiento de la Base de Datos es la reutilización del trabajo efectuado por
el Optimizador. El Optimizador tiene como tarea recibir las sentencias ejecutadas por los usuarios,
analizarlas la sentencia SQL sintácticamente, verifica en el diccionario de datos la existencia de los objetos
(tablas, vistas) invocados, valida que el usuario que ejecutara la sentencia cuenta con los privilegios, que
las tablas cuenten con las columnas que se mencionan y otras validaciones.

Una vez validada la sentencia, obtiene el PLAN DE EJECUCION que es la estrategia elegida para acceder a
los datos y obtener los resultados. Aquí optara entre efectuar un TABLE ACCESS FULL (lectura de toda la
tabla), INDEX RANGE SCAN (acceso a través del índice) o sin dos tablas combinaran antes o después que
las demás.

Una vez obtenido estos resultados se procede a compilarlos, proceso que consume alto nivel de CPU, a
todo este proceso detallado anteriormente se conoce como PARSE

Ahora tratemos de cuantificar cuantas sentencias distintas contienen nuestras aplicaciones, 10 mil, 15
mil, lo cierto es que si el aplicativo cubre más procesos de negocio contara con cada vez más sentencias
distintas. Cada una de estas sentencias deben ser PARSING en algún momento. Un alto número de
PARSES puede llegar a saturar el CPU y provocar un cuello de botella.

El compilado obtenido se guarda en el Library Cache para que cuando algún usuario utilice la misma
sentencia evitemos el PARSE y reutilicemos lo alojado en memoria. Disminuyendo sustancialmente el uso
de CPU.

VISTAS ADMINISTRATIVAS UTILIZADAS:

Vista Descripción
V$SQL Muestra las sentencias compiladas y alojadas en
el library cache.

Complementa con el número de ejecuciones,

consume de CPU, Lecturas en Disco y otras
estadísticas de cada sentencia.

CASO 1 :
En el siguiente caso se mostrará como el uso de VARIABLES COMO LITERALES, obliga al OPTIMIZADOR
a PARSEAR en forma innecesaria a diferencias del uso de BIND VARIABLES que optimiza el uso del
consumo de CPU.

a. SENTENCIA CON USO DE VARIABLES COMO LITERALES

Procedemos a ejecutar las siguientes sentencias:

SELECT * FROM hr.jobs WHERE job_id = 'SA_MAN';

SELECT * FROM hr.jobs WHERE job_id = 'AD_PRES';
SELECT * FROM hr.jobs WHERE job_id = 'AC_ACCOUNT';
Talleres Oracle Backup & Recovery

Procedemos a consultar el Library cache y comprobamos que cada una de las sentencias ha
pasado por el PARSING, consumiendo CPU y espacio de alojamiento en memoria.

SELECT executions , disk_reads, buffer_gets , sql_text

FROM V$SQL WHERE SQL_TEXT LIKE 'SELECT * FROM hr.jobs WHERE job_id =%';

Podemos comprobar que en el Library cache se alojan compilados por cada sentencia (3),
debido a que se utiliza literales cuando debería utilizarse variables.

Nota 1 : Si deseas borrar el contenido del Library Cache usar:

ALTER SYSTEM FLUSH SHARED_POOL;

Nota 2 : Si deseas borrar el contenido del Buffer Cache usar:

ALTER SYSTEM FLUSH BUFFER_GETS;

b. SENTENCIA CON USO DE VARIABLES DE ENLACE

En el siguiente ejemplo lanzaremos las mismas sentencias anteriores, utilizando variables:

SQL>VARIABLE JOB VARCHAR2(10)

SQL>EXEC :JOB := 'SA_MAN'
SQL> SELECT * FROM hr.jobs WHERE job_id =: JOB;

SQL>VARIABLE JOB VARCHAR2(10)

SQL>EXEC :JOB := 'AD_PRES'
SQL> SELECT * FROM hr.jobs WHERE job_id =: JOB;

SQL>VARIABLE JOB VARCHAR2(10)

SQL>EXEC :JOB := 'AC_ACCOUNT'
SQL> SELECT * FROM hr.jobs WHERE job_id =: JOB;

CONCLUSION:
Podemos comprobar que el uso de variables de enlace, permita reutilizar los compilados de
sentencias con características similares evitando uso innecesario de CPU y espacio en el Library
cache.