SlideShare ist ein Scribd-Unternehmen logo
1 von 68
Downloaden Sie, um offline zu lesen
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 ejecución de los distintos
procesos de un sistema disminuyan, haciendo
uso del menor número de recursos posible.
AFINAMIENTO EN ORACLE
 Las bases de datos necesitan técnicas para
mejorar su rendimiento, por lo que su
afinamiento es imprescindible para obtener su
máximo 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 desempeño RDBMS
Programas
60%

Source: ORACLE Performance Tuning1

Diseño
20%

Sistema
2.5%

Base de Datos
17.5%

precise software solutions, inc..
4 Metas de Oracle para
impactar rápidamente
1-Localizar suficiente memoria para Oracle.
2-Conseguir los datos cargados en la memoria (cache).
3-Buscando queries problemáticos que afectan la
memoria y I/O.
4-Afinando los queries problemáticos
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 ?
¿Cómo vemos lo que
tenemos activado ?
 DB_BLOCK_BUFFERS
 SHARED_POOL_SIZE
 SORT_AREA_SIZE
Meta#1: ¿tenemos suficiente
memoria localizada para Oracle ?
Valores del parámetro “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
sort_area_size

7000000
262144
A. DB_BLOCK_BUFFERS
 Si DB_BLOCK_BUFFERS es bajo, los usuarios podrían no
tener suficiente espacio en memoria para trabajar
eficientemente.

 Si DB_BLOCK_BUFFERS es alto, el sistema podría
comenzar a hacer swap y se podría detener.
B. El SHARED_POOL_SIZE:
 Esta es la porción de memoria localizada para la librería y
el cache del diccionario de datos.
 Si el SHARED_POOL_SIZE esta seteado demasiado bajo
no se aprovecharía 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 parámetro 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 pequeña.
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 están 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 lógicas
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
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 Diseñadores
Algunos metodos :
 El Optimizers
 Usando Hints (sugerencias)
 Usando Histograms
 Driving Tables
 Partitions
 Parallel Query
El Optimizers









El Parámetro 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 rápidamente (Informes)
First_Row - Consigue la primera fila rápidamente (Formas)
Escoja (Arregle áreas del problema)

Alter Session set Optimizer_Goal = <mode>;
El comando ANALYZE



En General:
Las estadísticas son generadas con el comando
ANALYZE



Deben generarse estadísticas de Cost Based
Optimization



Una vez que tabla es analizada; usar Cost Based
Optimization (a menos que se sobreescriba INIT.ora )



Una tabla también 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
ningún mensaje del error se emite.
 Las sugerencias sólo aplican a la declaración 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 declaración, el
seudónimo necesita estar en la sugerencia.
Key” Hints para Optimization
 Full – Forzar un análisis completo de tablas
select /*+ FULL(table_name) */ column1, column2 ...
 Index – Forzar una búsqueda indexada
select /*+ INDEX(table_name index_name1 index_name2...)
*/ column1, column2 ...
 Ordered – Forzar el ordenamiento de una tabla con la
cláusula FROM
select /*+ ORDERED */ column1, column2 ...
from table1, table2
La regla 95/5
 cuando "Optimizer“encuentra 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

User_dump_dest

Output.txt
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 básicas de optimización
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 añadirlo, ya que tener índices
extra sólo penaliza los tiempos de inserción,
actualización y borrado, pero no de consulta.
Normas básicas de optimización
2.

3.
4.

Al crear un restricción de tipo PRIMARY KEY o
UNIQUE, se crea automáticamente 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.
Normas básicas de optimización
5. Generar un plan para todas las consultas de la
aplicación, poniendo especial cuidado en los
planes de las vistas, ya que estos serán
incluidos en todas las consultas que hagan
referencia a la vista
–

–

