Hemos escrito muchos artículos sobre recomendaciones de todo tipo en este pase obligatorio que debemos hacer, sin embargo, sólo la experiencia en uso, es la que puede dar mejores parámetros de comparación y tomas en consideración.
Hay una nota interesante en MOS ( My Oracle Support ), el documento ID 793845.1 actualizado el 20 de mayo del presente año, aplicable para cualquier plataforma corriendo Oracle Database E.E. 11g.
Puede ser que puedas experimentar el siguiente comportamiento:
top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avg
wait % DB
Event Waits Time(s) (ms) time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
DB CPU 13,916 42.1
direct path read 1,637,344 13,359 8 40.4 User I/O
db file sequential read 47,132 1,111 24 3.4 User I/O
DFS lock handle 301,278 1,028 3 3.1 Other
db file parallel read 14,724 554 38 1.7 User I/O
Esta situación no es desconocida y tiene su origen en el cambio del comportamiento del optimizador de la base de datos, a la hora de hacer FTS sobre tablas muy "grandes".
En la versión 10g, los barridos serializados sobre tablas "grandes", se realizaba de facto a través del buffer cache. En 11g, la decisión entre realizar el barrido a través de "direct path reads" o a través de buffer cache, va a depender del tamaño de la tabla, del tamaño del buffer cache o de otras distintas estadísticas.
En algunos casos específicos, las lecturas a través de una ruta directa, pueden tener mayor beneficio y menor impacto en el rendimiento de la base de datos, sin embargo, si tenemos activado el ASMM ( Administración automática de las estructuras de memoria ), la situación podría volverse problemática.
Si usted esta experimentando problemas de rendimiento en su sistema, después de haber migrado de 10g a 11g en aquellos procesos en donde se hace constantemente FTS sobre tablas, tome en consideración las siguientes recomendaciones:
- Deshabilitar el ASMM y setear manualmente los tamaños del buffer cache, pga_agreggate_target, shared_pool, etc. Podría correr con el riesgo de subdimensionar o sobre dimensionar los tamaños, pero al menos, esto le permite contra-restar la sobrecarga generada en el sistema, a la hora de hacer cambios dinámicos en los tamaños de las estructuras de memoria, para ajustarse a las necesidades del momento.
- Utilice el consejero ASH, para establecer SQL's con problemas de rendimiento y tratar manualmente de mejorar las rutas de acceso a los datos. Juego con parámetros que cambien la generación de planes de ejecución para encontrar escenarios más óptimos para cada situación en común.
- Recuerde en 11g el optimizador de consultas sólo trabaja en modo COSTO. Rule ya no es soportado en 11g, muchos índices podrían dejar de funcionar y quedar superfluos.
- Actualice las estadísticas de todos los objetos de su base de datos, antes de iniciar una tarea de optimización. En 11g se recolectan tanto estadísticas para el sistema, como para los objetos de los esquemas aplicativos. La falta de estadísticas o estadísticas no actualizadas, afectan considerablemente el rendimiento de la base de datos.
- Valide los parámetros de semáforos del sistema operativo. Verifique que los valores, corresponden con los recomendados por la guía de instalación del producto.
Espero que estas recomendaciones, les puedan ser útiles. Este tema fue causa de discusión entre mi amigo Carlos Yakithi de Sao Paulo Brasil y mi persona, al ver detectado el primero, un comportamiento anormal en su base de datos, migrada recientemente a 11g.
