TUNING

Definiendo el tuning (afinamiento)

El ajuste de bases de datos debe ser un

proceso proactivo encaminado a detectar
posibles cuellos de botella en el gestor de
bases de datos as como lograr que los
tiempos de ejecucin de los distintos
procesos de un sistema disminuyan, haciendo
uso del menor nmero de recursos posible.
 AFINAMIENTO EN ORACLE

Las bases de datos necesitan tcnicas para

mejorar su rendimiento, por lo que su
afinamiento es imprescindible para obtener su
mximo aprovechamiento.

Cuatro grandes reas de gran importancia

para lograr ese objetivo.
 TUNING EN ORACLE
Cuatro reas principales SGA(System Global
Area)
Causas de una respuesta pobre
Razones para un pobre desempeo RDBMS
Diseo
Programas 20%
60%

Base de Datos
17.5%
Sistema
2.5%
Source: ORACLE Performance Tuning1

precise software solutions, inc..

 4 Metas de Oracle para
impactar rpidamente

1-Localizar suficiente memoria para Oracle.

2-Conseguir los datos cargados en la memoria (cache).

3-Buscando queries problemticos que afectan la

memoria y I/O.

4-Afinando los queries problemticos

Meta # 1: tenemos suficiente
memoria localizada para Oracle ?

1000

800

600
SGA Size
400 OS Memory

200

0
Oracle5 Oracle6 Oracle7 Oracle8
Meta # 1: tenemos suficiente
memoria localizada para Oracle ?

Cmo vemos lo que

tenemos activado ?

DB_BLOCK_BUFFERS

SHARED_POOL_SIZE