Generar y optimizar al máximo 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 básicas de optimización
6. Si una aplicación que funcionaba rápido, 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 búsquedas. Cuantos más índices tenga
una tabla, más se tardará en realizar inserciones y
actualizaciones sobre la tabla, aunque más rápidas
serán las consultas.
Hay que buscar un equilibrio entre el número de
índices y su efectividad, de tal modo que creemos el
menos número posible, pero sean utilizados el mayor
número de veces posible.
Normas básicas de optimización
7. Utilizar siempre que sea posible las mismas
consultas. La segunda vez que se ejecuta una
consulta, se ahorrará mucho tiempo de
parsing y optimización, así que se debe
intentar utilizar las mismas consultas repetidas
veces.
Normas básicas de optimización
8. Las consultas más 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 básicas de optimización
9. Los filtros de las consultas deben ser lo más
específicos y concretos posibles. Es decir: es
mucho más específico 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 básicas de optimización
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 después.
Normas básicas de optimización
11. Evitar la condiciones IN ( SELECT…) sustituyéndolas
por joins: cuando se utiliza un conjunto de valores en
la clausula IN, se traduce por una condición
compuesta con el operador OR. Esto es lento, ya que
por cada fila debe comprobar cada una de las
condiciones simples. Suele ser mucho más rápido
mantener una tabla con los valores que están 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 básicas de optimización
11. También hay que tener cuidado cuando se
mete un SELECT dentro del IN, ya que esa
consulta puede retornar muchas filas, y se
estaría cayendo en el mismo error.
Normalmente, una condición del tipo "WHERE
campo IN (SELECT...)" se puede sustituir por
una consulta con join.
Normas básicas de optimización
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 ejecución.
Aquellas tablas que retornan más filas deben ir
en las primeras posiciones, mientras que las
tablas con pocas filas deben situarse al final
de la lista de tablas.
Normas básicas de optimización
13. Si en la cláusula 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 condición como WHERE
ROUND(IMPORTE) > 0, entonces el índice
quedará desactivado y no se utilizará para la
consulta.
Normas básicas de optimización
14. Siempre que sea posible se deben evitar las
funciones de conversión de tipos de datos e
intentar hacer siempre comparaciones con
campos del mismo tipo. Si hay que hacer
algún tipo de conversión, intenta evitar el uso
del cast y aplica siempre la función de
conversión sobre la constante, y no sobre la
columna.
Normas básicas de optimización
15. Una condición negada con el operador NOT
desactiva los índices
16. Una consulta calificada con la cláusula
DISTINCT debe ser ordenada por el servidor
aunque no se incluya la cláusula ORDER BY.
Normas básicas de optimización
17. Si vamos a realizar una operación de
inserción, borrado o actualización masiva, es
conveniente desactivar los índices, ya que por
cada operación individual se actualizarán.
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
ordenación se hará al final, etc. No tiene en
cuenta el estado actual de la base de datos, ni
el número de usuarios conectados, ni la carga
de datos de los objetos, etc. Es un sistema de
optimización estático, no varía de un momento
a otro.
Optimizador basado en costes (CHOOSE)


Se basa en las reglas básicas, 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 número 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 catálogo público, por lo que es
recomendable que esté lo más actualizado posible (a
través de la sentencia ANALYZE), ya que de no ser
así, se pueden tomar decisiones a partir de datos
desfasados (la tabla tenía 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
ejecución. Los hint deben ir junto detrás de la
palabra SELECT:
SELECT /*+ HINT */ . . .
Sugerencias o hints
Hint

Descripción

/*+ CHOOSE */

Pone la consulta a costes.

/*+ RULE */

Pone la consulta a reglas.

/*+ ALL_ROWS */

Pone la consulta a costes y la optimiza para que devuelva todas las
filas en el menor tiempo posible. Es la opción 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.

/*+ FIRST_ROWS */

Pone la consulta a costes y la optimiza para conseguir que devuelva la
primera fila en el menor tiempo posible. Esto es idóneo 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.

/*+ INDEX( tabla
índice ) */

Fuerza la utilización 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).

/*+ ORDERED */

Hace que las combinaciones de las tablas se hagan en el mismo orden
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 estadísticas
almacenadas en el catálogo de Oracle, a
través de la instrucción:
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);
Tuning fondo-negro-2

Weitere ähnliche Inhalte

Was ist angesagt? (20)

JQuery selectors
JQuery selectors JQuery selectors
JQuery selectors
 
Design patterns in PHP
Design patterns in PHPDesign patterns in PHP
Design patterns in PHP
 
Best sql plsql material
Best sql plsql materialBest sql plsql material
Best sql plsql material
 
Php database connectivity
Php database connectivityPhp database connectivity
Php database connectivity
 
About XAML & HTML+CSS
About XAML & HTML+CSSAbout XAML & HTML+CSS
About XAML & HTML+CSS
 
Sub query_SQL
Sub query_SQLSub query_SQL
Sub query_SQL
 
