TECNICAS PARA LA OPTIMIZACIÓN DE BASE DE DATOS

ELKIN EDUARDO BEDOYA MUÑOZ

TUTOR:
ING PAOLA ANDREA OCAMPO AYALA

SERVICIO NACIONAL DE APRENDIZAJE SENA

ESPECIALIZACIÓN EN GESTIÓN Y SEGURIDAD DE BASES DE DATOS
MAYO DE 2020
 INTRODUCCION

A continuación se abordará el tema de la optimización de consultas a través de las

herramientas del SMBD, con el fin de mejorar la eficiencia en los tiempos de respuesta
de la base de datos usando los recursos disponibles. En algunas ocasiones la
complejidad de la consulta puede ser causante de una baja en el rendimiento del
sistema, por tal motivo este laboratorio está diseñado para el conocimiento de las
herramientas y métodos para que las BD alcancen un alto grado de eficiencia.
Tendremos en cuenta la creación de índices y algunas recomendaciones en el uso de
las base de datos.
 OBJETIVOS

 Utilizar herramientas para mejorar la definición y ejecución de consultas en la

base de datos.

 Hacer uso de índices para mejorar el desempeño a nivel de ordenamientos y

consultas en una Base de Datos.

 Analizar la estructura de la base de datos para mantener al mínimo las lecturas

en disco y mejorar los tiempos de respuesta.
 OPTIMIZACIÓN BASE DE DATOS

Iniciemos con un ejemplo, supongamos que tenemos una consulta lenta (no
optimizada) que tarda 5 segundos más de lo debido y también supongamos que
nuestra aplicación maneja 20 mil usuarios. Si hacemos el cálculo esto implica que por
esos 5 segundos de más estaríamos perdiendo 27 horas de procesamiento, es decir, si
dibujamos una cola de usuarios, el último en la cola (en este caso la persona de color
rojo), potencialmente tiene que esperar 27 horas para ser atendido.

Ahora pensemos en sistemas complejos donde hay mucho más de 20 mil usuarios por
ejemplo los sistemas bancarios donde todos quieren acceder a su cuenta de la manera
más rápida posible y simultáneamente.

Por eso la importancia de este tema.

Por lo tanto, hoy en día está demostrado que una de la mejores maneras de traer
información dentro de los Sistemas Manejadores de Bases de Datos (SMBD), ya que
los índices están usando de manera interna es una estructura de datos complejas
como por ejemplo tablas hash, las cuales implementa un tipo de datos abstracto de
matriz asociativa, una estructura que puede asignar claves a valores. Una tabla hash
usa una función hash para calcular un índice, también llamado código hash, en una
matriz de cubos o ranuras, desde donde se puede encontrar el valor deseado. Durante
la búsqueda, la clave se codifica y el resumen resultante indica dónde se almacena el
valor correspondiente. A continuación revisaremos el estado de las tablas de la Base
de Datos de la Secretaria de Salud:

Con base en ella, revisemos el siguiente ejercicio en el cual deseamos consultar un

registro en particular de una de sus tablas más importantes, la tabla persona, con la
sentencia: SELECT nombre FROM persona where nombre= 'JIMMY';
A momento de ejecutar una consulta, Oracle verifica el orden de las sintaxis SQL y que
este bien escrita, las sentencias select, from y where y luego verifica la sintaxis y por
último el usuario con el cual nos conectamos, tenga los permisos asignados para leer
los datos de esa tabla. Si todo está en orden, el resultado sería:

El resultado de la consulta es satisfactorio ya que mostro el resultado esperado. Pero

se trata es de medir el tiempo de respuesta, cuyo resultado fue 0,189 segundos. Ahora
revisamos el plan de ejecución de la consulta:
El plan de ejecución en esta consulta muestra que va a escanear todos los registros
(FULL) para buscar el registro en la sentencia, en este caso el nombre “WILLY”. En una
tabla con muchos registros puede influir demasiado en el rendimiento de una
aplicación, como lo vimos en el ejemplo inicial. Además, dice que el costo es 3. Esto
indica que la tabla es demasiado transaccional y no sería muy optimo que quede así
porque escanearía toda la tabla. Miremos que cambios ocurre cuando creamos un
índice con la siguiente sentencia: create index index_persona on persona (nombre);

Se muestra la estructura del índice creado:

Ahora intentamos nuevamente realizar la misma consulta anterior y obtenemos que:

El mismo resultado satisfactorio pero en tiempo de respuesta fue menor: 0,02

segundos; sin índice el tiempo de respuesta fue de 0,189 segundos. Y si ejecutamos
nuevamente el plan de ejecución para consulta a la tabla con indice, tenemos:
Podemos ver que el costo se ha reducido a 1 en lugar de 3, porque ya no hace un
escaneo a toda la tabla sino que hace un escaneo según el objeto índice. La aplicación
entonces se ejecuta más rápido. En conclusión, entre más bajo es el costo, la consulta
se ejecutara más rápido y con un mejor rendimiento de nuestras aplicaciones.

