PDF de programación - Manual de Optimización - Desarrollo de aplicaciones

Universidad de Córdoba

DESARROLLO DE
APLICACIONES

Manual de Optimización

Revisión 1.0

Servicio de Informática
Area de Sistemas
Julio 1993

1.

Introducción.

En este Manual se ha recopilado información relativa a la
optimización de aplicaciones desarrolladas con ORACLE, desde el
punto de vista del diseñador y del programador.

Aunque la referencia fundamental es Database Administrator’s
Guide Version 6.0, incluimos ideas de otras fuentes (Manuales,
Boletines Técnicos, publicaciones independientes,...) detalladas
en el Apéndice A. Por otra parte, la experiencia adquirida en el
desarrollo y explotación de aplicaciones ORACLE ha sido clave
para la confección de este Manual.

Se supone un conocimiento medio de SQL. Referencias
complementarias para el lector interesado en la implementación
que ORACLE ofrece de dicho lenguaje pueden encontrarse en la
documentación técnica correspondiente.

Hacemos notar que este Manual hace referencia a la versión 6.0
del gestor RDBMS de ORACLE. En la actualidad estamos
evaluando la versión 7.0 de dicho gestor en el cual se han
introducido numerosas modificaciones por lo que es de esperar
una proxima revisión de este Manual.

Servicio de Informática - Area de Sistemas

1

Universidad de Córdoba

2. Consideraciones generales.

1.

Introducción.

Uno de los aspectos fundamentales a tener presente en buena
parte de las etapas de diseño y desarrollo de un aplicación es el
del rendimiento futuro de la misma. Desde el momento mismo en
que se elige una configuración hardware y unas herramientas
software para el desarrollo, los impactos sobre el rendimiento
deben evaluarse cada vez que se tome una decisión de diseño y,
en última instancia, durante toda la fase de codificación.

Una escasa planificación en este terreno nos puede proporcionar
una aplicación poco eficiente lo que, con toda probabilidad,
conducirá a tomar medidas ad hoc muy costosas y de dudosa
efectividad.

En nuestro entorno se dispone de una herramienta, ORACLE,
altamente parametrizable,
lo que permite mejorar el
rendimiento global de las aplicaciones. En menor medida, el
sistema operativo UNIX permite al administrador adaptar su
comportamiento a las necesidades específicas de un entorno de
explotación concreto. Un desajuste en cualquiera de estos dos
aspectos repercutirá, de inmediato, en el rendimiento de todas
las aplicaciones.

La monitorización y ajuste del gestor ORACLE y del sistema
operativo es un tema muy complejo y no es nuestra intención
abordarlo en estas páginas dado su escaso interés general. Sin
embargo, la optimización de aplicaciones, sobre todo en fases
tempranas de desarrollo, es un tema de vital importancia para
todos aquellos involucrados en la puesta a punto de una
aplicación.

Este Manual intenta dar una visión amplia sobre los recursos
disponibles para mejorar el rendimiento de las aplicaciones
desde el punto de vista del diseñador y, sobre todo, del
programador.

Algunas serán afirmaciones obvias fácilmente extrapolables a
otros entornos. Sin embargo, la forma, a veces aparentemente
caprichosa, de actuar que muestra el gestor ORACLE hace
necesario que los desarrolladores dispongan de un conjunto claro
de reglas que les permitan tomar decisiones fundadas.

Servicio de Informática - Area de Sistemas

2

Universidad de Córdoba

Capítulo 2 Consideraciones generales.

Por último, y para animar al lector a evaluar en su justa medida
la importancia del tema aquí tratado, diremos que ORACLE
reconoce que en la optimización de un sistema construido con su
gestor de bases de datos, aproximadamente el 70% de las
mejoras de rendimiento se obtendrán actuando a nivel de
aplicación.

Esperamos que estas páginas sean de utilidad a todos aquellos
que estén embarcados en el desarrollo de una nueva aplicación o
en el mantenimiento de una existente.

1. Diseño.

Las primeras apreciaciones sobre el rendimiento comienzan a
discutirse en la fase de diseño. Es imprescindible conocer a fondo
los datos antes de decidir la estructura física de la base de datos
o de modificar una ya existente.

implementar una

idea sean virtualmente

La flexibilidad del modelo relacional hace que las posibilidades
de
ilimitadas.
Considerando los previsibles problemas de rendimiento, este
número de soluciones posibles se limita de forma apreciable. En
general, siguiendo las reglas usuales de normalización asociadas
a la teoría relacional, es posible obtener una base de datos con
una estructura aceptable. Acogerse a una técnica probada de
análisis ayuda a respetar unos criterios estrictos que usualmente
conducen a un buen modelo de datos.