database language ppt.pptx
database language ppt.pptxdatabase language ppt.pptx
database language ppt.pptx
 
Aggregate functions in SQL.pptx
Aggregate functions in SQL.pptxAggregate functions in SQL.pptx
Aggregate functions in SQL.pptx
 
7.1. procedimientos almacenados
7.1.  procedimientos almacenados7.1.  procedimientos almacenados
7.1. procedimientos almacenados
 
Packages in PL/SQL
Packages in PL/SQLPackages in PL/SQL
Packages in PL/SQL
 
Thread priority in java
Thread priority in javaThread priority in java
Thread priority in java
 
set operators.pptx
set operators.pptxset operators.pptx
set operators.pptx
 
Tema5 sql - ddl
Tema5   sql - ddlTema5   sql - ddl
Tema5 sql - ddl
 
Stored procedure
Stored procedureStored procedure
Stored procedure
 
Trigger in DBMS
Trigger in DBMSTrigger in DBMS
Trigger in DBMS
 
5. stored procedure and functions
5. stored procedure and functions5. stored procedure and functions
5. stored procedure and functions
 
MySql Triggers Tutorial - The Webs Academy
MySql Triggers Tutorial - The Webs AcademyMySql Triggers Tutorial - The Webs Academy
MySql Triggers Tutorial - The Webs Academy
 
Normalization in a Database
Normalization in a DatabaseNormalization in a Database
Normalization in a Database
 
Seguridad sql server
Seguridad sql serverSeguridad sql server
Seguridad sql server
 
Using the set operators
Using the set operatorsUsing the set operators
Using the set operators
 

Ähnlich wie Tuning fondo-negro-2

Ähnlich wie Tuning fondo-negro-2 (20)

Sql dinamico14042011
Sql dinamico14042011Sql dinamico14042011
Sql dinamico14042011
 
SQL avanzado
SQL avanzadoSQL avanzado
SQL avanzado
 
Rendimiento en aplicaciones web con Symfony2
Rendimiento en aplicaciones web con Symfony2Rendimiento en aplicaciones web con Symfony2
Rendimiento en aplicaciones web con Symfony2
 
Afinamientodebasesdedatosyservidoreswebs
AfinamientodebasesdedatosyservidoreswebsAfinamientodebasesdedatosyservidoreswebs
Afinamientodebasesdedatosyservidoreswebs
 
Database fundamental itprosdc_chapter2
Database fundamental itprosdc_chapter2Database fundamental itprosdc_chapter2
Database fundamental itprosdc_chapter2
 
Base de datos
Base de datosBase de datos
Base de datos
 
Sesion05 - Manipulacion de datos (Oracle)
Sesion05 - Manipulacion de datos (Oracle)Sesion05 - Manipulacion de datos (Oracle)
Sesion05 - Manipulacion de datos (Oracle)
 
Presentación1
Presentación1Presentación1
Presentación1
 
Procedimientos y funciones
Procedimientos y funcionesProcedimientos y funciones
Procedimientos y funciones
 
Parte 08 my sql
Parte 08 my sqlParte 08 my sql
Parte 08 my sql
 
Teoria procedimientos almacenados
Teoria procedimientos almacenadosTeoria procedimientos almacenados
Teoria procedimientos almacenados
 
Procedimientos almacenados en MySQL
Procedimientos almacenados en MySQLProcedimientos almacenados en MySQL
Procedimientos almacenados en MySQL
 
SQL Server Fundamentals 3ra Sesion
SQL Server Fundamentals 3ra SesionSQL Server Fundamentals 3ra Sesion
SQL Server Fundamentals 3ra Sesion
 
Lenguaje transact sql
Lenguaje transact sqlLenguaje transact sql
Lenguaje transact sql
 
Pres17BDII.ppt
Pres17BDII.pptPres17BDII.ppt
Pres17BDII.ppt
 
Trabajo bd
Trabajo bdTrabajo bd
Trabajo bd
 
Mysql
MysqlMysql
Mysql
 
MANUAL
MANUALMANUAL
MANUAL
 
Gustavo php
Gustavo phpGustavo php
Gustavo php
 
Fundamentos sql
Fundamentos sqlFundamentos sql
Fundamentos sql
 

Kürzlich hochgeladen

