miércoles, 9 de enero de 2013

Result Cache en Oracle Database 11gR2

Introducción

A partir de la versión Oracle Database 11g se cuenta con un espacio de memoria RAM llamado Result Cache que se encuentra alojado dentro del pool Shared Pool con la finalidad de almacenar resultados de queries y funciones PL/SQL que se ejecuten en el servidor de base de datos.


Este nuevo sub pool es muy útil para almacenar resultados de aquellos queries que analizan grandes cantidades de filas y retornan pocas filas; también para funciones PL/SQL que son frecuentemente utilizadas y cuyo resultado depende de información que no cambia mucho en el tiempo.


Implementación


Configuración del Result Cache


Por default el Result Cache almacena una cantidad de memoria RAM por default acorde a la siguiente regla:


a) Si está configurado la base datos con el parámetro MEMORY_TARGET, el Result Cache será  configurado con el 0.25% del valor del parámetro MEMORY TARGET automáticamente.


b) Si está configurado la base de datos con el parámetro SGA_TARGET, el Result Cache será configurado con el 0.5% del valor del parámetro SGA_TARGET automáticamente.


c) Si está configurado el parámetro SHARED_POOL_SIZE, el Result Cache será configurado con 1% del tamaño del valor del SHARED_POOL_SIZE automáticamente.


Si en caso queramos definir un tamaño al Result Cache de forma predeterminada debemos configurar un valor al parámetro RESULT_CACHE_MAX_SIZE. Si el parámetro es configurado con el valor de 0 se deshabilita el sub pool Result Cache.


Asimismo la cantidad máxima de memoria que se puede albergar como resultado de un query o función PL/SQL se define por el parámetro: RESULT_CACHE_MAX_RESULT, cuyo valor por default es de 5% respecto al tamaño del Result Cache.



Utilización para setencias SQL


Si deseamos que el resultado de un query se almacene dentro del Result Cache debemos utilizar el hint result_cache, ejemplo:


SQL> select /*+ result_cache */ count(*) from producto;


Al colocarle el hint de result_cache hace que el resultado del query se guarde en el Result Cache y una vez almacenado recién se devuelva el resultado al usuario.


Si nosotros ejecutamos el query por segunda vez, veremos en el plan de ejecución del query, que el resultado es obtenido del Result Cache haciendo que no sea nuevamente calculado:




Toda operación DML (insert/delete/update) ó DDL (alter table) sobre tablas que influye sobre los resultados almacenados en el Result Cache ocasiona que dichos resultados sean invalidados. En este escenario, el query tendrá que volver a calcular el resultado porque su resultado en el Result Cache fue invalidado.

Asimismo el parámetro RESULT_CACHE_REMOTE_EXPIRATION permite invalidar el resultado de un query que haga llamadas a objetos remotos. Por default tiene el valor de 0, es decir no se almacena resultados que se calculan en base a información de objetos remotos. El valor del parámetro es expresado en segundos.


Si nosotros queremos que el resultado de todo query o función PL/SQL se almacene en el Result Cache sin utilizar el hint result_cache configuramos el parámetro RESULT_CACHE_MODE con el valor de FORCE; por default este parámetro tiene el valor de MANUAL. En caso lo configuremos con el valor de FORCE podemos utilizar el hint no_result_cache si queremos que no se almacene en el Result Cache.


Nota 1: Si deseamos que el Result Cache a pesar de estar configurado sea omitido podemos ejecutar el siguiente procedimiento: DBMS_RESULT_CACHE.BYPASS(true) y colocándole el valor de false volvemos a dejar el Result Cache en modo normal.


Nota 2: No podemos usar Result Cache en sentencias SQL si estas utilizan los siguientes objetos: Tablas temporales, tablas del diccionario de datos, funciones no deterministicas como currval, nextval, sysdate, etc.



Utilización para funciones PL/SQL


Una función PL/SQL debe tener la cláusula RESULT_CACHE si queremos que su resultado se almacene en el Result Cache, ejemplo:




