switch

1. FACULTAD DE INGENIERÍA
ESCUELA DE INFORMÁTICA Y CIENCIAS DE LA
COMPUTACIÓN
Tema:
Afinamiento de Base de Datos en SQL
ELABORADO POR: NANCY ROGEL
DOCENTE
Ing. Ciro Saguay
Quito – Ecuador
16 de Junio de 2015

2. Introducción al afinamiento (tuning) de
SQL
El afinamiento de SQL es:
• un aspecto clave para mejorar el desempeño de las
aplicaciones
• Implica conocer los fundamentos teóricos de la
optimización
• Implica pensar en el tamaño de la base de datos hacia el
futuro
• Depende mucho del producto y de sus versiones: lo que
en un producto o versión puede ser recomendable podría
ser inadecuado, obsoleto o inexistente en otro

3. Beneficios al realizar afinamiento:
• Mejorar el tiempo de respuesta de las aplicaciones
online
• Mejorar el tiempo de las aplicaciones batch
• Garantizar la escalabilidad de la aplicación
• Reducir la carga del sistema  liberar recursos para
otras tareas
• Evitar actualizaciones innecesarias e inútiles

4. ¿Cuándo se debe afinar?
 Idealmente, las sentencias SQL se deberían
afinar en el momento en que se escriben
 Mientras más avanzado esté el proyecto, más
difícil será realizar el afinamiento ya que:
– El cambio de algunos aspectos puede implicar el
cambio de muchos otros
– Una vez que la aplicación entra en producción, la
simple adición, por ejemplo, de un índice a una tabla
grande puede ser complejo (tiempo, restricciones,
etc.)

5. El proceso de afinamiento de SQL
Generar plan de
ejecución
Afinar SQL
Reescribir la
sentencia SQL
Usar hints Adicionar o quitar
índices
¿Se lograron los
objetivos?
Formular un nuevo
plan de ejecución
Sentencia SQL
inicial
No
Sí
Terminar
El afinamiento
es un proceso
iterativo
Rediseñar las tablas Generar estadísticas Usar paralelismo

6. Condiciones para afinar
• Volúmenes de datos reales: afinar contra
tablas vacías o con pocos datos es
prácticamente inútil.
• Probar en el ambiente real antes de entrar en
producción
• Trabajar en un ambiente con tablas a escala de
las reales, por ejemplo, un 25% del tamaño de
las tablas grandes y un 100% de las tablas
pequeñas

7. • Se dispone de la documentación de los
modelos
• Se conocen los requisitos del sistema
• Si el diseño de la BD está mal, el afinamiento
puede ser inútil
• Aunque el SQL esté afinado, si otros aspectos
no lo están, esto podría impedir el logro de los
objetivos
Condiciones para afinar

8. Herramientas para
afinar sentencias
SQL

9. EXPLAIN PLAN
• El plan de ejecución de una sentencia SQL es la secuencia
de operaciones que un SGBD hace para ejecutar la sentencia
• El EXPLAIN PLAN es una herramienta proporcionada por
Oracle que:
• permite observar el plan de ejecución y otros datos
valiosos de una sentencia SQL
• muestra el plan de ejecución escogido por el optimizador
para las sentencias DML (SELECT, UPDATE, INSERT y
DELETE )

10. EXPLAIN PLAN
El plan de ejecución de una sentencia incluye:
• El orden de acceso a las tablas usadas en la sentencia
• Un método de acceso para cada tabla usada en la sentencia
• Un método de acceso para operaciones binarias:
- Reunión (join)  En la práctica es la principal
- Unión
- Intersección
- Etc.

11. EXPLAIN PLAN
• Los resultados del EXPLAIN PLAN quedan guardados en
una tabla llamada plan_table
• Algunas de las columnas de esta tabla son:
Es el identificador de la sentencia.
Columna Tipo de dato Descripción
STATEMENT_ID VARCHAR2(30) Es el identificador de la sentencia, es el valor
especificado al ejecutar el EXPLAIN PLAN. Si
no se especifica queda en NULL.
TIMESTAMP DATE La fecha y hora en la que se ejecutó el EXPLAIN
PLAN
REMARKS VARCHAR2(400
0)
Comentario asociado con un paso del plan de
ejecución.

12. EXPLAIN PLAN
Columna Tipo de dato Descripción
OPERATION VARCHAR2(30) Nombre de la operación hecha en este paso. Más
adelante se ven algunos de sus posibles valores.
OPTIONS VARCHAR2(255
)
Especifica variantes para la operación de la
columna anterior. Más adelante se ven algunos de
sus posibles valores.
OBJECT_OWN
ER
VARCHAR2(30) Nombre del usuario, dueño del esquema que
contiene al objeto (tabla, índice, etc.)
OBJECT_NAM
E
VARCHAR2(30) Nombre del objeto involucrado en el paso.
OBJECT_INST
ANCE
NUMBER(38) Un número correspondiente a la posición ordinal
del objeto en la sentencia (si hay subconsultas,
vistas se puede generar un orden impredecible).
OBJECT_TYPE VARCHAR2(30) Da información sobre un objeto, por ejemplo,
NON-UNIQUE para un índice.