U2_EA1_descargable TIC 2 SEM VIR PRE.pdf
U2_EA1_descargable TIC 2 SEM VIR PRE.pdfU2_EA1_descargable TIC 2 SEM VIR PRE.pdf
U2_EA1_descargable TIC 2 SEM VIR PRE.pdfJavier Correa
 
CIENCIAS SOCIALES SEGUNDO TRIMESTRE CUARTO
CIENCIAS SOCIALES SEGUNDO TRIMESTRE CUARTOCIENCIAS SOCIALES SEGUNDO TRIMESTRE CUARTO
CIENCIAS SOCIALES SEGUNDO TRIMESTRE CUARTOCEIP TIERRA DE PINARES
 
Herbert James Drape. Erotismo y sensualidad.pptx
Herbert James Drape. Erotismo y sensualidad.pptxHerbert James Drape. Erotismo y sensualidad.pptx
Herbert James Drape. Erotismo y sensualidad.pptxArs Erótica
 
Los escritos administrativos, técnicos y comerciales
Los escritos administrativos, técnicos y comercialesLos escritos administrativos, técnicos y comerciales
Los escritos administrativos, técnicos y comercialeshanda210618
 
UNIDAD DE APRENDIZAJE MARZO 2024.docx para educacion
UNIDAD DE APRENDIZAJE MARZO 2024.docx para educacionUNIDAD DE APRENDIZAJE MARZO 2024.docx para educacion
UNIDAD DE APRENDIZAJE MARZO 2024.docx para educacionCarolVigo1
 
la forma de los objetos expresión gráfica preescolar
la forma de los objetos expresión gráfica preescolarla forma de los objetos expresión gráfica preescolar
la forma de los objetos expresión gráfica preescolarCa Ut
 
Xardín de San Carlos (A Coruña) IES Monelos
Xardín de San Carlos (A Coruña) IES MonelosXardín de San Carlos (A Coruña) IES Monelos
Xardín de San Carlos (A Coruña) IES MonelosAgrela Elvixeo
 
Ejemplo de trabajo de TIC´s CON VARIAS OPCIONES DE LAS TAREAS
Ejemplo de trabajo de TIC´s CON VARIAS OPCIONES DE LAS TAREASEjemplo de trabajo de TIC´s CON VARIAS OPCIONES DE LAS TAREAS
Ejemplo de trabajo de TIC´s CON VARIAS OPCIONES DE LAS TAREASJavier Sanchez
 
Programación Anual 2024 - CIENCIAS SOCIALES.docx
Programación Anual 2024  - CIENCIAS SOCIALES.docxProgramación Anual 2024  - CIENCIAS SOCIALES.docx
Programación Anual 2024 - CIENCIAS SOCIALES.docxJhordanBenitesSanche1
 
Concurso de Innovación Pedagógica T2 FONDEP 2024 Ccesa007.pdf
Concurso de Innovación Pedagógica  T2  FONDEP 2024 Ccesa007.pdfConcurso de Innovación Pedagógica  T2  FONDEP 2024 Ccesa007.pdf
Concurso de Innovación Pedagógica T2 FONDEP 2024 Ccesa007.pdfDemetrio Ccesa Rayme
 
5°-CARPETA PEDAGÓGICA 2024-MAESTRAS DE PRIMARIA PERÚ-978387435.doc
5°-CARPETA PEDAGÓGICA 2024-MAESTRAS DE PRIMARIA PERÚ-978387435.doc5°-CARPETA PEDAGÓGICA 2024-MAESTRAS DE PRIMARIA PERÚ-978387435.doc
5°-CARPETA PEDAGÓGICA 2024-MAESTRAS DE PRIMARIA PERÚ-978387435.docGLADYSPASTOR
 
Kirpi-el-erizo libro descargar pdf 1 link
Kirpi-el-erizo libro descargar pdf 1 linkKirpi-el-erizo libro descargar pdf 1 link
Kirpi-el-erizo libro descargar pdf 1 linkMaximilianoMaldonado17
 
SECUENCIA DIDÁCTICA Matemática 1er grado
SECUENCIA  DIDÁCTICA Matemática 1er gradoSECUENCIA  DIDÁCTICA Matemática 1er grado
SECUENCIA DIDÁCTICA Matemática 1er gradoAnaMara883998
 
Tema 4 Rocas sedimentarias, características y clasificación
Tema 4 Rocas sedimentarias, características y clasificaciónTema 4 Rocas sedimentarias, características y clasificación
Tema 4 Rocas sedimentarias, características y clasificaciónIES Vicent Andres Estelles
 