En particular, ORACLE recomienda el modelo Entidad/Relación.
Una realización práctica de este modelo es el CASE*Method.
ORACLE es categórica en sus afirmaciones respecto al cuidado
necesario en la fase de análisis: una buena codificación no puede
contrarrestar los efectos negativos de una base de datos
pobremente diseñada.

En la fase final del análisis debe estudiarse la posibilidad de
desnormalizar algunas tablas de modo que se evite el uso
excesivo de joins. En particular debe prestarse atención a las
tablas auxiliares que describen códigos: muchas veces los códigos
no significan nada para el usuario final y puede ser más rentable
almacenar la descripción completa para evitar el join, sobre todo
si el rendimiento prima sobre consideraciones de espacio.

En cualquier caso, hay que cuidar el número de campos definidos
en cada tabla. Las tablas cargadas de descripciones (los campos
numéricos y tipo fecha no ocupan demasiado espacio) pueden

Servicio de Informática - Area de Sistemas

3

Universidad de Córdoba

Capítulo 2 Consideraciones generales.

influir negativamente en el rendimiento de la aplicación. Aunque
sólo se deseen recuperar algunos de los campos, la lectura de una
de estas tablas implica recuperar muchos bloques de disco dado
que éstos sólo pueden acomodar unas pocas filas de datos.

Otro aspecto fundamental al que a veces no se presta la
suficiente atención es el de la separación de los entornos online y
batch. En ORACLE: Building High Performance Online Systems
(ver Apéndice A), el autor define el concepto de transacción no
diseñada (undesigned transaction) como aquella que realiza más
de 8 ó 10 operaciones de entrada/salida. Muestra, además, el
efecto negativo que sobre el rendimiento de todo un sistema
puede tener mezclar transacciones diseñadas y no diseñadas.

Una norma básica en cualquier sistema en explotación es definir
un entorno batch con un horario de ejecución fuera de horas de
oficina en el que se incluirán el mayor número posible de las
transacciones no diseñadas que tengan que implementarse. El
análisis debe identificar claramente tales transacciones para que
el usuario final no pueda desencadenarlas libremente sino por
solicitud previa.

2. Codificación.

Independientemente de la herramienta utilizada, al final,
cualquier programa queda reducido a sentencias SQL. Dado que
este lenguaje es muy flexible, es posible alcanzar los mismos
resultados escribiendo la sentencia de distintas formas.

ORACLE incorpora un optimizador que decide el camino a seguir
para recuperar o modificar los datos. Este optimizador está
basado en reglas independientes de factores de explotación tales
como el número de filas de una tabla, la cardinalidad de un
índice o la distribución en disco. Esto hace que la forma de
escribir una sentencia sea el único modo de obligar al
optimizador a elegir un camino de búsqueda determinado. En
consecuencia, gran parte de este Manual estará dedicado a
evaluar el efecto de la sintaxis sobre el rendimiento de las
aplicaciones.

Una norma básica es utilizar la herramienta adecuada en cada
situación. ORACLE dispone de varias herramientas pensadas
cada una para un tipo de trabajo. Una elección adecuada de la
herramienta puede mejorar el rendimiento de la aplicación.

Servicio de Informática - Area de Sistemas

4

Universidad de Córdoba

Capítulo 2 Consideraciones generales.

SQL*Loader es una herramienta diseñada para insertar datos
masivamente en una tabla. Esto exige elaborar un fichero de con-
trol y disponer de los datos sobre un fichero secuencial. Este tra-
bajo adicional puede llevar a pensar que una operación del tipo
INSERT-SELECT, mucho más fácil de implementar, puede susti-
tuir con ventaja a una carga con SQL*Loader.

Hemos probado la carga de mil registros utilizando SQL*Loader,
por un lado, y el comando INSERT, por otro. Los resultados se
muestran en la Tabla I.

Herramienta

Tiempo de cpu

SQL*Loader

INSERT

0.43 s

20.00 s

Tabla I: Carga masiva de datos.

Como se puede observar, la diferencia es muy apreciable.

La cualificación de los campos con el alias de cada tabla en los
joins, facilita el trabajo de parse al gestor. De lo contrario, éste
deberá acceder a la definición de todas las tablas que intervienen
para determinar a cual de ellas pertenece cada campo. En este
sentido, y para evitar además dependencias del código con
respecto al diseño de la base de datos, deben evitarse también
sentencias del tipo:

SELECT * FROM TAB

Por último, decir que es necesario que el programador se
familiarice con las funciones que incorpora SQL (SUBSTR,
DECODE,...). En general es preferible emplear dichas funciones a
utilizar las propias del lenguaje huésped (C, COBOL,...).

Servicio de Informática - Area de Sistemas

5

Universidad de Córdoba

Capítulo 2