13. EXPLAIN PLAN
Columna Tipo de dato Descripción
OPTIMIZER VARCHAR2(255) Indica el modo del optimizador (all_rows,
first_rows, first_rows_n)
ID NUMBER(38) Un número asignado a cada paso del plan de
ejecución.
PARENT_ID NUMBER(38) Número del próximo paso de ejecución con
respecto al paso actual.
POSITION NUMBER(38) Indica el orden de procesamiento para los pasos
que tienen el mismo PARENT_ID
OTHER LONG Usado para consultas distribuidas. Contiene el
texto SQL que es ejecutado en un nodo remoto.
OTHER_TAG VARCHAR(255) Información adicional para consultas distribuidas
y paralelas.

14. Columna Tipo de dato Descripción
COST NUMBER(38) Costo de la operación. El valor de esta columna
no tiene una unidad de medida en particular.
CARDINALITY NUMBER(38) Número estimado de filas accedidas por la
operación
BYTES NUMBER(38) Número estimado de bytes retornados por la
operación
EXPLAIN PLAN

15. Ejemplo
Sean las tablas:
 CREATE TABLE dep(
 depno int not null identity(1,1) PRIMARY KEY,
 dnom VARCHAR(20));
 CREATE TABLE emp(
 ced int not null identity PRIMARY KEY,
 enom VARCHAR(10));
 --depno int not null identity(1,1) REFERENCES
dep);

16. Proceso de tuning en QL
Iniciaremos la herramienta DTA, desde el <Managemente
Studio><Tools><Database Engine Tuning Advisor>, y nos arrancara la
herramienta donde nos conectaremos contra la instancia, en la cual queremos
ejecutar la consulta para optimizarla. Daremos un nombre a nuestra sesión,
diremos donde esta ubicado el fichero .sql y seleccionaremos la base de datos
donde se ejecutara la consulta:

17. Una vez rellenada la ventana anterior, iniciaremos el análisis/optimización ->
Doble clic con el ratón en: “Start Analysis”. En ocasiones este proceso puede
tardar tiempo, dependiendo de la complejidad de las consultas a optimizar. Al
finalizar mostrará un resultado donde haciendo doble clic con el ratón en el
campo Definición, nos mostrará los índices que recomienda:

18. Una vez ejecutado el Analisis/optimización en el Database Engine Tuning Advisor
(DTA), como hemos contado mas arriba en este documento, se guarda información
en la base de datos msdb, por lo que podremos consultar acerca del análisis
realizado, con la consulta:
SELECT * FROM msdb..DTA_reports_query
Podemos ver en la salida de la consulta anterior, cual es el costo actual de la
consulta (campo CurrentCostu), y cual es el costo encontrado/optimizado (campo
RecommendedCost), para cada consula (campo StatementString):

19. Si ejecutamos las recomendaciones, propuestas por Database
Engine Tuning, el costo en nuestro plan de ejecución será menor.
A menor costo, menor tiempo de ejecución en la consulta.
Podemos ver el costo de nuestro plan de ejecución, como por
ejemplo:
https://www.youtube.com/watch?v=3R_3wHW6CVE

20. Ejemplo
 INSERT INTO dep VALUES(1,'Admin');
 INSERT INTO dep VALUES(2,'Pintura');
 INSERT INTO dep VALUES(3,'Lavado');
 INSERT INTO emp VALUES(101,'Lisa',1);
 INSERT INTO emp VALUES(201,'Kirsty',1);
 INSERT INTO emp VALUES(304,'Bjork',3);

21. Ejemplo 1:
 DELETE plan_table;
EXPLAIN PLAN
SET STATEMENT_ID = 'P1' FOR
SELECT *
FROM emp;
Se generan dos filas en la tabla plan_table con id = 0 e id = 1.
El contenido puede variar dependiendo de aspectos como la versión
del SGBD, número de filas en la tabla, entre otros.

22. ID STATEMENT_ID TIMESTAMP REMARKS
0 P1 15/02/2015
1 P1 15/02/2015
ID OPERATION OPTIONS OBJECT_OWNER
0 SELECT
STATEMENT
1 TABLE
ACCESS
FULL FJMORENO

23. ID OBJECT_
NAME
OBJECT_
INSTANCE
OBJECT_TYPE
0
1 EMP 1 TABLE
ID PARENT_ID OPTIMIZER
0 ALL_ROWS
1 0

