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
Programas 60% Diseo 20%

Sistema 2.5%
Source: ORACLE Performance Tuning1

Base de Datos 17.5%

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 200 0 Oracle5 Oracle6 Oracle7 Oracle8 OS Memory

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 db_block_buffers db_block_size shared_pool_size sort_area_size Valor 4000 4096 7000000 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 100,000,000

Free Bytes 82,278,960

Percent Free 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 select custid, city from customer where city = CHICAGO

11,131

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
300,219

SQL_TEXT
select order#,cust_no, from orders where division = 1

Encontrando el codigo PL/SQL

select from where order text user_source name = PROCESS_DATE 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 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});

At the session level:

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. Para chequeos, siempre es mejor crear restricciones (constraints) que disparadores (triggers). 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.

3.

4.

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 /*+ CHOOSE */ Descripcin 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 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 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 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 en que aparecen en el join.

/*+ ALL_ROWS */

/*+ FIRST_ROWS */

/*+ INDEX( tabla ndice ) */

/*+ ORDERED */

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);