Con base en el análisis anterior, se procedió entonces a verificar que las tablas de la
Base de Datos de la Secretaria de Salud cuenten con índices, para estar confiados de
que las consultas serán optimizadas.

Como resultado se reconstruyeron para cada una de las tablas los siguientes índices:

EJECUCIÓN DE SENTENCIAS SQL

Para realizar las consultas SQL, debemos preguntarnos ¿Cuál es la diferencia entre
una cláusula INNER JOIN y una cláusula WHERE?"

Bueno, la respuesta puede ser bastante larga, pero es posible responderla en pocas
palabras y de manera muy simple.
Si se está hablando del conjunto de resultados, no habrá mucha diferencia. Si se habla
de rendimiento, los SMBD son mucho más inteligentes puesto que reescribirán
automáticamente su búsqueda en la mayoría de los casos, por lo que no tendrá
diferencias en el rendimiento. Dicho esto, es preferible usar INNER JOIN cuando una
consulta involucra más de una tabla, ya que esa es la sintaxis válida de ANSI (Instituto
Nacional Estadounidense de Estándares)

CONSULTAS SECRETARIA DE SALUD

1. Alcaldía de San Antonio del Sena, necesita un informe de todos los usuarios
registrados en la base de datos de la Secretaria de Salud, que tengan la letra “C” como
inicial de su primer nombre.

SQL = SELECT * FROM persona WHERE nombre LIKE 'C%';

2. Se necesita un listado de todas las personas retiradas con los siguientes datos:
nombre, apellido, estado, eps, que servicios se le ha prestado a las personas retiradas
y cuanto cancelaron en total por los servicios prestados. Adicionalmente se necesita
que el informe salga en forma ordenada alfabéticamente por apellido.
SELECT p.idpersona, p.apellido, p.nombre, hp.ideps, e.nombre, sp.idservicio, sp.valor,
hp.estadopersona, ep.descripcion, hp.tipoafiliado, ta.descripcion
FROM persona p
INNER JOIN historialpersona hp
ON hp.idpersona=p.idpersona
INNER JOIN estadopersona ep
ON ep.estadopersona=hp.estadopersona
INNER JOIN Tipoafiliado ta
ON ta.idtipoafiliado=hp.tipoafiliado
INNER JOIN eps e
ON e.ideps=hp.ideps
INNER JOIN serviciopersona sp
ON sp.idpersona=p.idpersona
WHERE ep.estadopersona='R'
ORDER BY p.apellido;

3. Se requiere una consulta por EPS de todos sus afiliados

SELECT hp.ideps, e.nombre, hp.idpersona, p.apellido, p.nombre

FROM historialpersona hp
INNER JOIN persona p
ON p.idpersona=hp.idpersona
INNER JOIN eps e
ON e.ideps=hp.ideps
ORDER BY e.ideps, p.apellido;
CONSULTAS SECRETARIA DE HACIENDA (Con INNER JOIN y WHERE)

4. Listar los propietarios por apellido sus predios y cuáles son las facturas que tiene
vigentes

SELECT p.cedula, p.apellido, p.nombre, pd.ficha, pd.matricula, pd.area, pd.direccion,

fv.nrofactura, fv.fechaemision, fv.fechavencimiento, fv.totalpagar
FROM propietario p, predio pd, facturavigente fv
WHERE p.cedula = pd.propietario_cedula
AND pd.ficha = fv.fichapredio
ORDER BY p.apellido, pd.ficha, fv.nrofactura;

SELECT p.cedula, p.apellido, p.nombre, pd.ficha, pd.matricula, pd.area, pd.direccion,

fv.nrofactura, fv.fechaemision, fv.fechavencimiento, fv.totalpagar
FROM propietario p
INNER JOIN predio pd
ON pd.propietario_cedula = p.cedula
INNER JOIN facturavigente fv
ON fv.fichapredio = pd.ficha
ORDER BY p.apellido, pd.ficha, fv.nrofactura;
5. Organizar las facturas vigentes por fecha y concepto la suma valor pagado por mes

SELECT fv.nrofactura, fv.fechaemision, fv.fechavencimiento, fv.totalpagar,

fv.totaldescuento, df.codigoconceptopago, cp.nombreconcepto, df.valorbasegravable,
df.valortotalconcepto
FROM facturavigente fv, detallefacturavigente df, conceptopago cp
WHERE fv.nrofactura = df.nrofactura
AND df.codigoconceptopago = cp.codigoconceptopago;
SELECT fv.nrofactura, fv.fechaemision, fv.fechavencimiento, fv.totalpagar,
fv.totaldescuento, df.codigoconceptopago, cp.nombreconcepto, df.valorbasegravable,
df.valortotalconcepto
FROM facturavigente fv
INNER JOIN detallefacturavigente df
ON df.nrofactura = fv.nrofactura
INNER JOIN conceptopago cp
ON cp.codigoconceptopago=df.codigoconceptopago;

