Taller de Afinacion de Sentencias SQL

Manual para el participante
Oracle: Taller de
Afinación y Sentencias
SQL.
Tabla de contenido
PREFACIO .................................................................................................................................................... 6
1. SIGUIENDO UNA METODOLOGÍA DE AFINACIÓN...................................................................... 7

OBJETIVOS .................................................................................................................................................. 7
MANEJO DEL RENDIMIENTO ........................................................................................................................ 7
LOS FACTORES A SER MANEJADOS ............................................................................................................. 8
PROBLEMAS DE RENDIMIENTO .................................................................................................................... 9
RECURSO CRÍTICO ..................................................................................................................................... 10
EXCESO DE DEMANDA............................................................................................................................... 10
LA METODOLOGÍA DE AFINACIÓN ............................................................................................................ 11
AFINANDO ROLES ..................................................................................................................................... 12
AFINANDO DECLARACIONES DE SQL........................................................................................................ 12
APLICANDO LA METODOLOGÍA ................................................................................................................. 14
2. PROCESANDO SENTENCIAS DE SQL ............................................................................................. 15
OBJETIVOS ................................................................................................................................................ 15
VISIÓN GENERAL ...................................................................................................................................... 15
LAS AREAS DE SHARED SQL .................................................................................................................... 16
FASES DEL PROCESAMIENTO ..................................................................................................................... 17
COMPARTIENDO CURSORES: REQUERIMIENTOS ........................................................................................ 18
ESCRIBIENDO CURSORES COMPARTIDOS ................................................................................................... 19
VARIABLES BIND Y CURSORES COMPARTIDOS .......................................................................................... 19
ESCRIBIENDO CURSOS COMPARTIDOS ....................................................................................................... 19
MONITOREANDO CURSOS COMPARTIDOS .................................................................................................. 20
LA VISTA V$LIBRARYCACHE. ................................................................................................................... 21
V$SQLAREA COLUMNAS ....................................................................................................................... 21
MONITOREANDO EL USO DE CURSORES COMPARTIDOS ............................................................................. 22
RESUMEN .................................................................................................................................................. 23
PRÁCTICA 2 ............................................................................................................................................... 24
3. EXPLAIN Y AUTOTRACE................................................................................................................... 25
LOS OBJETIVOS ......................................................................................................................................... 25
CREANDO EL PLAN TABLE ........................................................................................................................ 25
EL COMANDO EXPLAIN PLAN............................................................................................................... 26
EJEMPLO DE EXPALON PLAN................................................................................................................ 27
DESPLEGANDO EL PLAN DE EJECUCIÓN.................................................................................................... 28
INTERPRETANDO EL PLAN DE EJECUCIÓN.................................................................................................. 29
SQL*PLUS AUTOTRACE EJEMPLOS ........................................................................................................... 30
SQL *PLUS AUTOTRACE ESTADÍSTICAS ................................................................................................... 31
RESUMEN .................................................................................................................................................. 31
PRACTICA.................................................................................................................................................. 32
4 SQL TRACE Y TKPROF........................................................................................................................ 33
LOS OBJETIVOS ......................................................................................................................................... 33
FACILIDAD DE SQL TRACE ....................................................................................................................... 33
COMO USAR EL SQL TRACE ...................................................................................................................... 34
INICIALIZANDO PARÁMETROS ................................................................................................................... 34
CONECTANDO TRACE DE SQL PARA UN INSTANCIA.................................................................................. 36
ENCONTRANDO LOS ARCHIVOS DE TRACE ................................................................................................ 36
FORMATEANDO ARCHIVOS DE TRACE ....................................................................................................... 37
OPCIONES DEL COMANDO TKPROF ......................................................................................................... 38
LA SALIDA DEL COMANDO TKPROF........................................................................................................ 39
EJEMPLO DE SALIDA TKPROF: NO INDEX ............................................................................................... 42
2
Oracle: Taller de Afinacion de Sentencias SQL
EJEMPLO DE SALIDA TKPROF: UNIQUE INDEX ........................................................................................42

RESUMEN ...................................................................................................................................................43
PRÁCTICA ..................................................................................................................................................44
5 OPTIMIZACIÓN BASADA EN REGLAS CONTRA COSTOS .........................................................45
OBJETIVOS .................................................................................................................................................45
VISIÓN GENERAL .......................................................................................................................................45
LAS FUNCIONES DEL OPTIMIZADOR ORACLE8I. ........................................................................................46
LA OPTIMIZACIÓN BASADA EN REGLAS ....................................................................................................46
OPTIMIZACIÓN BASADA EN COSTOS ..........................................................................................................47
LA ELECCIÓN ENTRE RBO Y CBO ............................................................................................................47
COLOCANDO EL ACERCAMIENTO DEL OPTIMIZADOR .................................................................................48
OPTIMIZACIÓN BASADA EN REGLAS ..........................................................................................................49
ORDENANDO EL ESQUEMA RBO...............................................................................................................50
EJEMPLO DE OPTIMIZACIÓN BASADO EN REGLAS......................................................................................50
INFLUENCIANDO OPTIMIZACIÓN BASADA EN REGLAS ...............................................................................51
RESUMEN ...................................................................................................................................................51
PRACTICA: .................................................................................................................................................52
6 ÍNDICES Y MÉTODOS DE ACCESO BÁSICO ..................................................................................53
OBJETIVOS .................................................................................................................................................53
ORACLE8I ROWIDS ..................................................................................................................................53
INDICES ORACLE 8I ....................................................................................................................................54
INDICES B*.TREE .......................................................................................................................................55
ESTRUCTURA DE ÍNDICE B*_TREE.............................................................................................................55
EJEMPLO ÍNDICE B*_TREE ........................................................................................................................56
SINTAXIS PARA LA CREACIÓN DE UN INDICE............................................................................................57
EL EFECTO DE OPERACIONES DML SOBRE ÍNDICES ................................................................................58
INDICES Y RESTRICCIONES .........................................................................................................................58
INDICES Y LLAVES FORÁNEAS ....................................................................................................................59
MÉTODOS DE ACCESO BÁSICO...................................................................................................................60
RESUMEN ...................................................................................................................................................61
7 COLECCIONANDO ESTADÍSTICAS ..................................................................................................62
OBJETIVOS .................................................................................................................................................62
EL COMANDO ANALYZE ............................................................................................................................62
MARCA DE AGUA ALTA .............................................................................................................................64
ESTADÍSTICAS DE ÍNDICE ...........................................................................................................................64
ESTADÍSTICAS DE COLUMNA .....................................................................................................................66
ESTADÍSTICAS DE CLUSTER .......................................................................................................................67
EL PAQUETE DBMS_STATS.....................................................................................................................68
DBMS_STATS:GENERANDO ESTADÍSTICAS ............................................................................................68
COPIANDO ESTADÍSTICAS ENTRE BASES DE DATOS ...................................................................................69
EJEMPLO COPIANDO ESTADÍSTICAS ...........................................................................................................70
EJEMPLO: REUNIENDO ESTADÍSTICAS........................................................................................................71
PREDICANDO LA SELECTIVIDAD ................................................................................................................72
VARIABLES BIND Y PREDICANDO SELECTIVIDAD. .....................................................................................72
LOS HISTOGRAMAS ....................................................................................................................................73
HISTOGRAMAS Y SELECTIVIDAD ...............................................................................................................74
TIPS PARA HISTOGRAMAS ..........................................................................................................................75
CUANDO USAR HISTOGRAMAS ..................................................................................................................76
ESCOGIENDO A UN TAMAÑO DE MUESTRA ................................................................................................76
ESCOGIENDO NUMERO DE CUBOS PARA UN HISTOGRAMA.........................................................................77
VIENDO ESTADÍSTICAS DE HISTOGRAMAS .................................................................................................77
RESUMEN ...................................................................................................................................................78
PRÁCTICA ..................................................................................................................................................78
3
8 INFLUENCIANDO AL OPTIMIZADOR ............................................................................................. 80
OBJETIVOS ................................................................................................................................................ 80
PONIENDO EL MODO OPTIMIZADOR .......................................................................................................... 80
PARÁMETROS ADICIONALES ..................................................................................................................... 81
LA SINTAXIS DE HINT DEL OPTIMIZADOR ................................................................................................. 81
REGLAS PARA HINTS ................................................................................................................................. 82
RECOMENDACIONES DE HINTS .................................................................................................................. 83
EJEMPLO DE HINT DE OPTIMIZADOR ........................................................................................................ 83
LAS CATEGORÍAS DE HINTS ...................................................................................................................... 84
RUTA DE ACCESO BÁSICO DE HINT .......................................................................................................... 84
AVANZADAS RUTAS DE ACCESO DE HINTS ................................................................................................ 84
BUFFER CACHE HINTS............................................................................................................................... 85
HINTS Y VISTAS ........................................................................................................................................ 85
VISTAS PROCESANDO HINTS ..................................................................................................................... 87
RESUMEN .................................................................................................................................................. 87
PRACATICA 8............................................................................................................................................. 88
9 SORTEANDO Y UNIENDO ................................................................................................................... 89
LOS OBJETIVOS ......................................................................................................................................... 89
AFINANDO DESEMPEÑO DE SORTEO .......................................................................................................... 89
SQL TOP-N............................................................................................................................................... 90
TERMINOLOGÍA DE JOIN........................................................................................................................... 90
OPERACIONES DE JOIN .............................................................................................................................. 91
JOINS NESTED LOOPS ................................................................................................................................ 92
PLAN JOIN DE NESTED LOOPS .................................................................................................................... 93
JOIN SORT/MERGE .................................................................................................................................... 93
PLAN DE JOIN SORT/MERGE ..................................................................................................................... 94
JOINS HASH ............................................................................................................................................... 94
PLAN DE JOIN HASH.................................................................................................................................. 95
CLUSTER JOINS.......................................................................................................................................... 96
UNIENDO MÚLTIPLES TABLAS .................................................................................................................. 96
JOIN OUTER ............................................................................................................................................... 97
EJECUCIÓN DE JOINSOUTER ...................................................................................................................... 97
EL OPTIMIZADOR Y JOINS.......................................................................................................................... 98
REGLAS DE ORDEN DE JOIN ....................................................................................................................... 98
OPTIMIZACIÓN DE JOIN RBO .................................................................................................................... 99
OPTIMIZACIÓN DE JOIN CBO................................................................................................................... 100
ESTIMANDO COSTOS DE JOIN................................................................................................................... 100
JOINS DE ESTRELLA................................................................................................................................. 101
HINTS PARA JOINS ORDER ....................................................................................................................... 102
HINTS PARA JOINS DE OPERACIONES ....................................................................................................... 103
SUBSCONSULTAS Y JOINS ........................................................................................................................ 105
PARÁMETROS DE INICIALIZACIÓN QUE INFLUENCIAN JOINS................................................................... 106
PROSPECTOS DE FILAS ............................................................................................................................. 107
MINIMIZANDO PROSPECTOS DE FILAS ..................................................................................................... 108
MINIMIZANDO EL PROCESAMIENTO ........................................................................................................ 109
RESUMEN ................................................................................................................................................ 109
10. PLAN DE ESTABILIDAD DEL OPTIMIZADOR......................................................................... 110
OBJETIVOS .............................................................................................................................................. 110
PLAN DE ESTABILIDAD DEL OPTIMIZADOR .............................................................................................. 110
PLAN EQUIVALENCIA .............................................................................................................................. 111
CREANDO OUTLINES ALMACENADOS ..................................................................................................... 111
USANDO OUTLINES ALMACENADOS........................................................................................................ 112
INFORMACIÓN DE DICCIONARIO DE DATOS ............................................................................................. 113
4
PLAN DE EJECUCIÓN LÓGICO ...................................................................................................................113

MANTENIENDO OUTLINES ALMACENADOS ..............................................................................................114
RESUMEN .................................................................................................................................................115
PRACTICA ................................................................................................................................................116
11. VISTAS MATERIALIZADAS Y TABLAS TEMPORALES.........................................................117
OBJETIVOS ...............................................................................................................................................117
VISTAS MATERIALIZADAS .......................................................................................................................117
CREANDO VISTAS MATERIALIZADAS .......................................................................................................118
ACTUALIZANDO VISTAS MATERIALIZADAS .............................................................................................118
VISTAS MATERIALIZADAS: ACTUALIZACIÓN MANUAL ...........................................................................120
CONSULTAS REESCRITAS .........................................................................................................................120
CREANDO VISTAS MATERIALIZADAS: OPCIONES DE SINTAXIS ................................................................122
HABILITANDO Y CONTROLANDO CONSULTAS REESCRITAS .....................................................................122
EJEMPLO DE CONSULTAS REESCRITAS .....................................................................................................123
DIMENSIONES: VISIÓN GENERAL .............................................................................................................124
DIMENSIONES Y JERARQUÍAS ...................................................................................................................124
DIMENSIONES: TABLA EJEMPLO ..............................................................................................................125
DIMENSIONES Y JERARQUÍAS ...................................................................................................................125
CREANDO DIMENSIONES Y JERARQUÍAS ..................................................................................................126
DIMENSIONES BASADAS EN MÚLTIPLES TABLAS .....................................................................................127
DIMENSIONES CON MÚLTIPLES JERARQUÍAS............................................................................................127
TABLAS TEMPORALES ..............................................................................................................................128
CREANDO TABLAS TEMPORALES .............................................................................................................129
RESUMEN .................................................................................................................................................129
SOLUCIONES ...........................................................................................................................................131
CAPITULO 2..............................................................................................................................................131
CAPITULO 3..............................................................................................................................................132
CAPITULO 4..............................................................................................................................................133
CAPITULO 5..............................................................................................................................................134
CAPITULO 7..............................................................................................................................................135
CAPITULO 8..............................................................................................................................................136
5
Prefacio
REQUISISTOS:
Antes de tomar este curso es necesario tener conocimiento sobre SQL y
SQL*Plus, además de experiencia como desarrollador de aplicaciones y haber
tomado los siguientes cursos:
- Introducción a Oracle (SQL y PL/SQL)
- Oracle para usuarios expertos de SQL.
Audiencia.
Este curso es ideal para todas aquellas personas que requieran de aumentar en
gran medida el rendimiento de sus aplicaciones por medio de afinación en sus
declaraciones de SQL y de procedimientos elaborados en PL/SQL, así como
también métodos de optimización y de almacenamiento.
Este Curso esta diseñado para dar a los participantes firmes fundamentos en el
arte de afinar declaraciones de SQL. El objetivo de este curso es dar al
participante los conocimientos necesarios y la habilidad para realizar afinaciones
efectivas sobre declaraciones de SQL.
Duración:
Tiene una duración aproximada de 8 horas diarias durante 3 días.
Introducción.
Cualquier persona involucrada en la afinación, podrá seguir una metodología
para lograr el máximo desempeño. Afinando declaraciones de SQL es un paso
muy importante ya que disminuye el costo, si es aplicado en el momento
apropiado dentro de la metodología.
Ejerciendo una metodología de afinación, es posible optimizar el desempeño del
optimizador, para un mejor tiempo de respuesta y dimensionalidad. La afinación
es uno, en el proceso en marcha del ciclo biológico de un proyecto que necesita
empezar en la fase de desarrollo y continúa a través de la fase de
mantenimiento.
• Manejar desempeño en una etapa tempranera
• Identificar problemas de desempeño
• Determinar afinar roles
• Afinar declaraciones de SQL
• Ejercer la metodología de afinación
Afinar declaraciones de SQL involucra usar herramientas de análisis, técnicas
de afinación de SQL, y el Optimizador eficazmente. Además, afinar el esquema
puede crear caminos adicionales de acceso para el Optimizador, como el uso de
un índice.
6
1. Siguiendo una Metodología de Afinación
Objetivos
Después de completar esta lección, podrás realizar lo siguiente:
• Conocer los Pasos del procedimiento en el manejo del rendimiento
• Describir las causas de los problemas del rendimiento.
• Identificar las principales áreas del proceso en donde se deberá de llevar
acabo la afinación
• Describir la metodología de afinación
• Explicar la mejora de seguir en orden una buena metodología de afinación
• Listar los pasos de afinación los cuales son responsabilidad del
desarrollador de aplicaciones.
Manejo del Rendimiento

La afinación requiere varios pasos.
Comienzo Efectivo
La dirección de desempeño debe extenderse a lo largo de la aplicación o
proyectarse continuamente ser con creces efectivo. Deberías considerar eso en
la etapa del diseño.
Poner Objetivos
No trate de afinar todo. . Use la metodología de RENDIMIENTO DE LA
INVERSIÓN (el Rendimiento del capital invertido) identificar las porciones de la
aplicación o proyéctese melodía. . Defina sus objetivos en una forma aceptada y
con la que se estuvo de acuerdo por todas las partes interesadas. . Los
contratos de nivel de servicio (SLAs) forman una parte progresivamente
importante de escenario los objetivos de grupos de operaciones y equipos de
dirección de instalaciones. Exitosamente puedes expandir este concepto en la
especificación de requisitos de aplicación.
Afinar y Monitorear el rendimiento
Después de que te hayas puesto en camino y hayas quedado de acuerdo sobre
los objetivos, está listo para afinar y coronar esos objetivos, monitoreando su
progreso como tu afine. Debes conservar registros detallados acerca del nivel de
conformidad con el requisito. Debes publicar medidas indicativas en los
intervalos regulares, resaltando cualquier desviaciones o tendencias.
Trabaje hombro a hombro
Los administradores de la base de datos, los administradores de sistema, y los
programadores deberían trabajar hombro a hombro como un equipo, no como
adversarios.
7
El manejo Excepciones y cambios
Cuando el monitoreo efectivo esté en su sitio y respaldado al nivel de los demás
de la aplicación, debes reaccionar prontamente para las excepciones cuando
son reportados. .Usa los datos disponibles seleccionar un curso de la acción y
entonces analizar el desempeño resultante para determinar si sus acciones
tienen éxito. . Si el mono cambia capacidad de patrones en uso o del equipo
ocurren, entonces deberías considerar ajustar objetivos nuevos.
La Regla del 80/20
Típicamente, 20 % de su cuenta de transacciones (incluyendo declaraciones
selectas) para 80 % del uso de sistema. . Las transacciones que forman este 20
% son los que necesitan ser sintonizados, y afinar cualquier otra cosa está
probablemente que no vale su tiempo y su energía.
También puedes formular este fenómeno con el siguiente corolario: : 50 % de la
utilización viene de 5 % de sus transacciones.
Factores que deben de ser manejados
• Esquema
− Diseño de los datos
− Indices
• Aplicación
− Estatus de SQL
− Código de procedimiento
• Instancia
• Base de datos
• Expectaciones del usuario
Los Factores a Ser Manejados

La dirección de desempeño puede estar dividida en las siguientes cuatro áreas.
Aunque las áreas son separadas, son también interdependientes y requieren
sets diferentes de habilidad.
La afinación de esquema se ocupa de la estructura física de los datos.
• La afinación de aplicación se ocupa de las funciones comerciales y los
módulos del programa que implementan las funciones. . Afinar el código
procesal para el tipo de aplicación y afinar las declaraciones incrustadas de
SQL son también incluidas en este área.
• La afinación de ejemplo se ocupa de la instalación del Oracle8i Server y
cómo usa memoria.
• La afinación de la base de datos se ocupa de manejar el acomodamiento
físico de datos en el disco.
Este curso se concentra en esquema y afinación de declaración de SQL. Otras
partes de afinación de aplicación deberían ser parte de aprender ese tipo
particular de aplicación. . El ejemplo y la afinación de la base de datos están
cubiertos en cursos y literatura para administradores de la base de datos.
8
El esquema
Si una aplicación tiene diseño inadecuado o impropio de datos, entonces
afinando la fijación física, programas que reescribe con tal que índice, o no
sobrecogerán el problema.
Estatutos de SQL.
Si una aplicación es adecuadamente diseñada, entonces todavía puede quedar
mal. . Una razón común para esto es SQL mal escrito.
Las expectativas del usuario
Los usuarios esperan desempeño coherente. . Pueden hacer frente a las
funciones más lentas de aplicación si entienden por que la aplicación es más
lenta que usual. . El equipo de proyecto debería tratar de basar una expectativa
del usuario realista de desempeño, posiblemente incluyendo mensajes de
aplicación a advertir a los operadores que demandan las operaciones que son
hambrientas en recurso. . El mejor tiempo a hacer esto está antes del diseño y
constitución pone en fase y como parte de la fase de transición.
Problemas del rendimiento
• Inadecuado consumo de recursos
− CPU
− I/O
− Memoria (puede ser detectado como un problema
de I/O)
− Recurso de comunicación de los datos
• Inadecuado diseño de recursos
• Candados
Problemas de Rendimiento
Los problemas de desempeño ocurren cuando una función toma más tiempo
para funcionar que el tiempo permitió. . Esto está porque un recurso de un tipo
particular es insuficiente o inadecuado. . El recurso puede ser un recurso físico,
algo semejante como la memoria disponible modera para almacenar datos
bloquean, o un recurso artificial, como una cerradura.
Inadecuado consumo de recursos.
Un recurso simplemente puede ser inadecuado para responsabilizarse por la
necesidad bajo cualquier condiciones. Por ejemplo, si quieres una función para
completar en debajo una segunda, entonces una red con un intervalo de
basculamiento de mensaje de dos segundos nunca se responsabilizará por el
blanco.
Si el factor limitante es un recurso consumible, entonces como el poder de la
UPC, todos los usuarios de ese recurso son afectados.
Inadecuado diseño de recursos.
Si el factor limitante es la argumentación de procesos para un recurso del
diseño, entonces como una cerradura, entonces sólo los usuarios de esos
procesos específicos son probablemente para ser afectados.
9
Candados
La argumentación debido a poner candado por otras transacciones u otras
aplicaciones podría ser un problema.
Recurso critico
• El rendimiento depende lo siguiente:
− Cuantos clientes necesitan del recurso.
− Cuanto deben de esperar por este.
− Cuanto lo retendrá
• Considerar limites de demanda para mantener
tiempos de respuesta aceptables
Recurso crítico
El tiempo de respuesta está definido como el tiempo de servicio positivo la
espera cronometre de lograr una cierta tarea.
Como la demanda para un recurso con un solo servidor aumenta hacia la tasa
de servicio, las colas construyen arriba con el largo de la cola aumentando
exponencialmente para cada incremento en la demanda.
Aun si hay muchos servidores, puedes observar el mismo efecto con una sola
cola. . Sin embargo, los servidores múltiples dan un efecto valioso de alisamiento
cuando hay una variación ancha en el tiempo para el cual un recurso es ocupado
a las un de sus clientes antes de que esté disponible para la reafijación.
El cometido es diseñar, diseñar, y afinar el sistema a fin de que la carga nunca
permitida para despacio reparar veces de terminación debajo del nivel aceptable.
Exceso de demanda
• Gran incremento de tiempo de respuesta y reduce la
cantidad de información procesada
• Deberá ser procesada tanto como sea posible por un
limite de demanda para un nivel que aun permita una
razonable cantidad de información procesada.
Exceso de Demanda
El rendimiento específico está definido como el importe total de trabajo logrado
por el sistema en una cantidad dada de tiempo. . Demasiados procesos usando
un sistema simultáneamente pueden resultar en los siguientes síntomas.
10
El tiempo de respuesta aumentado

La mayoría de usuarios saben y entienden los efectos de colas en el tiempo de
respuesta creciente. . Pueden estar preparados a aceptar respuesta más lenta
en las veces culminantes si el efecto es lineal. . Sin embargo, la teoría
estadística y espectáculo de experiencia que una vez que el tiempo de respuesta
comienza a deteriorar, parte pequeña aumenta de carga puede tener un efecto
severo, cuál es inaceptable para los usuarios.
Información procesada reducida
Cualquier degradación marcada en el tiempo de respuesta es probablemente
desestabilizar la tasa de trabajo de los usuarios afectados. . Mucha gente no
entiende que añadir a más usuarios para un sistema significativamente
disminuye el rendimiento específico global del sistema.
Si el rendimiento específico de sistema es importante, entonces debes asegurar
que el número de usuarios no excede el umbral en el cual el rendimiento
específico comienza a declinar. . Es mejor limitar el número de usuarios
mecánicamente.
Esto puede obtener a la fuerza un cambio en trabajar patrones para hacer frente
a la restricción, pero propagando los períodos de utilización máxima a través el
día de trabajo puede mejorar la forma que el sistema está usado.
La metodología de la afinación
1. Función de la empresa
2. Diseño de los datos
3. Diseño de procesos
4. Estatutos de SQL
5. Estructuras físicas
6. Asignación de memoria
7. I/O
8. Contención de memoria
Sistema Operativo
La Metodología de Afinación
La lista en los espectáculos de la diapositiva que las fases del desarrollo reciclan
en cuál la afinación puede ser aplicada.
Después de los pasos en esta orden es recomendado para las siguientes
razones:
Lo anterior el paso, lo más alto el potencial para mejorar desempeño.
• Lo anterior el paso, lo más alto el costo para funcionar o revisarlo más tarde.
Por ejemplo, los cambios para las estructuras de datos y la aplicación
codifican después de que el diseño inicial tenga una tendencia a ser caro y
requerir el gasto adicional de reensayo de los componentes hipotecados.
• Las decisiones hechas en un paso pueden influenciar subsiguientes pasos. .
Por ejemplo, la declaración de SQL que escribes a compás 4 tendrá
compostura significante en analizar gramaticalmente y escondiendo en
reserva asuntos que son de los que se ocupó a compás 6.
11
• Lo más extensamente que usas técnicas de diseño orientado a objetos y
multiescalenó arquitectura, el apostador las oportunidades que tu con toda
seguridad logrará cualquier aplicación los cambia en un costo razonable.
Afinando Roles
Analista Empresarial 1. Función de la empresa
Diseñador 2.-Diseño de datos
3.-Diseño de procesos
Desarrollador de 4.-Estatus de SQL
Aplicaciones 5.-Estructuras físicas
6.-Signacion de memoria
7.-I/O
Administrador de DBA 8.-Contención de memoria
Administrador de 9.-Sistema operativo
Sistema operativo
Afinando Roles
El analista de empresas, el diseñador, el desarrollador de aplicación, el
administrador de la base de datos, y el administrador del sistema operativo son
responsables de pasos diferentes en el proceso de afinación. . En algunos
casos, una persona puede cumplir a cabalidad varia de estos papeles.
Las escaleras realizadas por el administrador de la base de datos y el
administrador del sistema operativo tienen un efecto inferior en el desempeño
que más temprano da un paso, excepto que ellos puede ser realizado en el costo
relativamente bajo con resultados inmediatamente disponibles y observables.
El cuarto paso en la metodología es primordialmente la responsabilidad del
desarrollador de aplicación. . Sin embargo, entender qué tan afinar SQL puede
facultar a los diseñadores a diseñar esquemas que afinarán fácilmente. . Los
administradores de la base de datos con esta comprensión pueden ayudar a
precisar necesidades de afinación de SQL y soluciones, así aliviando la carga en
sus bases de datos. Esto es especialmente útil si la aplicación está ya en la
producción y el desarrollador de aplicación está ya no disponible.
Nota: Una parte grande de afinación en el servidor - cliente o Web los ambientes guarda
relación con asuntos de la red, igualmente.
Afinando Declaraciones de SQL

Usa herramientas de análisis de rendimiento para
checar los resultados de los siguientes pasos
1. Afinar esquema
• Agregar índices.
• Crear índices para tablas
• Crear clusters.
2. Escoger un lenguaje: SQL o PL/SQL
3. Diseñar y afinar estatus SQL
4. Máximo rendimiento de el optimizador
12
Afinando estatutos de SQL

Durante los pasos dentro de la declaración de SQL afinando, las técnicas de
análisis deberían ser usadas frecuentemente determinar cometidos y progresar.
1. Afinando el Esquema
El diseñador es responsable de determinar cuáles mesas deberían ser usadas,
sus contenidos, y sus asuntos similares. . La aplicación que el desarrollador
entonces podría necesitar decidir cuando usar la indexación, cuando usar índice
organizó mesas, y cuando para usar el agrupamiento de estrellas. .
Denormalization puede ser necesario para el buen desempeño, especialmente
en los ambientes del almacén de datos. . Las decisiones que están hechas en
este paso grandemente asumen el desempeño de cualquier declaraciones de
SQL que usarían estas estructuras.
2. Escogiendo a un Lenguaje: SQL o PL/SQL
En algunos casos, puedes lograr mejor desempeño usando el lenguaje del
PL/SQL realizar una tarea.
3. El diseño para rehusar de SQL Analizando gramaticalmente,
Optimization, y Afinando Esfuerzos
El Oracle8i Server puede a menudo rehusar algún de sus esfuerzos en analizar
gramaticalmente y la optimización cuando ve una declaración idéntica se repitió.
. Por consiguiente, creando SQL declaraciones que aparecen idéntico puede
mejorar desempeño. También da al desarrollador de aplicación permiso de
enfocar y afinar declaraciones individuales de SQL que son usadas
repetidamente.
4. Diseñando y Afinando Declaraciones de SQL
Hay una variedad ancha de métodos para declaraciones de SQL de alto
rendimiento de diseño. . Saber el mono funciona de las ayudas del Optimizador
salir a la vista donde afinar esfuerzos puede ser efectivo. . Considere
declaraciones de SQL que reescribe en las declaraciones de equivalente del
semantically. . También, use el lenguaje correcto (el SQL o PL/SQL) en cada
situación.
5. Logrando Desempeño Máximo con el Optimizador
Para hacer el uso de mejor del Optimizador basado en costos Oracle, debes
entender cómo escoge caminos de acceso para los datos. debes ayudar el
Optimizador basado en costos usando lo ANALIZE orden y por algunas veces
proveerle los indicios acerca de lo mejor ganan acceso al camino. . El
Optimizador basado en reglas está también disponible. Ambos el Optimizador
basado en costos y el Optimizador basado en reglas estarán discutidos en el
"Optimization basado en costos Versus Optimization basado en reglas" lección.
13
Aplicando la Metodología
• Se practico: trabajar de arriba hacia abajo.
• Si tu debes de ser reactivo, Trabajar de abajo
hacia arriba usando lo siguiente:
− Establecer objetivos cuantificables
− Crear a mínimo de pruebas repetibles.
− Ask questions of affected users, and avoid
preconceptions.
− Pruebas hipotéticas y realizar anotaciones.
− Para cuando se conozca el destino
Objetivos cuantificables
Establecen objetivos cuantificables, y evitan vagos objetivos. . Un ejemplo de un
objetivo aceptable sería lo siguiente:
" debemos poder soportar hasta 20 operadores, cada introducir 20 órdenes por
hora, y las listas de cogida deben estar producidas dentro de 30 minutos del fin
del cambio""
"La prueba Repetible mínima
Si tratas de cortar una carrera de cuatro horas para dos horas, se repitió,
entonces las oportunidades del momento se toman mucho tiempo. . Realice sus
pruebas iniciales en contra de un ambiente experimental parecido a la real (o
provee entrada para una condición negativa, como procesadora departamento
en lugar de 500 de ellas). . El precedente legal ideal debería presentar la
candidatura para más que un minuto a fin de que las mejoras son demostradas
intuitivamente y pueden ser medidas usando cronometrando características.
• Has preguntas de usuarios afectados y evite prejuicios.
• Prueba hipótesis y conserve notas.
• Deténte cuando se responsabiliza por el blanco.
Afinando a un Problema Específico para un Aplicación que ya existe en la
Producción
A menudo, los especialistas de desempeño son emplazados hacia fines del ciclo
biológico de un proyecto, cuando el sistema está en la producción y realizando
inaceptablemente.
En esta situación, comience al pie de la lista de método y maquine. . Los
artículos al final son el más barato y más rápido para funcionar. Si no solucionan
el problema, entonces tendrás que operar hacia atrás "cuesta arriba," y esto
comienza a aumentar expensas y retrasos de tiempo.
14
2. Procesando Sentencias de SQL
Objetivos
Sabiendo cómo pueden ayudar las declaraciones SQL de procesos Oracle8i
Server tu diseñas declaraciones de SQL que puede rehusar el análisis
gramatical y esfuerzos de optimización.
Después de completar esta lección, deberás poder:
• Describir los pasos básicos involucrados en tramitar una declaración de SQL
• Monitorear el uso de áreas compartidas de SQL
• Escribe una declaración de SQL de la que aprovecharse áreas compartidas
(Esto le facultará a rehusar esfuerzos de análisis gramatical y de
optimización) de SQL
Visión General
• Areas Compartidas de SQL
• Fases del Procesamiento de SQL
• Cursores compartidos
• Normas de Codificaciones SQL
Visión general
Sabiendo de compartió áreas de SQL, el procesamiento de SQL pone en fase, y
los cursores compartidos, puedes entender cómo codificando normas le faculta a
minimizar cada cuánto sus declaraciones debe ser al que se analizó
gramaticalmente y optimized.
Adicionalmente, como las declaraciones que escribes en lo que se convirtió más
estandarizó, puedes identificar declaraciones que y los dedican afinación
adicional para ellos.
Areas compartidas de SQL
15
Las Areas de Shared SQL
La shared pool es parte del Sistema Global Area (SGA). La shared pool contiene
el cache del diccionario y el cache de la biblioteca. Las áreas compartidas de
SQL son parte del cache de la biblioteca. El cache de la biblioteca también
contiene metadatos.
La shared pool es automáticamente mantenida por un mecanismo envejecido.
Este mecanismo envejecido usa un algoritmo menos recientemente usado (LRU)
determinar cuál ha sido allí más largo y las edades que él fuera de cuando el
espacio sea requerido.
El administrador de la base de datos (DBA) puede cambiar el diccionario
disponible y SQL compartido que las áreas espacian modificando el parámetro
SHARED_POOL_SIZE de inicialización de EL DBA haría esto como parte de un
esfuerzo global de afinación de la base de datos, lo cual estaría sujeto a las
restricciones diversas discutidas en el curso Oracle8i Performance Tuning.
Los cursores
Dentro del área compartido de SQL, cada declaración de SQL es a la que se
analizó gramaticalmente en su propia parte, conocido como un área de contexto
o cursor.
Cada cursor sostiene la siguiente información:
• La declaración a la que se analizó gramaticalmente (la estática, dinámico, y
el SQL recursivo, y las unidades del programa como los procedimientos y los
triggers de la base de datos)
• El plan de ejecución
• Una lista de objetos para los que se estableció referencias
Si dos usuarios emiten la misma declaración de SQL, entonces usarán el mismo
cursor. La declaración es a la que se reanalizó gramaticalmente si la
representación en la shared pool es inválida. Esto ocurre, por ejemplo, si una
declaración de lenguaje de definición de datos (DDL) tan ALTER TABLE fue
usada en uno de los objetos en la declaración, o si una tabla dependiente es
analizada
Fases del procesamiento de una sentencia
de SQL
16
Fases del Procesamiento