U2_EA2_descargable TICS PRESENCIAL 2.pdf
U2_EA2_descargable TICS PRESENCIAL 2.pdfU2_EA2_descargable TICS PRESENCIAL 2.pdf
U2_EA2_descargable TICS PRESENCIAL 2.pdfJavier Correa
 
explicacionsobrelasemanasanta-190411100653.ppt
explicacionsobrelasemanasanta-190411100653.pptexplicacionsobrelasemanasanta-190411100653.ppt
explicacionsobrelasemanasanta-190411100653.pptjosemanuelcremades
 
sociales ciencias segundo trimestre tercero
sociales ciencias segundo trimestre tercerosociales ciencias segundo trimestre tercero
sociales ciencias segundo trimestre terceroCEIP TIERRA DE PINARES
 
Revista digital primer ciclo 2024 colección ediba
Revista digital primer ciclo 2024 colección edibaRevista digital primer ciclo 2024 colección ediba
Revista digital primer ciclo 2024 colección edibaTatiTerlecky1
 

Kürzlich hochgeladen (20)

U2_EA1_descargable TIC 2 SEM VIR PRE.pdf
U2_EA1_descargable TIC 2 SEM VIR PRE.pdfU2_EA1_descargable TIC 2 SEM VIR PRE.pdf
U2_EA1_descargable TIC 2 SEM VIR PRE.pdf
 
CIENCIAS SOCIALES SEGUNDO TRIMESTRE CUARTO
CIENCIAS SOCIALES SEGUNDO TRIMESTRE CUARTOCIENCIAS SOCIALES SEGUNDO TRIMESTRE CUARTO
CIENCIAS SOCIALES SEGUNDO TRIMESTRE CUARTO
 
Herbert James Drape. Erotismo y sensualidad.pptx
Herbert James Drape. Erotismo y sensualidad.pptxHerbert James Drape. Erotismo y sensualidad.pptx
Herbert James Drape. Erotismo y sensualidad.pptx
 
Los escritos administrativos, técnicos y comerciales
Los escritos administrativos, técnicos y comercialesLos escritos administrativos, técnicos y comerciales
Los escritos administrativos, técnicos y comerciales
 
UNIDAD DE APRENDIZAJE MARZO 2024.docx para educacion
UNIDAD DE APRENDIZAJE MARZO 2024.docx para educacionUNIDAD DE APRENDIZAJE MARZO 2024.docx para educacion
UNIDAD DE APRENDIZAJE MARZO 2024.docx para educacion
 
la forma de los objetos expresión gráfica preescolar
la forma de los objetos expresión gráfica preescolarla forma de los objetos expresión gráfica preescolar
la forma de los objetos expresión gráfica preescolar
 
Xardín de San Carlos (A Coruña) IES Monelos
Xardín de San Carlos (A Coruña) IES MonelosXardín de San Carlos (A Coruña) IES Monelos
Xardín de San Carlos (A Coruña) IES Monelos
 
Ejemplo de trabajo de TIC´s CON VARIAS OPCIONES DE LAS TAREAS
Ejemplo de trabajo de TIC´s CON VARIAS OPCIONES DE LAS TAREASEjemplo de trabajo de TIC´s CON VARIAS OPCIONES DE LAS TAREAS
Ejemplo de trabajo de TIC´s CON VARIAS OPCIONES DE LAS TAREAS
 
Programación Anual 2024 - CIENCIAS SOCIALES.docx
Programación Anual 2024  - CIENCIAS SOCIALES.docxProgramación Anual 2024  - CIENCIAS SOCIALES.docx
Programación Anual 2024 - CIENCIAS SOCIALES.docx
 
Concurso de Innovación Pedagógica T2 FONDEP 2024 Ccesa007.pdf
Concurso de Innovación Pedagógica  T2  FONDEP 2024 Ccesa007.pdfConcurso de Innovación Pedagógica  T2  FONDEP 2024 Ccesa007.pdf
Concurso de Innovación Pedagógica T2 FONDEP 2024 Ccesa007.pdf
 
5°-CARPETA PEDAGÓGICA 2024-MAESTRAS DE PRIMARIA PERÚ-978387435.doc
5°-CARPETA PEDAGÓGICA 2024-MAESTRAS DE PRIMARIA PERÚ-978387435.doc5°-CARPETA PEDAGÓGICA 2024-MAESTRAS DE PRIMARIA PERÚ-978387435.doc
5°-CARPETA PEDAGÓGICA 2024-MAESTRAS DE PRIMARIA PERÚ-978387435.doc
 