24. ID POSITION OTHER OTHER_TAG
0 5
1 1
ID COST CARDINALITY BYTES
0 5 3 99
1 5 3 99

25. Ejemplo 2:
 DELETE plan_table;
EXPLAIN PLAN
SET STATEMENT_ID = 'P1' FOR
SELECT *
FROM dep, emp
WHERE emp.depno = dep.depno;
Se generan cuatro registros en la tabla plan_table
con id = 0,1,2 y 3.
Un posible contenido de la tabla plan_table es:

26. ID STATEMENT_ID TIMESTAMP REMARKS
0 P1 15/02/2015
1 P1 15/02/2015
2 P1 15/02/2015
3 P1 15/02/2015

27. ID OPERATION OPTIONS OBJECT_OWNER
0 SELECT
STATEMENT
1 HASH JOIN
2 TABLE
ACCESS
FULL FJMORENO
3 TABLE
ACCESS
FULL FJMORENO

28. ID OBJECT_
NAME
OBJECT_
INSTANCE
OBJECT_TYPE
0
1
2 DEP 1 TABLE
3 EMP 2 TABLE

29. ID PARENT_ID OPTIMIZER
0 ALL_ROWS
1 0
2 1
3 1

30. ID POSITION OTHER OTHER_TAG
0 8
1 1
2 1
3 2

31. ID COST CARDINALITY BYTES
0 8 3 174
1 8 3 174
2 2 3 75
3 5 3 99

32.  Una buena forma para visualizar las
operaciones que se hacen en un EXPLAIN
PLAN es usar la siguiente consulta:
EXPLAIN PLAN

33. SELECT LPAD(' ', 2*LEVEL) || OPERATION || ' '
|| OPTIONS || ' ' || OBJECT_NAME
AS query_plan
FROM PLAN_TABLE
WHERE STATEMENT_ID = 'P1'
CONNECT BY PRIOR ID = PARENT_ID
START WITH ID = 0;
EXPLAIN PLAN

34. QUERY_PLAN
-----------------------------
SELECT STATEMENT
HASH JOIN
TABLE ACCESS FULL DEP
TABLE ACCESS FULL EMP
El resultado será algo similar a esto:
EXPLAIN PLAN

35.  Sin embargo, en las versiones recientes de Oracle
se puede usar el paquete DBMS_XPLAN así:
SELECT *
FROM table(DBMS_XPLAN.DISPLAY);
 Otra alternativa es usar en SQL*Plus:
SET AUTOTRACE ON
EXPLAIN PLAN

36. Ejemplo 1 con un INDEX RANGE SCAN:
CREATE TABLE producto(
codigo NUMBER(3) PRIMARY KEY,
nombre VARCHAR(10) NOT NULL,
peso_prom NUMBER(3) NOT NULL
);
CREATE INDEX i_peso ON producto(peso_prom);
INSERT INTO producto VALUES(1,'Gato',50);
INSERT INTO producto VALUES(2,'Rueda',5);

37. EXPLAIN PLAN FOR
SELECT *
FROM producto
WHERE peso_prom < 40;
SELECT *
FROM table(DBMS_XPLAN.DISPLAY);
EXPLAIN PLAN FOR
SELECT /*+ INDEX(p i_peso) */ *
FROM producto p
WHERE peso_prom < 40;
SELECT *
FROM table(DBMS_XPLAN.DISPLAY);
Hint: ensayar también NO_INDEX

38. Ejemplo 2 con un cluster.
 Un cluster de tablas está conformado por
tablas que se almacenan juntas ya que tienen
en común una o más columnas.
 Con frecuencia las tablas del cluster se usan
juntas en consultas, (especialmente en joins)

39. Se crea un cluster llamado mi_cluster cuya columna
clave es departamento*:
CREATE CLUSTER mi_cluster
(departamento NUMBER(6));
Se debe crear un índice sobre la clave del cluster
para poder ejecutar sentencias DML:
CREATE INDEX i_mi_cluster ON CLUSTER
mi_cluster;

40. Se crean las tablas y se agregan al cluster:
CREATE TABLE dpto(
codigo NUMBER(6) PRIMARY KEY,
descripcion VARCHAR2(10) NOT NULL
) CLUSTER mi_cluster(codigo);
CREATE TABLE emp (
cedula NUMBER(8) PRIMARY KEY,
nombre VARCHAR2(20) NOT NULL,
dep NUMBER(6) NOT NULL REFERENCES dpto)
CLUSTER mi_cluster(dep);

41. Observar ahora el plan de ejecución de:
EXPLAIN PLAN FOR
SELECT *
FROM dpto, emp
WHERE codigo = dep;
SELECT *
FROM table(DBMS_XPLAN.DISPLAY);