Las cuatro fases más importantes en la declaración de SQL yendo en procesión
analizan gramaticalmente, amarrando, ejecutando, y yendo a traer.
Las flechas inversas indican procesar escenarios; Por ejemplo,
FETCH (RE) BIND EXECUTE FETCH.
El FETCH fase sólo aplica para las consultas.
Fase del procesamiento
El Oracle8i Server hace lo siguiente:
• Va en busca de la declaración en la shared pool
• Comprueba la sintaxis de declaración, dado la gramática y las
especificaciones del lenguaje de SQL
• Comprueba la semántica, asegurando eso objeta para el que se estableció
referencias en la declaración de SQL sea válido y satisfaga restricciones
prendarias
• Determina ya sea el proceso emitiendo la declaración tiene privilegios
apropiados para ejecutarlo
• Transforma una declaración de SQL en una vista en una declaración
equivalente de SQL en su definición subyacente, y los intentos para
simplificar una declaración con una subconsulta reescribiéndola en una
juntura
• Determina y almacena el plan de ejecución, o usa un plan existente de
ejecución, si es posible
Fase BIND.
• El Oracle8i Server comprueba la declaración para las referencias de variables
de vinculación.
• El Oracle8i Server hace cesión o reasigna un valor para cada variable.
Nota: Esta orden de fase significa que el Oracle8i Server no sabe valores de variable de
vinculación cuando la optimización una declaración. Esto posibilita un ayuno vuelve a
atar ejecute sin que sea necesario para reanalizar gramaticalmente, así ahorrar el
tiempo y la memoria; Una desventaja es que es imposible que el Optimizador estime
selectividad de predicado. Esto se discutirá en más detalle en el "Statistics de
recolección" lección.
Fase EXECUTE.
• El Oracle8i Server ejerce el árbol sintáctico para los amortiguadores de datos.
• Los usuarios múltiples pueden compartir el mismo árbol sintáctico.
• El Oracle8i Server realiza reconocimiento médico lee o los reads/writes
lógicos para las declaraciones de LENGUAJE DE MANIPULACIÓN DE
DATOS y también clasifica los datos cuando es necesitado.
Fase FETCH
El Oracle8i Server recupera filas para una declaración SELECTA durante la fase
de ESTRATAGEMA. Cada estratagema típicamente recupera filas múltiples,
usando una estratagema de conjunto imponente.
17
Cada herramienta Oracle ofrece sus propias formas de influenciar el tamaño de
conjunto imponente; En el SQL*PLUS haces eso usando al ARRAYSIZE
sedimentándose:
SQL> SHOW arraysize
Arraysize 15
SQL> SET arraysize 1
Con este escenario, el SQL*PLUS procesará una fila a la vez. El valor
predeterminado es 15.
El cursor compartido: beneficios
Cuando una declaración de SQL es encontrada en el área compartida de SQL,
entonces la fase PARSE es reducida y el cursor existente es usado. Éstas son
las prestaciones principales de cursores participativos:
• Compartir cursores se achica analizar gramaticalmente y ahorra tiempo.
• La memoria dinámicamente se ajusta al SQL siendo ejecutada.
• El uso de memoria puede mejorar dramáticamente, puede emparejar para
herramientas que almacenan SQL dentro de la aplicación.
Compartiendo Cursores: Requerimientos

• Sólo las declaraciones idénticas de SQL pueden usar el mismo cursor.
• El texto de las declaraciones de SQL debe ser caso exactamente igual,
inclusivo, espacios, etiquetas, retornos de carro, y comentarios.
• Los objetos para los que se estableció referencias en las declaraciones de
SQL deben resolver para los mismos objetos en la base de datos.
• Los tipos de la vinculación que las variables usaron en las declaraciones de
SQL deben ser lo mismo.
Nota: Antes de las declaraciones remitentes de SQL para el Oracle8i Server, la mayoría
de herramientas Oracle (como PL/SQL, los precompiladores, y Oracle Developer)
pretramitan declaraciones de SQL para hacerlas tan idéntico tan posible removiendo
comentarios, apretando espacio blanco, y mutando para la caja alta o la letra minúscula.
El SQL * Y, sin embargo, envía las declaraciones de SQL al Oracle8i Server en
el mismo formato en su estado actual introducido.
Escribiendo cursores Compartidos.
En este caso la cantidad de espacio en blanco es
diferente entonces no son idénticos
SQL>select * from employees where emp_id=70727:
SQL>select * from EMPLOYEES where EMP_ID=70727 :
Si los objetos fueron escritos por usuarios diferentes
no son iguales.
SQL>select * from employees where EMP_ID=70727;
SQL>select * from employees where EMP_ID=70727 ;
18
Escribiendo Cursores Compartidos

Las declaraciones de SQL deben ser idénticas para poder compartir cursores.
Note esas declaraciones de uso compartido son sin importancia en un ambiente
de sistema de apoyo para la toma de decisiones (DSS), porque la mayoría de
declaraciones serán diferentes de cualquier manera.
Caso idéntico
Los primeros dos ejemplos en la diapositiva no son idénticos. Advierta la
diferencia de caso para la tabla y nombres de la columna. Por esta diferencia de
caso, las declaraciones no son idénticas y así no pueden compartir un área de
SQL.
Objetos idénticos
Aun cuando dos declaraciones se ven idénticas, si los objetos realmente se
refieren a la base de datos diferente objeta, entonces las dos declaraciones no
son idénticas.
En los últimos dos ejemplos en la diapositiva, las declaraciones son expedidas
por dos usuarios diferentes que cada uno tiene su propia tabla de EMPLOYEES.
Así las declaraciones no son idénticas y no pueden compartir un área de SQL.
Variables Bind y Cursores Compartidos

Supón que ejecutas las siguientes consultas
select * from employees where emp_id = :c
select * from employees where emp_id = :d
Ambas sentencias son cambiadas por:
select * from employees where emp_id = :b1
Variables BIND
Si dos variables de vinculación tienen tipos diferentes de datos, entonces las
declaraciones no son idénticas. Si la vinculación que los datos variables los tipos
hacen juego con excepto que sus nombres no es idéntico, como en el ejemplo
arriba, allí no es problemática, porque vinculación las variables serán
renombradas internamente. La primera variable es siempre llamada:B1, el
segundo es:B2, etcétera.
Escribiendo Cursos Compartidos

Cree código genérico usando lo sig:
• Procedimientos y paquetes almacenados
• Triggers de base de datos
• Procedimientos realizados en forma de Oracle.
• Cualquier otras librerías, rutinas y procedimientos
Escribiendo SQL para Cursores Compartidos
Desarrolle codificar buenas costumbres para las declaraciones de SQL en
respecto a escritos de consultas, de SQL, y llamadas Oracle Call Interface (OCI).
19
Usando Código Compartido Genérico
• Escriba y almacene procedimientos que puede ser compartidos a través de
aplicaciones.
• La base de datos de uso se acciona.
• Los triggers de base de datos.
• Las rutinas de la biblioteca de escritura y los procedimientos en otros
ambientes.
Escribiendo SQL para cursos compartidos
Siguiendo un estándar de codificación:
• Case
• Espacios en blanco
• Comentarios
• Objetos referenciados
• Variables Bind
Escribiendo SQL para Cursores Compartidos
Escribiendo a Formato Standard.
• Desarrolle normas del formato para todas las declaraciones, incluyendo esos
adentro código del PL/SQL.
• Desarrolle reglas para el uso de caja alta y la letra minúscula.
• Desarrolle reglas para el uso de espacio blanco (los espacios, las etiquetas,
los retornos de carro).
• Desarrolle reglas para el uso de comentarios, preferentemente
manteniéndolas apartado de las declaraciones de SQL mismas.
• Use los mismos nombres para referirse a los objetos idénticos de la base de
datos.
Monitoreando Cursos Compartidos

• V$LIBRATYCACHE provee Información general
de la librería cache.
• Información acerca de sentencias de SQL se
encuentra en las siguientes vistas:
− V$SQLTEXT
− V$SQLTEXT_WITH_NEWLINES
− V$SQL_BIND_DATA
− V$SQLyB$SQLAREA
Monitoreando cursores compartidos.
Cuando no haya alójese analizar gramaticalmente una declaración en el área
compartido de SQL, el más viejo cursor es cerrado y su espacio es rehusado. Si
la declaración original es necesaria otra vez, entonces el servidor lo debe
analizar gramaticalmente otra vez. La shared pool debería ser bastante grande
para conservar el número de declaraciones que son a las que se analizó
gramaticalmente más de una vez para un mínimo.
20
Puedes monitorear tu sistema para ver cada cuánto el servidor no puede

encontrar una declaración en la memoria. Puedes usar a Oracle Enterprise
Manager (OEM) o puede poner en duda los puntos de vista apropiados de
diccionario de datos: V$LIBRARYCACHE y V$SQLAREA.
V$LIBRATYCACHE Columnas
La Vista V$librarycache.
Esta vista sostiene información acerca de la dirección del cache de la biblioteca.
Los valores para PINHITRATIO y GETHITRATIO cerca de 1 indican un buen
desempeño del cache de la biblioteca. Noto que esta diapositiva no muestra
todas las columnas de la vista V$LIBRARYCACHE.
La vista V$LIBRARYCACHE es usada en la consulta debajo averiguar sobre la
cantidad de esconder en reserva.
SQL> select gethitratio, pinhitratio
2 from v$librarycache
3 where namespace = 'SQL AREA';
GETHITRATIO PINHITRATIO
------------------- ------------------
0. 0.95
V$SQLAREA Columnas
21
El uso compartido del Cursor
La vista V$SQLAREA contiene información acerca de todos los cursores
compartidos en el cache.
VERSIÓN COUNT> 1 Señala que el mismo texto es usado por usuarios
diferentes Sobre la misma tabla.
LOADS > 1 Indica que el curso vuelve a cargar después una
invalidación de este
COMMAND_TYPE 1: CREATE TABLE
2: INSERT
3: SELECT
6: UPDATE
7: DELETE
Nota: Sólo las columnas más importantes de la vista V$SQLAREA están en lista de
arriba.
Monitoreando el uso de Cursores Compartidos

• Una carga por estatuto seria ideal
• Una carga por versión/invalidación es aceptable.
• Mas de una carga por versión indica un beneficio
potencial desde el incremento del área de
shared spool
Monitoreando el uso de cursores compartidos
En el mejor caso el escenario, debería estar una versión de cada declaración
que es nunca deshabilitada o envejecida apagada.
Si el número de cargas está significativamente más alto que la suma de las
versiones y las invalidaciones, especialmente si el número de cargas le es
similar al número de, entonces las llamadas, entonces el cursor probablemente
han sido vueltas a cargar envejeciéndose, y el sistema puede aprovecharse
aumentando el tamaño de la shared pool.
SQL>select sql_text, version_count, loads
2. , Invalidations, parse_calls, sorts
3. From v$sqlarea
4. Where parsing_user_id>= 0
5. And command_type =3
6. Order by sql_text;
Version invalid par

Sql_text count loads dations cal
------------ -------- ------- ------------ -----
select * 2 2 0
from employees
where EMP_ID = 70727
select * 1 2 1
from employees
where emp_id = 70727
22

La declaración de arriba excluye información acerca del SQL recursivo
(analizando gramaticalmente al usuario SYS: user_id = 0) y los despliegues sólo
SELECT órdenes (el tipo de orden 3).
Hay dos versiones de la primera declaración, probablemente porque ponen
notas a dos objetos diferentes de EMPLOYEES. Sin embargo, cada versión ha
sido cargada sólo una vez. La declaración ha sido expedida tres veces
(PARSE_CALL).
Hay versión de único de la segunda declaración, pero eso ha sido cargada dos
veces, habiendo sido deshabilitado una vez (probablemente por algún DDL en la
tabla o el índice relacionado).
Nota: El SQL del Oracle Analyze, un componente del Oracle Enterprise Manager (OEM)
Afinando Paquete, ofrece una interfaz gráfica excelente encima de V$SQLAREA.
Resumen
Use declaraciones idénticas de SQL rehusar áreas de SQL y así aumentar
desempeño. De una manera realista, esto será más fácil si usas código
compartido como los procedimientos empacados, porque el mismo código será
ejecutado las veces múltiples. Esto que también el maintainability de
incrementos del código y las ayudas limitan que sus esfuerzos de afinación para
uno colocan compartió código en lugar de las declaraciones similares
desparramadas múltiples de SQL.
Fases del procesamiento
Hay cuatro etapas principales en tramitar una declaración de SQL:
• En la etapa PARSE, el Oracle8i Server comprueba la sintaxis de la
declaración, determina el plan de ejecución si la declaración no está ya en el
área compartido de SQL, y verifica la información en el diccionario de datos.
• La etapa BIND es cualquier variable no resuelta se les es asignado un valor.
• Dentro de la etapa EXECUTE , el Oracle8i Server ejecuta la declaración
realizando lecturas y escrituras (excepto por las consultas).
• En la etapa de FETCH (sólo para consultas), las filas son recuperadas
usando un mecanismo de estratagema de conjunto imponente.
Areas compartidas de SQL.
Evitar análisis gramatical cada declaración de SQL emitida para el Oracle8i
Server, desarrolle una codificación estándar para aprovecharse de las áreas
compartidas de SQL:
• Siga normas de codificación para espaciar, superior y las referencias de letra
minúscula, de comentarios, del objeto, etcétera.
• Use código genérico, los procedimientos, los triggers de la base de datos,
etcétera.
• Use los mismos nombres referirse a los objetos idénticos de la base de datos.
Trata de usar variables de vinculación a distinción de los valores literales en sus
declaraciones de SQL, a menos que el desempeño máximo pues una sola
declaración de SQL sea necesario. Hay un trueque entre el SQL compartido
23
utilizador (con variables de vinculación) y el desempeño máximo (usando ad
literam valores, habilitando el Optimizador venidero levantado con un plan óptimo
de ejecución).
Práctica 2
En esta práctica, use las vistas del diccionario de datos para analizar el manejo
del cache:
• Use la vista V$LIBRARYCACHE analizar desempeño del cache de la
biblioteca
• Use la vista V$SQLAREA para ver la información acerca de todos los
cursores compartidos en el cache
Práctica 2 (optativo)
1. Determino que el arraysize se sedimentó en su SQL*PLUS su ambiente.
2. Emita la siguiente declaración de SQL, entonces mire la información
generada por esta declaración en la vista V$SQLAREA.
SQL> select cls_status, description
2 from cls_statuses;
SQL> select sql_text, sorts
2 from v$sqlarea
3 where command_type = 3
4 and lower(sql_text) like '%cls_statuses%';
3. Modifique la consulta en la tabla CLS_STATUS y añada un criterio de tipo,
entonces mire la información generada por esta declaración en la vista
V$SQLAREA.
SQL> select cls_status, description
2 from cls_statuses
3 order by cls_status;
2 from v$sqlarea
3 where command_type = 3
4. Introduzca un registro nuevo en la tabla CLS_STATUS. Mire la información
generada por la esta declaración en la vista V$SQLAREA. Recorte su
transacción para restaurar la situación original.
SQL> insert into cls_statuses
2 values('HOLD', 'Class on hold');
2 from v$sqlarea
3 where command_type in (2,3)
SQL> rollback;
5. Use la vista V$LIBRARYCACHE para comprobar la cantidad de cache
reservado.
24
3. Explain y Autotrace
Los Objetivos
Puedes usar herramientas diversas de análisis evaluar el desempeño de
declaraciones de SQL.
Después de completar esta lección, debería :
• Crear la PLAN_TABLE usando el escrito del utlxplan.sql
• El uso del comando EXPLAIN PLAN para mostrar cómo es una declaración
procesada
• Usar el SQL*Plus AUTOTRACE para mostrar el plan de ejecución y
estadísticas de una declaración de sql.
Creando el Plan Table

Correr el script que genera una PLAN_TABLE
SQL>@utlxplan.sql
Crear tu propia PLAN_TABLE con un nombre diferente.

SQL>create table my_plan_table
2. As
3. Select * from plan_table
4. Where 1=2;
Creando la tabla Plan
El comando EXPLAIN PLAN usa una tabla para almacenar información acerca
del plan de ejecución seleccionado por el optimizador. Si examinas el plan,
entonces podrás ver cómo ejecuta el Oracle8i Server la declaración. Debes
seguir tres pasos para usar EXPLAIN PLAN:
1. Crea la tabla de salida de plan.
2. Usa el comando EXPLAIN PLAN.
3. Recupera los pasos de plan por las declaraciones utilizadoras de SQL.
EL PLAN TABLE
Tienes varias opciones para crear un PLAN_TABLE:
• La tabla predeterminada de salida es nombrada de PLAN_TABLE.
• Puedes usar el escrito del utlxplan.sql crear _ PLAN_TABLE.
• En ambiente de Windows, este escrito puede ser encontrado en
%ORACLE_HOME%\rdbms\admin; Bajo UNIX
$ORACLE_HOME/rdbms/admin. En un ambiente del servidor - cliente, esté
seguro usar la versión correcta (el lado del servidor) de este escrito.
• Puedes crear una tabla similar con cualquier nombre que desees usando el
comando CRÉATE TABLE.. AS SELECT. También puedes copiar y puedes
editar el escrito del utlxplan.sql; Nota que no deberías cambiar la estructura
de la tabla.
25
La Sintaxis para crear el PLAN_TABLE
La sintaxis entera para la PLAN_TABLE es mostrada debajo:
Create table PLAN_TABLE
(statement_id varchar2(30),
timestamp date,
remarks varchar2(80),
operation varchar2(30),
options varchar2(30),
object_node varchar2(128),
object_owner varchar2(30),
object_name varchar2(30),
object_instance numeric,
object_type varchar2(30),
optimizador varchar2(255),
search_columns number,
id numeric,
parent_id numeric,
position numeric,
cost numeric,
cardinality numeric,
bytes numeric,
other_tag varchar2(255),
partition_start varchar2(255),
partition_stop varchar2(255),
partition_id numeric,
other long,
distribution varchar2(30)); long
Las columnas más importantes estarán discutidas más tarde en esta lección
El Comando EXPLAIN PLAN
El comando EXPLAIN PLAN

Esta orden introduce una fila en la PLAN_TABLE para cada paso del plan de
ejecución.
En el diagrama de sintaxis enseñado en la diapositiva, los campos en letras
itálicas tienen los siguientes significados:
26
El campo El significado
text Éste es un identificador optativo para
la declaración. deberías introducir un
valor Para identificar cada declaración
a fin de que mas tarde puedas
especificar la declaración que quieres
clarificar. Esto es especialmente
importante cuando compartes el plan
Posponga con otros, o cuándo
guardes planes múltiples de ejecución
en lo mismo
Schema.table Éste es el nombre optativo de la tabla
de salida. El incumplimiento es _
PLAN_TABLE.
statement Éste es el texto de la declaración de
SQL
Ejemplo de EXPALON PLAN