6. La secretaria de hacienda quiere saber cuáles facturas esta pendientes por concepto
Declaración de Renta agrupándolos por el tipo de uso: “Comercial, Gobierno, Mixto,
Publico y Residencial”.

SELECT fv.nrofactura, fv.fechaemision, fv.fechavencimiento, fv.totalpagar,

fv.totaldescuento, df.codigoconceptopago, cp.nombreconcepto, p.ficha,
p.tipouso_codigo, tu.nombretipouso, df.valorbasegravable, df.valortotalconcepto
FROM facturavigente fv, detallefacturavigente df, conceptopago cp, predio p, tipouso tu
WHERE fv.nrofactura = df.nrofactura
AND df.codigoconceptopago = cp.codigoconceptopago
AND fv.fichapredio = p.ficha
AND p.tipouso_codigo = tu.codigo
AND df.codigoconceptopago = 1;
SELECT fv.nrofactura, fv.fechaemision, fv.fechavencimiento, fv.totalpagar,
fv.totaldescuento, df.codigoconceptopago, cp.nombreconcepto, p.ficha,
p.tipouso_codigo, tu.nombretipouso, df.valorbasegravable, df.valortotalconcepto
FROM facturavigente fv
INNER JOIN detallefacturavigente df
ON df.nrofactura=fv.nrofactura
INNER JOIN conceptopago cp
ON cp.codigoconceptopago=df.codigoconceptopago
INNER JOIN predio p
ON p.ficha=fv.fichapredio
INNER JOIN tipouso tu
ON tu.codigo=p.tipouso_codigo
WHERE df.codigoconceptopago = 1;

7. La secretaria de Hacienda quiere un informe de las cuentas por pagar y cobrar a

terceros, necesita sus números de teléfono y su nombre para poder hacer contacto y
pagar sus obligaciones.

SELECT t.nroidentifica, concat(concat(t.nombre, ' '), t.apellidos) AS Proveedor,

t.telefono, t.celular, cxp.nrocuenta, cxp.valorcuenta
FROM cuentasporcobrar cxp, tercero t
WHERE t.codTercero = cxp.codTercero;
SELECT t.nroidentifica, concat(concat(t.nombre, ' '), t.apellidos) AS Proveedor,
t.telefono, t.celular, cxp.nrocuenta, cxp.valorcuenta
FROM tercero t
INNER JOIN cuentasporpagar cxp
ON t.codtercero = cxp.codtercero;

8. Saber las facturas vigentes de estratos 1.2.3 sobre el impuesto predial, se requiere la
siguiente información: filtrado por estrato, fecha de vencimiento, predio y nombre
completo del propietario

SELECT fv.nrofactura, fv.fechavencimiento, df.codigoconceptopago,

cp.nombreconcepto, p.ficha AS predio, p.direccion,
e.codigo AS estrato, concat(concat(pp.nombre, ' '), pp.apellido) AS propietarios
FROM facturavigente fv, detallefacturavigente df, estrato e, propietario pp, predio p,
conceptopago cp
WHERE fv.nrofactura = df.nrofactura
AND df.codigoconceptopago = cp.codigoconceptopago
AND fv.fichapredio = p.ficha
AND p.estrato_codigo = e.codigo
AND p.propietario_cedula = pp.cedula
AND p.estrato_codigo <=3
AND cp.codigoconceptopago=4
ORDER BY e.codigo;
SELECT fv.nrofactura, fv.fechavencimiento, df.codigoconceptopago,
cp.nombreconcepto, p.ficha AS predio, p.direccion,
e.codigo AS estrato, concat(concat(pp.nombre, ' '), pp.apellido) AS propietarios
FROM facturavigente fv
INNER JOIN detallefacturavigente df
ON df.nrofactura = fv.nrofactura
INNER JOIN conceptopago cp
ON cp.codigoconceptopago = df.codigoconceptopago
INNER JOIN predio p
ON p.ficha = fv.fichapredio
INNER JOIN estrato e
ON e.codigo = p.estrato_codigo
INNER JOIN propietario pp
ON pp.cedula = p.propietario_cedula
WHERE p.estrato_codigo <=3
AND cp.codigoconceptopago=4
ORDER BY e.codigo;
 BIBLIOGRAFÍA

https://www.oratable.com/ora-01450-maximum-key-length-exceeded/

https://www.ibm.com/support/knowledgecenter/es/SSZLC2_8.0.0/com.ibm.commerce.d
eveloper.doc/refs/rsdperformanceworkspaces.htm

https://blog.toadworld.com/sql-optimizer-for-oracle-un-caso-real