Kirpi-el-erizo libro descargar pdf 1 link
Kirpi-el-erizo libro descargar pdf 1 linkKirpi-el-erizo libro descargar pdf 1 link
Kirpi-el-erizo libro descargar pdf 1 link
 
SECUENCIA DIDÁCTICA Matemática 1er grado
SECUENCIA  DIDÁCTICA Matemática 1er gradoSECUENCIA  DIDÁCTICA Matemática 1er grado
SECUENCIA DIDÁCTICA Matemática 1er grado
 
Tema 4 Rocas sedimentarias, características y clasificación
Tema 4 Rocas sedimentarias, características y clasificaciónTema 4 Rocas sedimentarias, características y clasificación
Tema 4 Rocas sedimentarias, características y clasificación
 
U2_EA2_descargable TICS PRESENCIAL 2.pdf
U2_EA2_descargable TICS PRESENCIAL 2.pdfU2_EA2_descargable TICS PRESENCIAL 2.pdf
U2_EA2_descargable TICS PRESENCIAL 2.pdf
 
explicacionsobrelasemanasanta-190411100653.ppt
explicacionsobrelasemanasanta-190411100653.pptexplicacionsobrelasemanasanta-190411100653.ppt
explicacionsobrelasemanasanta-190411100653.ppt
 
VISITA DE ESTUDO À CRUZ VERMELHA _
VISITA DE ESTUDO À CRUZ VERMELHA                   _VISITA DE ESTUDO À CRUZ VERMELHA                   _
VISITA DE ESTUDO À CRUZ VERMELHA _
 
sociales ciencias segundo trimestre tercero
sociales ciencias segundo trimestre tercerosociales ciencias segundo trimestre tercero
sociales ciencias segundo trimestre tercero
 
Tema 5.- BASES DE DATOS Y GESTIÓN DE LA INF. PARA EL MARKETING.pdf
Tema 5.- BASES DE DATOS Y GESTIÓN DE LA INF. PARA EL MARKETING.pdfTema 5.- BASES DE DATOS Y GESTIÓN DE LA INF. PARA EL MARKETING.pdf
Tema 5.- BASES DE DATOS Y GESTIÓN DE LA INF. PARA EL MARKETING.pdf
 
Revista digital primer ciclo 2024 colección ediba
Revista digital primer ciclo 2024 colección edibaRevista digital primer ciclo 2024 colección ediba
Revista digital primer ciclo 2024 colección ediba
 