SQL EXPLAIN PLAN
2. Set statmement_id = demo_01 for
3. Select *
4. From classes
5. Where status = cibf
6. And loc_id =22;
Explained.
Note: El comando EXPLAIN PLAN no ejecuta
actualmente la declaración
EXPLAIN PLAN ejemplo:
Esta orden introduce el plan de ejecución de la declaración de SQL en la
PLAN_TABLE, y añade la demostración de la etiqueta de nombre _ 01 para
utilización futura.
Desplegando PLAN_TABLE
SQL> column Query Plan format a50
SQL> select id
2. lpad( , 2*level) | | operation
3. ||decode (id,0, cost= ||posit
4. || || options
5. || || objetc_name as Query Plan
6. from plan_table
7. WhereStatement_id = demo_01
8. Connect by riorid = parent_id
9. Start wit id =0;
27
Desplegando el pLan de Ejecución.
La declaración selecta en la diapositiva es diseñada para ostentar los pasos que
serían tomados si la declaración de SQL fuera ejecutada. Las siguientes
columnas de la PLAN_TABLE son usadas:
STATEMENT_ID El valor del parámetro optativo de STATEMENT_ID
especificado en la declaración de EXPLAIN PLAN.
OPERATION El nombre de la operación realizada en este paso; Contiene
un valor en la primera fila generada para cada declaración
OPTIONS Las opciones para la operación (por Ejemplo, esto dirá
"remoto" Si una tabla remota es para la que se estableció
referencias en la Declaración de SQL).
OBJECT_NAME El nombre del objeto.
ID El número de este paso en el plan de ejecución
PARENT_ID Él ID del paso que opera en los resultados de este paso.
POSITION La orden en la cual los pasos con el mismo padre son
tratados.
Nota: Normalmente, metes esta declaración en un escrito de SQL con una variable para
el valor del ID de la declaración. Estas marcas usando lo explican plan mucho más
factible. En ese mismo escrito, también puedes suprimir (o truncar) todas las filas de la
PLAN_TABLE después de que los recuperase.
Alternativamente, el SQL*Plus y AUTOTRACE para eliminar la necesidad a
emitir consultas en contra de la PLAN_TABLE.
Desplegando PLAN_TABLE
SQL> select id
2. lpad( , 2*level) | | operation )
3. ||decode (id,0, cost= ||posit
4. || || options
5. || || objetc_name as Query Plan
6. from plan_table
7. Where Statement_id = demo_01
8. Connect by priorid = parent_idstart with id=0
ID Query plan
----- ----------------------------------------------------------------------
0 SELECT STATEMENT cost =
1 TABLE ACCESS BY INDEX ROWID CLASSES
2 AND-EQUAL
3 INDEX RANGE SCAN STAT_INDEX
4 INDEX RANGE SCAN LOC INDEX
Desplegando el plan de ejecución
Algunos otras columnas útiles (no usadas en el ejemplo) de la PLAN_TABLE
son:
TIMESTAMPLa fecha y el tiempo cuando la declaración expedida.
COST Basado el optimizador en costos la estimación del costo de realizar
la operación Incluyendo el costo de cualquier operación que están
obligadas a completar esta operación (El valor de esta columna no
tiene una unidad de medida particular. Es meramente un valor
ponderado usado para comparar expensas de ejecución planea.)
28
CARDINALITY Basado el optimizador en costos la estimación del número de

filas procesadas
BYTES Basado el optimizador en costos la estimación del número de
bytes
OTHER El texto de SQL para cursores remotos y la consulta de
paralelo los Esclavos como adecuadamente tan igual a
información - de consulta la operación - flujo de datos
OTHER_TAG Las descripciones de función del texto de SQL en la OTRA
columna
OPTIMIZADOR El modo actual del optimizador
OBJECT_OWNER El nombre del esquema que contiene la tabla o el índice
OBJECT_TYPE Un modificador que describe el objeto, como NON-UNIQUE
para un índice
Interpretando el plan de ejecución
Interpretando el Plan de Ejecución

Cada paso del plan de ejecución o rescata filas de la base de datos o acepta
filas como la entrada de uno o más otros pasos, también conocido como fuentes
de la fila. En el diagrama, los números son propios de los valores de la ID en el
PLAN_TABLE
La operación AND_EQUAL (2) acepta los ROWIDs obtenidas por ahí lo repasa
con la vista del STAT_INDEX (3) y LOC_INDEX (4), y regresa los ROWIDs que
vienen de ambas fuentes. Esto resulta en un set de ROWIDs que permiten
TABLE ACCESS(1) de la tabla de CLASES a devolver las filas que satisfacen la
consulta. Los ROWIDs están clarificados en los "Índices y" Métodos de acceso
"Básicos" lección.
El costo de un plan de ejecución es un valor proporcional para lo esperado
tiempo transcurrido necesitado para ejecutar la declaración, usando ese plan de
ejecución. Si el Optimizador basado en reglas es usado, entonces el costo no
está disponible y muestra un valor NULO.
Comparando Planes de Ejecución
Puedes determinar la ejecución que el plan usó por el Optimizador usando
EXPLAIN PLAN. Si una declaración de SQL no funciona satisfactoriamente,
29
entonces puedes resolver introducir un índice. Deberías comprobar el plan de
ejecución otra vez para hacer seguro que el índice está usado.
SQL *Plus AUTOTRACE
El SQL*PLUS AUTOTRACE
En el SQL*PLUS, automáticamente puedes obtener el plan de ejecución y
algunas estadísticas adicionales en la corrida de una orden de SQL usando al
AUTOTRACE. A diferencia del EXPLAIN PLAN, la declaración es de hecho
puesta a funcionar, aun si haces suprimir la salida de declaración; Así puedes
ostentar estadísticas realistas. AUTOTRACE, un rasgo disponible desde la
liberación Oracle Server 7.3, es una herramienta diagnóstica excelente para
afinación de declaraciones de SQL. Porque es puramente declarativo, sea más
fácil usar EXPLAIN PLAN
Opciones del comando:
ON Desahabilita autorastrear declaraciones de SQL
OFF Habilita autorastrear declaraciones de SQL
TRACEONLY Posibilita autorastrear declaraciones de SQL y suprime
salida de declaración
EXPLAIN Despliega los planes de ejecución pero no estadísticas
STATISTICSDespliega estadísticas pero no planes de ejecución
Nota: Si ambas opciones de los comandos EXPLAIN y las STATISTICS son omitidas,
entonces los planes de ejecución y las estadísticas son desplegadas por defecto.
SQL*Plus Autotrace Ejemplos

• Para comenzar rastreando declaraciones con AUTORACE:
SQL> set autotrace on
• Para ocultar la salida de la declaración
SQL> set autotrace traceonly
• Solo para desplegar la ejecución del plan
SQL> set autotrace traceonly explain
Los prerrequisitos para Usar a AUTOTRACE
Para usar lo EXPLICA opción de AUTOTRACE, primero debes crear la
PLAN_TABLE de la tabla en su esquema, tal como necesitarías hacer antes de
usar orden de EXPLAIN PLAN.
Para ganar acceso a los datos de ESTADÍSTICAS, debes tener acceso a varias
tablas dinámicas de desempeño. El ADMINISTRADOR DE BASE DE DATOS
puede conceder acceso usando el plustrace de papel creado en el escrito del
plustrce.sql. (Este nombre del escrito puede cambiar por sistema operativo.) El
30
ADMINISTRADOR DE BASE DE DATOS debe poner a funcionar el escrito como

el usuario SYS y debe conceder el papel para los usuarios que quieren usar la
opción de ESTADÍSTICAS de AUTOTRACE.
Controlando al AUTOTRACE Execution Plan Layout
El plan de ejecución consta de cuatro columnas exhibidas en la siguiente orden:
ID_PLUS_EXP El número de la línea de cada paso
PARENT_ID_PLUS_EXP El número de la línea de paso del padre
PLAN_PLUS_EXP El paso de reporte
OBJECT_NODE_PLUS_EXP Ligas de base de datos servidores de consulta
paralelos usados
Puedes cambiar el formato de estas columnas, o las puede suprimir, usando el
SQL*PLUS la orden de la COLUMNA.
SQL *Plus Autotrace Estadísticas

SQL>set autotrace traceonly statistics
SQL> select * frin dyak;
Statistics
-----------------------------------------------------------------------------------
0 recursive calls
3 db block gets
1 consistent gets
0 physical reads
0 redo size
565 bytes sent via SQL *Net to client
646 bytes received via SQL *Net from client
4 SQL*Net roundtrips to/from client
1 sort (memory)
0 sort (disk)
1 rows processed
ESTADISTICAS AUTOTRACE.
AUTOTRACE ostenta varias estadísticas, no todos ellos pertinente para el
debate a estas alturas. En la siguiente lección, al discutiendo Indicio de SQL y
TKPROF, este curso entra en más detalle acerca de las estadísticas de
ejecución de declaración de SQL. Los más importantes son lo siguiente:
Db block gets El número de entrada/salidas lógicas actuales traidas.
Consistents gets El número de entrada/salidas lógicas lecturas consistentes
Physical reads El número de bloques leídos de disco
redo size La cantidad de redos generados (para declaraciones DML)
sorts(la memoria) El número de sorteos realizados en memoria.
sorts (disco) El número de sorteos realizados temporalmente en disco.
Resumen
La afinación involucra análisis meticuloso de estadísticas de ejecución de planes
y de ejecución. Varias herramientas están disponibles para ayudar probar y
diagnosticar problemas de desempeño con una declaración de SQL:
• PLAN_TABLE almacena planes de ejecución y puede ser creadas usando el
escrito del utlxplan.sql.
31
• EXPLAIN PLAN determina cómo tramitaría el optimizador una declaración (la
declaración no es ejecutada) y almacena el plan de ejecución en el
PLAN_TABLE.
• La orden DETERMINADA AUTOTRACE en el SQL*PLUS le faculta a mirar el
plan de ejecución y una variedad de estadísticas acerca de la ejecución
cuando quieras que ejecute una declaración de SQL.
Varios otras herramientas pueden usarse para monitorear desempeño,
alertándole para la necesidad para afinar declaraciones de SQL. Algunas de
estas herramientas estarán cubiertas en lecciones futuras.
Practica.
En esta práctica, debes crear una PLAN_TABLE, analizar una declaración de
SQL y formatear los resultados analizados, usando el escrito del rp.sql. También
usar el SQL*PLUS para aplicar el comando AUTOTRACE revisar planes de
ejecución.
Práctica 3
1. Verifique la existencia de una tabla de la _ PLAN_TABLE en su esquema.
Cree esta tabla cuándo Necesitado, usando el escrito del utlxplan.sql.
2. Explique la siguiente orden de SQL:
SQL> select first_name, last_name
2 from employees
3 where emp_id = 6191;
3. Ahora consulte la tabla PLAN_TABLE:
SQL> select * from plan_table;
Use el escript rp.sql para consultar la tabla PLAN_TABLE de una manera mas
sofisticada SQL> @rp
4. Habilite el AUTOTRACE para desplegar planes de ejecución y ejecute el
comando del paso 2 nuevamente.
5. Use el AUTOTRACE para suprimir la salida del comando y mostrar ambos
planes, de ejecución y estadísticas y ejecute el paso 2 nuevamente.
6. Si tienes algún tiempo, entonces introduce tus declaraciones de SQL y
experimenta con EXPLAIN PLAN y AUTOTRACE.
32
4 SQL trace y TKPROF
Los Objetivos
Puedes usar herramientas diversas de análisis para evaluar el desempeño de
declaraciones de SQL.
Después de completar esta lección, debes:
• Configurar Inicio de SQL para recoger estadísticas
• Establecer parámetros apropiados de inicialización
• Formatear las estadísticas de trace usando la utilidad TKPROF
• Interpretar la salida de comando TKPROF
Facilidad de SQL Trace

• Puede ser conectado para un ejemplo o una
sesión
• Genera estadísticas para declaraciones de SQL
• Produce salida que puede ser formateadas por
TKPROF
La Facilidad de SQL Trace

Un buen trecho a comparar dos planes de ejecución es ponerlos a funcionar a
ellos y comparar las estadísticas para ver que cuál realiza mejor. Puedes usar la
facilidad de SQL Trace para obtener información de desempeño. El SQL Trace
escribe su salida para un archivo, y usar a TKPROF para formatearlo.
La facilidad de SQL Trace:
• Puede ser conectado para un ejemplo o una sesión
• Hace un reporte sobre estadísticas de volumen y de tiempo para la fases de
el PARSE, EXECUTE, y FETCH.
• La salida de productos que se formateó por TKPROF
Cuándo la facilidad de trace de SQL es posibilitada para una sesión, Oracle
genera un archivo de trace conteniendo estadísticas para las declaraciones
rastreadas de SQL para esa sesión. Cuándo la facilidad de trace de SQL es
posibilitada para un ejemplo, Oracle crea un archivo separado de trace para
cada proceso.
33
Como usar el SQL Trace
1. Ajustar parámetros de iniciación
2. Conectar el trace
3. Correr la aplicación
4. Formatear el archivo de trace
5. Interpretar la salida.
Cómo Usar el SQL Trace

Debes completar cinco pasos para usar la herramienta de SQL Trace:
1. 1.Ajuste los parámetros apropiados de inicialización.
2. 2.Conecte Trace de SQL.
3. 3.Ponga a funcionar la aplicación (y el interruptor fuera de rastrear cuando
hecho).
4. 4.Formatear el archivo de trace producido por el SQL Trace con TKPROF.
5. Interprete la salida y afine las declaraciones de SQL cuando sea necesario
Poniendo a funcionar sistema de incrementos de SQL Trace aéreo. Use el SQL
Trace sólo en caso de necesidad, y use eso en el nivel de sesión en vez de en
el nivel de ejemplo.
Inicializando Parámetros
TIME_STATISTICS = { FALSE |TRUE}
MAX_DUMP_FILE_SIZE = {N | 500}
USER_DUMP_DEST = directory_path
• MAX_DUMP_FILE_SIZE es la medida de bloques de
sistema operativo
• Default USER_DUMP_DEST:
Destino donde genera el archivo
La iniciación Parámetros
Varios parámetros de iniciación guardan relación con SQL Trace.
TIMED_STATISTICS
La facilidad de SQL Trace provee una variedad de información acerca de los
procesos, opcionalmente incluyendo a cronometrar información. Si quieres
cronometrar información, entonces debes cambiar de dirección en este
parámetro. Puedes hacer eso para la base de datos entera ajustando el
34
siguiente parámetro de iniciación en el archivo de parámetro antes de

sobresaltándose y abriendo la base de datos:
TIMED_STATISTICS = TRUE
El parámetro también puede ser determinado dinámicamente para una sesión
particular con la siguiente orden:
El SQL > alter Session set timed_statistics=true
Las estadísticas de oportunidad del momento tienen una resolución de un
centésimas de un segundo. Esto quiere decir que cualquier operación que
termina rápidamente no puede ser regular exactamente, como consultas simples
que ejecutan rápidamente.
TIMED_STATISTICS que haber cronometrado cambiaron de dirección en el
desempeño de afectos ligeramente porque el servidor Oracle debe hacer algún
trabajo adicional. Por consiguiente, este parámetro está comúnmente apagado
específicamente deseado para propósitos de afinación. Sin embargo,
mantenerse TIMED_STATISTICS revueltas podrían hacer más útiles para
ingenieros del soporte en un fallo del sistema.
Nota: Los valores subrayados en la diapositiva indican los valores predeterminados para
los parámetros.
MAX_DUMP_FILE_SIZE y USER_DUMP_DEST
Estos dos parámetros controlan el tamaño y el destino del archivo de salida:
MAX_DUMP_FILE_SIZE = n
USER_DUMP_DEST = directory_path
El MAX_DUMP_FILE_SIZE el valor por dafault es 500, y este valor de
parámetro es expresado en bloques de sistema operativo.
MAX_DUMP_FILE_SIZE también puede cambiarse en el nivel de sesión usando
el comando ALTER SESIÓN.
El default de USER_DUMP_DEST varia de acuerdo al sistema operativo;
Normalmente es el destino predeterminado para el sistema se desploma en su
sistema. USER_DUMP_DEST es un parámetro de nivel de sistema que no
puede variarse en el nivel de sesión. Sólo puede variarse dinámicamente por un
administrador de la base de datos usando lo ALTER SESIÓN.
Obtenga Información acerca de Parameter Settings
Puedes desplegar los valores actuales del parámetro en la vista de
V$PARÁMETER:
SQL> select name, value
2 from v$parameter
3 where name like '%dump%';
Nota: Las especificaciones del camino del directorio que aparecen en la columna de
VALUE manejan dependiente de sistema.
35
Prendiendo SQL trace
• Para una instancia, cambiar los parámetros sig.
SQL_TRACE = TRUE
• Para una sesión actual:
SQL> Alter Session Set Sql_Trace =True;
SQL> execute dbs_session.set:sql:trace (true);
• Para una sesión.
SQL>execute dams_system.set_sql_trace_in_session
2 (session_id, serial_id, true);
Conectando Trace de SQL para un Instancia

Para conectar Trace de SQL para un ejemplo entero, ajustó el parámetro de
inicialización:
SQL_TRACE=TRUE
Conectando Trace de SQL para un Sesión
Puedes usar una orden de SQL conectar Trace de SQL para su sesión.
SQL> alter session set sql_trace = true;
También puedes usar un paquete abastecido conectar Trace de SQL para su
sesión. Esto es útil cuando quieres animar al SQL Trace y completamente desde
adentro de una unidad del PL/SQL.
SQL> execute dbms_session.set_sql_trace(true);
También puedes conectar Trace de SQL para la sesión de otro usuario con un
paquete abastecido.
SQL> execute dbms_system.set_sql_trace_in_session
2 (session_id, serial_id, true);
En esta llamada de procedimiento, session_id serial_id son los valores en de las
columnas SID y de V$SESSION, una vista de diccionario de datos comúnmente
usada por administradores de la base de datos.
Apagando el SQL Trace
Cuando hayas terminado la afinación, podrás apagar el SQL Trace usando
cualquier de los métodos citados anteriormente, substituyendo la palabra FALSE
por TRUE. Si conectas Trace de SQL para una sola sesión, entonces apagar el
SQL Trace.
Encontrando los Archivos de Trace

• Ver en el directorio especificado en la variable
USER_DUMP_DEST.
• Si pocos usuarios están corriendo SQL trace ver el mas
reciente
• De otra manera, considerar escribir un scrip.
SQL>@ readtrace.sql
SQL> execute gettrace;
PL/SQL procedure successfully completed.
36
Encontrando Archivos de trace

Identificar su archivo de trace en el directorio especificó por USER DUMP_DEST
es usualmente una materia de descubrimiento el archivo de trace con la estampa
más reciente de tiempo. Sin embargo, esta tarea se pone más difícil cuando
varios usuarios generan archivos de trace al mismo tiempo.
Cuando Varios Usuarios Crean Archivos de trace
Cuando varios usuarios crean archivos simultáneamente, el escrito del
readtrace.sql puede ser útil. Crea un procedimiento que abre su archivo actual
de trace usando el paquete UTL_FILE. El nombre predeterminado del archivo de
salida es username.trc, pero también puedes especificar un nombre por ti
mismo.
SQL> @readtrace.sql
SQL> alter session set sql_trace = true;
SQL> select * from dual;
SQL> execute gettrace('output_filename');
Formateando Archivos de Trace

OS>tkprof tracefile outputfile [options]
Ejemplos del comando TKPROF
Os>tkprof
Os>tkprof ora_815.rc run 1.txt
Os>tkprof ora_815.rc run 1.txt sys=no
Sort=execpu print=3
Formateando archivos de trace
Use la orden TKPROF para formatear sus archivos de trace en una salida
legible.
Ésta es la sintaxis TKPROF:
OS> tkprof tracefile outputfile [options]
tracefile El nombre del archivo de salida de trace (introduzca en la
computadora para TKPROF)
outputfile El nombre del archivo a almacenar los resultados formateados
Cuándo la orden TKPROF es introducida sin cualquier discusión en, general un
mensaje de uso conjuntamente con una descripción de todas las opciones
TKPROF. Vea la siguiente página para una lista llena.
Nota: Los archivos de trace generados inmediatamente después del arranque de ejemplo
contienen datos eso refleja la actividad del proceso de arranque. En particular, reflejan
una cantidad desproporcionada de actividad de entrada/salida física como los escondites
en la SGA estén llenos. Para los propósitos de afinación, deberías ignorar tales archivos
de trace.
La salida del comando TKPROF
Ésta es la salida que obtiene cuando introduces la orden TKPROF sin cualquier
discusión:
Uso: tkprof tracefile outputfile [explain= ] [table= ]
[print= ] [insert= ] [sys= ] [sort= ]
table=Schema.tablename Use schema.tablename con la opción EXPLAIN
37
explain = user/password Conéctese a la base de datos y use EXPLAIN PLAN.
Print=integer Liste sólo las primeras declaraciones de SQL de
entero.
aggregate = no No agregue declaraciones idénticas de SQL en un
resultado.
Insert=filename Las declaraciones de SQL de la lista y los datos de
adentro INTERCALAN declaraciones.
Sys = no TKPROF no lista declaraciones de SQL dirigidas
como usuario SYS.
Record=filename Registre declaraciones poco recursivas encontradas
en el archivo de trace.
sort=option El set de cero o más de las siguientes opciones de
sorteo:
Las opciones:
prscnt El número de por PARSE fue llamado
prscpu El análisis gramatical de tiempo de procesador
prsela El análisis gramatical de tiempo transcurrido
prsdsk El número de disco lee durante PARSE
prsqry El número de buffers para coherente leído durante PARSE
prscu El número de buffers para corriente leyó durante PARSE
prsmis El número de perdidas en escondite de la biblioteca durante PARSE
execnt El número de EXECUTE fue llamado
execpu El tiempo de procesador pasado ejecutando
exeela El tiempo transcurrido ejecutando
exedsk El número de disco lee durante EXECUTE
exeqry El número de buffers para coherente leído durante EXECUTE
execu El número de buffers para corriente leyó durante EXECUTE
exerow El número de filas procesadas durante EXECUTE
exemis El número de escondite de la biblioteca extrañan durante EXECUTE
fchcnt El número de por la estratagema fue llamado
fchcpu El tiempo de procesador pasado yendo a traer
fchela El tiempo transcurrido yendo a traer
fchdsk El número de disco lee durante la estratagema
fchqry El número de buffers para coherente leído durante la estratagema
fchcu El número de buffers para corriente leyó durante la estratagema
fchrow El número de filas a traer
userid La identificación del usuario que analizó gramaticalmente el cursor
Opciones del Comando TKPROF

SORT=option
PRINT= n
EXPLAIN= username/password
INSERT= filename
SYS= NO
AGGREGATE=NO
RECORD=filename
TABLE= schema tablename
38
Opciones del comando TKPROF

SORT La orden en la cual para clasificar las declaraciones en el reporte (la Sede la
página previa Para una lista de valores.)
PRINT Produce un reporte en este (Esta opción (clasificado) número de
declaraciones únicos Es especialmente útil en la combinación con la opción
de TIPO.)
EXPLAIN Se conecta en el sistema y ejecuta EXPLAIN PLAN en el esquema
especificado
INSERT Crea un escrito de SQL para cargar los resultados TKPROF en una tabla de
la base de datos
SYS Desactiva la lista de declaraciones recursivas de SQL, expedidas por el
usuario SYS
AGGREGATE Desactiva o activa el (default) comportamiento de TKPROF, agregando
Las declaraciones idénticas de SQL en un registro
RECORD Crea un escrito de SQL con todas las declaraciones de SQL poco recursivas
encontradas adentro El archivo de trace (Este escrito puede usarse para
volver a jugar la sesión de afinación más tarde.)
TABLE Especifica la tabla para almacenar planes de ejecución antes de escribir para
el archivo de salida (Este parámetro es ignorado si EXPLAIN no está
especificado. Es útil cuando varias personas físicas usan a TKPROF para
afinar lo mismo esquema concurrentemente, a evitar interferencia
destructiva.)
Salida del comando TKPROF

• Texto de la declaración de SQL
• Estadísticas del trace (para una declaración y llamadas recurridas)
separados dentro de un árbol de los pasos procesados de SQL:
PARSE Translada la declaración de SQL dentro de un plan de
ejecución
EXECUTE Executa la declaración (Este paso modifica los datos de las
declaraciones del INSER, UPDATE, y DELETE.)
FETCH Regresa las filas generadas por la consulta (los fonos tiene
rendimiento solo por SELECT).
La Salida del Comando TKPROF

La salida TKPROF lista las estadísticas para una declaración de SQL por el paso
de procesamiento de SQL.
El paso para el cual cada fila contiene estadísticas es identificado por el valor de
la columna de llamada.
PARSE Este paso traduce la declaración de SQL a un plan de ejecución e incluye
Los cheques para autorización prendaria correcta y cheques para la
existencia de Las tablas, las columnas, y otros objetos para los que se
estableció referencias.
EXECUTE Este paso es la ejecución real de la declaración por el Oracle8i Server.
Pues el INSERTO, la ACTUALIZACIÓN, y las declaraciones DELETE, esto
dan un paso modifica lo Los datos (incluyendo tipos cuando necesitado).
Pues las declaraciones SELECTAS, esto dan un paso Identifica las filas
seleccionadas.
FETCH Este paso recupera filas devueltas por una consulta, y las clasifica cuando es
necesitado. Las estratagemas son realizadas sólo para declaraciones
SELECTAS
39
Nota: El valor PARSE incluye ambos duro y suave analiza gramaticalmente. Uno duro
analiza gramaticalmente manera a la que el núcleo Oracle realmente tiene analiza
gramaticalmente la declaración de SQL (incluyendo optimización); Se guarda
subsiguientemente en library cache. Uno suave analiza gramaticalmente manera que una
declaración de SQL es por la que se envió el análisis gramatical para el núcleo, pero el
núcleo encuentra él en library cache, y sólo las necesidades a verificar cosas les gustan
los derechos de acceso. Duro analiza gramaticalmente puede costar caro, en particular
debido a la optimización; Uno suave analiza gramaticalmente cuesta en su mayor parte
caro en términos de la actividad dlibrary cache.
Siete categorías de estadísticas para trace
Count Numero de veces que l procedimiento fue ejecutado
CPU Numero de segundo procesados
El aps ed TOTAL DE SEGUNDOS PARA EL EXECUTE
Disk Numero de bloques físicamente leídos
Query Numero de lecturas lógicas por lecturas consistentes
Current Number of logical buffers readin current mode
Rows Numero de filas procesadas para el fetoh o execute
La salida del comando TKPROF
Al lado de la columna de LLAMADA, TKPROF despliega las siguientes
estadísticas para cada declaración:
count Numero de veces que una declaración fue analizada gramaticalmente, (Cheque
esto La columna para los valores > 1 antes de interpretar las estadísticas en las
otras columnas A menos que el AGGREGATE = NO opción sea usado, los
agregados TKPROF las ejecuciones idénticas de declaración en una tabla
sumaria.)
CPU Totaliza tiempo de procesador en los segundos para todo PARSE, EXECUTE, o
FETCH
Elapsed Totalice tiempo transcurrido en los segundos para todo PARSE, EXECUTE, o
FETCH
Disk El número total de bloques de datos físicamente leen de los archivos de datos en
disco
Para todo PARSE, EXECUTE, o FETCH
Query Totalice número de buffers recuperados en el modo coherente para todo PARSE,
EXECUTE O las llamadas de estratagema (los Buffers son usualmente
recuperados en el modo coherente para consultas.)
Current Totalice número de buffers recuperados en el modo actual (los Buffers
típicamente son
Recuperado en el modo actual para las declaraciones de DML. Sin embargo, el
encabezado del segmento los bloques son siempre recuperados en el modo
actual.)
rows Totalice número de filas tratadas por la declaración de SQL (Este total no incluye
el número de filas regresadas por las subconsultas: Para las declaraciones del
SELECT el numero de filas regresadas por cada fetch. Para las declaraciones de
UPDATE, DELETE, INSERT el número de filas procesadas aparecen para el
execute
40

La TKPROF salida incluye lo siguiente:
• Declaraciones recursivas de SQL
• Perdidas de Library cache
• Parseo del usuario ID
• Plan de ejecución
• Modo del Optimizar
Llamadas recursivas
Algunas veces para ejecutar un SQL que la declaración emitió por un usuario, el
servidor Oracle debe emitir declaraciones adicionales. Tales declaraciones son
llamadas declaraciones recursivas de SQL. Por ejemplo, si introduces una fila en
una tabla que no tiene bastante espacio a mantener esa fila, entonces el servidor
Oracle hace llamadas recursivas para ubicar el espacio dinámicamente. Las
llamadas recursivas son también generadas cuando la información de diccionario
de datos no está disponible en el escondite de diccionario de datos y debe ser
rescatada de disco.
Si las llamadas recursivas ocurren mientras la facilidad de trace de SQL es
posibilitada, entonces TKPROF los marca claramente como las declaraciones
recursivas de SQL en el archivo de salida.
Puedes suprimir la lista de llamadas recursivas en el archivo de salida ajustando
el parámetro de línea de comando SYS=NO. Noto que las estadísticas pues
declaraciones recursivas de a SQL les es siempre incluido en la lista para la
declaración de SQL tan causado la llamada recursiva.
Perdidas del Library cache
TKPROF también lista el número de fallos library cache resultando de PARSE y
EXECUTE pasos para cada declaración de SQL. Estas estadísticas aparecen en
líneas separadas siguiendo las estadísticas tabulares.
Analizando gramaticalmente ID del usuario
Ésta es la ID del último usuario para analizar gramaticalmente la declaración.
La ejecución Plan
Si especificas el parámetro en la línea de comando TKPROF, entonces TKPROF
usa lo EXPLAIN PLAN para generar el plan de ejecución de cada SQL que la
declaración rastreó. TKPROF también despliega el número de filas tratadas por
cada paso del plan de ejecución.
Nota: Sea consciente que el plan de ejecución es generado en el momento en que la
orden TKPROF es puesta a funcionar y no en el tiempo que el archivo de trace fue
producido. Esto podría hacer una diferencia si, por ejemplo, un índice ha sido creado o
caído desde rastrear las declaraciones.
Optimizador Mode o Hint
Esto indica el Optimizador que el indicio usó durante la ejecución de la
declaración. Si no hay indicio, entonces muestra el Optimizador que el modo
41
usó. Los indicios y los modos Optimizador se discuten en más detalle en la
"Influenciando al Optimizador".
Ejemplo de Salida TKPROF: No Index

SQL>select status from registrations
2 Where class_id= 155801 and stud_id = 7586;
Call Count Cpu Elapsed disk query current rows
Parse 1 0.54 0.56 1 0 0 0
Execute 1 0.01 0.01 0 0 0 0
Fetoh 1 0.52 1.47 1159 1160 0 1
Total 3 1.07 2.04 1160 1160 0 1
Hisses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 75
El ejemplo de salida TKPROF : No Index
El ejemplo en la diapositiva muestra una fila siendo yendo a traer de la tabla de
inscripciones. Requiere 1,160 lean y 0.52 segundos de tiempo de estratagema
de la CPU. La declaración es ejecutada a través de búsqueda en toda la tabla de
REGISTRATIONS, como podrías usar el EXPLAIN opción de línea de comando.
La declaración necesita ser optimizada.
Ejemplo de Salida TKPROF: Unique Index

SQL>select status from registrations
2. Where class_id= 155801 and stud_id = 7586;
Call Count Cpu Elapsed disk query current rows
-------------------------------------------------------------------------------------------------------------------------------
Parse 1 0.10 0.10 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetoh 1 0.00 0.00 0 4 0 1
-------------------------------------------------------------------------------------------------------------------------------
Total 3 0.10 0.10 0 4 0 1
Hisses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 75
El ejemplo de salida TKPROF : Único Index
La misma fila es recuperada, pero en este caso entrada/salida se reduce
sustancialmente sólo cuatro bloques leídos. Además, el tiempo de procesador se
reduce a 0.00 segundos. Estos resultados son logrados porque la declaración
usa un único índice.
Puedes lograr mejoras significantes en el desempeño por la indexación sensata.
Identifique áreas para la mejora potencial usando la facilidad de SQL Trace.
Nota: Los índices no deberían forjarse hasta requeridos. Los índices lentos derriban el
procesamiento de las ordenes INSERT, UPDATE, y DELETE, porque las referencias
para filas necesitan estar añadidas, cambiadas, o removidas. Los índices sin uso
deberían estar removidos. Si es posible, tramite todo SQL de aplicación directo
EXPLAIN PLAN y saca cualquier índice que no son para los que se estableció
referencias.
42
Interpretación TKPROF
• Lectura consistencia trap
• Esquema a trap
• Tiempo trap
• Trigger trap
Lectura Consistente Trap
Algunas veces otras transacciones tienen cambios no comprometidos contra una
tabla. Esto aumenta el número de visitas del bloque, porque los bloques
adicionales deben estar construidos y visitados pues deben leer la consistencia.
El esquema Trap
Las estadísticas TKPROF muestran un número alto de visitas del bloque
mientras el plan de ejecución indica un acceso del índice. Especialmente si la
salida muestra un poco cero aprecie para corriente, entonces la tabla debe de
ser a la que se ganó acceso por una tabla llena repase con la vista (compare las
columnas actuales en las dos páginas previas). El índice debe de ser construido
después de que el archivo de trace sea producido, o las estadísticas de la tabla y
de la columna pueden ser recomputadas.
El tiempo Trap
Si una declaración particular de LENGUAJE DE MANIPULACIÓN DE DATOS
muestra a gran altura cronometrando estadísticas, entonces la explicación puede
ser interferencia de otra transacción manteniendo (compartidas) cerraduras
sobre el tapete. Por esto es el tiempo de procesador es un mejor señalizador que
el tiempo transcurrido.
El trigger Trap
Los recursos reportados para una declaración incluyen esos para todo el SQL
emitido mientras la declaración estaba siendo tratada. Por consiguiente, incluyen
cualquier recurso usado dentro de un trigger, junto con los recursos usados por
cualquier otro SQL recursivo (como el SQL usado para la fijación de espacio).
Resumen
En esta lección, tu deberás de haber aprendido como:
• Parámetros de inicialización de SQL trace
− SQL_TRACE, TIMED_STATISTICS
− USER_DUMP_DEST, MAX_DUMP_FILE_SIZE
• Conectar SQL Trace para una sesión
Alter session set sql_trace =tree
Dbms_session.set_sql_trace ()
Dbms_system.set_sql_trace_in_session()
• Formatear archivos con TKPROF
• Interpretar la salida
43
Resumen
Esta lección le presentó para la facilidad de SQL Trace. Usando SQL Trace,
puedes evaluar el desempeño de declaraciones de SQL. Una vez que SQL
Trace es animado, mira planes de ejecución y estadísticas en el SQL que las
declaraciones generaron en un archivo de trace.
• Para usar SQL Trace:
• Identifique los parámetros apropiados de inicialización que quieres usar
• Activar el SQL Trace
• Formatee el ARCHIVO de trace que se generó por TKPROF utilizador
• Interprete la salida de TKPROF
Práctica
En esta práctica, veras y cambiaras los parámetros de inicialización que influyen
en el trace de declaraciones de SQL. Entonces SQL trace para analizar una
declaración de SQL. Los resultados del análisis escritos para un archivo de
trace. Encuentre el archivo de trace y use a TKPROF para formatear las
estadísticas. Interprete los resultados formateados de trace.
1. Compruebe los siguientes parámetros de inicialización:
− TIMED_STATISTICS
− MAX_DUMP_FILE_SIZE
− USER_DUMP_DEST
− SQL_TRACE
Asegúrese que ambos TIMED_STATISTICS y de SQL_TRACE está en TRUE
para su sesión. El SQL de vuelta * Y AUTOTRACE completamente.
2. EXECUTE la siguiente orden de SQL:
SQL> select first_name, last_name
2> from employees
3> where emp_id = 6191;
3. Ahora habilite el trace para su sesión y trate de encontrar su archivo de trace.
Abra el archivo de trace con un editor de texto del sistema operativo e
investigue los contenidos de su archivo de trace.
4. Inicie TKPROF sin argumentos en la línea de comando. TKPROF despliega
un mensaje de uso listando todas las opciones de líneas de comando.
5. Inicie a TKPROF otra vez, esta vez con el nombre de su archivo de trace
como un argumento. También especifique un nombre para el reporte de
salida TKPROF. Compruebe el resultado con editor de sistema operativo otra
vez, y vea cómo es la legibilidad mejorada.
6. Finalmente, inicie TKPROF de tal manera que la ejecución tenga pensado
agregar para el reporte y las declaraciones recursivas de SQL son
suprimidas.
44
5 Optimización Basada en Reglas Contra

Costos
Objetivos
Después de completar la lección podrás realizar los siguiente:
• Describir las funciones del Optimizador de Oracle8i
• Distinguir entre optimización basada en reglas(RBO) y costos(COB) .
• Identificar cuando usar RBO y CBO
• Identificar los factores que considera CBO
• Identificar e influenciar el comportamiento de RBO
• Asignar valores al Optimizador para una instancia y/o una sesión
Visión General
• Optimización basada en reglas
• (RBO)
• Optimización basada en costos (CBO)
• Ajustado el Optimizador
• Ordenación del esquema por rango
• Influenciando el RBO
Visión general
Hay caminos de métodos diversos y de acceso que pueden usarse para ejecutar
una declaración de SQL. Es el trabajo de Optimizador escoger cuáles para usar.
• La función RBO se decide basada en un conjunto de reglas.
• La función CBO basada esta elección en las estadísticas que sostiene acerca
de las tablas.
Esta lección da aclaraciones cómo se decide el Optimizador de Oracle entre
estos dos avances.
Para usar optimización basada en costos, deberías coleccionar estadísticas
acerca de las tablas involucradas. Esto está cubierto en una posterior lección. La
optimización basada en costos puede ser influenciada en varias formas
sofisticadas; Esto está también cubierto en una posterior lección.
Aunque se logra todavía usar optimización basada en reglas, no deberías usar
este método. Esta lección sale a la vista qué tan basado en reglas los usos de
optimización un esquema de mayor categoría a producir planes de ejecución.
también verás codificar técnicas que han sido populares en el pasado para
influenciar optimización basada en reglas.
Finalmente, esta lección detalla cuatro avances básicos del optimizador de
Oracle8i, lo cual puede estar lista en el ejemplo y el nivel de sesión.
45
Funciones del Optimizador de Oracle 8i
• Evalúa expresiones y condiciones
• Transforma declaraciones en declaraciones
equivalentes
• Decide como accesar el dato
• Decide como unir tablas
• Decide cual ruta es mas eficiente
Las Funciones del Optimizador Oracle8i.

El Optimizador es la parte del Oracle8i Server que crea el plan de ejecución para
una declaración de SQL. Un plan de ejecución es una serie de operaciones que
son realizadas consecutivamente para ejecutar la declaración. La mayor parte de
estos pasos se discutieron en el "procesamiento de declaraciones de SQL".
El Optimizador puede usar trozos de información diversos diseñar el mejor
camino:
• Los indicios abastecidos por el desarrollador
• Las estadísticas
• La información en el diccionario
• La cláusula WHERE
Usualmente, el Optimizador opera en el trasfondo. Sin embargo, con
herramientas de diagnosis como EXPLAIN, SQL*PLUS Y AUTOTRACE, y OEM
SQL, puedes ver las decisiones que el Optimizador hace.
Optimización basada en reglas
• Soportado por versiones anteriores
• Es manejada la sintaxis
• No usa estadísticas de los datos
• No calcula costos
La Optimización Basada en Reglas

La optimización basada en reglas es respaldada en Oracle8i, pero sólo para la
compatibilidad con versión Oracle 6 y debajo. Si todavía tienes las aplicaciones
OLTP existentes desarrolladas y cuidadosamente afinaron usar versión Oracle 6,
podrías querer continuar usando optimización basada en reglas cuando mejoras
estas aplicaciones para Oracle8i.
La optimización basada en reglas es sintaxis conducida, lo cual quiere decir tan
cambiante que la sintaxis de declaraciones de SQL podría cambiar el
desempeño. Dese cuenta de lo siguiente:
• Ninguna de las estadísticas son usadas, así es que el Optimizador no sabe
cualquier cosa acerca del número de filas en una tabla y los valores en las
columnas de la tabla.
• Ningún de los planes de ejecución se calculan; La decisión acerca de un plan
de ejecución se basa completamente en un conjunto de reglas.
46
Nota: Al las herramientas diagnósticas utilizadoras les gusten EXPLIQUE y SQL * Y

AUTOTRACE, el acercamiento basado en reglas de optimización es fácil para
reconocer: El COSTO siempre ostentará un valor NULO. Tan pronto como un valor de
costo aparece, sabes que el acercamiento basado en costos del Optimizador es usado.
Optimización Basada en Costos

• Fue introducido por Oracle?
• Maneja estadísticas
• Decisiones basadas en calculo de costo
− Numero de lecturas lógicas
− Uso de CPU
− Transmisiones por la red
• Es continuamente realizado
• Típicamente Funciona mejor que RBO
La optimización basada en costos
Oracle7 fue la primera liberación que implementó optimización basada en costos.
A diferencia de la optimización basada en reglas, el Optimizador basado en
costos basa sus decisiones en las estimaciones de costo, cuál en la vuelta
básese en estadísticas almacenadas en el diccionario de datos.
En calcular el costo de ejecución planea, la optimización basada en costos
considera lo siguiente:
• El número de lógico lee (Éste es el factor más importante.)
• La utilización de la UPC
• Enlace en red transmisiones
La optimización basada en costos es continuamente realzada con cada
liberación nueva del servidor Oracle, y varias características Oracle8i como
uniones, señalan con un inicio de consultas, histogramas, y tablas organizadas
en índice están disponibles sólo para la optimización basada en costos.
Eligiendo entre RBO y CBO
• Comportamiento del optimizador de Oracle 8i
− RBO Cuando no hay estadísticas disponibles
− CBO Cuando las estadísticas están disponibles
para al menos una referencia del objeto
• Esto puede influir en los siguientes niveles:
− Instancia
− Sesión
− Declaración
La Elección Entre RBO y CBO
Éste es el comportamiento predeterminado Oracle8i Optimizador:
• Cuándo ninguna de las estadísticas son disponibles, la optimización basada
en reglas es usada.
47
• Cuando las estadísticas están disponibles pues al menos una puso notas al
objeto, la optimización basada en costos es usada;
• Cualquier estadísticas faltantes son estimadas o reemplazadas por valores
de códigos duro, incorporados.
Influenciando el comportamiento Predeterminado
Este comportamiento predeterminado puede ser influenciado por ejemplo,
para obtener a la fuerza optimización basada en reglas bajo todas las
condiciones en tres niveles diferentes:
• El nivel de ejemplo
• El nivel de sesión
• El nivel de declaración
.Nota: Si cualquier tabla para la que se estableció referencias en una consulta tiene un
grado de paralelismo más que 1, CBO siempre será usada a pesar de cualquier indicios
o escenarios. También asegúrate que tiene estadísticas de la tabla, las estadísticas de la
columna, de otra forma recolección, pues una tabla no resultarán en la optimización
basada en costos.
Activando el Optimizador
• A nivel instancia, Actualice el parámetro:
OPTIMIZER_MODE =
{CHOOSE| RUEL|FIRST|_ROWS|ALL_ROWS}
• Para una sesión use el siguiente comando de
SQL;
SQL>alter session set optimizer_moce
{choose| ruel|first|_rows|all_rows}
Colocando el Acercamiento del Optimizador

Oracle8i tiene cuatro avances básicos del Optimizador:
CHOOSE Se comporta tan descrito más temprano en esta lección: Basado en
costos cuando las estadísticas son Disponibles, basados en reglas
cuando no son (cuál es el valor predeterminado)
RULE Obtiene a la fuerza optimización basada en reglas a pesar de la
presencia de estadísticas
FIRST_ROWS Optimiza para reducir el tiempo hasta el primer que regresa
el primer resultado (tan para interactivo las aplicaciones OLTP)
ALL_ROWS El rendimiento específico global del Optimizador (tan para
informaciones y los trabajos de la cantidad de cosas)
Los niveles de Acercamiento del Optimizador
A nivel de instancia, puedes ajustar el acercamiento del Optimizador usando el
parámetro de inicialización de OPTIMIZADOR_MODE. Cuando este parámetro
no es determinado, incumple para CHOSE.
Cuando las estadísticas están disponibles, CHOOSE es equivalentes para
ALL_ROWS.
En el nivel de sesión, el acercamiento del Optimizador colocado en al nivel de la
instancia puede ser del que se decidió usando el comando ALTER SESSION
48
Optimización Basada en Reglas

• Use índices incondicionalmente, porque no hay
estadísticas
• Use un esquema incorporado con puntuación para
rutas de acceso
• Es difícil manejarlo
La optimización basada en reglas
La optimización basada en reglas siempre usa índices cuando es posible, aun
cuando las tablas son pequeñas o cuando las consultas típicamente devuelven
un porcentaje significante de las filas, tan ese mas rápido el repaso de una tabla.
La optimización basada en reglas no se da cuenta de estadísticas, como el
número de filas en una tabla o la selectividad de un predicado.
La optimización basada en reglas usa un esquema de mayor categoría para
decidir cuál es el mejor camino de acceso para los datos hacer una selección.
Influenciando RBO
No puedes influenciar optimización basada en reglas, excepto por índices que
crea, dejando caer índices, o inutilizando índices cambiando la sintaxis de
declaración.
Si RBO encuentra dos planes de ejecución que acumulan puntos, entonces lo
mismo en el esquema de mayor categoría, hace una decisión arbitraria. Por
ejemplo, suponga que cada plan disponible puede usar único de dos índices
diferentes. En ese caso la decisión de RBO no está documentada, pero
descender y recrear uno de los índices involucrados influenciará el
comportamiento de RBO: Usará el índice recién creado. Así, deberías ser
consciente que recreando una serie de índices en una orden diferente
probablemente influenciará el comportamiento de RBO. Alternativamente,
puedes cambiar la declaración de SQL para imposibilitarla para EL RBO para
usar uno de los índices. Esto se discute más tarde en esta lección.
Rango del esquema RBO
RANGO RUTA DE ACCESO
1. Solofila por Rowd
2. Solofila por cluster join
3. Solofia por hash duster key con llave primaria o única
4. Solofila por llave primaria o única
5. Ouster join
6. Hasholuste key
7. Indexado cluster key
8. Indcloe compuesto
9. Single-columnindex
10. Búsqueda definida sobre columnas indexadas
11. Búsqueda definida sobre columnas indexadas
12. Sort-merge oin
13. MAX o MIN de columnas indexadas
14. ORDER BY sobre una columna
15. Buscar en toda la tabla
49
Ordenando el Esquema RBO
La optimización basada en reglas ejerce reglas basadas en la sintaxis de
declaración para establecer el camino de acceso.
El Optimizador determina todos los caminos disponibles de acceso para una
declaración y entonces escoge el camino con el número mínimo de ordenación
por rango del esquema de mayor categoría exhibido arriba.
Este acercamiento siempre asume ese una tabla llena repase con la vista (rango
15) es el peor método de acceso. Éste realmente no podría ser el caso,
especialmente con tablas pequeñas o con consultas que devuelven un
porcentaje grande de las filas en una tabla.
Estos (y más) caminos de acceso están disponibles a la optimización basada en
costos. Sin embargo, el Optimizador ignora las ordenaciones por rango y
determina que el esperado costo pues cada camino posible de acceso, entonces
escoge el que está con el costo estimado menor. Muchas características nuevas
(hash joins, consultas, histogramas, y tablas organizadas en índice) están
disponibles a través de la optimización basada en costos.
Nota: Para más información acerca de las rutas de acceso de RBO, vea a Oracle8i
Afinando y Oracle8i Concepts: "El Optimaizer".
Ejemplo de optimización basada en reglas
SQL> select las_name
2 From employees
3. Where job= INSTRUCTOR
4. And salary between 3000 abd 6000
5. Order by last_name;
RBO tiene las siguientes rutas de acceso:
• Búsqueda en toda la tabla Rank= 15
• ORDER BY sobre columna indexada Rank =14
• Job índice igual(range) scan Rank=9
• Indice desalary por búsqueda definida de rango Rank=10
Ejemplo de Optimización Basado en Reglas.

El acercamiento basado en reglas escoge un camino basado en la sintaxis de la
declaración. El Optimizador escoge el camino de acceso con el número mínimo
de ordenación por rango.
Si LAST_NAME, JOB Y SALARY son indexados, entonces el Optimizador
basado en reglas tiene las siguientes elecciones:
FULL TABLE SCAN Este camino está disponible para todas las
declaraciones de SQL. Ordena por rango 15.
ORDER BY Este camino podría hacer la clasificación innecesaria.
Ordena por rango 14.
JOB INDEX SCAN Use el índice en el JOB. Ordena por rango 9, un
índice de la sola columna.
SALARY INDEX SCAN Use el índice sobre SALARY. Ordena por rango 10,
SEARCH una búsqueda definida de rango.
50
El rango mínimo es 9, así es que el índice en el TRABAJO se usará para ganar

acceso a las filas de los empleados la tabla.
Note que aunque el índice en el JOB es usado, un filtro que la operación
necesita ser realizada en la columna SALARY para devolver los resultados
correctos.
INFLUENCIANDO LA OPTIMIZACIÓN
BASADA EN REGLAS
• Cambiar el orden de la tabla en la cláusula FROM
• Cambiar el predicado en la orden de la cláusula
WHERE
• Crear o borrar incides
• Suprima el uso de índices con trucos de sintaxis:
− Numeric_colum + 0
− Date_column + 0
− Char_column | |
Influenciando Optimización Basada en Reglas

La optimización basada en reglas es altamente sensitiva para la sintaxis. Cuando
una tablas, la orden en la cual las tablas están especificadas en el FROM la
cláusula puede tener un impacto significante de desempeño. Por ejemplo,
siempre deberías calcular la tabla más restrictiva en el fin, porque el Optimizador
evalúa la cláusula FROM de derecha a izquierda. También, la orden de los
predicados en un compuesto DONDE la cláusula pueda influenciar desempeño.
El Optimizador siempre usa índices cuando están disponibles. Así es importante
para crear índices apropiados y índices de caída que deterioran desempeño.
Desafortunadamente, la mayor parte de los únicos índices no pueden ser a los
que se dejó caer porque protegen restricciones de integridad.
La forma estándar a prevenir optimización basada en reglas de índices
existentes utilizadores debe usar un truco: Los índices son utilizables sólo
cuando los nombres asociados de la columna aparecen limpios en los
predicados. Aplicando a un operador falso (añadiendo cero o concatenando una
cadena vacía), suprime el uso del índice. investigarás este comportamiento del
Optimizador en más detalle en los talleres.
Nota: La optimización basada en costos provee uno más flexible, legible, y método
aceptable para influenciar el Optimizador. Los predicados modificativos en medio
descritos de arriba aquietan trabajos, pero no es recomendado. Sin embargo, deberías
entender el comportamiento de RBO al mantener o la promoción existiendo aplicaciones.
Resumen
Esta lección introdujo la optimización basada en reglas y basada en costos. La
optimización basada en reglas es todavía respaldada para la compatibilidad
retrasada. Has visto cómo usa RBO en un esquema de mayor categoría, y cómo
puede influenciar su comportamiento.
51
La optimización basada en costos fue introducida en Oracle7. El Optimizador usa
estadísticas para calcular el costo de caminos de acceso, teniendo en cuenta el
número del uso de entrada/salidas lógicas, de la CPU, y red tráfico.
También aprendiste cómo puede ser el acercamiento del Optimizador
determinado en el ejemplo y el nivel de sesión, soportando cuatro escenarios
diferentes:
CHOOSE Juzgue El comportamiento: CBO cuando las estadísticas están
disponibles, RBO cuando no.
RULE Obtiene a la fuerza comportamiento de RBO
FIRS ROWS El tiempo de respuesta DEL optimizador para el primer resultado
ALL_ROWS El rendimiento específico global del optimizador
Practica:
En esta práctica, deberás analizar planes de ejecución usando RBO. Después
de cambiar su sesión para usar al CBO, generaras planes nuevos de ejecución
y examinaras los resultados.
Práctica 5 (optativo)
1. Use el ALTER SESSION para obligar su sesión a usar el modo del
Optimizador de REGLA.
Habilite SQL*PLUS AUTOTRACE para desplegar planes de ejecución y analizar
la declaración de SQL enseñado debajo.
SQL> select e.last_name
2 e.first_name
3 r.status
4 from employees e
5 registrations r
6 where e.emp_id = r.stud_id
7 and r.class_id = 55999;
Analice la declaración de SQL demostrada de debajo para ver cuál modo del
Optimizador es
usado.
SQL> select *
2 from cls_statuses
3 where cls_status = 'BOOK';
Use el ALTER SESSION para obligar a su sesión a usar el modo del
Optimizador CHOOSE. recuerde quitar SQL*PLUS Y AUTOTRACE antes de
usar el comando ALTER SESSION.
Habilite SQL*PLUS AUTOTRACE. Reejecute la consulta del paso 2 y examine
los resultados. ¿Los resultados son diferentes? Explique por que.
52
6 Índices y Métodos de Acceso Básico
Objetivos
Después de completar esta lección, deberás poder hacer lo siguiente:
• Identifica a Oracle8i ROWIDs
• Identifica sorteos de índice
• Muestra la relación entre índices y las restricciones
• Crea índices manualmente
• Identifica asuntos del índice con llaves foráneas
• Identifica métodos de acceso básicos
Oracle 8i ROWIDs
• ROWIDs indican la dirección de la fila
• ROWIDs extendidos y restringidos están disponibles
• Cada Tabla tienen una pseudocolumna ROWID,
SQL> selecat rowid, rs.*
2 from reg_statuses rs;
ROWID REG DESCRIPTION
-------------------------------- --------------- ---------------------
AAABDlAACAAAFOZAAA CANC Canceled
AAABDlAACAAAFOZAAB HOLD Hold
AAABDlAACAAAFOZAAC PEND Pending
AAABDlAACAAAFOZAAD REGI Registered
AAABDlAACAAAFOZAAE WAIT Waitlisted
Oracle8i ROWIDs
El Oracle usa ROWIDs almacenar direcciones de filas de la tabla, como adentro
índices. El formato extendido ROWID se introdujo con las capacidades nuevas
de partición de discos de Oracle 8.0. Un tipo restringido de datos ROWID está
todavía disponible para la compatibilidad retrasada. El Oracle todavía usa
ROWIDs restringidos internamente, cuándo el formato extendido no son
necesarios.
Cada tabla Oracle tiene un pseudocolumnas denominado ROWID. Los ROWIDs
no se guardan en la base de datos. Sin embargo, tu puede crear que las tablas
que contienen columnas teniendo los datos ROWID mecanografían, aunque
Oracle no garantiza que los valores de tales columnas sean ROWIDs válidos.
El ROWID extendido tiene un formato de cuatro pedazos, usando una técnica
que codifica base-64. En el ejemplo arriba, éstos son los campos y su
significado:
AAAABDL Numero del objeto, Identifica el segmento de la BD
AAC Numero relativo del archivo, único dentro del tablespace
AAAF0Z Numero del bloque, Dentro del datafile
AAA-AAE Numero de registros en el bloque
53
ROWID Manipulación
Tu puede usar el paquete de DBMS_ROWID extraer información de un ROWID
extendido o convertir a un ROWID de formato extendido a restringido el formato
(o viceversa).
Indices Oracle 8i
• Indice Unique y nonunique
• Indices compuestos
• Técnicas de almacenamiento índices:
− B*-tree Descending
− Bitmap Function bases
− Reverse key Domain index,
Indices Oracle8i.
Un índice es un objeto de la base de datos que es lógicamente y físicamente
independiente de los datos de la tabla. El Oracle8i Server puede usar un índice
ganar acceso a los datos requeridos por una declaración de SQL, o usar índices
implementar restricciones de integridad. Tu puede crear y puede dejar caer
índices en cualquier momento. El Oracle8i Server automáticamente mantiene
índices cuando los cambios relatados de datos.
Sorteos de índices
Los índices pueden ser únicos o no únicos. Los únicos garantizan que no existan
dos entradas que tengan el mismo valor. Un índice compuesto (también llamado
uno índice concatenado) es un índice que tu crea en columnas múltiples en una
tabla (hasta 32). Las columnas en un índice compuesto no pueden aparecer en
cualquier orden, y necesita sea adyacente en la tabla.
Las técnicas de Almacenamiento del índice
Para índices estándar, Oracle usa a B*tree que son simétricos para igualar
tiempos de acceso.
Los exponentes Bitmap se discuten en el "Indexes adelantado" lección.
Los índices cruciales inversos ponen al revés los bytes de los valores de la
columna. Tienen prestaciones cuando son usados para los valores de
monotonically-increase que puedan conducir a sesgado los índices en los cuales
los valores mayores son descartados sobre el tiempo.
Los índices basados en funciones están también cubiertos en los lección "Índices
adelantados".
Los índices de dominio son índices específicos en la aplicación. Son creados,
manejados, y ganados acceso as por las rutinas suministrados por un tipo del
índice.
54
Indices B*.Tree
Una Descripción de Índices B*tree

Cada Índice B*tree tiene un bloque de la raíz como un punto de partida. A
merced del número de entradas, haya uno o más estratos del bloque de la rama.
Un B*tree consta de un set de bloques de la hoja, conteniendo todos los valores
y ROWIDs apuntando hacia las filas en los datos asociados segmentan. Los
bloques de la hoja están conectados por punteros previos y siguientes del
bloque, a fin de que pueden ser atravesados de izquierda a derecha y viceversa.
Los índices son siempre simétricos y se derivan del fondo y arriba. En ciertas
situaciones, el algoritmo de balanceo puede causar a un B*tree un alto
incremento innecesariamente.
Tu deberás reorganizar sus índices regularmente para garantizar eficiencia de
almacenamiento óptima y desempeño.
Estructura de Índice B*_Tree

Cada entrada de índice comprende lo siguiente:
• Entrada
− Numero de columnas
− Información Bloqueada
• Columna llave pares longitud valor
• ROWD de la fila
El formato de entrada del índice
Una entrada del índice está compuesta de los siguientes componentes:
Un encabezado de entrada, que almacene número de columnas e información
cerrada
Los pares cruciales - de la columna el valor - largo, cuál definen el tamaño de la
columna en la llave que se siguió por el valor de la columna (el número de tales
pares es un máximo del número de columnas en el índice)
ROWID de una fila, que contenga los valores de la llave
Las características de Entrada del índice
Los valores cruciales son repetidos si hay filas múltiples que hacen el mismo
afinar valor.
55
No hay entradas del índice para filas que tienen todas las columnas cruciales
conteniendo valores NULOS.
Pues las tablas poco subdivididas, los ROWIDs restringidos se usan para
apuntar hacia las filas de la tabla, porque todas las filas forman parte del mismo
segmento.
Ejemplo Índice B*_Tree
Ejemplo del Índice B*tree

La estructura interna de una B*tree da acceso rápido para valores indexados. El
Oracle8i Server directamente puede ganar acceso a las filas después de que
haya rescatado la dirección (el ROWID) de los bloques del índice.
Si el Optimizador se decide a usar un índice, las búsquedas Oracle8i Server que
el índice para la columna aprecia ganó acceso a por la declaración y tomas los
siguientes pasos:
• Si la declaración gana acceso sólo columnas que están presentes en el
índice, entonces recupera los valores de la columna directamente del índice
sin ir al segmento de datos.
• Si la declaración también ganan acceso a otras columnas, rescata las
direcciones del índice, entonces gana acceso a los bloques de datos por
ROWID.
Sintaxis CREATE INDEX
56
Sintaxis Para La Creación De Un Indice.

La opción NOSORT puede ser usada sólo con índices estándar (B*tree), y sólo
si las filas en la tabla están adentro en la orden correcta. Se saltará la fase de
tipo, apresurando la marcha de la creación del índice. Si las filas no están en la
orden correcta, el siguiente error será devuelto:
ORA-01409: NOSORT option may not be used; rows are not ascending order
La opción NOLOGGING reduce lo desecho generado durante la creación del
índice.
La cláusula de atributos de reconocimiento contiene detalles acerca del
almacenamiento físico para el índice para ser creada..
Tu puede usar la expresión de la columna crear índices basados en funciones,
los cuáles están discutidos en la lección de "Índices adelantados". En el caso
más simple, la expresión de la columna es justamente un solo nombre de la
columna.
Con las opciones ASC y DESC, tu puede especificar si los valores del índice
deberán estar en un orden ascendente o descendente. Note que estas opciones
siempre han sido respaldadas (pero ignorado) para razones de compatibilidad,
pero comenzando con Oracle8i, tienen efecto.
Al crear un índice compuesto, use las siguientes (posiblemente estando en
conflicto) líneas directivas:
• Ponga la columna más frecuentemente puesta en duda (también llamada la
interlineación parte del índice), porque el Optimizador lo puede usar como un
índice en su propio derecho.
• Ponga la columna más restrictiva primera si tu planea especificar la llave
llena.
• Considere añadir columnas adicionales para el índice, a fin de que tu puede
recuperar resultados de consulta sin ganar acceso a la tabla . Esto requiere
capacidad de almacenamiento adicional pero ahorra I/O.
Al crear índices compuestos tu pudiese considerar usar la opción COMPRESS,
para eliminar ocurrencias de valores cruciales de la columna. Esto
sustancialmente puede reducir almacenamiento. Por ejemplo:
SQL> create index emp_idx on employees(job,last_name) compress 1; Esto
comprime las ocurrencias repetidas de JOB. NOCOMPRESS es por default.
Estadísticas de índices
En la lección de recolección de estadísticas, las estadísticas se discuten en
detalle. Tu puede coleccionar y puede recuperar algunas estadísticas útiles del
índice con las siguientes órdenes:
SQL> analyze index <index_name> validate structure;
SQL> select * from index_histogram;
57
SQL> select * from index_stats;La primera orden puebla las dos vistas que se
puso en duda por las últimas dos órdenes. La primera vista da información
acerca de la selectividad del índice (cardinality de valores cruciales), y la
segunda vista le puede contar la altura sobre la B * - el árbol, el número de
bloques, el número de valores cruciales distintos, y el número de hoja bloqueen
entradas.
Declaración ALTER INDEX
Tu puede usar la declaración ALTER INDEX para cambiar una definición del
índice, o reconstruir un índice existente..
El Efecto De Operaciones DML Sobre Índices

El servidor Oracle mantiene todos los índices cuando las operaciones de DML
son efectuadas sobre el tapete. Aquí está una explicación del efecto de una
orden de DML en un índice:
• Las operaciones del inserto resultan en la inserción de una entrada del índice
en el bloque apropiado. Si no hay cuarto para la entrada en el bloque,
entonces es dividido en dos bloques, y una entrada está añadida en el bloque
del padre para apuntar hacia el bloque nuevo.
• Suprimir una pelea resulta sólo en una supresión lógica de la entrada del
índice. El espacio usado por la fila suprimida no está disponible para las
entradas nuevas hasta todas las entradas en el bloque sea suprimido.
• Las actualizaciones para las columnas cruciales resultan adentro uno lógico
suprime y un inserto para el índice. El PCTFREE sedimentándose no tiene
efecto en el índice excepto en el tiempo de creación. Una entrada nueva
puede agregarse para un bloque del índice aun si tiene menos espacio que
eso especificó por PCTFREE.
Después de los períodos de actividad alta de DML, tu deberás reorganizar a los
índices B*tree. Esto puede estar hecho en línea en Oracle8i. Los índices creados
(o reconstruido) en los datos existentes son siempre más eficientes que índices
que son implícitamente mantenidos por el Oracle8i Server.
Indices y Restricciones
El servidor Oracle 8i Implícitamente crea o usa Indices
B*_tree cuando tu defines lo sig:
Restricciones de llave primaria
Restricciones Unicas
SQL> CREATE ATABLE REG_STATUSES
{REG_STATUS VARCHAR2(4)
CONSTGRAINT REG_STATUS_pk PRIMARY KEY
,DESCRIPTION VARCHAR2 {40}
};
Los índices y Restricciones
58
Cuando tu defines una restricción primaria o única y crucial en una tabla,

Oracle8i automáticamente genera un exponente, o unos usos un índice
existente, para respaldarlo. Los índices creados para este propósito son
físicamente, solamente no lógicamente, independientes de la estructura de la
tabla.
El Oracle8i Server le da al índice el mismo nombre como la restricción.
Tu no puede dejar caer un índice que implementa una restricción. En lugar de
eso, tu debe desactivar la restricción, las más veces causando a Oracle8i para
automáticamente dejar caer el índice.
Se consciente que Oracle8i respalda restricciones diferibles. Las únicas
restricciones diferibles son siempre índices poco únicos utilizadores obligados.
También, al desactivar tal restricción, el Oracle8i Server no deja caer el índice
asociado, así ofreciendo un cheque fácil cuando la restricción es habilitada otra
vez.
Los índices sirven al menos dos propósitos: Hacer más rápido las consultas e
implementar claves únicas y primarias. El Oracle8i Optimizador usa índices
existentes cuando las restricciones nuevas están definidas. Nota que Oracle8i
puede usar poco únicos índices para comprobar restricciones únicas.
Indices y llaves Foráneas

• Indices que no son creados automáticamente
• Hay implicaciones de bloqueo para actividad
DML sobre tablas padres-hijos.
Índices y llaves foráneas

Oracle8i automáticamente no crea un índice para una restricción de llave
foránea.
Si las las columnas de la llave foránea están a menudo usadas en condiciones
del join, entonces tu deberás crear un índice en ellos para realzar el proceso de
join.
Suprimiendo o actualizar datos en el padre-hijo de las tablas (con una restricción
foránea) las causas comportamiento diferente que cierra, a merced de la
presencia de un índice en la columna crucial foránea. Si su aplicación le
actualiza al padre posponga frecuentemente, entonces la argumentación puede
ocurrir.
Si tu no indexa una llave foránea, entonces la tabla del hijo está cerrada (con
una cerradura de nivel de la tabla) cuandoquiera que lo siguiente ocurre:
• Una fila es suprimida de la tabla del padre
59
• Las columnas apuntadas para por la llave foránea están actualizadas en la
tabla del padre
Por esta razón, tu deberás indexar columnas foráneas, aun si no son
normalmente usadas en las condiciones del join y cláusula WHERE.
Métodos de Acceso Básico

• Búsqueda en toda la tabla:
− Puede usar I/O Multibloque
− Puede ser paralelizado
• Búsqueda con índice:
− Acceso solo con índice:
− Seguido por acceso de ROWID
• Busquen en toda la tabla con índice:
− Puede usar I/O Multibloque
− Puede ser paralizado
Búsqueda en toda la tabla.
Una búsqueda en toda la tabla puede involucrar leer muchos bloques
secuenciales de datos de archivos de la base de datos en disco dentro del
buffer cache. Sin embargo, el Oracle8i Server puede leer varios bloques
secuenciales en una sola I/O. Esto es al que se refirió como I/O del multibloque.
Tu puede influenciar multibloque de I/O colocándole al parámetro
DB_FILE_MULTIBLOCK_READ_COUNT. Usar la consulta en paralelo ya que
puede ayudar a acelerar la búsqueda en toda la tabla ubicando varios procesos
para el trabajo.
Búsqueda por índice
Los índices mejoran el desempeño de muchas declaraciones de SQL. Sin
embargo, una consulta indexada puede leer de ambos índice y los bloques de
datos. Estos bloques no son usualmente secuenciales, así es que la consulta no
puede usar multibloque lee. Use índices sólo cuando mejoran desempeño.
Por regla general, el uso B*tree para las consultas que seleccionen al menos el
5 % de las filas de una tabla. Sin embargo, este punto de equilibrio disiente con
sus datos. Asegura experimentar esto para todos los procesos críticos usando
herramientas de diagnosis.
Busque rápida por índice en toda la tabla
La búsqueda en toda la tabla por índice es una alternativa para una búsqueda
completa cuando hay un índice que contiene todas las columnas que sea
necesario para una consulta. Es más rápido que un índice normal de búsqueda
en toda la tabla porque puede usar I/O del multibloque y puede ser paralelizado
al modo búsqueda en toda la tabla. A diferencia de índice de búsqueda en toda
la tabla, sin embargo, las filas necesariamente no regresarán adentro orden
clasificada. Si hay un predicado que limita la búsqueda del índice para un rango
de valores, entonces el Optimizador no considerará un índice rápido de
búsqueda en toda la tabla.
60
Resumen
Esta lección te introduce al concepto de índices. Un índice es un objeto de la
base de datos que es lógicamente y físicamente independiente de los datos de la
mesa. El Oracle8i Server puede usar un índice ganar acceso a los datos
requeridos por una declaración de SQL, o usar índices implementar restricciones
de integridad.
Hay diferentes sorteos de índices. Para índices estándar, Oracle usa a B*tree
que son simétricos para igualar tiempos de acceso. Tu puedes crear un índice
manualmente usando la sintaxis CREATE INDEX, o automáticamente creando
restricciones únicas o primarias y cruciales en mesas.
Los índices pueden afectar desempeño. Hay métodos diferentes para buscar en
toda la tabla, índice para búsqueda en toda la tabla, y el índice rápido para
búsqueda en toda la tabla. El índice de búsqueda en toda la tabla puede mejorar
el desempeño de muchas declaraciones de SQL.
61
7 Coleccionando Estadísticas
Objetivos
• Usa el comando ANALYZE para proveer el Optimizador basado en costos
Oracle8i de estadísticas.
• Identifica tabla, índice, columna, y estadísticas de grupo. Mira estas
estadísticas en las vistas de diccionario de datos Oracle8i.
• Usa el paquete de DBMS_STATS coleccionar y manejar estadísticas del
Optimizador.
• Identifica cálculos de selectividad de predicado, asumiendo aun
distribución de datos. Identifica las consecuencias de variables
utilizadoras de vinculación para la selectividad de predicado.
• Crea histogramas para columnas con datos sesgados.
• Escoge valores apropiados para:
- Un tamaño de muestra (al usar la opción de ESTÍMATE de lo ANALICE
orden)
- El número de cubos del histograma
El Comando Analyze
El comando ANALYZE
Tu puedes coleccionar estadísticas en un objeto con lo ANALYZEN . Aunque el
Optimizador no es sensitivo para los cambios menores en el volumen o la
selectividad, tu puedes querer coleccionar estadísticas nuevas periódicamente
adelante frecuentemente modificó tablas para asegurar que el Optimizador usa
información reciente, exacta.
Usando el ANALYZE para coleccionar estadísticas nuevas sobreescribe
cualquier estadísticas existentes en el diccionario de datos y purga cualquier
planes relatados de ejecución de la piscina compartida.
El paquete de DBMS_DDL contiene un procedimiento llamado
ANALYZE_OBJETO que permite un índice, tabla, o grupo ser analizado. El
paquete de DBMS_DDL contiene un procedimiento llamado
62
ANALYZE_SCHEMA que recoge estadísticas en todo objeto en el esquema

dado.
La opción COMPUTE STATISTICS
Tu puedes calcular estadísticas exactas con esta opción. El rendimiento de una
búsqueda en toda la tabla y varios cálculos. Para tablas grandes, esta operación
podrían tomar una cantidad considerable de tiempo.
La opción ESTIMATE STATISTICS.
Sin embargo, si tu usa esta opción con un adecuado ejemplo de los datos,
entonces es casi tan fidedigna como la opción de compute statistics.
La opción DELETE STATISTICS.
Tu puedes borra estadísticas con esta opción. Tu no necesita usar esta opción
antes de reanalizar un objeto, porque las estadísticas existentes son
sobrescritas.
El comando ANALYZE
El comando ANALYZE: Ejemplificando

Si más de la mitad de datos están especificados como un tamaño de muestra,
entonces el Oracle8i Server lee todos los datos y computa las estadísticas en
vez de estimarlas. Si la tabla tiene menos que 1,064 filas y un tamaño de
muestra no es especificado, entonces el Oracle8i Server computará las
estadísticas a pesar de ya sea ESTÍMATE STATISTICS o COMPUTE
STATISTICS estén seleccionadas.
Nota: Por defalut el comportamiento del ANALYZE es la combinación de FOR TABLE y
FOR ALL INDEXES.
Cláusula FOR
La cláusula FOR es significada para histogramas y se discutirá en más detalle
más tarde en esta lección.
63
Marca de Agua Alta
Cada tabla mantiene una señal del nivel del agua alta en el bloque de inicio del
segmento. La señal del nivel del agua alta indica el último escollo que sirvió
alguna vez para la tabla. Cuando el servidor Oracle realiza una repaso en toda la
tabla, lee cuidadosamente todos los bloques a la señal del nivel del agua alta.
Noto que la señal del nivel del agua alta no es vuelta a arrancar cuando las filas
son suprimidas de la tabla; La señal del nivel del agua alta termina al usar la
orden TRÚNCATE.
Tu también puede usar el procedimiento de DBMS_SPACE.UNUSED_SPACE
para encontrar la señal del nivel del agua alta y el número de bloques por encima
de la señal del nivel del agua alta, si analizar una tabla es imposible o
indeseable.
Vistas del diccionario de datos ALL_TABLE y DBA_TABLE.
Las estadísticas de la tabla son almacenadas en el diccionario de datos. Pueden
ser exhibidas consultando las tablas ALL_TABLE y DBA_TABLE.
Name Null? Type
---------------- - -------- ---------------
TABLE_NAME NOT NULL VARCHAR2(30)
TABLESPACE_NAME VARCHAR2(30)
NUM_ROWS NUMBER
BLOCKS NUMBER
EMPTY_BLOCKS NUMBER
AVG_SPACE NUMBER
CHAIN_CNT NUMBER
AVG_ROW_LEN NUMBER
SAMPLE_SIZE NUMBER
LAST_ANALYZED DATE
...Ejemplo:
SQL> analyze table employees
2 estimate statistics for table; SQL> select num_rows,blocks,empty_blocks
2 ,avg_space,avg_row_len
3 ,sample_size
4 from user_tables
5 where table_name = 'EMPLOYEES';
NUM_ROWS BLOCKS EMPTY_BLOCKS AVG_SPACE AVG_ROW_LEN SAMPLE_SIZE
5132 434 5 225 48 1064
Estadísticas de Índice
• Nivel de índice (siempre exacto)
• Numero de bloque hojas
• Numero de llaves distintas
• Porcentaje de numero bloques hojas por llave
• Porcentaje de numero bloques de datos por llave
• Numero de entradas de índice
• Factor clustering
• Ultima fecha de ANALYZE y tamaño del ejemplo
Estadísticas de Índice.
64
Note que el nivel de estadísticas B*tree es siempre exacta, independientemente

si tu computas o estimas estadísticas del índice. El número de llaves distintas
puede incluir filas que han sido suprimidas.
El factor del Agrupamiento del índice
El factor del agrupamiento del índice es una estadística importante del índice
para que el CBO estime exponente repasan con la vista cuesta. Es una
indicación del número de (lógicos) datos que las visitas del bloque necesitaron
recuperar todas las filas de la tabla por el índice. Si las entradas del índice
siguen la fila de la tabla ordene, entonces estas teorías del valor el número de
bloques de datos (cada bloque será visitado sólo una vez). Inversamente, si el
índice que las entradas al azar apuntan en los datos diferentes se bloquea,
entonces el factor del agrupamiento de estrellas podría acometer el número de
filas.
Suponga que una tabla típica contiene 50 filas por bloque de datos y 5,000 filas
en total. Cuando una consulta busque 50 filas (la selectividad es 1 %), el
agrupamiento que el factor indica ya sea que tu debe visitar un bloque mejor
caso: 1 % de los bloques de datos) o 50 bloques (el peor caso: 50 % bloques de
datos).
Estadísticas de Indices
• Coleccionando estadísticas mientras se crea o
reconstruye índices.
• Vistas del diccionario de datos:
USER_INDEX, ALL_INDEXES
SQL>selecat uniqueness, hlevel
2, , leaf_hlocks,distinct_keys
3, , clustering_factor
4 from userindexes
5. where index_name=REG_PK;
Tu puedes coleccionar estadísticas del índice con el comando ANALYZE , pero
también puede coleccionar estadísticas del índice al crear o reconstruyéndolas,
usando la siguiente sintaxis:
SQL> create index compute statistics
SQL> alter index rebuild compute statistics
Vistas del diccionario de datos USER_INDEXES y ALL_INDEXES
Las estadísticas del índice son almacenadas en el diccionario de datos. Las
cuales pueden ser desplegadas:
Name Null? Type
----------------------- -------- ------------
INDEX_NAME NOT NULL VARCHAR2(30)
INDEX_TYPE VARCHAR2(12)
UNIQUENESS VARCHAR2(9)
BLEVEL NUMBER
LEAF_BLOCKS NUMBER
DISTINCT_KEYS NUMBER
AVG_LEAF_BLOCKS_PER_KEY NUMBER
65
AVG_DATA_BLOCKS_PER_KEY NUMBER
CLUSTERING_FACTOR NUMBER
NUM_ROWS NUMBER
SAMPLE_SIZE NUMBER
LAST_ANALYZED DATE
...
Ejemplo:
SQL> analyze index reg_pk compute statistics;
SQL> select uniqueness, blevel
2 , leaf_blocks, distinct_keys
3 , clustering_factor
4 from user_indexes
5 where index_name = 'REG_PK';
UNIQUENESS BLEVEL LEAF_BLOCKS DISTINCT_KEYS CLUSTERING_FACTOR
UNIQUE 2 682 56252 21349
Estadísticas de Columna
• Numero de valores distintos
• Valor mas bajo
• Valor mas alto
• Ultima fecha de ANALYZE y tamaño del
ejemplo
• Vistas del diccionario de datos:
USER_TAB_COL:STATISTICS,
ALL_TAB_COL_STATISTICS
Estadísticas de la columna:
Éstas son las estadísticas de la columna coleccionadas por el comando
ANALYZE:
El número de valores distintos
El valor mínimo
El valor más alto
El último ANALYZE y tamaño
Ambos el valor bajo y el más alto son almacenados en formato CRUDO (binario);
Las vistas del diccionario de datos USER/ALL_TAB_COL_STATISTICS
Name Null? Type
TABLE_NAME NOT NULL VARCHAR2(30)
COLUMN_NAME NOT NULL VARCHAR2(30)
NUM_DISTINCT NUMBER
LOW_VALUE RAW(32)
HIGH_VALUE RAW(32)
DENSITY NUMBER
NUM_NULLS NUMBER
NUM_BUCKETS NUMBER
66
LAST_ANALYZED DATE
SAMPLE_SIZE NUMBER
GLOBAL_STATS VARCHAR2(3)
USER_STATS VARCHAR2(3)
AVG_COL_LEN NUMBER
Nota: Para la compatibilidad retrasada con Oracle7, las vistas de diccionario de datos
del USER/ALL TAB_COLUMN también muestran valores de estadística de la columna.
También, la columna NUM_BUCKET sale a la vista que las estadísticas regulares de la
columna son tratadas como un histograma con un cubo. Los histogramas están discutidos
más tarde en esta lección.
El ejemplo
SQL> select column_name, num_distinct
2 , low_value, high_value
3 , num_nulls, num_buckets
4 from user_tab_col_statistics
5 where table_name = 'EMPLOYEES';
NUM NUM NUM
COLUMN_NAME DISTINCT LOW_VALUE HIGH_VALUE NULLS BUCKETS
EMP_ID 15132 C2191A C403013E05 0 1
MGR_ID 1167 C21361 C403013D07 0 1
LAST_NAME 4383 4162626F7474 5A696D6D6572 0 1
FIRST_NAME 445 416B73686169 5A6875736869 107 1
HIREDATE 535 77980217010101 77C6050B010101 0 1
JOB 24 4141 54454348 36 1
SALARY 496 C208 C30A62 0 1
Estadísticas de Cluster
• Porcentaje de longitud de llave cluster
encadenada
• Vistas del diccionario de datos :
USER_CLUSTERS,ALL_CLUSTERS
Estadísticas de cluster.
La única estadística que es específica para clusters es el largo común de la
cadena de la llave de grupo. Por supuesto, cualquier tabla que es parte de un
grupo tiene sus propias estadísticas regulares del table/index/column.
Para acceder a una file en una tabla cluster, el Oracle8i Server lee todos los
bloques conteniendo filas con ese valor. Si estas filas ocupan, entonces el
múltiplo se bloquea, ganar acceso a una sola fila podría requerir más lean que
ganando acceso a la misma fila en una tabla no apelotonada.
Las vistas del diccionario de datos USER_CLUSTERS Y ALL_CLUSTERS :
Éstas son las definiciones pertinentes de la columna de diccionario de datos para
estadísticas de grupo:
67
Name Null? Type
CLUSTER_NAME NOT NULL VARCHAR2(30)
AVG_BLOCKS_PER_KEY NUMBER
...
El paquete DBMS_STATS
El paquete DBMS_STATS
El paquete DBMS_STATS.
Tu puedes usar el paquete DBMS_STATS para generar y manejar estadísticas
para la optimización basada en costos. Las estadísticas pueden radicar en el
diccionario de datos o en una tabla creada en el esquema del usuario. Sólo las
estadísticas son almacenadas en el impacto del Optimizador basado en costos.
Los procedimientos en el paquete pueden estar divididos en tres funciones
principales:
• Asignar o obtener estadísticas individuales
• Transferir estadísticas entre el diccionario de datos y las tablas del usuario
• Recoger ciertas clases de estadísticas del Optimizador
DBMS_STATS:Generando Estadísticas
Dbms_stats, GATHER_TABLE_STATS
{SST --schema
ĆLASSES --table
ŃULL --partition
´20 --sample size(%)
´FALSE --block sample?
´FOR ALL COLUMNS --column spec
´4 --degree off //
´DEFAULT --granularity
´TRUE --cascade to indexes
);
68
Procedimientos DBMS_STATS
Use los siguientes procedimientos recoger estadísticas en índices, tablas,
columnas, y particiones:
Procedimiento Descripción
GATHER_ INDEX_STATS Colecciona estadísticas de índices
GATHER_TABLE_STATS Colecciona estadísticas de tablas, columnas e
índices
GATHER_SCHEMA_STATS Colecciona estadísticas de todos los objetos
en el esquema
GATHER_DATABASE_STATS Colecciona estadísticas de todos los objetos
de la BD
DBMS_STATS no recoge estadísticas de grupo, pero tu lo puede usar para
recoger estadísticas en las tablas individuales en el grupo. Otras opciones para
recoger estadísticas con DBMS_STATS incluyen lo siguiente:
• Colecciona estadísticas ya sea en serie o en el paralelo. . Las estadísticas del
índice están sólo reunidas en serie.
• El cómputo o las estimaciones de estadísticas; Usa ejemplo de bloques o de
registros para estimar estadísticas.
• Especifique las columnas para las cuales las estadísticas son necesarias con
GATHER_TABLE_STATS.
• Use la opción de CASCADE para coleccionar estadísticas del índice cuando
generen estadísticas de tablas.
• Sostenga estadísticas en tablas de estadísticas para experimentar con
diferentes sets de estadísticas.
Copiando Estadísticas entre Bases de Datos
Copiando Estadísticas Entre Bases de datos

Tu puede usar el paquete de DBMS_STATS para copiar estadísticas de una
producción para una base de datos experimental para facilitar la afinación. . Por
ejemplo, para copiar estadísticas de un esquema:
• Use el procedimiento DBMS_STATS.CREATE_STAT_TABLE en la base de
datos de producción crear una tabla definida por usuario de estadísticas.
69
• Use el procedimiento DBMS_CREATE.EXPORT_SCHEMA_STATS en la
base de datos de producción para copiar estadísticas del diccionario de datos
para la tabla definida por usuario de estadísticas
• Use la exportación e importe utilerías para transferir las estadísticas que
corresponden a las estadísticas del usuario en la base de datos experimental.
• Use procedimiento DBMS_STATS.IMPORT_SCHEMA_STAT para importar
las estadísticas dentro del diccionario de datos de la base de datos
experimental.
Tu también puede usar DBMS_STATS para respaldar estadísticas antes de
objetos que ANALYZE. . Use un respaldo para:
• Restaure viejas estadísticas
Estudie cambios en las características de datos con el paso del tiempo
Ejemplo Copiando Estadísticas

dbms_stats.CRATE_STAT_TABLE
(SST --schema
STATS --statistics table name
USERS --tablespace
);
dbms_stats.EXPORT_TABLE_STATS
(SST --schema
ĆOURSES --statistics table name
ŃULL --no partitions
´STATS --statistics table name
ĆRS demo --id for statistics
´TRUE --index statistics
);
Ejemplo
Para copiar estadísticas para que una tabla del diccionario de datos para una
tabla definida por usuario de estadísticas, use el procedimiento
CREATE_STAT_TABLE para crear la tabla definida por usuario y EXPORT_
TABLE _ STATS para copiar las estadísticas. DBMS_STATS incluye los
siguientes procedimientos para copiar estadísticas
CREATE_STAT_TABLE Crea una tabla definida por usuario para guardar
DROP_STAT_TABLE estadísticas
EXPORT_object_STATS Borra la tabla definida por el usuario para la tabla
IMPORT_object_STATS Exporta estadísticas del diccionario de datos a la
tabla definida
Importa estadísticas de la tabla al diccionario de la
datos
70
Donde el objeto puede ser COLUMNA, INDECE, TABLA, o ESQUEMA.
Ejemplo: Reuniendo Estadísticas

Begin
Dbms_stats.CREATE_STAT_TABLE
(SST, STATS);
Dbms_stats.CREATE_TABLE_STATS
(SST, COURSES
´stattab=> STATS);
end;
Begin
dbms_stats.CREATE_STAT_TABLE
(SST, STATS);
Dbms_stats.GATHER_TABLE_STATS
(SST, COURSES
´stattab=> STATS);
end;
Reuniendo Estadísticas del Optimizador
El procedimiento de la GHATER_TABLE_STATS recoge estadísticas de la tabla
y de la columna (y el índice). . Hay varios parámetros para el procedimiento; ; La
mayoría es optativa y tiene un valor de incumplimiento.
El ejemplo
Ha abundado la modificación en contra de la tabla de COURSES desde el último
tiempo que las estadísticas fueron recogidas. . Para asegurar que el Optimizador
basado en costos todavía selecciona el mejor plan, las estadísticas son
recogidas otra vez usando GHATER_TABLE_STATS. Sin embargo, tu está
preocupado que las estadísticas nuevas causarán el Optimizador escoja malos
planes cuando las actuales son aceptables.
Si tu cree que las estadísticas nuevas causan que Optimizador para generar
planes pobres, entonces tu puede restaurar las estadísticas originales usando
DELETE_TABLE_STATS y SET TABLE_STATS.
Selectividad de predicado
• Unico o llave primaria = constante
Unifica-fila predicado
• Indice no único = constante
Selectivity inct_keys
• Limitado o ilimitado rango recorrido
Selectivity = (high-low+1) / (max-min+1)
Alto: Limite alto (o max)
Bajo: Limite bajo (o min)
Max,min: estadísticas de columna
71
Predicando la Selectividad
El esperado porcentaje de filas (la selectividad) depende del tipo de operación
realizada en la cláusula WHERE. . El acercamiento basado en costos es más
probable para escoger un camino de acceso del índice para una consulta con
buena selectividad. . El Oracle8i Optimizador usa las siguientes reglas cuando
calcula selectividad.
La igualdad en condiciones
La llave única o primaria = constante
Éste es un predicado de la sola fila, devolviendo un máximo de la fila; ; Tiene
selectividad máxima.
El índice Nounica = constante
La consulta puede devolver más que una fila, así es que el Optimizador usa el
número de valores cruciales distintos en la columna. . La selectividad es 1
dividida por el número de valores distintos.
Rangos definidos e ilimitados
Los rangos definidos e ilimitados necesitan estadísticas para calcular
selectividad, así CBO y RBO producen resultados diferentes. . El RBO debe
confiar en la sintaxis y su esquema de mayor categoría; ; El CBO usa la
siguiente fórmula:
Variables Bind Y Selectividad De Predicado

Condición de igualdad:
No diferente
Limitado o ilimitado rango de recorrido:
Construye por default la selectividad asumida
Si es asumido un alto rendimiento, considera usar
SQL dinámico en lugar de variables bind:
Paquete DBMS_SQL
EXECUTE IMMEDIATE
SQL dinámico denota menor shared SQL
Variables Bind y Predicando Selectividad.

En caso de las condiciones de igualdad (esto es, si el operador es una igualdad
signo), una variable de vinculación es tratada como uno constante.
Porque la fase de vinculación sigue lo analice gramaticalmente fase, el Oracle8i
Optimizador no sabe los valores reales de variable de vinculación cuando la
optimización una declaración de SQL. . Esto quiere decir que el Optimizador
debe usar una selectividad predeterminada incorporada en caso una declaración
de SQL contiene variables de vinculación. . Estos valores incorporados no están
documentados, no pueden ser influenciados, y pueden cambiar con cada
liberación nueva del servidor Oracle.
72
El desempeño
Si el desempeño es un asunto, entonces considere usar SQL dinámico basado
en declaraciones con valores literales en lugar de las variables de vinculación. .
Esto quiere decir que cada declaración será optimizada separadamente (dando
desempeño óptimo). . Sin embargo, hay una desventaja grande: : Porque las
declaraciones de SQL más dinámicas son diferentes al uno al otro, tu tendrá
menos beneficio de SQL compartido.
Tu puede enviar a SQL dinámico (esto es, las declaraciones de SQL que se
forjan durante la corrida) al Oracle8i Server usando el paquete de DBMS_SQL, o
usando la declaración EXECUTE INMEDIATE.
Histograma
Los Histogramas
El Optimizador debe estimar el número de filas tratadas por una consulta dada. .
Esto es logrado en parte, estimando las selectividad de predicados de la
consulta. . La exactitud de estas estimaciones depende del conocimiento de
Optimizador de la distribución de datos. . Sin histogramas, una distribución
pareja está asumida.
Los sorteos de Histogramas
La partición balanceada en anchura de histogramas el dominio de atributo en los
rangos iguales de anchura, llamados cubos, y la cuenta el número de filas, el
valor de cada columna hace que caiga dentro de cada cubo. Si varias filas
contienen el mismo valor, todos ellos son puestas en el mismo cubo,
aumentando la altura de ese cubo.
En histogramas de alturas equilibradas, cada cubo tiene (casi) el número del
mismo de filas. . Si varias filas contienen el mismo valor, pueden ser metidas en
el mismo cubo o la colcha a través de varios cubos, como el histograma
balancee las alturas de los cubos. . Algunos cubos informan acerca de único o
algunos valores, porque hay muchas filas con esos valores. Algunos cubos
informan acerca de muchos valores, porque hay pocas filas con esos valores.
73
Los histogramas de alturas equilibradas son más adecuados para estimaciones
de selectividad de cómputo y son usados por el Oracle8i Server.
Histogramas Y Selectividad
Valores populares y no populares (NP)
DENSITY estadística de columna
Rango de rastreo de selectividad determinada por

el numero de buquets spanned
Selectividad de búsqueda por igualdad es
determinada por
El numero de buckets (valores populares valúes)
DENSITY(Valores no populares valúes)
Valores populares y no populares
Cuando tu creas histogramas, el Oracle8i Server distingue entre valores
populares y poco populares. . Los valores populares aparecen más de una vez
como un valor del punto final del cubo; Los valores que aparecen sólo una vez o
de ningún modo son considerados poco populares.
Estadísticas de densidad.
Cuando tu crea un histograma, la estadística de DENSIDAD se calcula. . Es
usada por el CBO a reducir el prejuicio causado por la repetición de valores
populares. . Cuándo una columna no tiene los histogramas, esta estadística
contienen un valor NULO.
Selectividad estimada por CBO.
Cuando el CBO estime selectividad para un rango de búsqueda, el número de
cubos de los que se extendió a lo largo es dividido por el número total de cubos.
. El CBO no considera cubos parciales, asumiendo que el número cubos ofrezca
demasiada gradulación. Para la igualdad buscan condiciones, el Oracle8i
Optimizador tiene dos avances:
• Para un valor popular, el número de cubos teniendo ese valor del punto final
es dividido por el número total de cubos.
• Para un valor poco popular, la estadística de DENSIDAD es utilizada como
una selectividad estimada.
Estadísticas de Histogramas:Example
• Generando estadísticas para la tabla CLASSES
Y la columna CLASS_ID; máximo 100 buckets.
SQL> analyse table classes compute statistics
2 for table for columns class_id size 100;
• Recalculando estadísticas sobar la misma columna
sin especificar el numero de buckets.
SQL> analyse table classes compute statistics
2 for columns class_id;
74
Ejemplo de colección de estadísticas de histogramas

Las estadísticas de la columna contienen los puntos finales del cubo para el
histograma, el número de valores distintos y valores nulos, y la densidad de esos
valores.
La colección de Estadísticas
Use el comando ANALYZE para coleccionar información para histogramas
usando la cláusula FOR . La opción de SIZE especifica el número de cubos.
ANALYZE TABLE TABLE {COMPUTE|ESTIMATE} STATISTICS
FOR {TABLE | ALL INDEXES
|ALL [INDEXED] COLUMNS [SIZE n] |FOR COLUMNS [SIZE n
],column [SIZE n] [,column [SIZE n]]}
Nota: El número máximo de cubos del histograma es 255. Note, sin embargo, que
Oracle nunca creará más cubos que el número valores distintos, porque eso es inútil. . Si
tu tiene mismo cubo para cada valor distinto, entonces tu puede almacenar la
cardinalidad exacta de cada valor de la columna.
Tips Para Histogramas

• Usa la opción FOR ALL INDEXED COLUMNS.
• Actualizar frecuentemente histogramas si la
distribución del dato no es estático.
• Cláusula WHERE con variables tipos bind no
usar hist0gramas.
• No usar histogramas a menos que ellos
substancialmente mejoren el rendimiento.
• Los histogramas usan almacenamiento adicional
Tips para Histogramas
Para muchas tablas, es apropiado para simplemente usar la cláusula FOR ALL
INDEXED COLUMNS para coleccionar estadísticas en todas las columnas
indexadas. Se consciente, sin embargo, que los histogramas son también
creados en llave única y primaria de contraints de columnas que son obligadas a
través de índices, que podrían ser un derroche de espacio.
Si la distribución de datos no es estática, entonces el histograma debe estar
frecuentemente actualizado.
Porque el Optimizador no toma en consideración el valor corriente de variables
de vinculación, los histogramas no son de ayuda (y por consiguiente que no vale
el gasto) cuando las variables de vinculación son usadas.
Los histogramas ubican almacenamiento adicional y deberán ser usados sólo
cuando sustancialmente pueden mejorar los planes de consulta.
75
Cuando Usar Histogramas
• Use histogramas para una columna cuando los datos
estén altamente segados
• Evite usar histogramas cuando:
− La columna no es usada en una cláusula WHERE
− La columna es única y usado solo con predicados
de igualdad
− Todos los predicados sobre la columna usa variable
tipo brind
− El dato de la columna es distribuido en forma
uniforme
Cuando usar Histogramas
Los histogramas cuestan caro para almacenar; Por consiguiente, úselos sólo
cuando sustancialmente mejoren desempeño. . Los histogramas deberán ser
usados cuando los datos tenga un grado de alto de desalineamiento, con
algunos valores aconteciendo mucho más a menudo que otros.
• Los histogramas no deberán ser usados cuando:
• La columna no es usada en la cláusula WHERE de consultas
• La columna es única y es usada sólo con consultas de igualdad
• Todos los predicados en el uso de la columna convalidan variables
• Los datos de la columna son uniformemente distribuidos
Eligiendo un tamaño de muestra
• Si el dato es distribuido en uniforme de, 5% de las filas
puede ser suficiente.
• Elige un ejemplo en el que el numero de valores distintos
es mas que 10% de le numero de filas.
• Cuando use histogramas el numero de filas ejemplificadas
debe ser mínimo 100 veces del numero de buckets.
Escogiendo a un Tamaño de Muestra

Si los datos a ser analizados es casi uniformemente distribuido, entonces una
muestra de casi 5 % de las filas deberás ser adecuada. . No use histogramas en
este caso, porque el beneficio será mínimo.
Si el número de valores distintos es grande como más que 10 % del número de
filas entonces un porcentaje más alto de muestreo puede ser necesario.
Si tu resuelve crear histogramas, entonces el número de filas probadas deberás
estar al menos 100 veces el número de cubos en el histograma. . En otras
palabras, el número común de filas probadas por cubo deberás ser por lo menos
100. Tu no deberás combinar un histograma muy detallado con un tamaño de
muestra mínimo
76
Eligiendo un numero de cubos

• Comience con un default de 75 cubos.
• Experimente con diferentes tamaños para obtener
óptimos resultados.
• Asigne el número cubos para ser mas grande que
el numero de valores distintos que
frecuentemente ocurren, si hay poca relatividad.
Escogiendo Numero de Cubos para un Histograma

El número predeterminado de cubos es 75. Este valor provee un nivel apropiado
de detalle para la mayoría de distribuciones de datos. Sin embargo, porque el
número de cubos en el histograma, el tamaño de muestra, y la distribución de
datos todo asumen la utilidad de un histograma, tu puede necesitar experimentar
con números diferentes de cubos para obtener los mejores resultados.
Si el número de frecuencia ocurren valores distintos en una columna es
relativamente pequeño, entonces tu deberás ajustar el número de cubos para ser
mayor que el número de frecuencia ocurrida de valores distintos.
Nota que el servidor Oracle nunca creará más cubos que el número valores distintos de
una columna, y el máximo son 255 cubos.
Tu puede usar SQL*plus AUTOTRACE o EXPLAIN_PLAN para ver la influencia
del número de cubos en el costo, estimado por el optimizador basado en costos.
En un cierto momento, subir el número de cubos ya no cambiará
significativamente los costos de los cálculos.
Viendo Estadísticas de Histogramas

• Información de histogramas:
USER/ALL_HISTOGRAMS
SQL>select *
2 From user_histograms
3 Where table_name = CLASSES
4 And column_name = CLASS_ID;
• El numero de buckets en cada histograma:
USER/ALL_TAB_COL_STATISTICS
Viendo Estadísticas del Histograma
La consulta de ejemplo en la diapositiva probablemente muestra el siguiente:
ENDPOINT_NUMBER ENDPOINT_VALUE
0 50008
1 55198
2 56718
3 63037
----- -----------
74 146296
75 155801
77
Tu tiene 75 cubos, incluyendo un cubo especial de cero a almacenar el valor
mínimo (50008) de CLASE_ID. El último cubo tiene 155801 como el valor del
punto final, lo cual es el valor máximo de CLASE_ID. Este histograma no tiene
valores populares, porque la CLASE_ID es la llave primaria de la tabla de
CLASSES.
Nota: Si un histograma tiene valores populares, entonces aparecen como "las aberturas"
en el punto final de numero de columna. Los cubos múltiples con el mismo valor del
punto final se guardan en el diccionario de datos como una sola fila, para preservar
espacio.
Resumen
Esta lección le presentó como usar la tabla de estadísticas con el Optimizador
basado en costos. Para Usar el comando ANALYZE o el paquete
DBMS_STATS, tu puede coleccionar estadísticas en sus tablas que son usadas
por el Optimizador basado en costos en el que determinar rutas óptimas de
ejecución para las declaraciones de SQL de las tablas analizadas.
La selectividad, el esperado porcentaje de filas devueltas, depende del tipo de
operación realizada en la cláusula WHERE. . El acercamiento basado en costos
es más probable para escoger un camino de acceso del índice para una consulta
con buena selectividad. . La selectividad es influenciada por distribución de
datos. . Cuando las variables de vinculación sean usadas en una declaración de
SQL, el Optimizador debe usar una selectividad predeterminada incorporada.
Estos valores incorporados no pueden ser influenciados.
El Oracle puede usar un histograma decidirse de todos modos usar el índice. .
Un histograma almacena información acerca de la frecuencia de valores diversos
de la columna. . Sin histogramas, una distribución pareja está asumida. Cree
histogramas para columnas con datos sesgados.
Práctica
En esta práctica, tu debes generar estadísticas de la tabla REGISTRATIONS .
Porque la columna de STATUS de la tabla de REGISTRATIONS es buen
candidato para un histograma, tu crea un histograma para esa columna. Calcula
la selectividad de un cierto predicado en la columna, antes y después de crear el
histograma. Entonces tu consulta el diccionario de datos para el último
ANALYZE, la fecha y tamaño. Finalmente, suprime las estadísticas en la tabla de
REGISTRATIONS del diccionario de datos.
Práctica 7
1.Apaga el SQL*Plus Autotrace.
Compute estadísticas para la tabla de REGISTRATIONS y ve las estadísticas
de la tabla y de la s columnas con apropiadas declaraciones de select.
2.¿Por qué es buen candidato la columna de STATUS de la tabla de
INSCRIPCIONES para crear un histograma?
Recupere los (distintos) valores de STATUS y su cardinalidad.
78
3. Crea un histograma para la columna de STATUS con 20 cubos y ve las

estadísticas del histograma.
4. Calcula la selectividad de la siguiente declaración ,antes y después de crear el
histograma:
SQL> select * from re

Bn gistrations
2 where status = 'CANC';5. Identifica la fecha y el tamaño del último
ANALYZE para todas las tablas en tu esquema.
7. Suprime las estadísticas para la tabla de REGISTRATIONS y comprueba el
diccionario de datos otra vez.
79
8 Influenciando al Optimizador
Objetivos
Después de completar esta lección, tu deberás poder:
• Influenciar el comportamiento del Optimizador Oracle8i en los siguientes
niveles:
- El nivel de ejemplo, ajustando parámetros de inicialización
- El nivel de sesión, usando lo ALTER orden de SESIÓN
- El nivel de declaración, usando hints
• Especifique las rutas de acceso para los hints
• Especifique hints adelante y adentro vistas
Poniendo El Modo Optimizador

a nivel instancia, ponga el siguiente parámetro:
OPTIMIZER_MODE =
{CHOOSE| RULE|FIRST_ROWS|ALL_ROWS}
Para una sesión, use el siguiente comando:
SQL>alter session set optimizer_mode =
{choose| rule|first_rows|all_rows}
Colocando el modo Optimizador
Oracle8i tiene cuatro modos básicos del Optimizador:
CHOOSE Cuando las estadísticas de COB están
disponibles(ALL_ROWS), y ROB no
RULE Forza la optimización de ROB aunque exista COB
FIRST_ROWS Optimiza la respuesta hasta que el primer resultado es devuelto
ALL_ROWS Optimiza el rendimiento especifico
Los niveles de Acercamiento del Optimizador
En el nivel de ejemplo, tu puede ajustar el acercamiento del Optimizador usando
el parámetro de inicialización de OPTIMIZADOR_MODO. Cuando este
parámetro no es determinado, el default es CHOOSE.
En el nivel de sesión, el acercamiento del Optimizador colocado en el ejemplo
puede ser del que se decidió en contra usando el comando ALTER SESSIÓN.
Nota: Cuándo las estadísticas no estan disponibles y la optimización basada en costos es

forzada, el optimizador usa valores incorporados predeterminados en lugar de eso. Esto
puede producir planes subóptimos de ejecución.
80
Parámetros Adicionales
• OPTIMIZER_FEATURES_ENABLE
− Defaults para 8.0.0
− Poner para la versión actual las ultimas
características de optimizador.
• OPTIMIZER_INDEX_COST_ADJ
Algunos Parámetros Adicionales
Tu puede usar OPTIMIZADOR_FEATURES_ENABLE para cambiar un set de
parámetros de inicialización que controlan el comportamiento de optimizador. El
valor predeterminado es 8.0.0; Otros valores son, por ejemplo, 8.0.3, 8.0.4, 8.1.3,
y 8.1.5. Tu puede usar este parámetro para prevenir el comportamiento
inesperado del optimizador al emigrar para una versión más alta.
Tu puede usar OPTIMIZADOR_INDEX_COST_ADJ para afinar el
comportamiento del optimizador para la selección del camino de acceso para ser
que se indexa amistosamente. Este parámetro le faculta a ajustar el costeo de
caminos de acceso del índice en el optimizador basado en costos y por
consiguiente hacer el optimizador propenso seleccionando un camino de acceso
del índice sobre una búsqueda en toda la tabla .
El incumplimiento para este parámetro es 100 por ciento, lo cual hace al
optimizador estimar caminos de acceso del índice en el costo regular. Cualquier
otro valor hará al optimizador estimar el camino de acceso en el porcentaje del
costo regular. Por ejemplo, colocando eso para 50 por ciento hará el índice
ganar acceso para que el camino parezca tan caro como normal.
El rango de valores legal para este parámetro es 1 a 10,000 por ciento. Tu puede
usar este parámetro para afinar el desempeño de un sistema donde se ve que el
optimizador hace una elección también pocos o demasiadas rutas de acceso
para los índices.
Sintaxis del hint del Optimizador
La Sintaxis de Hint del Optimizador

Incluye hints dentro de los comentarios de una declaración de SQL. Tu puede
usar cualquier estilo de comentario.
El delimitador del hint (+ ) debe venir detrás del delimitador del comentario. Si tu
los separa por un espacio, entonces el optimizador no reconocerá el comentario
como hints que contiene.
81
Por ejemplo, los siguientes hints meten a la fuerza las tablas la cláusula FROM
para ser adjuntó dejado bien:
select /*+ORDERED */ ...
select /*+ ORDERED */ ...El siguiente intento es tratado como un
comentario normal por el espacio que interviene
select /* +ORDERED */ ...El Oracle8i Server ignora hints especificados
incorrectamente. Sin embargo, desee cuenta de lo siguiente:
• Tu nunca obtendrás un mensaje de error.
• Otros (correctamente) hints especificados dentro del mismo comentario son
considerados.
• Las combinaciones de hints conflictivos están también ignoradas por el
Oracle8i Server.
Reglas Para Hints

• Coloque hints inmediatamente después de la primera
palabra clave de SQL de un bloque de declaración.
• Cada bloque de declaración puede tener solo un
comentario de hint, pero puede contener hints
múltiples
• Hints Sólo aplican para el bloque deceleración en el
cual aparecen
• Si una declaración usa alias, entonces los hint deben
establecer referencias para alias en vez de los
nombres de la tabla
Las reglas para usar Hints
• Tu debes colocar el comentario de hint inmediatamente después de la
primera palabra clave (SELECT, INSERT, UPDATE O DELETE) de un bloque
de declaración de SQL.
• Un bloque de declaración puede tener solo un comentario que contenga un
hint, pero puede contener muchos hints dentro de ese comentario.
• Los hints aplican sólo para el bloque de declaración en el cual aparecen y
pasan sobre la instancia o nivel de sesión de parámetros
• Un bloque de declaración es:
1. Un simple SELECT , INSERT, UPDATE, o una declaración DELETE
2. Una declaración del padre o una subconsulta de una declaración
complicada
3. Una parte de una consulta usando operadores determinados (UNION,
MINUS, INTERSECT)
• Si uno alias es usado en una declaración de SQL, entonces los hints deben
establecer referencias para el alias en vez del nombre de la tabla.
82
Recomendaciones de Hints
• Use hints como ultimo recurso, porque implica una
carga alta de mantenimiento.
• Desee cuenta del impacto de desempeño ofhard-
coded hints cuando sea menos validos
Recomendaciones de hints
Use hints como un último remedio al afinar declaraciones de SQL. Sea
consciente que el optimizador no puede cambiar planes de ejecución, aun
cuando mejores alternativas pueden disponibles.
Los hints pueden ponerse menos válidos (o aun el inválido) cuando la
construcción de la base de datos o los contenidos cambien.
Nota: Tenga cuidado que todos los hints, excepto el hint de RULE, forza la optimización
basada en costos independientemente de su modo del optimizador acometiendo contra la
sesión o el nivel de instancia.
Ejemplo De Hint De Optimizador

SQL> update --+INDEX(E I_EMPLOYEES_JOB)
2 employees e
3 set e.salary =
4 (select --+ INDEX(m
I_EMPLOYEES_SLARY)
5 (e.salary + m.salary)/2
6 from employees m
7 where m. Emp_id=w.mgr_id
8 and m. Salary > e.salary)
9 where e..job = INSTRUCTOR
10 and e.hiredate > to date ( 02/02/1998
11 dd/mm/yyyy);
Ejemplo de Sintaxis del optimizador Hint
La diapositiva muestra un ejemplo con hints que aconsejan el optimizador
basado en costos para usar índices. Nota que el bloque de subconsulta tiene su
propio hint del ÍNDICE. El plan de ejecución se parecerá a esto:
Execution Plan
0 UPDATE STATEMENT Optimizador=CHOOSE
(Cost=17 Card=2 Bytes=96)
1 0 UPDATE OF 'EMPLOYEES'
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'EMPLOYEES'
3 2 INDEX (RANGE SCAN) OF 'I_EMPLOYEES_JOB' (NON-UNIQUE)
(Cost=1 Card=2)
4 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMPLOYEES'
5 4 INDEX (RANGE SCAN) OF 'I_EMPLOYEES_SALARY' (NON-UNIQUE)
(Cost=4 Card=1)
83
Las Categorías de Hints
• Los hints para modo de optimización
• Los hints para métodos de rutas de acceso
• Los hints para Ejecución en paralelo
• Los hints para Join Ordenados y Operaciones
Ruta De Acceso Básico De Hint

Full Performs a full table scan
Rowid Accesa una tabla por ROWID
Index Repaso con índice en orden ascendente
Index_asc Repaso con índice en orden ascendente
Index_desc Repaso con índice en orden descendente
And_equal Asocia índices de una sola columna
Index_ffs Rendimiento rápido full index scan
No_index Prohibe usar un set de índices
Hints Descripción
FULL(t) Realiza el acceso a toda la tabla
ROWID(t) Accesa la tabla por medio de ROWID
INDEX(t[idx]...) Repasa con un índice en el orden ascendente
INDEX_ASC(t[idx]...) Repasa con un índice en el orden ascendente
INDEX_ASC(t[idx]...) Repasa con un índice en el orden descendente
AND_EQUAL Mancomuna índices de la sola columna
INDEX_FFS(t[idx]...) Rendimiento búsqueda de la tabla por índice
NO_INDEX(t[idx]...) Prohibe usar un set de índices
Nota: El NO_INDEX hint es útil si tu usa optimización distribuida de consulta. Tiene
aplicación funciones basadas B*TREE , bitmap, cluster e índices de dominio. Si este hint
no especifica cualquier nombre de índice , entonces el optimizador no considerará un
repaso sobre un indice y/o de la tabla.
Avanzadas Rutas de Acceso de hints

CLUSTER Rendimiento a cluster scan
HASH Rendimiento a has scan
HASH_AJ Transformas a una subconulta NOT IN en un
has anti-join
MERGE_AJ TRANSFORMA UN SUBCONSULTA NOT IN EN
MERGE ANTI-JOIN
MERGE_SJ Transforma un subconsulta correlacionada
EXISTS en un merge semijoin
USE_CONCAT Reescribe OR dento UNION ALL y apaga
INLIST proceso
NO_EXPAND Previene OR-expansión
84
Avanzadas rutas de acceso de hints

Hint Descripción
CLUSTER(t) Rendimiento de repaso por cluster
HASH(t) Rendimiento de repaso por hash
HASH_AJ(t) Transforma una NOT IN de subconsulta en un hash anti-join
MERGE_AJ(t) Transforma una NOT IN de subconsulta en un merge anti-join
MERGE_SJ(t) Transforma una subconsulta correlacionada en un merge anti-join
Rescribe OR dentro de un UNION ALL y apaga proceso de inlist
USE_CONCAT Previene OR-EXPANSION
NO_EXPAND
Buffer Cache Hints

CACHE Lugar de bloques de IVRU fin de la lista
LRU(full table scan)
NOCACHE Lugares de bloques del LRU fin la lista LRU
(full table scan) (default)
Los hints buffer cache
El hint CACHE especifica que los bloques recuperados para esta tabla están
acomodados en la lista de los más recientemente usados (MRU) de la lista LRU
en buffer cache cuando se lleva acabo un repaso en toda la tabla. Esta opción es
útil para tablas pequeñas.
El hint NOCACHE especifica que los bloques recuperaron para esta tabla son
colocados por lo menos f recientemente usado de la lista LRU en buffer cache
cuando una repaso en toda la tabla sea realizado. Éste es el comportamiento
normal buffer cache, asegurando que una solo repaso de toda la tabla grande no
puede empujar que todos bloques recientemente usados del lista LRU.
Nota: Tu también puede especificar el CACHE o NOCACHE al creas o alteras tablas.
Hints y Vistas
• No usar hints en vistas
• Técnicas de optimización en vistas
− Transformación de declaración
− Acceso a los resultados de una vista como una
tabla
• Hints y vistas fusionadas
• Hints y vistas no fusionadas
Hints y Vistas
Tu no deberás usar hints interiores o en vistas. Esto es porque las vistas pueden
estar definidas en un contexto y pueden ser usado en otro; Tales hints pueden
resultar en planes inesperados. En particular, los hints dentro de vistas o en
vistas son manipulados diferentes, o la vista no es fusionable en la consulta del
más alto nivel.
85
Optimización de la vista
Para optimizar una declaración que accese a una vista, el optimizador tiene dos
alternativas. Normalmente la declaración es transformada en una declaración
equivalente que accesa la tabla que es base de la vista. El optimizador puede
usar una de estas técnicas transformar la declaración:
• Anexar la consulta de la vista en el bloque de consulta que establece
referencias para la declaración de acceso.
• Empuje el predicado del bloque de consulta que establece referencias para
dentro de la vista
Cuando estas transformaciones son imposibles, la consulta de la vista es
ejecutada y el resultado acceso es a como si fuera una tabla. Esto aparece como
un paso de la VISTA en los planes de ejecución.
Fusión de vistas
El optimizador puede anexar una vista en un bloque de consulta previendo la
definición de la vista no debe contener lo siguiente:
• Operadores (UNION, UNION ALL, INTERSECT, MINUS)
• Clausula A CONNECT BY
• La seudocolumna ROWNUM
• Funciones de grupo (AVG, COUNT, MAX, MIN, SUM) en la lista del select
Los hints y Vistas Fusionables
El acercamiento de optimización y los hints pueden ocurrir en una consulta del
más alto nivel o dentro de vistas:
• Si hay un hint en la consulta del más alto nivel, el hint es usado a pesar de
cualquier otro que ser encuentre dentro de las vistas.
• Si no hay optimizador-modo del más alto nivel , entonces los hints de modo
en vistas para las que se estableció referencias son usado mientras todos
los hints de modo en las vistas sean coherentes.
• Si dos o más hints de modo en las vistas para las que se estableció
referencias están en conflicto, entonces todos los hints de modo en las vistas
son descartados y el modo de sesión es usado, ya sea el default o
especificado por usuario.
El método de acceso y los hints del join en vistas para las que se estableció
referencias son ignorados a menos que la vista contenga una sola tabla (o las
referencias otra vista con una sola tabla). Para tales vistas una sola tabla, un hint
de método de acceso o un hint del join en la vista aplica para la tabla dentro de
la vista.
El método de acceso y los hints del join también pueden aparecer en una
definición de la vista:
• Si la vista es una subconsulta (esto es, si aparece en la cláusula FROM de
una declaración SELECT), entonces todo método de acceso e hints del join
dentro de la vista son preservados cuando la vista es anexada con la
consulta del más alto nivel.
86
• Para vistas que no son subconsultas, de métodos de acceso y los hints del
join en la vista son preservados sólo si la consulta del más alto nivel no pone
notas a otras tablas u otras vistas (esto es, si la cláusula FROM de la
declaración SELECT contiene sólo la vista).
Los hints y Vistas no fusionables
Con vistas poco fusionables, los hints de modo de optimización dentro de la vista
están ignorados. La consulta del más alto nivel decide el modo de optimización.
Desde que las vistas poco fusionables son optimized separadamente de la
consulta del más alto nivel, el método de acceso y los hints del join dentro de la
vista están siempre conservados. Por la misma razón, los hints de métodos de
acceso en la vista en la consulta del más alto nivel están ignorados.
Sin embargo, los hints del join en la vista en la consulta del más alto nivel son
preservados porque en este caso, una vista poco fusionable es similar a una
tabla.
Vistas Procesando Hints

MERGE Fusiona vistas complicadas o subconsultas
con la consulta circundante
NO_MERGE No asocia vistas fucionables
Vistas procesando hints
Tu puedes hacer pueda ser anexada sobre un per-consulta en una base de por
la consulta usando el MERGE Y NO_MERGE hints. El hint NO_MERGE causa
que el servidor de Oracle8i no anexe vistas fusionables.
Ejemplo:
SQL> select /*+ MERGE(v) */
2 c.class_id, c.crs_id, v.no_att
3 from classes c
4 , (select r.class_id
5 , count(r.stud_id) as no_att
6 from registrations r
7 group by r.class_id )v
8 where c.class_id = v.class_id
9 and c.days = 1;
Nota: Porque la función de grupo es usado en la línea 5, el hint MERGE (v) está
ignorado.
Resumen
Esta lección le presentó escenarios adicionales del optimizador y los hints.
Tu puede ajustar el modo del optimizador para usar ya sea el método basado en
costos o el método basado en reglas. Los valores respaldados de modo del
optimizador son COSE, RULE, FIRST_ROWS, ALL_ROWS
87
Usando hints, tu puede influenciar al CBO en la declaración ecuánime. Use hints
como un último remedio al afinar declaraciones de SQL. Hay varias categorías
de hint, uno del cual son hints para los métodos de ruta de acceso.
Sea precavido al usar hints con vistas. Los hints dentro de vistas o en vistas son
manipulados en forma diferente esto depende que la vista sea o no fusionable
en la consulta del más alto nivel.
Pracatica 8
En esta práctica, investiga comportamiento de RBO para una consulta en la tabla
de CATEGORIES que es una tabla pequeña con un índice. Esto está
consumado por estadísticas de la tabla que suprime y coloca el modo del
CHOOSE del optimizador. Entonces usa un hint para forzar un repaso completo
de la tabla. Compare los resultados y decida el mejor acercamiento para esta
consulta.
1 Suprima todas las estadísticas para la tabla de CATEGORIES.
2 Despliega los contenidos de la tabla de CATEGORIES. Note que es una
tabla pequeña. Hay un índice sobre la columna CAT_ID, para soportar la
restricción de llave primaria.
3 Altera la sesión y ajusta el modo CHOOSE del optimizador.
4 Analiza la declaración del select siguiente:
SQL> select *
2 from categories
3 where cat_id > 30;
5 ¿Qué método de optimización es usado?
6 Incluye un hint para un repaso de la tabla con la declaración del select
usado en el paso 4.
7 Ve los resultados del EXPLAIN_PLAN. ¿Qué método de optimización es
usado? ¿Con la tabla de CATEGORIES, cuál acercamiento es más
eficiente?
88
9 Sorteando y Uniendo
(Sort and Join)Los
objEtivos
Después de completar esta lección, tu deberás poder:
• Optimizar el desempeño, usando Top-N SQL
• Describir las técnicas usadas para ejecutar declaraciones de join
• Explicar la optimización realizada en joins
• Encuentra el plan óptimo de ejecución para una join
Las joins deben de ser la causa más frecuente de problemas de desempeño.
Afinando Desempeño de Sorteo

• Sorting large sets puede ser costoso:
Tune sort parameters
• Nota que DISTINCT, GROUP BY, y mas
operadores causan sorteo implícito
• Minimizar sorteo por uno de los siguientes:
− Trate de evitar el DISTINCT and GROUP BY
− Usa UNION ALL en lugar de UNION
− Habilite el acceso por índice para evitar el
sorteo
Afinando Desempeño de Sorteo
Tu deberás contactar al administrador de la base de datos para afinar
parámetros de tipo, como lo siguiente:
• SORT_MULTIBLOCK_READ_COUNTSORT_AREA_SIZE
• SORT_AREA_RETAINED_SIZESi es posible, escriba sus declaraciones de
SQL de tal manera que la clasificación no sea necesaria. Nota que varios
componentes de lenguaje de SQL causan sorteos implícitos, como DISTINCT,
GROUP BY, UNION, MINUS e INTERSECT, Asegúrese que sólo obtiene los
sorteos que son necesarios para su resultado.
Los sorteos pueden ser evitados por índices que crea. Los índices
concatenados, con el apropiado DESC o ASC atribuyen, especialmente puede
ayudar a evitar sorteos. Nota, sin embargo, que tu tienes la ventaja de I/O del
multibloque, porque para evitar un tipo el índice repasa secuencialmente. Un
índice de repaso completo (usando I/O del multibloque) no garantiza que las filas
son devueltas en la orden correcta.
SQL Top-N
SQL> select *
2 from (select emp_id
3 , last_name
4 , first _name
89
5 , salary
6 from employees
7 ORDER By sañaru desc)
8 where ROWNUM<=5;
Top-N SQL
La idea detrás de la característica SQL del Top-N es que tu no necesita
clasificar un set lleno , por ejemplo, tu está sólo interesado en los cuatro valores
más altos (o mínimos).
Si un set es demasiado grande para ser clasificado en la memoria, entonces el
desempeño lo es significativamente y especialmente degradando. Esto se debe
a la I/O desde el almacenamiento temporal de resultados inmediatos sobre el
disco de resultados intermedios en disco.
Si tu sólo quiere saber los cuatro valores más altos, entonces tu sólo necesita un
conjunto imponente con cuatro ranuras para repasar el set y guardar los cuatro
valores más altos en que forman en orden.
La cláusula WHERE de la declaración de arriba es anexada en la vista de línea
para prevenir la tabla llena de EMPLOYEES de ser clasificada por SALARY.
Esto aparece en el plan de ejecución como sigue:
Execution Plan
SELECT STATEMENT Optimizador=CHOOSE
COUNT (STOPKEY)
VIEW
SORT (ORDER BY STOPKEY)
TABLE ACCESS (FULL) OF 'EMPLOYEES'
Terminología de JOIN
• Declaración de JOIN
• Predicado De Join y nonjoin predícate
• Predicado Single-row
SQL> select cls.start_date,,cls.instr_id
2 from classes cls, courses crs
3 where cls. crs_id = crs.crs_id
4 and cls.status =CONF
5 and crs.shart_name = SQLTUN80 ;
Terminología Join
Una declaración join es una declaración select con más de una tabla en la
cláusula FROM.
Sin embargo, el optimizador usa las técnicas normalmente asociadas con joins al
ejecutar otros sorteos de declaraciones donde más que una tabla es para la que
se estableció referencias, como una subconsulta.
Éste es un ejemplo de una declaración de join:
SQL> select cls.start_date, cls.instr_id
3 where cls.crs_id = crs.crs_id -- join predicate
90
4 and cls.status = 'CONF' -- non-join predicate

5 and crs.short_name = 'SQLTUN80' -- single row predicateUn
predicado join es un predicado en la cláusula WHERE que engancha
conjuntamente las columnas de dos de las tablas en el join.
Un predicado de nonjoin es un predicado en la cláusula WHERE que establece
referencias para una sola tabla.
Un predicado de una sola fila es un predicado de igualdad en una columna con
una restricción única o primaria y crucial, o una columna con un único índice sin
restricción correspondiente. El optimizador sabe que estos predicados siempre
devuelven una fila o ninguna de las filas del todo.
Terminologia de Join
• Equijoin
• Nonequijoin
SQL> selecat cls.start_date, cls.inst_id
3 Where cls.crs_id=crs.crs_id
4 and cls.status= CONF
5 and crs.short_name = SQLTUN80;
(Continuación)
Un equijoin es una declaración de join donde el predicado del join muestra el
signo igual (= ) entre las columnas. Un equijoin es el tipo más común de join. La
declaración de arriba es un ejemplo de un equijoin.
Un nonequijoin se refiere a las declaraciones del join dónde el predicado del join
usa uno de los otros operadores de comparación, tan <, >, < =, > =, y.
Nonequijoins sea también llamado theta-join. Ocurren infrecuentemente y
pueden indicar un propósito poco numeroso de la base de datos.
Operaciones de Join
• Una operación de join combina dos fuentes como
salidas y regresa solo una como resultado.
• Los tipos de operaciones de join incluyen las
siguientes:
− Join Nested loops
− Join Sort/merge
− Join Hash
− Join Cluster
Operaciones de Joins.
Una operación de join combina la salida de dos fuentes de la fila y devuelve una
fuente resultante de la fila. Las fuentes de la fila se introdujeron
Tipos de operaciones de join
El Oracle8i Server respalda cuatro sorteos diferentes de operación del join:
• Nested loops join
• Sort/merge join
91
• Hash Join
• Cluster Join
Joins Nested Loops

• Una de las dos tablas es definida como outer
table o driving table.
• La otra tabla es llamada inner table.
• Para cada fila de la tabla outer, Todas las filas
que coincidan con la tabla inner serán regresadas.
Plan de Ejecución básico de Nested Loops Joins

NESTED LOOPS
TABLE ACCESS () OF our_outer_table
TABLE ACCESS () OF our_inner_tablePorque son a menudo usados
con accesos indexados de la tabla, los nested loops son comunes con un plan
de ejecución que se ve de la siguiente manera:
NESTED LOOPS
TABLE ACCESS (BY ROWID) OF our_outer_table
INDEX (... SCAN) OF outer_table_index (..)
TABLE ACCESS (BY ROWID) OF our_inner_table
INDEX (RANGE SCAN) OF inner_table_index (NON-UNIQUE)
Es común que la tabla exterior (la conducción) sea accesada con un repaso de
toda tabla.
Non-equijoins
Si tu tiene un nonequijoin, nested loops join es posible solo una operación de
join.. Dependiendo de los predicados de nonjoin, Nonequijoins pueden resultar
en nested loops con repaso en tabla en ambos mientras exterior y tablas inners.
Esto significa que se realiza un repaso completo en la tabla exterior; Y para cada
fila, también es realizada (una y otra vez) en la tabla inner. Esto usualmente
resulta en desempeño pobre.
92
Plan join de Nested Loops
Plan Nested Loops Join

Para cada fila de la tabla outer (la conducción), todas las filas de la tabla inner
que satisfaga el predicado del join serán regresadas.
Cualquier nonjoin en la tabla inner considérese después de esta recuperación
inicial, a menos que un índice compuesto, lo cual combine ambos el join y
nonjoin, es usado.
El nested loops join puede solucionar toda clase de requisitos de join, no
importa qué join . Por consiguiente, tu deberás usar el nested loops join cuando
tu no puedas usar a sort/merge, hash, o clusters joins..
Join Sort/Merge
Un join sort/merge es ejecutado como sigue:
• Las filas de cada fila fuente son sorteadas en las
columnas del predicado
• Las dos fuentes de la fila son asociadas y
regresa el resultado de la fila fuente
Nota:Sort/merge es posible solo para equijoins
Sort/Merge Joins
En el tipo las operaciones, las dos fuentes de la fila son clasificadas en los
valores de las columnas usadas en el predicado del join. Si una fuente de la fila
ya ha sido clasificada en una operación previa, entonces la operación de
clasificación por fusión se salta el tipo en esa fuente de la fila.
La clasificación podría hacer esta técnica del join cara, especialmente si la
clasificación no puede ser realizada en la memoria.
Lo anexión que las combinaciones de operación las dos fuentes clasificadas de
la fila para recuperar cada par de filas que contienen valores que hace juego
para las columnas usadas en el predicado del join.
El plan básico de Ejecución
MERGE (JOIN)
SORT (JOIN)
TABLE ACCESS () OF tableA
SORT (JOIN)
TABLE ACCESS () OF tableB
93
Plan De Join Sort/Merge
El plan del Sort/Merge Join

Los accesos de la tabla (las fuentes de la fila 4 y 5) pueden basarse en índice
repaso si hay predicados de la poco join que pueden usar un índice. Sin
embargo, esta operación del join más a menudo aparece repaso total en ambas
tablas.
La secuencia (qué tabla es primera clasificada) no tiene importancia; No hay
concepto de una tabla del outer/driving. Recuerdo que la clasificación puede
resultar en la creación de segmentos temporales en disco (dando más I/O que
las que justamente la tabla se repaso).
Las joins Sort/merge tienen una tendencia a funcionar mejor que un nested loops
join de lazos si el número de filas liquidando la condición del join representa una
parte principal del número total de filas en las dos tablas.
Nota: El punto de equilibrio para una join del sort/merge y un indexado nested loops join
depende del desempeño de clasificación de la base de datos. El desempeño de tipo puede
ser influenciado por definición de tablespaces temporales definitivos de tipo
TEMPORARY, poniendo el parámetro de SORT_AREA_SIZE para definir la cantidad de
memoria usar para un tipo ordenamiento, y poniendo SORT_AREA_RETAINED_SIZE
para soltar la memoria después del ordenamiento. Ésta es típicamente una tarea de DBA.
Joins Hash
Un join has join es ejecutado como sigue:
• Ambas tablas son divididas en tantas particiones
como se requiera, usando un barrido de toda la
tabla
• Para cada par de partición, una tabla de hash se
construye en memoria sobre la partición mas
pequeña
• La otra partición se usa para explorar la tabla hash
94
Hash Joins
El Oracle8i Server considera que hash join sólo cuando tu usa el optimizador
basado en costos. Los hash joins, como los sort/merge, pueden ser realizadas
sólo para equijoins. Éstos son los pasos realizados para una join hash:
• El servidor Oracle realiza un repaso total en ambas tablas y hendiduras, cada
uno en muchas particiones según lo solicitado, basadas en la memoria
disponible.
• El servidor Oracle basa una tabla de direcciones calculadas en la partición
menor y usa la otra partición explorar la tabla de direcciones calculadas.
Todos los pares de partición que no caben dentro de memoria están posados
encima de disco.
El número de particiones en las cuales las tablas están partidas depende de la
cantidad de memoria disponible.
HASH JOIN
TABLE ACCESS (..) OF tableA
TABLE ACCESS (..) OF tableB
Consideraciones del desempeño.
Por regla general, las joins hash funcionan mejor que las joins sort/merge. En
algunos casos, una join sort/merge puede funcionar mejor que un nested loops
join; Es aun más probable que una join hash lo hará.
Plan De Join Hash
El plan hash join

Para ejecutar un join hash, el servidor Oracle realiza estos pasos:
• Los pasos 2 y 3 realizan repaso total de las tablas que debe estar unidas.
• El paso 1 basa una tabla de direcciones calculadas fuera de las filas
entrantes de paso 2 y sondas ella con cada llegada de la fila de paso 3.
Nota: La inicialización del parámetro HASH_AREA_SIZE controla la cantidad de
memoria usada por la operaciones de un join hash y la inicialización del parametro
HASH_MULTIBLOCK_IO_COUNT controla el número de bloques que una operación
de join de hash podrán ser leídas y escritas concurrentemente.
95
Cluster Joins
• Prerequisitos de Join Cluster.
− Las tablas deben ser parte del mismo grupo
− Equijoin es realizado sobre la llave cluster
• Las filas con el mismo valor de la llave de clusterse
guardan en el mismo bloque
• Join cluster son similares a joins nested loops
Cluster Join
Un join Cluster ser realizada si las tablas a unir son parte del mismo grupo, el
predicado del join indica a un equijoin, y el join se realiza con la llave de grupo.
En un grupo, las filas de ambas tablas con el mismo valor de la llave de grupo se
guardan en el mismo bloque, normalmente resultantes en menos bloque lee.
NESTED LOOPS
TABLE ACCESS (FULL) OF our_outer_table
TABLE ACCESS (CLUSTER) OF our_inner_table
Uniendo Múltiples Tablas

• Tu puedes unir solo dos filas fuentes a la vez
• Las uniones con mas de dos filas son ejecutadas como
sigue:
1. Dos tablas son unidas, resultando una fila fuerte.
2. La próxima tabla es unida con la fila fuente
resultante del paso 1.
3. Repite el paso 2 hasta que todas las tablas son
unidas
Uniendo tablas múltiples
El Oracle8i Server puede unir sólo dos fuentes de la fila a la vez.
Las operaciones del join (como: nested loops y sort/merge) son utilizadas como
bloques constructivos si la declaración del join contiene más que dos tablas.
Excepto por las limitaciones inherentes en cada tipo de declaración del join (por
ejemplo, las joins de grupo pueden ser realizadas sólo si las tablas vienen del
mismo racimo), no están restricciones en la combinación de operaciones del join
involucradas en una join con más que dos tablas.
Así, tu puedes ver operaciones de nested loops que mezclando joins hash o
sort/merge en el mismo plan de ejecución.
96
Join Outer
• Predicados de Join con signo (+)
• Predicados Nonjoincon signo (+)
• Predicados sin signo (+) puede deshabitar la
funcionalidad de un join outer
SQL> select crs. Description,cls,start_date
2. from classes cls, courses crs
3. where cls.crs_id(+) = crs.crs_id
4. and cls.inst_id =crs.dev_id
5. and cls.satus(+) = BOOK
6. and cls.type = N/EC;
Outer Joins
Una join Outer es una join donde los predicados del join tienen un signo de (+ ) ,
Significa que el join devuelve una fila aun la tabla con este predicado especial
(la tabla outer join no tiene una fila que satisface la condición del join.
Ejemplo:
Select crs.description, cls.start_date
From classes cls, courses crs
Wherecls.crs_id(+) = crs.crs_id -- join predicate with (+)
and cls.instr_id = crs.dev_id -- join predicate without (+)
and cls.status(+) = 'BOOK' -- non-join predicate with (+)
and cls.type = 'N/EC' -- non-join predicate without (+)Note que
cualquier predicados sin un signo de (+ ) en la tabla que es exterior unida desactivarán
la funcionabilidad exterior del join.
Ejecución de JoinsOuter
•Indices pueden ser usados por predicados de
join ouer
• Predicados de Nonjoin en la tabla outer join
puede usar índices, si un índice no es usado
para el predicado del join
SQL>select crs.description, cls. Start_date
2 from courses crs, clases cls
3 Where crs.crs_id = cls.crs_id(+)
4 and cls.clas_id(+) =56744;
Ejemplo de Outer Join
1. SQL> select crs.description, cls.start_date
1. from courses crs, classes cls where crs.crs_id = cls.crs_id(+);
97
El optimizador puede usar un índice en la columna cls.crs id.
2 from courses crs, classes cls
3 Where crs.crs_id = cls.crs_id(+)
4 And cls.class_id(+) = 56744;
El optimizador puede usar un índice en la columna cls.class id (un sola predicado
de la fila). COURSES es la tabla controlante.
2 from courses crs, classes cls
3 where crs.crs_id = cls.crs_id(+)
4 and cls.class_id = 56744;
Esta declaración es una join exterior discapacitada; a ambos el índice en
cls.class id y crs.crs id. Tu puedes remover lo (+) en el predicado del join, porque
no tiene función.
El Optimizador y Joins
El optimizador decide lo siguiente:
1. El orden en el cual unirá las tablas
2. Que operación de unión aplicara para cada
join
3. La ruta de acceso para cada fila fuente
El Optimizador y Joins
El oiptimizador Oracle8i de optimizadores toman parte en tres fases. Primero, el
optimizador genera una lista de todo lo que el join posible orden. Entonces, para
cada orden posible del join, la mejor operación del join es seleccionada.
Finalmente, el Oracle8i optimizador determina el mejor camino de acceso para
cada fuente de la fila del plan de ejecución.
Reglas de Orden de join

Regla1:
Un predicado de single-row forza a la fila fuente
hacer la primera en el orden del join
Regla 2:
Para joins outer, la tabla con el operador (+) debe
venir después de la otra tabla en el predicado del
join.
Reglas de Orden de join
• Un predicado de single-row forza su fuente de la fila a ser colocado primero
en el orden del join.
• Para las declaraciones del outer join, la tabla con el operador de outer join
debe venir antes de (en la orden del join) la otra tabla en el predicado del join.
98
Haciendo un predicado de single-row de una tabla el manejo de la tabla de la

operación de join, el optimizador eficazmente elimina una operación del join. Por
ejemplo, para una nested loops join, el loop principal no es un loop real. Los
resultados del predicado single-row en una fila (o ninguna de las filas del todo),
así es que el loop inner es ejecutado sólo una vez (o de ningún modo).
La razón para la segunda regla (acerca de outer joins) es que tu de otra manera
sería incapaz de producir el resultados correctos de outer join. Por ejemplo, si tu
unes la tabla REGISTRATIONS con la de CLASSES y también quieres ver
clases que no tienen inscripciones correspondientes, entonces tu debe comenzar
con la tabla de CLASES.
Después de considerar estas dos reglas, determine el orden del join y a las
operaciones basadas en el optimizador.
Optimización de Join RBO

• Como un primer paso, todos los ordenes posibles de join
son generados
• This potentially gives the following
Number of tables join orders
2 2! =2
3 2! =6
4 4! =24
• Tiempo de análisis (pares) exponencialmente cuando se
agrega tablas al join
Optimización de join RBO
El número posible de planes de ejecución es determinado por el número de
tablas en el join y los predicados especificados del join. Teóricamente, el número
de planes posibles de ejecución es:
Numero de tablas Planes posibles
2 2
3 3!=3*2*=6
4 4!=4*3*2=24
5 5!=5*4*3*2=120
... ....
Porque sólo los planes de ejecución que siguen el predicado del join son
considerados, el número de planes de ejecución normalmente no alcanza este
valor cuando el número de tablas es mayor que 3. Sin embargo, uniendo 20
tablas resultan posiblemente muchos planes de ejecución. Recuerde que todas
las tablas involucradas en una join, incluyendo esas que se encuentran en
escondido en vistas, cuentan como tablas separadas.
Optimización de join RBO(continuación)
Éstas son las reglas aplicadas por el optimizador basado en reglas, en la orden
especificada:
99
1. Trata de minimizar operaciones de nested loops en las cuales la tabla inner es
accesada por medio de un barrido completo.
2. Si hay una corbata, entonces trata de minimizar operaciones del sort/merge.
3. Si hay todavía una liga, entonces escoja una tabla controlante con el camino
de registro del órgano mejor de acceso.
4. Si hay todavía una liga, entonces escoja una tabla controlante que aparece
más tarde en la cláusula FROM(La regla izquierdo para derecho).
Optimizacion de join cbo join
• Un set de planes posibles de ejecución es generado,
limitado por dos parámetros :
- OPTIMIZER_SEARCH_LIMIT
- OPTIMIZER_MAX_PERMUTATIONS
• El optimizador estima el costo de cada plan y elige el
de menor costo
Optimización de join CBO.

El número de diferentes planes de ejecución está limitado por el valor del
parámetro OPTIMIZADOR_SEARCH_LIMIT , lo cual especifica el número
máximo de tablas para las cuales el optimizador considera un producto
cartesiano. El valor predeterminado es 5. Tan pronto como tu un ES más tablas,
el optimizador sólo considera que el cliente habitual se asocie; Esto es, sólo
considera órdenes del join donde las tablas están conectadas por los predicados
del equijoin.
El parámetro de inicialización OPTIMIZADOR_MAX_PERMUTATIONS
directamente limitan el número de permutaciones de la orden del join que el
optimizador considera. El valor predeterminado es 80,000. Reduciendo este
valor, tu puede asegurar eso se analice gramaticalmente por para las consultas
asociándose montones de tablas se quedan dentro de los límites aceptables; La
desventaja es que el optimizador puede necesitar el plan óptimo.
Estimando Costos de join

• Join Nested loops:
Cost=read(A)+card(A) *read(B)
- Parametro
OPTIMIZER_INDEX_CACHING
• Join Sort/merge:
Cost=read(A)+sort(A) +sort(B)
Costos estimados del Join
El costo de una nested loops join se basa en el costo de lectura de cada fila
seleccionada de la tabla outer y cada uno de sus filas que hace juego de tabla
inner.
El costo de un sort/merge join se basa en el costo de lectura y clasificando
ambas fuentes de la fila. El optimizador basado en costos también considera
otros factores al determinar el costo de cada operación. Por ejemplo:
100
• Un tamaño más pequeño de área de tipo es probablemente aumentar el

costo para un sort/merge join porque la clasificación lleva más tiempo de
procesador y I/O en un área más pequeña de sorteo.
• Un multibloque de lectura mayor, probablemente disminuirá el costo para
una join del sort/merge en relación a una nested loops join. Si un número
grande de bloques secuenciales pueden ser leídos de disco en una sola I/O,
entonces un índice en la tabla inner para el nested loops join es menos
probablemente para mejorar desempeño de repaso en toda la tabla.
Otro parámetro importante que influye en las estimaciones de costo CBO para
nested loops join es OPTIMIZADOR_INDEX_CACHING. El rango de valores es
0-100, y el valor predeterminado es 0. Ajustando este parámetro para un valor
más alto, el CBO dará por supuesto que cualquier índices en la tabla inner
estarán en el buffer cache. Esto quiere decir que un nested loops join - se
considerará más atractivo.
Join star
Joins de Estrella.
Un tipo de diseño warehouse se centra en lo que es conocido como un esquema
de estrella, el cuál es caracterizado por uno o mas grandes tablas de hecho que
contiene la información primaria en el warehouse y un número de dimensión muy
pequeña de la tabla (o lookup pospone), cada uno del cual contiene información
acerca de las entradas para un atributo particular en la tabla de hecho.
Una star join es una join entre una tabla de hecho y un número de lookupde
tablas. Cada tabla del lookup es unida a la tabla de hecho por una la llave
primaria para join de la llave foránea, pero las tablas del lookup no son unidas a
cada quien. El hecho que la tabla normalmente tenga un índice concatenado en
las columnas cruciales para facilitar este tipo de join.
Una star join es ejecutado usando las operaciones normales del join, pero
usando una orden del join que no es propia de los predicados del join: Las tablas
más pequeñas de dimensión son unidas primero (guste un producto cartesiano).
La fuente resultante de la fila sirve entonces para un acceso concatenado del
índice en la tabla de hecho usando un nested loops join.
101
El ejemplo del star join
SQL> select sum(c.days)
2 from cls_statuses s
3 , class_types t
4 , locations l
5 , classes c
6 where c.status = s.cls_status
7 and .type = t.type
8 and c.loc_id = l.loc_id
9 and s.description = 'Class rescheduled or consolidated'
10 and t.description = 'Scheduled Ed Center Class'
11 and l.city = 'Redwood Shores';
En este ejemplo, debes construir un índice concatenado sobre las columnas
STATUS, TYPE y LOC_ID de la tabla de CLASES para posibilitar la optimización
de consulta de estrella.
Nota: La optimización de la consulta de estrella es considerada cuándo usa el
optimizador basado en costos (CBO). Las joins de estrella normalmente funcionan mejor
que el join normal que corresponde a multitabla, porque el optimizador pueda iniciar con
una tabla de dimensión pequeña como la tabla controlante, solamente debe unir esa
tabla con la tabla de hecho. Esto produce un resultado intermedio grande que puede ser
unido con todo el remanente de dimensión de las tablas. La ventaja de una star join es
que la tabla del hecho es la última tabla en la orden del join.
Hints para Orden de Join
SQL> select /*+ORDERED */
2 from T1, T2,
3 where
SQL> select /*+LEADING (T1) */

2 from T1, T2,
3 where
SQL> select /*+STAR */

2 from T1, T2,
3 where
Hints para Joins Order

Especificar un hint forza que el CBO a será usado. Nota que especificando un
hint como un hint del índice para una de las tablas basados en la optimización de
costos servirá para las otras tablas en el join, igualmente.
ORDERED
El hint ORDERED se une a las tablas en la orden en la cual aparecen en la
cláusula FROM, de izquierda a derecha. Tu puedes experimentar con órdenes
diferentes del join cambiando la orden de la tabla en la cláusula FROM.
102
LEADING
El hint LEADING causa el optimizador que la tabla especificada ser utilizado
como la primera tabla en la orden del join. La diferencia con el hint ORDERED es
que LEADING sólo determina la tabla controlante.
START
El hint START forza a un plan de join star ser usado si es posible. Un plan de
star join tiene la tabla de más grande en la consulta de último en la orden del join
y con un nested loops join sobre un índice concatenado.
El hint star aplica cuando hay al menos tres tablas, el índice concatenado de la
tabla grande tiene al menos tres columnas, y no hay conflicto de acceso o join
con hints. El optimizador también considera permutaciones diferentes de las
tablas pequeñas.
Hints para Operaciones de Join
SQL> select /*+USE_NL(T2) */
2 from T1, T2,
3 where
SQL> select /*+USE_MERGE (T2) */
2 from T1, T2,
3 where
SQL> select /*+USE_HASH (T2) */
2 from T1, T2,
3 where
Hints para Joins de Operaciones

Estos tres hints para influenciar la operación del join aceptan que o más
nombres de tablas (o los alias). Es importante para saber que el nombre de la
tabla (o alias) especificas deberá ser la tabla inner, no la tabla controlante, para
la operación del join que quieres realizar
También nota USE_HASH y USE_MERGE hints son siempre ignorados para
nonequijoins, porque los nonequijoins sólo pueden estar resueltos con una
operación de nested loops join.
Ejemplos:
El hint de USE_NL causa que cada tabla especificada para ser unida con otra
fuente de la fila con un nested loop join usando la tabla especificada como la
tabla inner:
SQL> select /*+ USE_NL(T2 T3) ORDERED */ ...
2 from T1, T2, T3
3 where ...
Esto deberás dar la siguiente estructura de plan de ejecución:
NESTED LOOPS
TABLE ACCESS () OF T1
NESTED LOOPS
103
El hint de USE_MERGE causa que cada tabla especificada para ser unida con
otra fuente de la fila en la orden del join con un sort-merge join.
SQL> select /*+ USE_MERGE(TAB2) */ ... 2 from TAB1, TAB2 3 where ...
El hint de USE_HASH causa que cada tabla especificada para ser unida con
otra fuente de la fila en la orden del join con un hash join
SQL> select /*+ USE_HASH(TAB2) */ ... 2 from TAB1, TAB2 3 where ...
Usando los hints USE_NL, USE_MERGE, y USE_HASH.
El servidor Oracle8i Server usa estos tres hints de operación del join cuando
tabla para la que se estableció referencias (o alias) se ve forzada a una tabla
inner de un join, y estos son ignorados si la tabla para la que se estableció
referencias (o alias) es la tabla exterior. Por esto es que estos hints están a
menudo combinados con el hint ORDENADO.
Si tu tiene la idea que el optimizador ignora los hints USO_NL, USE_MERGE, o
USE_HASH probablemente encontraras un mejor plan para una orden diferente
del join.
Para eliminar esta posibilidad, tu puede añadir el hint ORDERED y puede
cambiar la orden de las tablas en su cláusula FROM, para forzar una cierta
orden del join.
Otros hints para Join
SQL> select /*+STAR_TRANSFORMATION) */
2 from T1, T2,
3 where
SQL> select /*+DRIVING_SITE (T1) */

2 from T1, T2,
3 where
START_TRANSFORMATION
Éste no es realmente un hint del join, pero más bien un hint para el acceso de
datos del optimizador para la tabla de hechos de un esquema de la estrella.
DRIVING_SITE
El hint DRIVING_SITE forza la ejecución para hacerlo en un sitio diferente que el
que tomo servidor de Oracle8i. Este hint puede ser usado con optimización
basado en reglas o basado en costos.
Ejemplo
SQL> select /*+ DRIVING_SITE(c) */
2 e.last_name
3 , e.first_name
4 , c.short_name
5 from employees e
6 , courses@rsite c
7 where e.emp_id = c.dev_id;
104
Subsconsultas y Joins
• Subconsultas, com ojoins, son declaraciones que
referencian a múltiples tablas
• Tipos de subconsultas:
− No correlacionada
− Correlacionada
− NOTINN(anti-joins)
− EXISTS semijoins)
Subconsultas No correlacionadas
Una subconsulta no correlacionada no contiene referencias para la consulta
exterior (main) y pueden ser ejecutadas independientemente.
Por ejemplo:
SQL> select cls.*
2 from classes cls
3 where cls.crs_id in (select crs.crs_id
4 from courses crs
5 where crs.dev_id = 10666);
Esta declaración es ejecutada como una nested loops join con una subconsulta
de la tabla exterior. Recupera todas las clases programadas pues los cursos
desarrollaron por empleado 10666. Sin cualquier índices que podrían mejorar
desempeño, ésta es la estructura de plan de ejecución:
Execution Plan
0 SELECT STATEMENT
1 0 NESTED LOOPS
2 1 TABLE ACCESS (FULL) OF 'COURSES'
3 1 TABLE ACCESS (FULL) OF 'CLASSES'
Subconsultas correlacionados
Este ejemplo de una subconsulta correlacionada, encuentra al empleado más
nuevo en cada equipo:
SQL> select e1.*
2 From employees e1
3 where e1.hiredate = (select max(e2.hiredate)
4 from employees e2
5 where e2.mgr_id = e1.mgr_id);Las subconsultas
correlacionadas normalmente tienen el siguiente plan de ejecución:
FILTER
TABLE ACCESS (..) OF EMPLOYEES -- E1
TABLE ACCESS (BY ROWID) OF EMPLOYEES -- E2
INDEX (RANGE SCAN) OF FK_EMP_MGR (NON-UNIQUE)
La operación del FILTER en este caso puede ser considerado como una
operación nested loops con el acceso para E1 como mientras tabla exterior y el
acceso para E2 como tabla inner.
105
Anti-Joins
Una antijoin es una declaración de select con una subconsulta con un NOT IN.
Por ejemplo:
SQL> select crs.*
2 from courses crs
3 where crs.dev_id = 79126
4 and crs.crs_id NOT IN (select cls.crs_id
5 from lasses cls);Una antijoin devuelve filas del
lado izquierdo del predicado para el cual no hay filas correspondientes sobre el
lado derecho del predicado.
El optimizador usa un algoritmo nestded loops para subconsultas de NOT IN por
defecto, a menos que el parámetro de inicialización ALWAYS_ANTI_JOIN que
esté colocado para un MERGE o HASH y las diversas condiciones requeridas
son por las que se responsabiliza que permite la transformación del NOT IN de la
subconsulta en un sort/merge o hash antijoin. Tu puedes colocar a un
MERGE_AJ o HASH_AJ en la subconsulta del NOT IN para especificar cuál
algoritmo el optimizador deberá usar.
Semijoins
Una semijoin devuelve las filas que hacen juego con una subconsulta EXISTS.
Por ejemplo:
SQL> select crs.*
2 from courses crs
3 where crs.dev_id = 79126
4 and crs.crs_id NOT IN (select cls.crs_id
5 from classes cls);
El optimizador usa un algoritmo de nested loops para las subconsultas EXISTS
por defecto, a menos que el parámetro de inicialización ALWAYS_SEMI_JOIN
que esté colocado para MERGE O y diversas condiciones requeridas son por los
que se responsabiliza. Tu puedes colocar a un MERGE_AJ o HASH_AJ en la
subconsulta del EXISTS para especificar cuál algoritmo el optimizador deberá
usar.
Parámetros De Inicialización Que Influencian Joins

• Parámetros para join Hash:
− HASH_JOIN_ENABLED
− HASH_AREA_SIZE
− HAS_MULTIBLOCK_10_COUNT
• Parámetros de sorteo:
− SORT_AREA_SIZE
− SORT_AREA_RETAINED_SIZE
− SORT_MULTIBLOCK_READ_COUNT
Parámetros de HASH JOIN.
HASH_JOIN_ENABLE, HASH_AREA_SIZE, y
HASH_MULTIBLOCK_IO_COUNT todo son realizadas.
106
HASH_JOIN_ENABLE
Este parámetro especifica si el optimizador deberá considerar usar un hash join
como un método de join. (Cuando se pone en FALSE, esta apagado; Esto es,
no está disponible como un método del join que el optimizador puede considerar.
Sin embargo, está todavía disponible en la nivel declaración-usando un cada si
el parámetro HASH_JOIN_ENABLE es determinado para FALSE.)
HASH_AREA_SIZE
Este parámetro especifica la cantidad máxima de memoria, en bytes, para ser
usados por hash joins.
HASH_MULTIBLOCK_IO_COUNT
Este parámetro especifica cuántos bloques secuenciales son leídos o escritos en
un I/O.
Parámetros de SORT
Varios parámetros de tipo influencian cómo realiza el Oracle8i Server una
operación de tipo. El desempeño de tipo, especialmente cuando ocupándose de
cantidades grandes de datos, varía mucho basado en los valores diferentes de
estos parámetros. El desempeño de tipo directamente influencia desempeño del
join del sort/merge.
Prospectos de Filas
• Las filas que son recuperadas pero no usadas
• Identificar el prospecto para comparar el numero de
filas de los siguientes:
− La operación de join
− Las filas fuentes de entrada
El prospecto de Filas
Compara el número de filas de las dos fuentes de la fila de entrada con el
número de filas de la operación del join. Si ambos introducen filas fuentes tienen
más filas que la operación del join, tu has identificado un prospecto de filas.
EJEMPLOS:
Rows Operation
100 NESTED LOOPS
45 TA45BLE ACCESS () OF our_outer_table
4530 TABLE ACCESS () OF our_inner_table
En este ejemplo, aproximadamente 98 % de las filas recuperadas (4,430 fuera
de 4,530 filas de la tabla inner) son arrojados fuera, Tan debería haber espacio
para mejora de desempeño.
107
Rows Operation
100 MERGE (JOIN
23 SORT (JOIN)
23 TABLE ACCESS () OF table_A
150 SORT (JOIN)
150 TABLE ACCESS () OF table_B
En este ejemplo, sólo una fracción pequeña de las filas recuperadas son a las
que se arrojó fuera, así es que tu no puede esperar mejoras significantes de
desempeño para reducir prospectos.
Minimizando Prospectos de Filas

• Comparar índices disponibles con predicados de
join y nonjoin predicates.
• Considerar sugerir para un nested loopen lugar de
operaciones de sort/merge.
Minimice un prospecto de Filas
Comparando índices disponibles con predicados regresados de la tarea de
encontrar el camino óptimo de acceso para un solo acceso de la tabla. En varias
situaciones, el modelo de datos es el centro de un prospecto de problema
desechable. Considere los siguientes dos ejemplos.
N-way Joins
Un join de N-way es una join con más que dos tablas, donde todas las tablas
establecen referencias entre ellas. Si las referencias son semejante en tipo que
el acceso especificado para cualquiera de las tres tablas requiere las llaves
foráneas de ambos de la otras, entonces el join tendrá un prospecto empotrado
de filas. Para mejorar desempeño, cualquier cambio de los datos modelan o
experimentan para encontrar la orden del join con la cantidad mínima de
prospecto.
Predicados erróneos de Join
SQL> select
2 from
3 where a.key1 = b.key1
4 and a.key2 = decode(a.key2, 0, a.key2, b.key2)Una condición errónea
del join sólo habilita el join para usar el primer (limpie) predicado del join para la
operación del join y entonces arrojar fuera los pares de la fila que no satisfacen
el segundo predicado del join.
Para mejorar el desempeño, cambia el segundo predicado para:
4 and (a.key2 = b.key2 OR a.key2 = 0)
Esto no removerá el prospecto de filas, solamente lo deberás limitar
significativamente.
108
Minimizando el Procesamiento
• Cambiando joins nested loops en joins sort/merge
puedes hacer lo siguiente:
− Remover acceso de índice
− Agregar sort overhead
• Teóricamente, joins hash son la operación de join
mas eficiente.
• Join Cluster necesitan menos I/O que el que necesita
el join nested loops
Minimizando el procesamiento.
Cambiando los joins nested loops en joins sort/merge pueden remover el acceso
al índice pero podrían agregar un sorteo significante.
Las joins de hash requieren menos procesamiento que la misma operación del
sort/merge; Los joins de hash son teóricamente el algoritmo más rápido para
unir tablas. Sin embargo, necesitan asignar una buena afinación.
Las joins de cluster necesitan menos I/O que los nested loops, porque las filas
hijo que forman parte de fila padre son guardadas conjuntamente en el mismo
bloque lógico del cluster.
Resumen
Esta lección te presentó el Top-N SQL, clasificación de desempeño, con sorteo
y cómo optimizar declaraciones de joins.
Hay varias operaciones diferentes del join que Oracle8i soporta:
• Nested loops joins
• Sort/merge join
• Hash join
• Cluster join
El optimizador de Oracle8i optimiza joins de tres fases. Primero, el optimizador
genera una lista de todo los joins posible de orden. Entonces, para cada orden
posible del join, la mejor operación del join es seleccionada. Finalmente, el
optimizador de Oracle8i determina el mejor camino de acceso para cada fuente
de la fila del plan de ejecución. RBO difiere de CBO. Especificar un hint fuerza al
CBO a ser usado.
El prospecto de filas ocurre cuando ambos introducen fuentes de fila que tienen
más filas que el resultado de la operación del join. Minimizando prospecto de
filas y mejorar desempeño.
109
10. Plan de Estabilidad del Optimizador
Objetivos
Después de completar esta lección, tu podrás hacer lo siguiente:
• Identificar el propósito y los beneficios de plan estabilidad
• Crear outlines almacenados
• Usar outlines almacenados
• Mantener outlines almacenados
Plan de Estabilidad del Optimizador

• Habilitar aplicaciones wel-tuned para forrar el uso
deseado de la ruta de acceso de SQL
• Mantener consistentes planes de ejecución a través de
cambios en la base de datos
• Si implemented using stored outlines consisting of hints
• Almacenar grupos deoutlines en categorías
Plan de estabilidad de optimizador.
Para cada consulta, el optimizador prepara un árbol de operaciones llamado un
plan de ejecución que define la orden y los procedimientos de los que el servidor
de Oracle sigue para ejecutar una consulta.
Porque el optimizador puede tener información incompleta, algunas veces el
mejor plan posible no está seleccionado. En estos casos, tu puedes encontrar
esto valido para influenciar el plan del optimizador para reescribir la declaración
de SQL, para usar hints o para usar otras técnicas de afinación.
Una vez satisfecho, tu puedes tener el deseo de asegurar que de la misma
forma plan afinado será generado cuandoquiera que la misma consulta es
recompilada, incluso cuando los factores que afectan la optimización pueden
tener cambiado.
Oracle8i te provee de una manera de planes equilibrantes de ejecución a través
de las diferentes versiones, cambios de base de datos, u otros factores que
podrían causar un plan de ejecución para cambiar. Tu puede crear un outline
almacenado conteniendo un set de hints usados por el optimizador para crear un
plan de ejecución.
Los outlines almacenados pueden ser agrupados en categorías nombradas. Las
categorías diferentes son útiles para crear grupos de caminos de ejecución para
situaciones diferentes. La misma declaración de SQL puede tener un outline
almacenado en más que una categoría. Por ejemplo, tu puede querer tener una
categoría OLTP y una categoría DSS.
110
Plan Equivalencia
• El texto de declaración SQL debe equivaler
• Los planes deben mantenerse a través de:
− Nuevas versiones de Oracle
− Nuevas estadísticas sobre objetos
− Initialization parameter changes
− Reorganización de base de datos
− Cambios en el esquema
• Plan equivalencia puede controlar planes de
ejecución para aplicaciones de terceros
Equivalencia de declaraciones de SQL
El plan de estabilidad confía en texto exacto de consultas, cuando determinas
que consulta tiene un outline almacenado. Esto es el mismo criterio usado para
determinar si un plan de ejecución en la shared pool puede ser rehusado.
Los outlines almacenados confían parcialmente en hints que el optimizador suele
lograr planes estables de ejecución. Por consiguiente, el grado para el cual los
restos de plan equivalente depende de las capacidades de los hints que uso el
plan. Los pasos de ejecución incluidos en un outline almacenado incluyen
métodos de acceso de la fila, join order, métodos de join se unen a los accesos
distribuidos, y anexándose view/subquery . El acceso distribuido no incluye el
plan de ejecución en el nodo remoto.
El plan Estabilidad
Estos planes son mantenidos a través de muchos tipos de cambios de la base
de datos y de instancias. Por consiguiente, si tu desarrollas aplicaciones para la
distribución masiva, tu puedes usar outlines almacenados para asegurar que
todos sus clientes gane acceso a los mismos planes de ejecución. Por ejemplo,
si el esquema se cambia añadiendo un índice, entonces los planes de ejecución
no cambian. Tu debes generar outlines almacenados nuevos, o debes
deshabilitar la estabilidad de plan, para beneficiarse del índice nuevo.
Creando Outlines Almacenados

• Para todas las declaraciones durante una sesión:
SQL>alter sesión
2 set CREAE_STORED_OUTLINES = TRAIN;
SQL>select;
SQL>select;
• For a specific statement
SQL> create or replace outline CO_CL_JOIN
2 for category TRAIN on
3 select co. Description,
4 from courses co
5 , classes cl
6 where co.crs_id=cl.crs_id
111
Creando Outlines de almacenados
Tu puede crear outlines para una sesión, o tu los puede crear para las
declaraciones específicas de SQL. Los outlines pueden derivar su entrada de
ambos de RBO y CBO. Sin embargo, el optimizador de Oracle8i sólo puede
usar outlines al usar al CBO, porque los outlines confían en hints.
Si tu omite un nombre de categoría cuando creas outlines , entonces serán
metidos en la categoría por DEFAULT.
Parametro CREATE_STORED_OUTLINES
El servidor Oracle crea outlines almacenados, automáticamente cuando tu ajusta
este parámetro para TRUE o para un nombre de categoría. Cuándo el parámetro
es determinado para TRUE, la categoría por default es usada. Cuando el
parámetro es activado, el servidor Oracle crea outlines para todas las
declaraciones ejecutadas de SQL. Tu puede desactivar esto ajustando el
parámetro para FALSE. Cuando tu usas este parámetro, el servidor Oracle
genera los nombres para cada outline almacenado.
Comando CREATE OUTLINE
Tu también puede crear outlines almacenados para las declaraciones
específicas usando el comando CREATE OUTLINE.
Una ventaja de usar esta orden es que tu puede nombrar los outlines
almacenados. En el ejemplo, el comando CREATE OUTLINE asigna el nombre
co_cl_join para guardar el outline.
Usando Outlines Almacenados

• Poner USE_STORED_OUTLINES en TRUE o el
nombre de categoría
SQL>alter sesión
2 set USE_STORED_OUTLINES=train;
SQL> select
• Puedes poner CREATE_STORED_OUTLINES y
USE_STORED_OUTLINES en dos niveles:
− ALTER SYSTEM
− ALTER SESSION
Usando Outlines Almacenados
Para usar un outline almacenado para una declaración en particular de SQL:
• USE_STORED_OUTLINES deben ser determinado para TRUE o un nombre
de categoría:
− -Si está colocado para TRUE, entonces los outlines por serán nombrados
en la categoría por default.
− Si está colocado para un nombre de categoría, entonces los outlines de
esa categoría son usados. Si no hay outline correspondiente en esa
categoría, pero hay uno en la categoría por default , entonces ese outline
es usado.
112
• La declaración debe hacer juego con el texto de la declaración en el outline.

Son comparados usando el mismo método para comparando cursores en la
piscina compartida. Esto quiere decir que los hints en el outline deben ser
usados en el texto de declaración a causar un encuentro. Los valores en las
variables de vinculación no necesitan equivaler.
Información de Diccionario de Datos

SQL> select name, CATEGORY, USED
2. , sql_text
3. from USER_OUTLINES;
SQL> select node, hint
2. ,from user_outline_hints
3. where name=;
SQL> select sql_text, outline_category
2. , from V$SQL
3. where ;
Información de diccionario de datos
La información alderredor almacenó outlines pueden ser obtenidos de los _
OUTLINES del USUARIO de vistas de diccionario de datos y _ HINTS del _
OUTLINE del USUARIO. Las descripciones de la columna de estas dos vistas
son:
NAME Nombre del outline
CATEGORY Definición por el usuario de el nombre de la categoría
USED Indicación usada por el outline (USED, UNUSED, or UNDEFINED)
TIMESTAMP Hora de creación del outline
VERSION Versión de Oracle en la cual fue creado el outline
SQL_TEXT Texto SQL de la consulta, incluyendo algunos hints que son parte de la
declaración original
NAME Nombre de loutline
NODE ID de la consulta o subconsulta a la cual se le aplico el hint (la consulta
del nivel alto es etiquetada con 1 y la subconsulta con 2)
JOIN_POS Posición de la tabla en el join (el valor es 0 para todos los hints excepto
los métodos de acceso de hints, el cual identifica una tabla para la cual
el hint y la posición del join es aplicado.)
HINT Texto del hint
Plan de Ejecución Lógico
113
La ejecución Lógica de Plan
Para determinar el plan de ejecución de una declaración de SQL, Oracle8i usa la
siguiente lógica:
• La declaración es comparada con las declaraciones de la shared spool para
pareo del texto y la categoría del outline.
• Si ninguna declaración igual es encontrada, entonces el diccionario de datos
es puesto en duda para un outline que hace juego.
• Si un outline que hace juego es encontrado, entonces Oracle8i integra el
outline en la declaración y crea el plan de ejecución.
• Si ningún outline es encontrado, entonces la declaración es ejecutada usando
métodos normales.
Si un outline especifica el uso de un objeto que no puede ser usado, entonces la
declaración simplemente no usará el hint. Por ejemplo, pone notas a un índice
que ya no existe. Para verificar que un outline almacenado es comenzado a
usarse, el plan de ejecución para una declaración debe ser comparado cuando
este ejecutándose con y sin USE_STORED_OUTLINES..
Manteniendo Outlines Almacenados

• Use OUTLIN_PKG para:
− Bonar outlins sin uso
− Bonar categorías de outlines
− Renombrar a categoría
• Use ALTER OUTLINE para:
− Renombrar un outline
− Reconstruir un outline
− Cambiar la categoría de un outline
• Outlines son guardados en esquema OUTLN.
Mantenimiento de Outlines almacenados
Los procedimientos de uso en el paquete OUTLN_PKG para el manejo de
outlines y sus categorías:
Procedure Description
DROP_UNUSED Borra outlines que no han sido usados desde que fueron
creados
DROP_BY_CAT Borra outlines asignados para un nombre de categoría
especifica.
UPDATE_BY_CAT Reasigna outlines de una categoría a otra
Tu puedes alterar outlines usando el comando ALTER OUTLINE y borrar el
comando DROP OUTLINE..
Tu puedes exportar e importar planes, exportando el esquema OUTLN, dónde
todos los outlines son guardados. Los outlines pueden ser consultados el
esquema OUTLN:
• OL$ contiene el nombre del outline, la categoría, tiempo de creación y texto
de la declaración
• OL$HINT contiene los hints para los outlines en OL$.
114
También, hay vistas equivalentes de diccionario de datos: DBA_OUTLINES y

DBA_OUTLINE_HINTS.
Nota: Porque el usuario OUTLN es automáticamente creado en la creación de la base de
datos con contraseña OUTLN, esta contraseña debería variarse por razones de
seguridad.
Manteniendo Outlines Almacenados
SQL>begin
2. Outln_pkg.droup_unused;
3. Outln_pkg.UPDATE_BY_CAT
4. (DEFAULT , TRAIN);
5. outln_pkg.DROP_BY_CAT (TRAIN);
6. end;
Manteniendo a Outlines Almacenado (continuación)
El procedimiento DROP_UNUSED no acepta argumentos y automáticamente
borra aquellas outlines que no han sido usados desde que se crearon.
El procedimiento UPDATE_BY_CAT del ejemplo mueve todos los outlines de la
categoría por DEFAULT a la categoría del TRAIN. Por ejemplo, este
procedimiento es útil para mover un de un set de outlines a una categoría
experimental (prueba ambiente) en una categoría de producción.
El procedimiento DROP_BY_CAT del ejemplo purga todos los outlines que
forman parte de la categoría del TRAIN en una sola llamada.
Exportando e importando outlines almacenados.
Para exportar e importar el esquema OUTLN, tu puede distribuir outlines para
otras bases de datos, como para todos los departamentos que usan una cierta
aplicación. Este acercamiento asegura consistencia de plan de ejecución en
todos los sitios.
Resumen
Esta lección te presentó el uso de outlines almacenados y su influencia en la
estabilidad de plan del optimizador, y el uso del paquete OUTLN_PKG en
outlines almacenados.
Oracle8i le provee de una manera de planes equilibrantes de ejecución a través
de las versiones de Oracle, cambios en la base de datos, u otros factores que
podrían causar un cambio en un plan de ejecución. Tu puede crear un outline
almacenado conteniendo un set de hints usados por el optimizador para crear un
plan de ejecución.
Los outlines almacenados confían parcialmente en hints que el optimizador suele
lograr planes estables de ejecución. Estos planes son mantenidos a través de
muchos tipos de cambios de la base de datos y instancia. Tu puede usar outlines
almacenados para asegurar que todos los usuarios tengan los mismos planes
de ejecución.
Tu puede crear outlines para una sesión, o tu los puede crear para las
declaraciones específicas de SQL.
115
Para usar outlines almacenados la opción USED_STORED_OUTLINES debe
ser puesta en TRUE o un nombre de categoría. Los procedimientos en el
paquete OUTLN_PKG para el manejo de outlines almacenados y sus categorías.
Hay vistas de diccionario de datos que almacenan información en los outlines.
Practica
En esta práctica, tu deberás crear, usar, y remover outlines almacenados.
Necesitaras alterar su sesión en orden para el outline a ser utilizado. Use las
vistas del diccionarios de datos USER_OUTLINES y USER_OUTLINE_HINTS
para ver el estado de su outline.
Práctica 10
1. El SQL de vuelta * Y AUTOTRACE completamente.
Asegúrese que la columna MGR_ID de la tabla de EMPLEADOS no esta
indexada, entonces cree un outline almacenado para la siguiente declaración
de SQL.
SQL> select e.first_name, e.last_name
2 from employees e
3 where e.mgr_id = 76505;Compruebe la vista del diccionario de datos
USER_OUTLINES para encontrar el nombre del outline y de su categoría
para el outline que creaste.; También, consulte la columna USED para ver
que el outline no está usado todavía.
3. Compruebe la vista del diccionario de datos USER_OUTLINE_HINTS para
ver cuáles hints son almacenados con su outline.
4. Use el comando ALTER SESSION para habilitar la sesión usando outlines
almacenados.
5. Ejecute la declaración de SQL del paso 1; cree un índice para la columna
MGR_ID de los tabla EMPLOYEES, ejecute la declaración de SQL otra vez
para ver si el plan de ejecución ha cambiado.
6. Compruebe la vista de diccionario de datos USER_OUTLINES otra vez para
ver si el outline ha sido usado.
7. Borre el outline, y ejecute la declaración de SQL otra vez, para ver que el
índice ahora será usado.
116
11. Vistas Materializadas y Tablas

Temporales
Objetivos
Al cabo de completar esta lección, tu deberás estar capacitado para:
• Identificar el propósito y las ventajas de las vistas materializadas
• Crear vistas materializada
• Habilitar versiones reescritas de consulta
• Crea dimensiones
• Identificar los beneficios de tablas temporales
Vistas Materializadas
Una vista materializada:
• Es una instanciacion de una declaración de SQL
• Tienen su propio segmento de datos y oferta:
- Opciones de manejo de espacio
- El uso de sus propios índices
• Util para:
- Costos y complejos joins
- Resumen y datos agregados
Materializando Vistas
Una vista materializada almacena ambos tanto la definición de una vista y las
filas, resultando de la ejecución de la vista. Como una vista, usa una consulta
como la base, pero la consulta es ejecutada en el tiempo que la vista es creada,
y los resultados son almacenados en una tabla. Tu puedes definir la tabla con los
mismos parámetros de almacenamiento como cualquier otra tabla y la puedes
meter en el tablespace de su elección. También puedes indexar la tabla
materializada de la vista como otras tablas para mejorar el desempeño de
consultas ejecutadas en contra de ellas.
Cuándo una consulta puede satisfacerse con datos de una vista materializada, el
servidor de Oracle8i transforma la consulta para usar la vista en lugar de las
tablas bases. Usando una vista materializada, operaciones caras como joins y
agregaciones no necesitan ser reejecutadas
117
Creando Vistas Materializadas
SQL>CREATE MATERIALIZED VIEW cls_summ AS
Sellect cl.clas_id, co.short_name
2. , cl.star_date, 1:city
3. , cl.star_count(r.stud_id) as tot_reg
4. from classes cl
5. , courses co
6. , locations 1
7. , registrations r
8. where cl.loc_id =1.loc_id
9. and cl.class_id =r.class_id
10. group by cl.class_id, co.short_name
11. , cl.star_date, 1.city;
Creando Vistas Materializadas
Si una consulta involucra resúmenes grandes o múltiples joins, o ambos. Y son
probablemente para ser usados múltiples veces , puede ser más eficiente crear
una vista materializada para los resultados de consulta. Esto requiere una sola
ejecución de la consulta y el espacio de almacenamiento para preservar los
resultados.
Si las consultas son probablemente rehusadas con el paso del tiempo, entonces
puedes necesitar un mecanismo para actualizar la vista materializada como el
cambio de la tablas bases. El desempeño y los gastos de almacenaje de
manutención que la vista materializada debe ser comparada con los costos de
reejecutar la consulta original cuandoquiera que es necesario.
El proceso de modificar una consulta a usar la vista en vez de la tabla base es
llamado una versión reescrita de consulta.
Actualizando Vistas Materializadas

• Tipos de actualización:
- COMPLETE
- FAST
- FORCE
- NEVER
• Creando logs para vistas materializadas para
actualización FAST
SQL>create materialized view log on
Dependiendo de la actividad en las tablas base y la exactitud de la información
requerida, el actualizar vistas materializadas puede estar hecho
consecuentemente. El mecanismo de actualizar es similar al usado por
snapshots: COMPLETE, FAST, FORCE y NEVER.
Una actualización involucra a truncar datos existentes y volver a insertar todos
los datos reejecutando la definición materializada de consulta de la vista.
118
La actualización FAST sólo ejercen los cambios hechos desde lo última

actualización. Dos tipos están disponibles:
Usando logs de vistas materializadas: En este caso, todos los cambios para las
tablas bases captadas en un log y entonces aplicadas para la vista
materializada.
• Usando rangos de ROWID: Una vista materializada puede ser actualizada
después de carga directa , basada en los ROWIDs de las filas nuevas. Los
logs directos del cargador son requeridos para esta actualización tipo.
No todas las vistas materializadas pueden usar un actualización FAST.
Una vista materializada definida como actualización de tipo FORCE actualiza
con el mecanismo rápido si es posible, o si no los usos completa la actualización
FORCE es la actualización de tipo por default:.
La opción NEVER suprime toda actualización de la vista materializada.
Nota: Los logs materializados de la vista son creados usando CREATE MATERIALIZED
VIEW LOG.
• Actualización Manual
Usando el paquete DBMS_MVIEW
• Actualización Automática
- Synchronous. Commitsobre cambios hechos
para tablas subyacentes-pero independientes
de la transacción hecha commit
- Asynchronaus. Define la actualización de la
vista a intervalos
Actualizando Vistas Materializadas(continuación)
Tan bueno como escoger el tipo de actualización, tu puedes decidir qué modo
usar para conservar vistas materializadas sincronizadas con sus tablas base.
Actualización Manual
La actualización manual es realizada usando el paquete DBMS_MVIEW. El
paquete DBMS_MVIEW provee un número de procedimientos y funciones para
operar vistas materializadas, incluyendo los procedimientos REFRESH,
REFRESH_DEPENDENT, y REFRESH_ALL_MVIEWS.
Actualización automática
La actualización automática puede ser realizado:
ON COMMIT: Cuándo esta opción está especificada para una vista
materializada, será actualizada cuando una de las tablas base sea
grabada(commit).
En un el tiempo especificado: Actualizar una vista materializada puede ser
programado para ocurrir en un el tiempo especificado. Por ejemplo, puede ser
actualización cada lunes en 9:00 a.m. usando las cláusulas START, WITH y
NEXT.
119
Vistas Materializadas: Actualización Manual
• Especificar vistas materializadas
DBMS_MVIEW.REFRESH
( SF_CLASSES , PARALLELISM =>10);
• Vistas materializadas basadas en una o mas
tablas
DBMS_MVIEW.REFRESH DEPENDENT
(CLASSES );
• Todas las vistas materializadas a actualizar
DBMS_MVIEW.REFRESH ALL_MVIEWS;
Actualización Manual
La siguiente es una lista de posibles escenarios de actualizaciones para vistas
materializadas:
• Actualice vistas materializadas específicas usando el procedimiento
REFRESH
• Actualice todas las vistas materializadas que dependen de un set dado de
tablas base usando el procedimiento REFRESH_DEPENDENT.
• Actualice todas las vistas materializadas que no hayan sido desde que la
última carga, para una o más tablas detalle usando el procedimiento
REFRESH_ALL_VIES.
• Los procedimientos en el paquete usan un número de parámetros para
especificar lo siguiente:
• Actualizar método
• Proceder si un error es encontrado
• Si para usar una sola transacción (coherente refresque)
• El segmento de rollback para usar
Necesitas colas de trabajo del servidor para correr la actualización de trabajo.
Por consiguiente los parámetros apropiados de inicialización,
JOB_QUEUE_PROCESES y JOB_QUEUE_INTERVAL, deben ser determinados
al habilitar la cola de trabajo para actualizar procesos.
Consultas Reescritas
• Para usar vistas materializadas en vez de tablas
base, la consulta debe ser reescrita.
• Las consultas reescritas son transparentes a las
aplicaciones.
• Las consultas reescritas no requieren especiales
privilegios sobre las vistas materializadas
• Una vista materializada puede ser habilitada o
deshabilitada para consultas reescritas.
Porque ganar acceso a una vista materializada puede ser significativamente más
rápido que ganar acceso a las tablas base subyacentes, el optimizador reescribe
una consulta para ganar acceso a la vista cuando la consulta la permite. La
120
actividad de la versión reescrita de consulta es transparente para las

aplicaciones. A este respecto, su uso es similar al uso de un índice.
Los usuarios no necesitan privilegios explícitos en vistas materializadas para
usarlos. Las consultas ejecutadas por cualquier usuario con privilegios en las
tablas subyacentes pueden ser reescritas para ganar acceso a la vista
materializada.
Una vista materializada puede ser habilitada o deshabilitada. Un punto de vista
materializado que es habilitada está disponible para la consultas reescritas.
Consultas reescritas.
El optimizador reescribe consultas en el orden para
utilizar vistas materializadas:
• El privilegio QUERRY REWRITE permite a los
usuarios habilitar vistas materializadas.
• El parque DBMS_OLAP tiene opciones para usar
vistas materializadas.
Consultas Reescritas(continuación)
Para habilitar o deshabilitar vistas materializadas para un a consulta reescribible
debes tener privilegios de sistema de GLOBAL QUERY REWRITE o QUERY
REWRITE. Ambas versiones de privilegio permiten habilitar vistas
materializadas en tu esquema. La versión GLOBAL le permite habilitar cualquier
vista materializadas de su propiedad, mientras que el simple privilegio QUERY
REWRITE requiere que las tablas bases así como también las vistas estén en
su esquema.
El paquete DBMS_OLAP paquete provee una colección de análisis de vistas
materializadas y funciones de aviso.
• Use EXPLAON PLAN O AUTOTRACE Para
verificar que consultas reescritas ocurren:
- Pocos bloques son accesados
- La respuesta en tiempo debe ser mejor
Consultas Reescritas(continuación).
El mejor método para detectar si ocurren consultas reescritas es usando el
comando EXPLAIN_PLAN o el AUTOTRACE. Deberías de notar el tiempo de
respuesta mejorado si una vista materializada es usada por el optimizer.
Creando vistas materializadas Opciones de
sintaxis
CREATE MATERIALIZES VIEW mview_name
[TABLESPACE ts_name]
[PARALLEL {DEGREE n}]
[BUILD {INMEDIATE|DEFERRED}]
[REFRESH {FAT| COMPLETE|FORCE
|NEVER|ON COMMIT}]
[{ENABLE| DISABLE} QUERY REWEITE]
AS SELECATFROM
121
Creando Vistas Materializadas: Opciones de Sintaxis
La sintaxis CREATE MATERIALIZED VIEW es similar al comando CREATE
SNAPSHOT , cuál reemplaza. Hay algunas opciones adicionales:
• La opción BUILD IMMEDIATE causan que la vista materializada a ser
pobladas cuando el comando CREATE es ejecutado. Éste es el
comportamiento predeterminado. Tu puedes escoger la opción BUILD
DEFERRED, la cual crea la estructura pero no puebla ella hasta que la
primera actualización ocurra.
• En lugar de la opción de BUILD, también puedes especificar ON PREBUIL
TABLE cuándo tu quieras una tabla sumaria existente para ser la fuente de
una vista materializada.
• La cláusula ENABLE/DISABLE QUERY REWRITE determina si las versiones
reescritas de consulta son automáticamente habilitadas para la vista
materializada.
Nota: Las opciones predeterminadas en la sintaxis son subrayadas.
Habilitando y Controlando Consultas Reescritas

• Query rewrites ad only availabel with cost.based
optimization.
QUERY_RERITE_ENABLES = {true|false}
QUERY_REWRITE_INTEGRITY =
{enforced|trusted|stale_tolerated}
• Optimizer hints to influence query rewrites are
REWRITE and NOREWRITE
Habilitando y deshabilitando consultas reescritas
OPTIMIZER_MODE: Las versiones reescritas de consulta están sólo disponibles
bajo la optimización basada en costos.
QUERY_REWRITE_ENABLED: Este parámetro puede ser determinado en
FALSE para suprimir consultas reescritas. Éste es un parámetro dinámico de
instance/sesión.
QUERY_REWRITE_INTEGRITY: Éste es también es un parámetro dinámico del
instance/sesión. Acepta los siguientes valores:
• ENFORCED(el default) habilita versiones reescritas de consulta únicas si el
optimizador puede garantizar consistencia. Sólo las vistas materializadas
actualizadas y las posibilitadas restricciones validadas sirven para versiones
reescritas de consulta.
• TRUSTED permite consultas reescritas basadas en lo relaciones declaradas
(no necesariamente obligadas). Todas las actualizaciones de vistas
materializadas, dimensiones y restricciones con la bandera RELY sirven para
consultas reescritas.
• STALED_TOLERADE aloja consultas reescritas para usar vistas
materializadas que no han sido actualizadas desde la última operación de
DML y relaciones que han sido declaradas.
122
Nota: No hay privilegios del objeto asociados con versiones reescritas de consulta. Los
usuarios con acceso a las tablas base implícitamente benefician a consultas reescritas.
Tu puede usar el hint REWRITE para restringir los puntos de vista
materializados que se consideran para versiones reescritas de consulta. El hint
NOREWRITE está disponible para suprimir consultas reescritas.
Ejemplo de Consultas Reescritas

SQL> expalin plan for
2. Select cl.class_id, co.short_name
3. From classes cl
4. , courses co
5. , locatios 1
6. where cl.loc_id =1.loc_id
7. and cl.crs_id =co.crs_id
8. group by;
OPERATION NAME
SELECT STATEMENT
TABLE ACCESS FULL CLS_SUMM
El ejemplo de consulta reescritas
El plan de ejecución muestra que la vista materializada es accesada en lugar del
join de la 4 tablas base para producir el resultado.
Un hint REWRITE/NOREWRITE pasa sobre la definición de la vista
materializada, colocado el comando CREATE o ALTER MATERIALIZED VIEW
con la cláusula ENABLED QUERY REWRITE.
Este ejemplo muestra una versión reescrita transparente de consulta donde la
consulta exactamente hace juego con la definición materializada de la vista. La
siguiente página demuestra un ejemplo de una consulta que no hace juego con
la definición materializada de la vista.
Ejemplo De consultas Reescritas
123
El ejemplo de consulta reescrita(Continuación)
El optimizador puede usar la vista materializada creada recientemente para
satisfacer la consulta.
Nota: Esta consulta exactamente no hace juego con la definición materializada de la
vista. Tu le tendras que agregar un predicado de nonjoin en la línea 8 y una cláusula
HAVING en la última línea. El predicado nonjoin es asociado dentro del la consulta
reescrita en contra de la vista materializada y la cláusula HAVING es traducida a un
segundo componente de la cláusula WHERE.
Dimensiones: Visión General

• Las dimensiones con estructuras del
diccionario de datos que definen jerarquías
basadas en columnas existentes.
• Dimensiones son opcionales pero
recomendadas por que ellos:
- Habilitan adicionales consultas reescritas
sin usar restricciones
- Puede ser usados por herramientas OLAP
Las dimensiones
Las dimensiones son estructuras de diccionario de datos que definen jerarquías
basadas en columnas en las tablas existentes de la base de datos. Aunque son
optativos, son recomendados porque ellos:
• habilite posibilidades adicionales reescritura sin el uso de restricciones (la
Implementación de restricciones no puede gustar en un almacén de datos
para las razones de desempeño).
• Las dimensiones del documento de ayuda y las jerarquías explícitamente.
• Puede ser usados por herramientas OLAP.
Dimensiones y Jerarquías
124
Dimensiones y Jerarquías.
Las dimensiones describen a las entidades comerciales como productos,
departamentos, y tiempo en una jerárquica, clasificada en categorías. Una
dimensión puede constar de uno o más jerarquías. En el ejemplo demostrado, la
dimensión de tiempo consta de tres jerarquías.
Cada jerarquía comprende niveles múltiples. Cada valor en un nivel inferior en la
jerarquía es el hijo de uno de un solo padre en el siguiente nivel más alto. Una
jerarquía consta de relaciones 1 a n relaciones entre los niveles, con el nivel
del padre representa un nivel de agregación del nivel del hijo. En el ejemplo, la
jerarquía del CALENDAR_ROLLUP consta de la fecha de venta, mes, cuarto, y
el año.
Un nivel en la jerarquía tiene un nivel llave que puede identificar uno o más
atributos dimensionales. En el ejemplo, el mes es un nivel donde el MONTH
crucial nivelado identifica el atributo MONTH_NAME.
Puedes usar llaves niveladas y estas relacionar nombres de forma
intercambiable en una consulta.
Dimensiones: Tabla Ejemplo

SQL>select * from time;
SDATE MONTH MONT_NAME QUARTER YEAR

01-JAN-98 1 JANUARY 1 1998
02-JAN-98 1 JANUARY 1 1998
03-JAN-98 1 JANUARY 1 1998
04-JAN-98 1 JANUARY 1 1998

30-DEC-98 12December 4 1998
31-DEC-98 12December 4 1998
Las dimensiones: Ejemplo tabla
Tu tiene una tabla TIME conteniendo información de tiempo en varias columnas
separadas (fecha, nombre de mes, cuarto y año.)
En las siguientes dos páginas tu crearás una dimensión TIME_DIM sobre la
tabla.
Tabla TIME dimensión TIME_DIM
Las dimensiones pueden basarse en columnas en una sola tabla, como se
muestra en este primer ejemplo.
125
Cuando creas dimensiones, debes definir y nombrar niveles de jerarquía
basados en el nombre de las columnas de tabla TIME.
En este caso, la dimensión TIME_DIM tiene 4 niveles:
El nivel más alto en la jerarquía consiste en la columna YEAR.
El siguiente nivel es derivado de la columna QUARTER.
El tercer nivel tiene la columna de MONTH como la llave y MONTH_NAME como
un atributo. Note que para cada valor de MONTH mapea un solo valor
MONTH_NAME y viceversa.
El nivel mas bajo se basa en la columna SDATE.
Creando Dimensiones y Jerarquías
Definiendo Dimensiones y Jerarquías

Las relaciones jerárquicas pueden ser declaradas entre dos columnas en una
dimensión de tabla, o entre dos columnas de tablas diferentes en caso de
esquemas normalizados o para soportar tales versiones reescritas. Un tipo
nuevo del objeto de esquema, una dimensión, es provisto para este propósito.
La relación de padre-hijo a lo largo de una dimensión es más fuerte que
integridad de referencia sola porque esto requiere que la llave del hijo sea
obligatoria (esto es, definido como NOT NULL).
El creador de una dimensión debe asegurar (opcionalmente, con restricciones de
la base de datos en caso de una dimensión normalizada) que las columnas de
cada nivel de jerarquía sean NOT NULL y esa integridad jerárquica es
mantenida.
Note que la llave y atributos para un nivel dado debe estar basada en columnas
de la misma tabla.
El ejemplo demuestra una sola jerarquía dentro de la dimensión de tiempo, pero
es posible tener jerarquías múltiples. Por ejemplo, otra jerarquía puede ser
creada para ligar fecha de ventas con la semana o la estación.
Un privilegio nuevo de sistema, CREATE DIMENSIÓN, está obligado a crear una
dimensión en su esquema basado en tablas que están dentro del mismo
esquema. Otro privilegio nuevo, CREATE ANY, le faculta a crear dimensiones en
cualquier esquema.
En el ejemplo mostrado, la dimensión es basado en la tabla TIME.
126
Dimensiones Basadas en Múltiples Tablas

• Ejemplo: dimensión GOEGRAPHY basado en las
tablas CITY, STATE, y REGION
• Defina restricciones de llave foránea en la tabla
hijo para mantener una dimensión valida
• Todos los atributos y llaves para un nivel deben
pertenecer a la misma tabla
Dimensiones Basadas en Múltiples Tablas
Una dimensión puede usar columnas de varias tablas. Por ejemplo, una
dimensión de GEOGRAPHY puede usar las siguientes tablas y las columnas:
• La tabla de CITY contiene las columnas CITY_NAME, OFFICE_ARDES,
POPULATION y STATE_CODE
• La tabla STATE tiene las columnas STATE_CODE, STATE_NAME, y
REGION_ID
• La tabla de la REGIÓN comprende de REGION_ID, REGION_NAME, y
COUNTRY.
En este caso, las restricciones de llave foránea deberían estar definidas en una
tabla hijo para referenciar a la llave primaria de la tabla del padre. Un ejemplo
puede ser CITY.STATE_CODE referencia a STATE.STATE_CODE. Esto ayuda
a mantener validez de dimensión.
Note que todas las columnas para un nivel dado se guardan en la misma tabla.
Dimensiones con Múltiples Jerarquías
Dimensiones con Múltiples Jerarquías

El par de jerarquías mostrados arriba puede ser creado dentro de una sola
dimensión. Debajo es la declaración para hacer esto:
CREATE DIMENSION time_dim
LEVEL dt IS time.time_id
LEVEL wk IS time.time_week
LEVEL month IS time.month
127
LEVEL qtr IS time.quarter
LEVEL yr IS time.year
HIERARCHY cal
dt CHILD OF
Mon CHILD OD
Qtr CHILD OF yr )
HIERARCHY week
(dt CHILD OF
Wk CHILD OF yr);
Tablas Temporales
• Tablas temporales retiene datos durante de una
transacción o sesión
• Las definiciones persisten en el diccionario de
datos
• Los datos son visibles solo para la sesión
• Tablas temporales:
- Usan espacio en memoria
- Asignan extents temporales, si es necesario
Tablas Temporales
El Oracle8i Server faculta a crear tablas temporales. Las tablas temporales
pueden mejorar desempeño significativamente para soportar datos temporales
para el aprovechamiento dentro de una transacción o la sesión.
Una tabla temporal tiene las siguientes propiedades:
• Los datos temporales de la tabla son sólo visibles dentro de su alcance
definido; El alcance puede estar definido para una sesión o una transacción.
• La definición de una tabla temporal global es visible para todas las sesiones.
En el contraste, la definición de una tabla temporal local no persiste al final de
la sesión que la crea.
Nota: El Oracle8i Server actualmente no soporta tablas temporales locales.
- Los datos temporales de la tabla son almacenados dentro espacio usado por
la sesión. Si el espacio de tipo no es suficiente para acomodar los datos,
entonces el espacio es ubicado en el tablespace temporal del usuario.
- Los índices en tablas temporales tienen el mismo alcance y la duración como
la tabla de la que ellos son propios.
- Los triggers y las vistas pueden estar definidos en tablas temporales. Sin
embargo, una vista no puede estar definida asociándose una temporal y una
tabla permanente.
- Los comandos CRETE GLOBAL TEMPORARY TABLE AS SELECT usarse
para crear una tabla temporal e insertar datos dentro de unos datos de la
tabla temporal y del inserto en ella.
Las definiciones de tablas temporales pueden ser exportadas e importadas
128
SQL> select table_name, temporary, duration

2 from dba_tables
3 where table_name = 'EMP_TEMP';
TABLE_NAME TEMPORARY DURATION

----------------- --------- ---------------
EMP_TEMP Y SYS$TRANSACTION
Creando Tablas Temporales

SQL>CREATE GLOBAL TEMPORARY TABLE
emp_temp
2. ( emp_id number(7)
3. , last_name varchar2 (24)
4. , salary number (7,2) )
5. ON COHIT DELETE ROWS;
SQL> select table_name, temprary, duration
2. From dba_tables
3. Quhere table_name = EMP_TEMP;
TABLE_NAME TEMPORARY DURATION
EMP_TEMP Y SYS$TRANSACTION
Creando Tablas Temporales
El ejemplo muestra el comando para crear una tabla temporal donde las filas son
sólo visibles dentro de la transacción que las creo.
Las cláusulas que controlan la duración de las filas son:
• ON COMMIT DELETE ROWS para especificar que las filas son sólo visibles
dentro de la transacción (Éste es el comportamiento predeterminado).
• ON COMMIT PRESERVE ROWS para especificar que las filas son visibles
para la sesión entera.
Aunque la orden no crea extensiones para la tabla, una sesión puede consultar
la tabla sin recibir un error.
La vista DBA_TABLES contiene columnas para señalar que la tabla es una tabla
temporal. La columna DURATION muestra los datos en la tabla para una sesión
entera o sólo dentro de la transacción.
Resumen
Esta lección presentó las versiones reescritas de vistas materializadas, de
consulta, las dimensiones y las jerarquías, y las tablas temporales:
• Una vista materializada almacena ambos la definición de una vista y las filas
resultando de la ejecución de la vista. Como una vista, usa una consulta
como la base, pero la consulta es ejecutada en el tiempo que la vista es
creada, y los resultados son almacenados en una tabla.
129
• Ya que ganar acceso a una vista materializada puede ser significativamente
más rápido el acceso a las tablas base subyacentes, el optimizador reescribe
una consulta para ganar acceso a la vista cuando la consulta la permite. La
actividad de consulta reescrita es transparente para las aplicaciones.
• Las dimensiones son estructuras de diccionario de datos que definen
jerarquías basadas en columnas de las tablas existentes de la base de datos.
Las dimensiones describen a las entidades comerciales como productos,
departamentos, y tiempo en una jerárquia, clasificada en categorías. Una
dimensión puede constar de uno o más jerarquías. Cada jerarquía
comprende niveles múltiples.
• El servidor de Oracle8i habilita a crear tablas temporales. Las tablas
temporales pueden mejorar el desempeño significativamente para datos
temporales y aprovecharlo dentro de su transacción o sesión.
130
Soluciones
Capitulo 2.
1.
show arraysize
2.
column sql_text format a50
select cls_status, description
from cls_statuses
/
select sql_text, sorts
from v$sqlarea
where command_type = 3
and lower(sql_text) like '%cls_statuses%'
/
3.
select cls_status, description
from cls_statuses
order by cls_status
/
from v$sqlarea
where command_type = 3
/
4.
insert into cls_statuses
values('HOLD', 'Class on hold')
/
from v$sqlarea
where command_type in (2, 3)
/
rollback
/
5.
select gethitratio, pinhitratio
from v$librarycache
where namespace = 'SQL AREA'
131
Capitulo 3.
1.
describe plan_table
create table PLAN_TABLE (

statement_id varchar2(30),
timestamp date,
remarks varchar2(80),
operation varchar2(30),
options varchar2(30),
object_node varchar2(128),
object_owner varchar2(30),
object_name varchar2(30),
object_instance numeric,
object_type varchar2(30),
optimizer varchar2(255),
search_columns number,
id numeric,
parent_id numeric,
position numeric,
cost numeric,
cardinality numeric,
bytes numeric,
other_tag varchar2(255),
partition_start varchar2(255),
partition_stop varchar2(255),
partition_id numeric,
other long,
distribution varchar2(30))
/
desc plan_table
2.
explain plan for
select first_name, last_name
from employees
where emp_id = 6191
/
select *
from plan_table
/
select lpad(' ',2*(level-1))
||operation ||' '
||options ||' '
||object_name||' '
132
||decode(id,0,'Cost = '||position) as "Query Plan"

from plan_table
start with id = 0
connect by prior id = parent_id
/
delete from plan_table
/
3.
select *
from plan_table
/
start rp
/
4.
set autotrace traceonly explain
from employees
where emp_id = 6191
/
5.
set autotrace traceonly
from employees
where emp_id = 6191
/
Capitulo 4
1.
column name format a30
column value format a30
select name, value
from v$parameter
where name in
('timed_statistics', 'max_dump_file_size',
'user_dump_dest', 'sql_trace')
/
alter session set timed_statistics = true
/
alter session set sql_trace = true
/
2.
from employees
where emp_id = 6191
133
/
3.
alter session set sql_trace = false
/
alter session set timed_statistics = false
/
Capitulo 5.
1.
alter session set optimizer_mode = RULE
/
2.
select e.last_name
, e.first_name
, r.status
from employees e
, registrations r
where e.emp_id = r.stud_id
and r.class_id = 55999
/
3.
select *
from cls_statuses
where cls_status = 'BOOK'
/
4.
alter session set optimizer_mode = CHOOSE
/
5.
select e.last_name
, e.first_name
, r.status
from employees e
, registrations r
where e.emp_id = r.stud_id
and r.class_id = 55999
/
134
Capitulo 7.
1.
col low_value format a15
col high_value format a15
analyze table registrations
compute statistics
/
select num_rows, blocks, empty_blocks
, avg_space, avg_row_len
from user_tables
where table_name = 'REGISTRATIONS'
/
select column_name, num_distinct
, low_value, high_value
, num_nulls
from user_tab_col_statistics
/
2.
select count(*), status
from registrations
group by status
/
3.
analyze table registrations compute statistics
for columns status size 20
/
select endpoint_number, endpoint_value
from user_histograms
and column_name = 'STATUS'
/
4.
select * from registrations
where status = 'CANC'
/
5.
select table_name, sample_size, last_analyzed
from user_tables
/
6.
analyze table registrations delete statistics
/
select table_name, sample_size, last_analyzed
from user_tables
/
135
Capitulo 8.
1.
analyze table categories delete statistics
/
2.
select *
from categories
/
3.
alter session set optimizer_mode = CHOOSE
/
4.
select *
from categories
where cat_id > 30
/
6.
select /*+ FULL(c) */
*
from categories c
where cat_id > 30
/
136

Taller de Afinacion de Sentencias SQL

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Taller de Afinacion de Sentencias SQL

Cargado por

Copyright:

Formatos disponibles

Manual para el participante

1. SIGUIENDO UNA METODOLOGÍA DE AFINACIÓN...................................................................... 7

EJEMPLO DE SALIDA TKPROF: UNIQUE INDEX ........................................................................................42

PLAN DE EJECUCIÓN LÓGICO ...................................................................................................................113

1. Siguiendo una Metodología de Afinación

Manejo del Rendimiento

Los Factores a Ser Manejados

El tiempo de respuesta aumentado

Afinando Declaraciones de SQL

Afinando estatutos de SQL

2. Procesando Sentencias de SQL

Fases del Procesamiento

Compartiendo Cursores: Requerimientos

Escribiendo Cursores Compartidos

Variables Bind y Cursores Compartidos

Escribiendo Cursos Compartidos

Monitoreando Cursos Compartidos

Puedes monitorear tu sistema para ver cada cuánto el servidor no puede

Monitoreando el uso de Cursores Compartidos

Version invalid par

Monitoreando el uso de cursores compartidos

Creando el Plan Table

Crear tu propia PLAN_TABLE con un nombre diferente.

El Comando EXPLAIN PLAN

El comando EXPLAIN PLAN

Ejemplo de EXPALON PLAN

CARDINALITY Basado el optimizador en costos la estimación del número de

Interpretando el Plan de Ejecución

SQL*Plus Autotrace Ejemplos

ADMINISTRADOR DE BASE DE DATOS debe poner a funcionar el escrito como

SQL *Plus Autotrace Estadísticas

4 SQL trace y TKPROF

Facilidad de SQL Trace

La Facilidad de SQL Trace

Cómo Usar el SQL Trace

siguiente parámetro de iniciación en el archivo de parámetro antes de

Conectando Trace de SQL para un Instancia

Encontrando los Archivos de Trace

Encontrando Archivos de trace

Formateando Archivos de Trace

Opciones del Comando TKPROF

Opciones del comando TKPROF

Salida del comando TKPROF

La Salida del Comando TKPROF

Salida del comando TKPROF

Ejemplo de Salida TKPROF: No Index

Ejemplo de Salida TKPROF: Unique Index

5 Optimización Basada en Reglas Contra

Las Funciones del Optimizador Oracle8i.

La Optimización Basada en Reglas

Nota: Al las herramientas diagnósticas utilizadoras les gusten EXPLIQUE y SQL * Y

Optimización Basada en Costos

Colocando el Acercamiento del Optimizador

Optimización Basada en Reglas

Ejemplo de Optimización Basado en Reglas.

El rango mínimo es 9, así es que el índice en el TRABAJO se usará para ganar

Influenciando Optimización Basada en Reglas

6 Índices y Métodos de Acceso Básico

Una Descripción de Índices B*tree

Estructura de Índice B*_Tree

Ejemplo Índice B*_Tree

Ejemplo del Índice B*tree

Sintaxis Para La Creación De Un Indice.

El Efecto De Operaciones DML Sobre Índices

SQL> select /+LEADING (T1) /

SQL> select /+STAR /

SQL> select /+DRIVING_SITE (T1) /