SORT_AREA_SIZE
Meta#1: tenemos suficiente
memoria localizada para Oracle ?
Valores del parmetro KEY INIT.ORA :
select name, substr(value,1,40)
from v$parameter where name in
('db_block_buffers','db_block_size','shared_po
ol_size','sort_area_size');
Nombre Valor
db_block_buffers 4000
db_block_size 4096
shared_pool_size 7000000
sort_area_size 262144
 A. DB_BLOCK_BUFFERS

Si DB_BLOCK_BUFFERS es bajo, los usuarios podran

no tener suficiente espacio en memoria para trabajar
eficientemente.

Si DB_BLOCK_BUFFERS es alto, el sistema podra

comenzar a hacer swap y se podra detener.
 B. El SHARED_POOL_SIZE:
Esta es la porcin de memoria localizada para la librera y
el cache del diccionario de datos.

Si el SHARED_POOL_SIZE esta seteado demasiado bajo

no se aprovechara adecuadamente el
DB_BLOCK_BUFFERS.
Determinar la Memoria asignada
en el SHARED_POOL_SIZE:
col value for 999,999,999,999 heading Shared Pool Size
col bytes for 999,999,999,999 heading Free Bytes
select to_number(v$parameter.value) value, v$sgastat.bytes,
(v$sgastat.bytes/v$parameter.value)*100 Percent Free
from v$sgastat, v$parameter
where v$sgastat.name = 'free memory'
and v$ parameter .name = shared_pool_size;

Shared Pool Size Free Bytes Percent Free

100,000,000 82,278,960 82.27896
Declaraciones que generan
Segmentos Temporales
Create Index...
Select .... Order By, Distinct, Group By, Union,
Intersect, Minus
Unindexed Joins & Correlated Subqueries
El valor por defecto de la magnitud inicial para
los segmentos temporales debe ser por lo
menos tan grande como el valor de
sort_area_size.
 C. Almacenar en memoria en lugar
de en segmentos temporales :
El parmetro SORT_AREA_SIZE de Init.ora localiza
memoria para efectuar ordenamientos.
Determina el espacio PER USER localizado en memoria
principal para cada proceso de ordenamiento.
Si no es suficiente, los segmentos temporales son usados.
Incrementar sort_area_size para reducir I/O a disco.
Causa swapping si la memoria asignada es pequea.
Cache parametro de una tabla

Examina toda la tabla y liste los mas

recientemente usados.
CREATE TABLE TEST_TAB (COL1 NUMBER)
TABLESPACE USERS
CACHE;

ALTER TABLE TEST_TAB

CACHE;

NOCACHE is the Default!

Meta # 3: Encuentre los queries
que estn obstruyendo la memoria y
causan problemas de I/O

Use V$SQLAREA para encontrar problemas

de Queries
Encuentre queries problematicos
hurting de memoria (v$sqlarea)
select disk_reads, sql_text
from v$sqlarea
where disk_reads > 10000
order by disk_reads desc;
Disk_reads SQL_TEXT
12,987 select order#,columns,types from orders
where substr(orderid,1,2)=:1
11,131 select custid, city from customer
where city = CHICAGO
Encontrar las lecturas lgicas
mas grandes:
select buffer_gets, sql_text
from v$sqlarea
where buffer_gets > 200000
order by buffer_gets desc;

Buffer_gets SQL_TEXT
300,219 select order#,cust_no, from
orders where division = 1
Encontrando el codigo PL/SQL
select text
from user_source
where name = PROCESS_DATE
order by line;
TEXT___________________________
procedure process_date is
test_num number;
begin
test_num := 10;
if test_num = 10 then
update order_main
set process_date = sysdate
where order_num = 12345;
end if;
end;
Encontrar USER que bloquean
a otros.
Select a.serial#, a.sid, a.username, b.id1, c.sql_text
from v$session a, v$lock b, v$sqltext c
where b.id1 in
(select distinct e.id1
from v$session d, v$lock e
where d.lockwait = e.kaddr)
and a.sid = b.sid
and c.hash_value = a.sql_hash_value
and b.request = 0;
Mate al USER del problema

SERIAL# SID USERNAME ID1

SQL_TEXT
18 11 JOHNSON 393242
update authuser.emp set salary=90000

alter system kill session 11,18;

Session Killed.
Meta # 4: Afinando problemas
de Queries
Lo que necesito saber para poner a punto
mi sistema
Cost-Based, Optimization and Analyze
La regla 95/5
Using HINTS (sugerencias)
Uso de Index y Abusos
La Driving Table
Usando Parallel Query
Lo que necesito saber para
poner a punto mi sistema
Datos Usted debe conocer sus datos
DATOS!
Metodos de Tuning Usted necesitara
toda una lista.

Donde el sistema es mas lento Los

usuarios ofreceran esto.
Otros Diseadores
Algunos metodos :

El Optimizers

Usando Hints (sugerencias)

Usando Histograms

Driving Tables

Partitions

Parallel Query
El Optimizers

El Parmetro de Optimizer_Mode - los Valores

Regla
Escoja
Optimizer_Goal - los Valores
Regla (no tiene tiempo para poner a punto todos esto)
All_Rows - Consigue todas las filas rpidamente (Informes)
First_Row - Consigue la primera fila rpidamente (Formas)
Escoja (Arregle reas del problema)

Alter Session set Optimizer_Goal = <mode>;

El comando ANALYZE

En General:
Las estadsticas son generadas con el comando
ANALYZE
Deben generarse estadsticas de Cost Based
Optimization

Una vez que tabla es analizada; usar Cost Based

Optimization (a menos que se sobreescriba INIT.ora )

Una tabla tambin se puede-ANALYZEd; Usando el

'Delete Statistics'
El comando ANALYZE

PURPOSE:
To perform one of these functions on an index, table, or
cluster:
To collect statistics about the object used by the
optimizer and store them in the data dictionary
To delete statistics about the object from the data
dictionary
To validate the structure of the object
To identify migrated and chained rows of the table or
cluster
ANALYZE Ejemplos:

SQL> ANALYZE TABLE CUSTOMER

ESTIMATE STATISTICS sample 5000 rows;

SQL> ANALYZE TABLE CUSTOMER

ESTIMATE STATISTICS sample 25 percent;

SQL> ANALYZE TABLE CUSTOMER

DELETE STATISTICS;
execute dbms_utility.analyze_schema(SCOTT,COMPUTE);
ANALYZE Ejemplos:
desc dba_tab_modifications;
SQL> exec dbms_stats.gather_schema_stats( -
> ownname => 'SCOTT', -
> options => 'GATHER AUTO');
There are several values for the options parameter that we need
to know about:
gather re-analyzes the whole schema.

gather empty Only analyze tables that have no existing

statistics.

gather stale Only re-analyze tables with more than 10%

modifications (inserts, updates, deletes).

gather auto This will re-analyze objects which currently have no

statistics and objects with stale statistics. Using gather auto is
like combining gather stale and gather empty.
Usando key sugerencias
Usando sugerencias ( Hints)
La Sintaxis debe ser correcta o la sugerencia se ignorar, y
ningn mensaje del error se emite.

Las sugerencias slo aplican a la declaracin en la que ellos

estan. Se tratan declaraciones anidadas como declaraciones
totalmente diferentes y requieren sus propias sugerencias.

Hay un limite de 255 caracteres para las sugerencias.

Al usar un alias para una tabla en la declaracin, el

seudnimo necesita estar en la sugerencia.
Key Hints para Optimization

Full Forzar un anlisis completo de tablas

select /*+ FULL(table_name) */ column1, column2 ...

Index Forzar una bsqueda indexada

select /*+ INDEX(table_name index_name1 index_name2...) */
column1, column2 ...

Ordered Forzar el ordenamiento de una tabla con la

clusula FROM
select /*+ ORDERED */ column1, column2 ...
from table1, table2
La regla 95/5

cuando "Optimizerencuentra un query para

recuperar menos 4-7% de las filas, el
optimizer escoger manejar el query con un
index si este existe.
Optimizer Modes
There are two types of optimizer modes:
Rule-based:
Uses a ranking system
Syntax and data dictionary driven
Cost-based:
Chooses the path with lowest cost
Statistics-driven
Setting the Optimizer Mode
At the instance level:
Optimizer mode =
{choose|rule|first_rows|first_rows_n|all_rows}
At the session level:
Alter Session Set optimizer_mode =
{choose|rule|first_rows|first_rows_n|all_rows}
At the statement level:
Using hints
Using Hints in a SQL Statement
CREATE INDEX st_idx ON CUSTOMER
(STATE);

SELECT /*+ INDEX(CUSTOMER ST_IDX)*/

NAME, ADDRESS, CITY
FROM CUSTOMER
WHERE STATE = 'CA';
Optimizer Plan Stability
Users can stabilize execution plans, to force
applications to use a desired SQL access path.
A consistent execution path is thereby
maintained through database changes.
This is done by creating a stored outline
consisting of hits.
Plan Equivalence
SQL statement text must match the text in a
stored outline.
Plans are maintained through:
New Oracle versions
New statistics on objects
Initializacion parameter changes
Database reorganization
Schema changes
SQL Reports in Statspack
The following reports on statements are
provided by Statspack:
SQL ordered by gets
SQL ordered by reads
SQL ordered by executions
SQL ordered by parse calls
Generate the Execution Plan
Can be used without tracing
Needs the plan_table table utlxplan.sql
Create the explain plan:
EXPLAIN PLAN FOR
SELECT last_name FROM hr.employees;
Query the plan_table Table
Use utlxpls.sql (hide parallel Query information)
Use utlxplp.sql (show parallel Query information)
Use the dbms_xplan package
SELECT * FROM TABLE(dbms_xplan.display);
Using SQL Trace and TKPROF
Set the initialization parameters
ALTER SESSION SET sql_trace = True;
Run the application
ALTER SESSION SET sql_trace = False;
Format the trace file with TKPROF
Interpret the output
Enable / Disabling SQL Trace
At the instance level:
SQL_Trace = True | False
At the session level:
Alter session set sql_trace = TRUE | FALSE
EXECUTE dbms_session.set_sql_trace
(True|False);
EXECUTE
dbms_system.set_sql_trace_in_session
(session_id, serial_id, {True|False});
Formatting the Trace File with TKPROF

$ tkprof tracefile.trc output.txt [options]

Tracefile.trc Output.txt

User_dump_dest
TKPROF Statistics
Count:Number of execution calls
CPU: CPU seconds used
Elapsed: Total elapsed time
Disk: Physical reads
Query: Logical reads for consistent read
Current: Logical reads in current mode
Rows: Rows processed
SQL*Plus Autotrace
Create the plan_table Table
Create and grant the plustrace role
@$oracle_home/sqlplus/admin/plustrce.sql
Grant plustrace To scott;

SET AUTOTRACE off|on|traceonly

Explain|Statistics
Normas bsicas de optimizacin
1. Las condiciones (tanto de filtro como de join)
deben ir siempre en el orden en que est
definido el ndice. Si no hubiese ndice por las
columnas utilizadas, se puede estudiar la
posibilidad de aadirlo, ya que tener ndices
extra slo penaliza los tiempos de insercin,
actualizacin y borrado, pero no de consulta.
Normas bsicas de optimizacin
2. Al crear un restriccin de tipo PRIMARY KEY o
UNIQUE, se crea automticamente un ndice sobre
esa columna.
3. Para chequeos, siempre es mejor crear restricciones
(constraints) que disparadores (triggers).
4. Hay que optimizar dos tipos de instrucciones: las que
consumen mucho tiempo en ejecutarse, o aquellas
que no consumen mucho tiempo, pero que son
ejecutadas muchas veces.
Normas bsicas de optimizacin
5. Generar un plan para todas las consultas de la
aplicacin, poniendo especial cuidado en los
planes de las vistas, ya que estos sern
incluidos en todas las consultas que hagan
referencia a la vista
Generar y optimizar al mximo el plan de las vistas.
Esto es importante porque el SQL de una vista, no
se ejecuta mientras que la vista no es utilizada en
una consulta,
as que todas las consultas de esa vista se ven
afectadas por su plan. Hay que tener especial
cuidado de hacer joins entre vistas.
Normas bsicas de optimizacin
6. Si una aplicacin que funcionaba rpido, se vuelve
lenta, hay que parar y analizar los factores que han
podido cambiar. Si el rendimiento se degrada con el
tiempo, es posible que sea un problema de volumen
de datos, y sean necesarios nuevos ndices para
acelerar las bsquedas. Cuantos ms ndices tenga
una tabla, ms se tardar en realizar inserciones y
actualizaciones sobre la tabla, aunque ms rpidas
sern las consultas.
Hay que buscar un equilibrio entre el nmero de
ndices y su efectividad, de tal modo que creemos el
menos nmero posible, pero sean utilizados el mayor
nmero de veces posible.
Normas bsicas de optimizacin
7. Utilizar siempre que sea posible las mismas
consultas. La segunda vez que se ejecuta una
consulta, se ahorrar mucho tiempo de
parsing y optimizacin, as que se debe
intentar utilizar las mismas consultas repetidas
veces.
Normas bsicas de optimizacin
8. Las consultas ms utilizadas deben
encapsularse en procedimientos
almacenados. Esto es debido a que el
procedimiento almacenado se compila y
analiza una sola vez, mientras que una
consulta (o bloque PL/SQL) lanzado a la base
de datos debe ser analizado, optimizado y
compilado cada vez que se lanza.
Normas bsicas de optimizacin
9. Los filtros de las consultas deben ser lo ms
especficos y concretos posibles. Es decir: es
mucho ms especfico poner WHERE campo
= 'a' que WHERE campo LIKE '%a%'. Es muy
recomendable utilizar siempre consultas que
filtren por la clave primaria u otros campos
indexados.
Normas bsicas de optimizacin
10.Hay que tener cuidado con lanzar demasiadas
consultas de forma repetida, como por ejemplo
dentro de un bucle, cambiando una de las
condiciones de filtrado. Siempre que sea
posible, se debe consultar a la base de datos
una sola vez, almacenar los resultados en la
memoria del cliente, y procesar estos
resultados despus.
Normas bsicas de optimizacin
11. Evitar la condiciones IN ( SELECT) sustituyndolas
por joins: cuando se utiliza un conjunto de valores en
la clausula IN, se traduce por una condicin
compuesta con el operador OR. Esto es lento, ya que
por cada fila debe comprobar cada una de las
condiciones simples. Suele ser mucho ms rpido
mantener una tabla con los valores que estn dentro
del IN, y hacer un join normal. Por ejemplo, esta
consulta:
SELECT * FROM datos WHERE campo IN ('a', 'b', 'c',
'd', ... , 'x', 'y', 'z');
SELECT * FROM datos d, letras l WHERE d.campo =
l.letra;
Normas bsicas de optimizacin
11. Tambin hay que tener cuidado cuando se
mete un SELECT dentro del IN, ya que esa
consulta puede retornar muchas filas, y se
estara cayendo en el mismo error.
Normalmente, una condicin del tipo "WHERE
campo IN (SELECT...)" se puede sustituir por
una consulta con join.
Normas bsicas de optimizacin
12.Cuando se hace una consulta multi-tabla con
joins, el orden en que se ponen las tablas en
el FROM influye en el plan de ejecucin.
Aquellas tablas que retornan ms filas deben ir
en las primeras posiciones, mientras que las
tablas con pocas filas deben situarse al final
de la lista de tablas.
Normas bsicas de optimizacin
13. Si en la clusula WHERE se utilizan campos
indexados como argumentos de funciones, el
ndice quedar desactivado. Es decir, si
tenemos un ndice por un campo IMPORTE, y
utilizamos una condicin como WHERE
ROUND(IMPORTE) > 0, entonces el ndice
quedar desactivado y no se utilizar para la
consulta.
Normas bsicas de optimizacin
14. Siempre que sea posible se deben evitar las
funciones de conversin de tipos de datos e
intentar hacer siempre comparaciones con
campos del mismo tipo. Si hay que hacer
algn tipo de conversin, intenta evitar el uso
del cast y aplica siempre la funcin de
conversin sobre la constante, y no sobre la
columna.
Normas bsicas de optimizacin
15. Una condicin negada con el operador NOT
desactiva los ndices

16. Una consulta calificada con la clusula

DISTINCT debe ser ordenada por el servidor
aunque no se incluya la clusula ORDER BY.
Normas bsicas de optimizacin
17. Si vamos a realizar una operacin de
insercin, borrado o actualizacin masiva, es
conveniente desactivar los ndices, ya que por
cada operacin individual se actualizarn.
Optimizador basado en reglas (RULE)
Se basa en ciertas reglas para realizar las
consultas. Por ejemplo, si se filtra por un
campo indexado, se utilizar el ndice, si la
consulta contiene un ORDER BY, la
ordenacin se har al final, etc. No tiene en
cuenta el estado actual de la base de datos, ni
el nmero de usuarios conectados, ni la carga
de datos de los objetos, etc. Es un sistema de
optimizacin esttico, no vara de un momento
a otro.
Optimizador basado en costes (CHOOSE)

Se basa en las reglas bsicas, pero teniendo

en cuenta el estado actual de la base de
datos: cantidad de memoria disponible,
entradas/saludas, estado de la red, etc. Por
ejemplo, si se hace una consulta utilizando un
campo indexado, mirar primero el nmero de
registros y si es suficientemente grande,
entonces merecer la pena acceder por el
ndice, si no, acceder directamente a la tabla.
Optimizador basado en costes (CHOOSE)
Para averiguar el estado actual de la base de datos se
basa en los datos del catlogo pblico, por lo que es
recomendable que est lo ms actualizado posible (a
travs de la sentencia ANALYZE), ya que de no ser
as, se pueden tomar decisiones a partir de datos
desfasados (la tabla tena 10 registros hace un mes
pero ahora tiene 10.000).
ALTER SESSION SET OPTIMIZER_GOAL =
[RULE|CHOOSE];
Sugerencias o hints
Un hint es un comentario dentro de una
consulta SELECT que informa a Oracle del
modo en que tiene que trazar el plan de
ejecucin. Los hint deben ir junto detrs de la
palabra SELECT:
SELECT /*+ HINT */ . . .
Sugerencias o hints
Hint Descripcin
/*+ CHOOSE */ Pone la consulta a costes.
/*+ RULE */ Pone la consulta a reglas.
Pone la consulta a costes y la optimiza para que devuelva todas las filas
en el menor tiempo posible. Es la opcin por defecto del
/*+ ALL_ROWS */ optimizador basado en costes. Esto es apropiado para procesos en
masa, en los que son necesarias todas las filas para empezar a
trabajar con ellas.
Pone la consulta a costes y la optimiza para conseguir que devuelva la
primera fila en el menor tiempo posible. Esto es idneo para
/*+ FIRST_ROWS */ procesos online, en los que podemos ir trabajando con las primeras
filas mientras se recupera el resto de resultados. Este hint se
desactivar si se utilizan funciones de grupo como SUM, AVG, etc.
Fuerza la utilizacin del ndice indicado para la tabla indicada. Se puede
/*+ INDEX( tabla ndice indicar el nombre de un ndice (se utilizar ese ndice), de varios
) */ ndices (el optimizador elegir uno entre todos ellos) o de una tabla
(se utilizar cualquier ndice de la tabla).
Hace que las combinaciones de las tablas se hagan en el mismo orden
/*+ ORDERED */
en que aparecen en el join.
Calcular el coste de una consulta
Para calcular el coste de una consulta, el
optimizador se basa en las estadsticas
almacenadas en el catlogo de Oracle, a
travs de la instruccin:
ANALYZE [TABLE,INDEX] [COMPUTE,
ESTIMATE] STATISTICS;
Ejemplos
EXPLAIN PLAN FOR
SELECT ename, job, sal, dname
FROM emp, dept
WHERE emp.deptno = dept.deptno
AND NOT EXISTS
(SELECT *
FROM salgrade
WHERE emp.sal BETWEEN losal AND hisal);