Oracle Performance Tuning: Top 10 Errores Comunes en Clientes
Acerca del Autor: Jhon Robert Quintero H.
Oracle Performance Tuning y Los 10 principales errores encontrados en los sistemas de clientes según experiencia y lecciones aprendidas.
En este artículo se enumeran los errores más comunes encontrados en los sistemas de clientes:
- Mal administración de conexiones: La aplicación se conecta y desconecta para cada interacción de base de datos. Este problema es común con el middleware en los servidores de aplicaciones. Estas aplicaciones en donde cada interacción es manejada independientemente genera gran impacto en el rendimiento, y no son escalables.
- Mal uso de cursores y la shared pool: No utilizar shared cursors da lugar a hacer mucho parse. Si no se usan variables de enlace, entonces se hace hard parsing para todas las sentencias SQL. Esto genera un impacto exponencial en el rendimiento, haciéndolo poco escalable. Utilice cursores con variables de enlace que abran el cursor y lo ejecutan muchas veces. Desconfíe de las aplicaciones que generan SQL dinámico, pueden generar problema con Oracle Performance Tuning.
- Un mal SQL: Es un SQL que utiliza más recursos de los necesarios que los requerimientos de la aplicación. Esto puede ser una consulta de un sistema BI o minería de datos que se ejecuta durante más de 24 horas o una consulta de una aplicación en línea que tarda más de un minuto. Cualquier SQL que consume recursos significativos del sistema debe ser investigado para una mejora potencial. El ADDM identifica sentencias SQL de alta carga y el SQL Tuning Advisor se puede utilizar para proporcionar recomendaciones de mejora.
- Uso de parámetros de inicialización no estándar: Estos podrían haber sido implementados sobre la base de malos consejos o suposiciones incorrectas. La mayoría de los sistemas dan un rendimiento aceptable usando sólo el conjunto de parámetros básicos. En particular, los parámetros asociados con características de optimizador indocumentadas pueden causar una gran cantidad de problemas que pueden requerir una investigación considerable. Del mismo modo, los parámetros del optimizador establecidos en el archivo de parámetros de inicialización pueden invalidar los planes de ejecución óptimos probados. Por estas razones, los esquemas, las estadísticas de esquema y la configuración del optimizador deben gestionarse juntos como un grupo para garantizar la coherencia del rendimiento.
- Problemas de Configuración de Disco: Muchos sitios establecen mal sus bases de datos sobre los discos disponibles. Otros sitios especifican el número de discos incorrectamente, porque configuran el subsistema de E / S por espacio de disco y no por ancho de banda de E / S.
- Problemas de Configuración de Redo log: Muchos sitios trabajan con muy pocos Redo log y que son demasiado pequeños. Los Redo logs pequeños hacen que los chekpoints del sistema pongan continuamente una alta carga en la buffer cache y en el sistema de E / S. Si hay pocos Redo logs, el archive log no puede mantenerse actualizado y la base de datos espera que el proceso de archive log se ponga al día.
- Serialización de data blocks en la buffer cache: Debido a la falta de free lists, free list groups, transaction slots (INITRANS) o escasez de rollback segments. Esto es particularmente común en aplicaciones de inserción pesada, en aplicaciones que han elevado el tamaño de bloque por encima de 8 KB, o en aplicaciones con gran número de usuarios activos y pocos rollback segments. Utilice el Automatic Segment Space Management (ASSM) y el Automatic Undo Management para resolver este problema.
- Los full-table scans: Los full-table scans muy grandres para operaciones de alto volumen u operaciones en línea interactivas podrían indicar un diseño de transacciones deficiente, la falta de índices o una optimización de SQL deficiente. Los full-table scans muy grandres, por naturaleza son intensivos en E/S y no escalables.
- Alto volumen de SQL recursivo: Grandes cantidades de SQL recursivo ejecutadas por SYS podrían indicar actividades de gestión de espacio, tales como asignaciones de extent, que estén sucediendo. Esto no es escalable e impacta el tiempo de respuesta del usuario de a cara a un mejor Oracle Performance Tuning.
Utilice tablespaces administrados localmente para reducir el SQL recursivo debido a la asignación de extent. El SQL recursivo ejecutado bajo otro ID de usuario es probablemente SQL o PL/SQL, pero esto no es un problema.
- Errores de despliegue y migración: En muchos casos, una aplicación utiliza demasiados recursos porque el esquema que posee las tablas no se ha migrado correctamente del entorno de desarrollo o de una implementación anterior. Ejemplos de esto son índices faltantes o estadísticas incorrectas. Estos errores pueden llevar a planes de ejecución fatales y un rendimiento deficiente de cara al usuario. Al migrar aplicaciones de rendimiento conocido, exporte las estadísticas del esquema para mantener la estabilidad del plan utilizando el paquete DBMS_STATS. Las líneas base del plan SQL proporcionan un método para migrar los planes de ejecución e impedir la regresión del plan.