Tuning fondo-negro-2

  • 2. 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 ejecución de los distintos procesos de un sistema disminuyan, haciendo uso del menor número de recursos posible.
  • 3. AFINAMIENTO EN ORACLE  Las bases de datos necesitan técnicas para mejorar su rendimiento, por lo que su afinamiento es imprescindible para obtener su máximo aprovechamiento.  Cuatro grandes áreas de gran importancia para lograr ese objetivo.
  • 4. TUNING EN ORACLE  Cuatro áreas principales SGA(System Global Area) Causas de una respuesta pobre Razones para un pobre desempeño RDBMS Programas 60% Source: ORACLE Performance Tuning1 Diseño 20% Sistema 2.5% Base de Datos 17.5% precise software solutions, inc..
  • 5. 4 Metas de Oracle para impactar rápidamente 1-Localizar suficiente memoria para Oracle. 2-Conseguir los datos cargados en la memoria (cache). 3-Buscando queries problemáticos que afectan la memoria y I/O. 4-Afinando los queries problemáticos
  • 6. Meta # 1: ¿tenemos suficiente memoria localizada para Oracle ? 1000 800 600 SGA Size 400 OS Memory 200 0 Oracle5 Oracle6 Oracle7 Oracle8
  • 7. Meta # 1: ¿tenemos suficiente memoria localizada para Oracle ? ¿Cómo vemos lo que tenemos activado ?  DB_BLOCK_BUFFERS  SHARED_POOL_SIZE  SORT_AREA_SIZE
  • 8. Meta#1: ¿tenemos suficiente memoria localizada para Oracle ? Valores del parámetro “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 sort_area_size 7000000 262144
  • 9. A. DB_BLOCK_BUFFERS  Si DB_BLOCK_BUFFERS es bajo, los usuarios podrían no tener suficiente espacio en memoria para trabajar eficientemente.  Si DB_BLOCK_BUFFERS es alto, el sistema podría comenzar a hacer swap y se podría detener.
  • 10. B. El SHARED_POOL_SIZE:  Esta es la porción de memoria localizada para la librería y el cache del diccionario de datos.  Si el SHARED_POOL_SIZE esta seteado demasiado bajo no se aprovecharía adecuadamente el DB_BLOCK_BUFFERS.
  • 11. 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
  • 12. 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.
  • 13. C. Almacenar en memoria en lugar de en segmentos temporales :  El parámetro 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 pequeña.
  • 14. 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!
  • 15. Meta # 3: Encuentre los queries que están obstruyendo la memoria y causan problemas de I/O  Use V$SQLAREA para encontrar problemas de Queries
  • 16. 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
  • 17. Encontrar las lecturas lógicas 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’
  • 18. 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;
  • 19. 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;
  • 20. 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.
  • 21. 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
  • 22. 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 Diseñadores
  • 23. Algunos metodos :  El Optimizers  Usando Hints (sugerencias)  Usando Histograms  Driving Tables  Partitions  Parallel Query
  • 24. El Optimizers         El Parámetro 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 rápidamente (Informes) First_Row - Consigue la primera fila rápidamente (Formas) Escoja (Arregle áreas del problema) Alter Session set Optimizer_Goal = <mode>;
  • 25. El comando ANALYZE   En General: Las estadísticas son generadas con el comando ANALYZE  Deben generarse estadísticas de Cost Based Optimization  Una vez que tabla es analizada; usar Cost Based Optimization (a menos que se sobreescriba INIT.ora )  Una tabla también se puede-ANALYZEd; Usando el 'Delete Statistics'
  • 26. 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
  • 27. 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’);
  • 28. 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.
  • 30. Usando sugerencias ( Hints)  La Sintaxis debe ser correcta o la sugerencia se ignorará, y ningún mensaje del error se emite.  Las sugerencias sólo aplican a la declaración 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 declaración, el seudónimo necesita estar en la sugerencia.
  • 31. Key” Hints para Optimization  Full – Forzar un análisis completo de tablas select /*+ FULL(table_name) */ column1, column2 ...  Index – Forzar una búsqueda indexada select /*+ INDEX(table_name index_name1 index_name2...) */ column1, column2 ...  Ordered – Forzar el ordenamiento de una tabla con la cláusula FROM select /*+ ORDERED */ column1, column2 ... from table1, table2
  • 32. La regla 95/5  cuando "Optimizer“encuentra un query para recuperar menos 4-7% de las filas, el optimizer escogerá manejar el query con un index si este existe.
  • 33. 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
  • 34. 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
  • 35. 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';
  • 36. 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.
  • 37. 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
  • 38. 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
  • 39. 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;
  • 40. 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);
  • 41. 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
  • 42. 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});
  • 43. Formatting the Trace File with TKPROF  $ tkprof tracefile.trc output.txt [options] Tracefile.trc User_dump_dest Output.txt
  • 44. 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
  • 45. 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
  • 46. Normas básicas de optimización 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 añadirlo, ya que tener índices extra sólo penaliza los tiempos de inserción, actualización y borrado, pero no de consulta.
  • 47. Normas básicas de optimización 2. 3. 4. Al crear un restricción de tipo PRIMARY KEY o UNIQUE, se crea automáticamente 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.
  • 48. Normas básicas de optimización 5. Generar un plan para todas las consultas de la aplicación, poniendo especial cuidado en los planes de las vistas, ya que estos serán incluidos en todas las consultas que hagan referencia a la vista – – Generar y optimizar al máximo 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.
  • 49. Normas básicas de optimización 6. Si una aplicación que funcionaba rápido, 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 búsquedas. Cuantos más índices tenga una tabla, más se tardará en realizar inserciones y actualizaciones sobre la tabla, aunque más rápidas serán las consultas. Hay que buscar un equilibrio entre el número de índices y su efectividad, de tal modo que creemos el menos número posible, pero sean utilizados el mayor número de veces posible.
  • 50. Normas básicas de optimización 7. Utilizar siempre que sea posible las mismas consultas. La segunda vez que se ejecuta una consulta, se ahorrará mucho tiempo de parsing y optimización, así que se debe intentar utilizar las mismas consultas repetidas veces.
  • 51. Normas básicas de optimización 8. Las consultas más 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.
  • 52. Normas básicas de optimización 9. Los filtros de las consultas deben ser lo más específicos y concretos posibles. Es decir: es mucho más específico 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.
  • 53. Normas básicas de optimización 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 después.
  • 54. Normas básicas de optimización 11. Evitar la condiciones IN ( SELECT…) sustituyéndolas por joins: cuando se utiliza un conjunto de valores en la clausula IN, se traduce por una condición compuesta con el operador OR. Esto es lento, ya que por cada fila debe comprobar cada una de las condiciones simples. Suele ser mucho más rápido mantener una tabla con los valores que están 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;
  • 55. Normas básicas de optimización 11. También hay que tener cuidado cuando se mete un SELECT dentro del IN, ya que esa consulta puede retornar muchas filas, y se estaría cayendo en el mismo error. Normalmente, una condición del tipo "WHERE campo IN (SELECT...)" se puede sustituir por una consulta con join.
  • 56. Normas básicas de optimización 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 ejecución. Aquellas tablas que retornan más filas deben ir en las primeras posiciones, mientras que las tablas con pocas filas deben situarse al final de la lista de tablas.
  • 57. Normas básicas de optimización 13. Si en la cláusula 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 condición como WHERE ROUND(IMPORTE) > 0, entonces el índice quedará desactivado y no se utilizará para la consulta.
  • 58. Normas básicas de optimización 14. Siempre que sea posible se deben evitar las funciones de conversión de tipos de datos e intentar hacer siempre comparaciones con campos del mismo tipo. Si hay que hacer algún tipo de conversión, intenta evitar el uso del cast y aplica siempre la función de conversión sobre la constante, y no sobre la columna.
  • 59. Normas básicas de optimización 15. Una condición negada con el operador NOT desactiva los índices 16. Una consulta calificada con la cláusula DISTINCT debe ser ordenada por el servidor aunque no se incluya la cláusula ORDER BY.
  • 60. Normas básicas de optimización 17. Si vamos a realizar una operación de inserción, borrado o actualización masiva, es conveniente desactivar los índices, ya que por cada operación individual se actualizarán.
  • 61. 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 ordenación se hará al final, etc. No tiene en cuenta el estado actual de la base de datos, ni el número de usuarios conectados, ni la carga de datos de los objetos, etc. Es un sistema de optimización estático, no varía de un momento a otro.
  • 62. Optimizador basado en costes (CHOOSE)  Se basa en las reglas básicas, 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 número de registros y si es suficientemente grande, entonces merecerá la pena acceder por el índice, si no, accederá directamente a la tabla.
  • 63. Optimizador basado en costes (CHOOSE)   Para averiguar el estado actual de la base de datos se basa en los datos del catálogo público, por lo que es recomendable que esté lo más actualizado posible (a través de la sentencia ANALYZE), ya que de no ser así, se pueden tomar decisiones a partir de datos desfasados (la tabla tenía 10 registros hace un mes pero ahora tiene 10.000). ALTER SESSION SET OPTIMIZER_GOAL = [RULE| CHOOSE];
  • 64. 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 ejecución. Los hint deben ir junto detrás de la palabra SELECT: SELECT /*+ HINT */ . . .
  • 65. Sugerencias o hints Hint Descripción /*+ CHOOSE */ Pone la consulta a costes. /*+ RULE */ Pone la consulta a reglas. /*+ ALL_ROWS */ Pone la consulta a costes y la optimiza para que devuelva todas las filas en el menor tiempo posible. Es la opción 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. /*+ FIRST_ROWS */ Pone la consulta a costes y la optimiza para conseguir que devuelva la primera fila en el menor tiempo posible. Esto es idóneo 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. /*+ INDEX( tabla índice ) */ Fuerza la utilización 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). /*+ ORDERED */ Hace que las combinaciones de las tablas se hagan en el mismo orden en que aparecen en el join.
  • 66. Calcular el coste de una consulta   Para calcular el coste de una consulta, el optimizador se basa en las estadísticas almacenadas en el catálogo de Oracle, a través de la instrucción: ANALYZE [TABLE,INDEX] [COMPUTE, ESTIMATE] STATISTICS;
  • 67. 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);