Nota: En la versión Oracle Database 11gR1 se requería la cláusula RESULT_CACHE RELIES ON (), donde la cláusula RESULT_CACHE indica a Oracle Database que invalide el resultado de la función almacenada en el Result Cache para cualquier operación DML o DDL que ocurra sobre la tabla que se liste en el cláusula. En My Oracle Support (MOS) Nota: 1142314.1 (Processes Terminate With ORA-7445 [__intel_new_memcpy()] Errors After Upgrade to 11.2), se especifica que la cláusula RELIES ON ya no debe ser especificada en versiones Oracle Database 11gR2 hacia adelante.

Las restricciones que tiene las funciones PL/SQL sobre Result Cache es que ellas no deben ser funciones pipelined, no pueden tener parámetros out/in out y si son parámetros in no pueden ser de tipo LOB, ref cursor, objetos y colecciones.


Reportes & Validación


a) Si deseamos obtener un reporte del espacio utilizado en el Result Cache podemos utilizar la función: DBMS_RESULT_CACHE.MEMORY_REPORT.




b) La vista V$RESULT_CACHE_STATISTICS permite visualizar cuantos resultados fueron almacenados en el Result Cache y asimismo cuantas veces un query obtuvo sus resultados del cache.




c) Si deseamos ver los queries que tienen resultados guardados en el Result Cache y además de visualizar con que tablas tiene dependencias, estos resultados consultamos la vista: V$RESULT_CACHE_OBJECTS.


d) Para obtener un reporte de cada resultado almacenado en el Result Cache con que objetos de la base de datos tiene dependencia consultamos la vista: V$RESULT_CACHE_DEPENDENCY.

e) Si deseamos limpiar la cache del Result Cache ejecutamos el siguiente procedimiento:

SQL> execute DBMS_RESULT_CACHE.FLUSH;


Result Cache Client


Oracle Database 11g también nos da la posibilidad de utilizar la memoria del lado del cliente para almacenar los resultados de las sentencias SQL que ejecute la aplicación cliente.


Al habilitar el Result Cache Client evitamos viajes innecesarios al servidor de Base de Datos además de ahorrar espacio en él ya que el resultado se almacena en la capa del cliente y no en el caché del servidor. El resultado almacenado en el Result Cache Client es independiente al Result Cache Server, es decir el Result Cache Client puede ser configurado sin que esté configurado el Result Cache en el servidor.


La base de datos es responsable de invalidar un resultado almacenado en el Result Cache Client cuando una operación DML o DDL ha ocurrido sobre un objeto que influye en el resultado de una operación almacenada.


Result Cache Client está habilitado para aplicaciones Oracle OCI, JDBC OCI, ODP.NET, Pro*C, Pro*Cobol y ODBC y no está habilitado por default. El cliente Oracle debe tener una versión mínima a 11gR1 y no está soportado para conexiones beaqueth.


Nota: Subqueries, vistas, objetos remotos, flashback queries, queries que incluyen funciones PL/SQL y queries que referencian políticas VPD en una tabla no son enviados al cache.


Parámetros relacionados a su configuración:


a) CLIENT_RESULT_CACHE_SIZE, determina el máximo tamaño del resultado de un query que un cliente puede almacenar en su cache.


Si su valor es 0 entonces el Result Cache Client está deshabilitado.


b) CLIENT_RESULT_CACHE_LAG, indica el número de segundos que el cliente Oracle validará contra el servidor la consistencia de la información en cache, no es obligatorio su configuración.


Para obtener las métricas del trabajo realizado por el Result Cache Client podemos consultar la vista: CLIENT_RESULT_CACHE_STATS$.


Conclusión


Concluimos que Oracle Database 11g ha diseñado un nuevo sub pool llamado Result Cache que nos ayuda almacenar resultados de nuestros queries y funciones PL/SQL en ventaja de que si son nuevamente invocados dichas operaciones, el trabajo no tenga que ser nuevamente calculado, evitando un gasto innecesario de recursos en la base de datos y por el lado del usuario es una mejora considerable en el tiempo de respuesta.




Publicado por Ing. Francisco Riccio. Es un IT Specialist en productos Oracle e instructor de cursos oficiales de certificación Oracle. Está reconocido por Oracle como un Oracle ACE y certificado en productos de Oracle Application & Base de Datos.

e-mail: francisco@friccio.com

web: www.friccio.com

No hay comentarios:

Publicar un comentario