Errores más frecuentes en Sistema Oracle

A continuación se indican los errores más comunes encontrados en Sistemas Oracle. Siguiendo el Método Oracle de Mejora del Rendimiento, se deberían evitar todos estos errores. Si se evidencian estos errores en el sistema y no pueden ser eliminados, entonces se debe hacer una reingeniería de la Aplicación en aquellos aspectos en los que el esfuerzo par mejorar el rendimiento sea elevado.

1. Gestión de Conexiones Errónea

La Aplicación se conecta y desconecta para cada interacción de Base de Datos. Este problema es común en componentes midleware “no oficiales” en Servidores de Aplicaciones. Tiene un impacto en el rendimiento de 2 órdenes de magnitud y es completamente no escalable.

2. Mala utilización de cursores y de la Shared Pool.

La no utilización de cursores genera parsers repetitivos. Si no se utilizan variables bind se realizará hard parser de todas las sentencias SQL. Tiene un impacto en el rendimiento de un orden de magnitud y es completamente no escalable. Se deben utilizar cursores con bind variables que permiten que el cursor se abra y ejecute muchas veces. Se debe sospechar de Aplicaciones que generan SQL dinámico.

3. Transferencia incorrecta de datos de la Base de Datos

En muchas ocasiones la base de datos esta mal distribuida entre los discos disponibles. En otras ocasiones el número de discos es no apropiado pues configuran los discos en función de maximizar la capacidad global en lugar de hacerlo maximizando el ancho de banda de las operaciones de entrada/salida.

4. Problemas de configuración de Redo Log

En muchas ocasiones se asignan muy pocos ficheros de Redo Log y además son de pequeño tamaño. Los ficheros de Redo Log pequeños hacen que las verificaciones del sistema generen una alta carga en la buffer cache y en el subsistema de entrada/salida. Si hay demasiado pocos ficheros de Redo Log, el proceso de archivado no puede realizarse y la base de datos hasta que el proceso de archivado se pueda realizar.

5. Serialización de acceso a bloques de datos.

El acceso en serie a bloques de datos en la buffer cache es debido a un insuficiente número de free lists, free list groups, entradas de transacciones (INITRANS) u ordenación de segmentos de rollback. Este punto es especialmente habitual en Aplicaciones que realizan muchos INSERT, en Aplicaciones que han aumentado el tamaño de bloque de base de datos a 8K o 16K o en Aplicaciones con un elevado número de usuarios activos y pocos segmentos de rollback.

6. Full Table Scans de mucha duración

La existencia de full table scans de larga duración en operaciones online interactivas puede indicar un diseño poco eficiente de las transacciones, carencia de índices o sentencias SQL poco optimizadas. Estas operaciones son, por su naturaleza, intensivas respecto a transferencias del subsistema de entrada/salida y no escalables.

7. Ordenaciones en disco

Las ordenaciones en disco para operaciones online podrían indicar un diseño de transacciones poco eficiente, carencia de índices o sentencias SQL poco optimizadas. Estas operaciones son, por su naturaleza, intensivas respecto a transferencias del subsistema de entrada/salida y no escalables.

8. Elevado número de SQL recursivo de SYS.

Un elevado número de sentencias SQL recursivas debidas al usuario SYS puede indicar actividades de gestión de espacio, como puede ser asignación de extensiones. Esta situación es no escalable y tiene impacto en el tiempo de respuesta del usuario. La ocurrencia de sentencias SQL recursivas ejecutas por otro usuario diferente a SYS son debidas probablemente a SQL y PL/SQL y no suponen un problema.

9. Errores de Schema y problemas del Optimizador

En muchos casos, una Aplicación utiliza demasiados recursos debido a que el schema propietario de las tablas no ha sido migrado con éxito desde el entorno de desarrollo o desde una implementación previa. Ejemplos de esto es pérdida de índices o estadísticas incorrectas. Estos errores pueden ocasionar la ejecución de planes no óptimos y generar un rendimiento pobre. Cuando se migran Aplicaciones de rendimientos conocidos, se deben exportar, mediante DBMS_STATS, las estadísticas del schema para mantener la estabilidad de los planes de ejecución. De igual modo, los parámetros relativos al optimizador pueden tener preferencia sobre planes de ejecución previamente eficientes. Por estas razones, los schemas, las estadísticas de los schemas y la configuración del optimizador se deben manejar juntas como un grupo para garantizar la consistencia del rendimiento.

10. Uso de parámetros de inicialización no estándar.

Esto suele ocurrir debido a un consejo no adecuado o a suposiciones incorrectas. En particular, los parámetros asociados con SPIN_COUNT sobre latches y características del optimizador no documentadas pueden generar una gran cantidad de problemas que requieren una importante investigación.

11. Pensar que solo existen los 10 errores anteriores