Afinamiento 23

Unauthorized reproduction or distribution prohibitedฺ Copyright 2012, Oracle and/or its affiliatesฺ
L A
D E
D OS
Oracle Database 11g: SA Ajuste de
Rendimiento GR yฺ E
E E onl
VolumenN
D se
I • Guía deluAlumno
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
c le U UN
Ora
D50317CS20
Edición 2.0
Junio de 2010
D73949
Autor Copyright © 2010, Oracle y/o sus filiales. Todos los derechos reservados.
James Spiller Renuncia
Este documento contiene información propiedad de Oracle Corporation y se

Colaboradores y encuentra protegido por las leyes de copyright, así como por otras leyes de
y Revisores Técnicos propiedad intelectual. El usuario podrá realizar copias o imprimir este documento
para su uso exclusivo en los cursos de formación de Oracle. Este documento no
John Beresniewicz podrá ser modificado ni alterado en modo alguno. Salvo que la legislación de los
derechos de autor lo considere un uso excusable o legal o "fair use", no podrá
Yanti Chang utilizar, compartir, descargar, cargar, copiar, imprimir, mostrar, representar,
Kurt Engeleiter reproducir, publicar, conceder licencias, enviar, transmitir ni distribuir este documento
total ni parcialmente sin autorización expresa por parte de Oracle.
Gerlinde Frenzen
Joel Goodman La información contenida en este documento está sujeta a cambio sin previo aviso.
Si detecta cualquier problema en el documento, le agradeceremos que nos lo
Martin Jensen comunique por escrito a: Oracle University, 500 Oracle Parkway, Redwood Shores,
California 94065 USA. Oracle Corporation no garantiza que este documento esté
Pete Jones exento de errores.
Sean Kim
Aviso sobre Restricción de Derechos
Roderick Manalac
Wayne Reeser Si esta documentación se entrega al Gobierno de los EE.UU. o a cualquier entidad
Branislav Valny
que la utilice en nombre del Gobierno de los EE.UU., se aplicará la siguiente
advertencia: L A
Sergiusz Wolicki D E
U.S. GOVERNMENT RIGHTS S
A DO
The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or
disclose these training materials are restricted by the terms of the applicable Oracle
Redactores R ES
license agreement and/or the applicable U.S. Government contract.
Aju Kumar E
Aviso de Marca Registrada G nlyฺ
Raj Kumar
N DE use o
Oracle and Java son marcas comerciales registradas de Oracle y/o sus filiales. Todos
Vijayalakshmi Narasimhan
C IO AL
los demás nombres pueden ser marcas comerciales de sus respectivos propietarios.
D A RIT
Diseñador Gráfico
F UN DIST
Satish Bettegowda
a nd AD
r s ity RSID
Editores
n i ve IVE
Syed Ali U
c l e UN
a
Shaik Mahaboob
OrMichael
Basha
Sebastian
Contenido
1 Introducción
Objetivos del Curso 1-2
Organización 1-3
Agenda 1-4
No se Incluye 1-6
¿Quién se Encarga del Ajuste? 1-7
¿Qué Ajusta el DBA? 1-8
¿Cómo se Ajusta? 1-10
Metodología de Ajuste 1-11
Objetivos de Ajuste Efectivos 1-13
Sesión de Ajuste General 1-15 LA
Prueba 1-17 D E
S
Resumen 1-18
A DO
R ES
2 Diagnósticos de Ajuste Básicos
E G nlyฺ
Objetivos 2-2
N DE use o
Diagnósticos de Ajuste de Rendimiento O 2-3
C I 2-5ITA
L
A
Herramientas de Ajuste del Rendimiento
D TR
Objetivos de Ajuste 2-7 UN
F D IS
a d
Eventos de Tiempo Principales
nDatos A D 2-8
y
sitde Ajuste
Tiempo de Base de D
SdeI Tiempo de CPU y de Espera 2-10
2-9
e r
Dimensiones R
U
Modelo IVE Visión General 2-11
niv deNTiempo:
c le U
Jerarquía de las Estadísticas de Modelo de Tiempo 2-12
Ora Ejemplo de Modelo de Tiempo 2-14
Prueba 2-15
Vistas de Rendimiento Dinámico 2-16
Vistas de Rendimiento Dinámico: Ejemplos de Uso 2-17
Vistas de Rendimiento Dinámico: Consideraciones 2-18
Niveles de Estadísticas 2-19
Estadísticas de Actividad de la Instancia y Eventos de Espera 2-21
Clases de Estadísticas del Sistema 2-23
Visualización de Estadísticas 2-24
Visualización de Estadísticas de SGA 2-26
Eventos de Espera 2-27
Uso de la Vista V$EVENT_NAME 2-28
Clases de Espera 2-29
iii
Visualización de Estadísticas de Eventos de Espera 2-30
Eventos de Espera Más Comunes 2-32
Uso de la Vista V$SESSION_WAIT 2-33
Precisión de las Estadísticas del Sistema 2-35
Prueba 2-36
Uso de las Funciones de los Paquetes 2-37

Acceso a la Página Inicial de la Base de Datos 2-39
Información de Rendimiento en la Página Inicial de la Base de Datos 2-40
Visualización del Log de Alertas 2-42
Uso de la Información del Log de Alertas para Facilitar el Ajuste 2-43
Archivos de Rastreo de Usuarios 2-45
Archivos de Rastreo de Procesos en Segundo Plano 2-46
Prueba 2-47
Resumen 2-48 LA
Visión General de la Práctica 2: Uso de Herramientas Básicas 2-49 D E
OS
A D
3 Uso del Repositorio de Carga de Trabajo Automática
R ES
Objetivos 3-2
E G nlyฺ
E eo
Repositorio de Carga de Trabajo Automática: Visión General
D3-4 3-3
I O N
Datos del Repositorio de Carga de Trabajo Automática
L us
Repositorio de Carga de Trabajo 3-5
D AC RITA
Database Control y AWR 3-6
F IST 3-7
UN deDAWR
a d AD
Política de Depuración de Instantáneas
nAWR
Valores de Instantáneas
s i t y SID3-8
de
i v er Vde
Instantáneas Manuales
E R
AWR 3-9
Gestión denInstantáneas
I con PL/SQL 3-10
e U U N
cl
aGeneración de Informes de AWR en EM 3-11
Or Generación de Informes de AWR en SQL*Plus 3-12
Lectura del Informe de AWR 3-13
Instantáneas y Comparaciones de Períodos 3-14
Compare Periods: Ventajas 3-15
Compare Periods: Resultados 3-16
Compare Periods: Informe 3-17
Compare Periods: Perfil de Carga 3-18
Compare Periods: Eventos Principales 3-19
Prueba 3-20
Resumen 3-21
Visión General de la Práctica 3: Uso de Herramientas Basadas en AWR 3-22
iv
4 Definición de Problemas
Objetivos 4-2
Definición del Problema 4-3
Limitación del Ámbito 4-4
Definición de la Prioridad 4-5
5 Eventos de Tiempo Principales 4-6

Definición de la Prioridad: Ejemplo 4-7
Informes de SQL Principal 4-8
Problemas de Ajuste Comunes 4-9
Ajuste de las Fases del Ciclo de Vida 4-11
Ajuste durante el Ciclo de Vida 4-12
Diseño y Desarrollo de Aplicaciones 4-13
Prueba: Configuración de la Base de Datos 4-14
Despliegue 4-15 LA
Producción 4-16 D E
S
DO
Migración, Actualización y Cambios de Entorno 4-17
A
Sesión de Ajuste de ADDM 4-18
R ES
G nlyฺ
Rendimiento frente a Requisitos del Negocio 4-19
E
N DE use o
Recursos de Ajuste de Rendimiento 4-20
Archivado de una Solicitud de Servicio de Rendimiento 4-21
C IO AL
Informe de RDA 4-22
D A RIT
Prueba 4-25 F UN DIST
Herramienta de Supervisión y Ajuste: Visión General 4-23
Resumen 4-26 a nd AD
r s ity RSID
Visión General de la Práctica 4: Identificación del Problema 4-27
n ive IVE
c l5e U
Uso de U
N
Métricas y Alertas
Ora Objetivos 5-2
Métricas y Alertas 5-3
Limitación de las Estadísticas Básicas 5-4
Herramientas Delta Típicas 5-5
Oracle Database 11g Solución: Métricas 5-6
Ventajas de las Métricas 5-7
Visualización de la Información del Historial de Métricas 5-8
Uso de EM para Ver Detalles de Métricas 5-9
Histogramas Estadísticos 5-10
Vistas de Histograma 5-11
Alertas Generadas por el Servidor 5-12
Modelo de Uso de Alertas 5-13
Definición de Umbrales 5-14
Creación y Prueba de una Alerta 5-15
v
Vistas de Métricas y Alertas 5-16
Prueba 5-17
Resumen 5-18
Visión General de la Práctica 5: Trabajar con Métricas 5-19
6 Uso de Líneas Base

Objetivos 6-2
Análisis de Rendimiento Comparativo con Líneas Base de AWR 6-3
Líneas Base de Repositorio de Carga de Trabajo Automática 6-4
Línea Base de Ventana Móvil 6-5
Líneas Base en Valores de Página de Rendimiento 6-6
Plantillas de Línea Base 6-7
Líneas Base de AWR 6-8
Creación de Líneas Base de AWR 6-9 LA
Línea Base de AWR Única 6-10 D E
S
DO
Creación de Plantillas de Línea Base de Repetición 6-11
A
Gestión de Líneas Base con PL/SQL 6-12
R ES
G nlyฺ
Generación de una Plantilla de Línea Base para un Período de Tiempo Único 6-13
E
Vistas de Línea Base 6-15 N DE use o
Creación de Plantillas de Línea Base de Repetición 6-14
C IO AL
Control de Rendimiento y Líneas Base 6-16
D A RIT
F UN DIST
Definición de Umbrales de Alerta mediante una Línea Base Estática 6-18
Uso de EM para Configurar Rápidamente Umbrales Adaptativos 6-19
a nd AD
Cambio de Valores de Umbrales Adaptativos 6-21
Prueba 6-22 r s ity RSID
n ive IVE
Resumen 6-23
c le U UN
Práctica 6: Visión General Uso de Líneas Base de AWR 6-24
Ora
7 Uso de Herramientas Basadas en AWR
Objetivos 7-2
Tareas de Mantenimiento Automáticas 7-3
Ventanas de Mantenimiento 7-4
Plan de Mantenimiento por Defecto 7-5
Prioridades de Tareas de Mantenimiento Automáticas 7-6
Tareas de Mantenimiento de Ajuste Automáticas 7-7
Control del Rendimiento de ADDM 7-8
ADDM y Tiempo de Base de Datos 7-9
Gráfico de Tiempo de Base de Datos y Metodología de ADDM 7-10
Principales Problemas de Rendimiento Detectados 7-12
Database Control y Búsquedas de ADDM 7-13
Resultados de los Análisis de ADDM 7-14
vi
Recomendaciones de ADDM 7-15
Database Control y Tarea ADDM 7-16
Modificación de Atributos ADDM 7-17
Recuperación de Informes ADDM Mediante SQL 7-18
Prueba 7-19
Historial de Sesiones Activas: Visión General 7-20

Historial de Sesiones Activas: Mecanismos 7-21
Creación de Ejemplos de ASH: Ejemplo 7-22
Acceso a Datos ASH 7-23
Análisis de Datos ASH 7-24
Generación de Informes ASH 7-25
Script del Informe ASH 7-26
Informe ASH: Sección General 7-27
Estructura del Informe ASH 7-28 L A
Informe ASH: Activity Over Time 7-29 D E
S
DO
Nuevas o Mejoradas Vistas de Repositorio de Carga de Trabajo Automática 7-30
A
Prueba 7-31
R ES
Resumen 7-32
E G nlyฺ
DE use o
Visión General de la Práctica 7: Uso de Herramientas Basadas en AWR 7-33
N
8 Supervisión de Aplicaciones C IO AL
D A RIT
Objetivos 8-2 N T
¿Qué es un Servicio?d 8-3FU DIS
a
Atributos de Servicio
n 8-4 AD
Tipos de r s it R8-5SID
y
Servicios
n ive de Servicios
Creación I V E 8-6
U
le GestiónUdeNServicios en un Entorno de Instancia Única 8-7
c
Ora ¿Dónde se Utilizan los Servicios? 8-8
Uso de Servicios con Aplicaciones Cliente 8-9
Uso de Servicios con el Gestor de Recursos 8-10
Servicios y Gestor de Recursos con EM 8-11
Servicios y Gestor de Recursos: Ejemplo 8-12
Servicios y Programador con EM 8-13
Servicios y Programador: Ejemplo 8-15
Uso de Servicios con Umbrales de Métrica 8-16
Cambio de Umbrales de Servicio con EM 8-17
Servicios y Umbrales de Métrica: Ejemplo 8-18
Agregación y Rastreo de Servicios 8-19
Página de Rendimiento de Servicios Principales 8-20
Configuración de Agregación de Servicios 8-21
Agregación de Servicios: Ejemplo 8-22
vii
Agregación y Rastreo de Identificador de Cliente 8-23
Utilidad trcsess 8-24
Vistas de Rendimiento de los Servicios 8-25
Prueba 8-27
Resumen 8-28
Visión General de la Práctica 8: Uso de Servicios 8-29
9 Identificación de Sentencias SQL con Problemas

Objetivos 9-2
Fases de Procesamiento de Sentencias SQL 9-3
Fase de Análisis 9-4
Almacenamiento de Cursores SQL 9-5
Uso y Análisis del Cursor 9-6
Fases de Procesamiento de Sentencias SQL: Enlazar 9-8 LA
Fases de Procesamiento de Sentencias SQL: Ejecución y Recuperación 9-9 D E
S
Procesamiento de una Sentencia DML 9-10
A DO
Procesamiento COMMIT 9-12
R ES
Rol del Optimizador de Oracle 9-13
E G nlyฺ
Prueba 9-15
Identificación de SQL Erróneo 9-16N DE use o
C IO AL
A RIT
Informes de SQL Principal 9-17
D
Supervisión de SQL 9-18
F UN DIST
nd AD
Ejecuciones SQL Supervisadas 9-19
a
r s ity RSID
Lista de Supervisión de SQL 9-20
ive IVE
Detalles de Ejecución de SQL Supervisada 9-21
n
le U UN
Informe de Supervisión de SQL 9-22
c
Prueba 9-23
Ora ¿Qué es un Plan de Ejecución? 9-24
Métodos para Ver los Planes de Ejecución 9-25
Usos de Planes de Ejecución 9-27
Paquete DBMS_XPLAN: Visión General 9-28
Comando EXPLAIN PLAN 9-30
Comando EXPLAIN PLAN: Ejemplo 9-31
Comando EXPLAIN PLAN: Salida 9-32
Lectura de un Plan de Ejecución 9-33
Uso de la Vista V$SQL_PLAN 9-34
Columnas de V$SQL_PLAN 9-35
Consulta de V$SQL_PLAN 9-36
Vista V$SQL_PLAN_STATISTICS 9-37
Consulta de AWR 9-38
viii
SQL*Plus AUTOTRACE 9-40
Uso de SQL*Plus AUTOTRACE 9-41
SQL*Plus AUTOTRACE: Estadísticas 9-42
Utilidad SQL Trace 9-43
Uso de la Utilidad SQL Trace 9-45
Parámetros de Inicialización 9-46

Activación de SQL Trace 9-48
Desactivación de SQL Trace 9-49
Formateo de los Archivos de Rastreo 9-50
Opciones del Comando TKPROF 9-51
Salida del Comando TKPROF 9-53
Salida de TKPROF sin Índice: Ejemplo 9-58
Salida de TKPROF con Índice: Ejemplo 9-59
Generación de un Rastreo de Optimizador 9-60 L A
D E
Prueba 9-61 S
Resumen 9-62
A DO
ES
Visión General de la Práctica 9: Uso de las Utilidades del Plan de Ejecución 9-63
R
E G nlyฺ
10 Influencia del Optimizador
N DE use o
Objetivos 10-2
C IO AL
A 10-3
Funciones del Optimizador de Consulta
D R IT
Selectividad 10-5
F UN DIST
Cardinalidad y Costo
a nd10-6 AD
r s ity RSID del Optimizador 10-7
Cambio del Comportamiento
n ive del
Estadísticas
I V E
Optimizador 10-9
U UNAmpliadas 10-11
le Estadísticas
c
Ora
Parámetros del Optimizador 10-12
Control del Comportamiento del Optimizador con Parámetros 10-13
Activación de las Funciones del Optimizador de Consulta 10-15
Uso de Indicaciones 10-16
Influencia en el Enfoque del Optimizador 10-17
Optimización de las Sentencias SQL 10-18
Prueba 10-19
Rutas de Acceso 10-20
Selección de una Ruta de Acceso 10-21
Exploraciones de Tablas Completas 10-22
Exploraciones de Identificador de Fila 10-24
Operaciones de Índice 10-25
Operaciones de Índice de Árbol B* 10-26
Índices de Bitmap 10-27
ix
Acceso a Índices de Bitmap 10-28
Combinación de Bitmaps 10-29
Operaciones de Bitmap 10-30
Operaciones de Unión 10-31
Métodos de Unión 10-32
Unión de Bucles Anidados 10-33

Unión Hash 10-35
Uniones de Fusión/Ordenación 10-36
Rendimiento de la Unión 10-38
Selección de los Planes de Ejecución para Uniones por Parte del Optimizador de
Consulta 10-39
Operaciones de Ordenación 10-41
Ajuste de Rendimiento de Ordenación 10-41
Prueba 10-42 LA
Resumen 10-43 D E
S
DO
Visión General de la Práctica 10: Influencia en el Optimizador 10-44
A
R ES
11 Reducción de Costos
E G nlyฺ
Objetivos 11-2
Reducción de Costos 11-3 N DE use o
Mantenimiento de Índices 11-4 C IO AL
D A RIT
Borrado de Índices 11-6
Creación de Índices 11-7 d F
UN DIST
a
Otras Opciones de Índices
n11-8 AD
r s y
it 11-9 S ID
ive IVER
Asesor de Acceso SQL
n
Prueba 11-10
U U N
c l e
Mantenimiento de Tablas para el Rendimiento 11-11
OraMétodos de Reorganización de Tablas 11-12
Gestión del Espacio 11-14
Gestión de Extensiones 11-15
Extensiones Gestionadas Localmente 11-16
Extensiones Grandes: Consideraciones 11-17
Almacenamiento de Datos de Tabla 11-19
Anatomía de un Bloque de Base de Datos 11-20
Reducción de las Visitas al Bloque 11-21
Parámetro DB_BLOCK_SIZE 11-22
Tamaño de Bloque Pequeño: Consideraciones 11-23
Tamaño de Bloque Grande: Consideraciones 11-24
Asignación de Bloques 11-25
Listas de Bloques Libres 11-26
Gestión de Espacio de Bloques 11-27
x
Gestión de Espacio de Bloques con Listas de Bloques Libres 11-28
Gestión Automática de Espacio de Segmento 11-30
Gestión Automática de Espacio de Segmento en el Trabajo 11-31
Gestión de Espacio de Bloques con ASSM 11-33
Creación de Segmentos de Gestión Automática de Espacio de Segmento 11-34
Prueba 11-35
Migración y Encadenamiento 11-36
Instrucciones para PCTFREE y PCTUSED 11-38
Detección de Migración y Encadenamiento 11-39
Selección de las Filas Migradas 11-40
Eliminación de las Filas Migradas 11-41
Reducción de Segmentos: Visión General 11-43
Reducción de Segmentos: Consideraciones 11-44
Reducción de Segmentos mediante SQL 11-45 LA
Reducción de Segmentos: Ejecución Básica 11-46 D E
S
DO
Reducción de Segmentos: Consideraciones sobre la Ejecución 11-47
A
ES
Uso de EM para Reducir Segmentos 11-48
R
G nlyฺ
Compresión de Tablas: Visión General 11-49
E
N DE use o
Conceptos de Compresión de Tablas 11-50
Compresión de Datos de Tabla 11-51
C IO AL
A RIT
Uso de la Compresión de Tablas 11-53
D
UN DIST
Uso de Asesor de Compresión 11-54
F
nd AD
Visualización de Información de Compresión de Tablas 11-55
a
r s ity RSID
Prueba 11-56
ive IVE
Resumen 11-57
n
Visión General de la Práctica 11: Reducción de Costos 11-58
c le U UN
Ora 12 Uso de SQL Performance Analyzer
Objetivos 12-2
Real Application Testing: Visión General 12-3
Real Application Testing: Casos de Uso 12-4
SQL Performance Analyzer: Proceso 12-5
Captura de Carga de Trabajo SQL 12-7
Creación de una Tarea de SQL Performance Analyzer 12-8
SQL Performance Analyzer: Tareas 12-9
Parameter Change 12-10
Página SQL Performance Analyzer Task 12-12
Informe de Comparación 12-13
Detalles de SQL del Informe de Comparación 12-14
Ajuste de Sentencias que Empeoran 12-15
Ajuste de Sentencias SQL Empeoradas 12-17
xi
Prevención de Regresiones 12-18
Análisis de Cambio de Parámetro 12-19
Análisis de Flujo de Trabajo Guiado 12-20
SQL Performance Analyzer: Ejemplo de PL/SQL 12-21
SQL Performance Analyzer: Vistas del Diccionario de Datos 12-23
Prueba 12-24
Resumen 12-25
Práctica 12: Visión General 12-26
13 Gestión del Rendimiento SQL

Objetivos 13-2
Mantenimiento del Rendimiento SQL 13-3
Mantenimiento de Estadísticas del Optimizador 13-4
Tareas de Mantenimiento Automáticas 13-5 LA
Opciones de Recopilación de Estadísticas 13-6 D E
S
Definición de Preferencias de Estadísticas 13-7
A DO
Restauración de Estadísticas 13-9
R ES
G nlyฺ
Publicación de Estadísticas Diferidas: Visión General 13-10
E
N DE use o
Publicación de Estadísticas Diferidas: Ejemplo 13-12
Ajustes SQL Automáticos: Visión General 13-13
C IO AL
Creación de Perfiles de Sentencias SQL 13-14
D A RIT
F UN DIST
Flujo de Ajustes de Planes y Creación de Perfiles SQL 13-15
Bucle de Ajustes SQL 13-16
a nd AD
Uso de Perfiles SQL 13-17
r s ity RSID
Asesor de Ajustes SQL: Visión General 13-18
n ive IVE
Uso del Asesor de Ajustes SQL 13-19
c le U UN
Opciones del Asesor de Ajustes SQL 13-20
OraRecomendaciones del Asesor de Ajustes SQL 13-21
Uso del Asesor de Ajustes SQL: Ejemplo 13-22
Planes de Ejecución Alternativos 13-23
Prueba 13-25
Uso del Asesor de Acceso SQL 13-26
Visualización de Recomendaciones 13-28
Visualización de Detalles de Recomendación 13-29
Gestión de Planes SQL: Visión General 13-30
Línea Base de Plan SQL: Arquitectura 13-31
Carga de Líneas Base de Plan SQL 13-33
Evolución de las Líneas Base de Plan SQL 13-34
Atributos Importantes del Plan SQL de Línea Base 13-35
Selección del Plan SQL 13-37
Supuestos Posibles de Gestión de Planes SQL 13-39
xii
Supuesto con SQL Performance Analyzer y la Línea Base de Plan SQL 13-40
Carga Automática de una Línea Base de Plan SQL 13-41
Política de Depuración de Base de Gestión SQL 13-42
Enterprise Manager y Líneas Base de Plan SQL 13-43
Prueba 13-44
Resumen 13-45
Práctica 13: Visión General del Uso de Gestión de Planes SQL 13-46
14 Uso de la Reproducción de Base de Datos

Objetivos 14-2
Uso de la Reproducción de Base de Datos 14-3
Estructura General 14-5
Arquitectura del Sistema: Captura 14-6
Arquitectura del Sistema: Procesamiento de la Carga de Trabajo 14-8 L A
Arquitectura del Sistema: Reproducción 14-9 D E
S
Consideraciones sobre la Captura 14-10
A DO
ES
Consideraciones sobre la Reproducción: Preparación 14-11
R
G nlyฺ
Consideraciones sobre la Reproducción 14-12
E
N DE use o
Opciones de Reproducción 14-13
Análisis de Reproducción 14-15
C IO AL
Flujo de Trabajo de Reproducción de Base de Datos en Enterprise Manager 14-17
D A RIT
F UN DIST
Captura de Cargas de Trabajo con Enterprise Manager 14-18
Asistente de Captura: Plan Environment 14-19
a nd AD
Asistente de Captura: Options 14-20
r s ity RSID
Asistente de Captura: Parameters 14-21
n ive IVE
Visualización de Progreso de Captura 14-22
c le U UN
Visualización de Informe de Captura 14-23
Ora Exportación de Datos de AWR de Captura 14-24
Prueba 14-25
Visualización de Historial de Captura de Carga de Trabajo 14-26
Procesamiento de Carga de Trabajo Capturada 14-27
Uso del Asistente de Preprocesamiento de Carga de Trabajo Capturada 14-28
Uso del Asistente de Reproducción de Carga de Trabajo 14-29
Replay Workload: Prerequisites 14-30
Replay Workload: Choose Initial Options 14-32
Replay Workload: Customize Options 14-33
Replay Workload: Prepare Replay Clients 14-34
Replay Workload: Wait for Client Connections 14-35
Replay Workload: Replay Started 14-36
Visualización de Progreso de Reproducción de Carga de Trabajo 14-37
Visualización de Estadísticas de Reproducción de Carga de Trabajo 14-38
xiii
Paquetes y Procedimientos 14-40
Vistas del Diccionario de Datos: Reproducción de Base de Datos 14-41
Reproducción de Base de Datos: Ejemplo de PL/SQL 14-42
Calibración de Clientes de Reproducción 14-44
Prueba 14-45
Resumen 14-46
Práctica 14: Visión General 14-47
15 Ajuste del Pool Compartido

Objetivos 15-2
Arquitectura del Pool Compartido 15-3
Operación del Pool Compartido 15-4
Caché de Biblioteca 15-5
Bloqueo Interno y Mutex 15-7 LA
Bloqueo Interno y Mutex: Vistas y Estadísticas 15-9 D E
S
DO
Herramientas de Diagnóstico para Ajustar el Pool Compartido 15-11
A
Indicadores de Statspack/AWR 15-13
R ES
Load Profile 15-14
E G nlyฺ
Instance Efficiencies 15-15
N
Eventos de Tiempo Principales 15-16
DE use o
Time Model 15-17 C IO AL
D A RIT
F UN DIST
Actividad de la Caché de Biblioteca 15-19
Cómo Evitar Análisis Pesados 15-20
a nd AD
¿Se Están Compartiendo los Cursores? 15-21
r s ity RSID
Uso Compartido de Cursores 15-23
n ive IVE
Uso Compartido del Cursor Adaptativo: Ejemplo 15-25
c le U UN
Vistas de Uso Compartido del Cursor Adaptativo 15-27
OraInteracción con el Uso Compartido del Cursor Adaptativo 15-28
Reducción del Costo de los Análisis Ligeros 15-29
Prueba 15-30
Ajuste de Tamaño del Pool Compartido 15-31
Asesoramiento del Pool Compartido 15-32
Asesor del Pool Compartido 15-34
Cómo Evitar la Fragmentación 15-35
Requisitos de Memoria Grande 15-36
Ajuste del Espacio Reservado del Pool Compartido 15-38
Mantenimiento de Objetos Grandes 15-40
Caché de Diccionario de Datos 15-42
Faltas de Caché de Diccionario 15-43
Caché de Resultados de Consultas SQL: Visión General 15-44
Gestión de la Caché de Resultados de Consultas SQL 15-45
xiv
Uso de la Indicación RESULT_CACHE 15-47
Uso de la Anotación Table para Controlar el Almacenamiento en Caché de los
Resultados 15-48
Uso del Paquete DBMS_RESULT_CACHE 15-49
Visualización de la Información del Diccionario de Caché de Resultados SQL 15-50
Caché de Resultados de Consultas SQL: Consideraciones 15-51

Prueba 15-52
Resumen 15-53
Visión General de la Práctica 15: Ajuste del Pool Compartido 15-54
16 Ajuste de la Caché de Buffers

Objetivos 16-2
Arquitectura de Oracle Database 16-3
Caché de Buffers: Aspectos Destacados 16-4 L A
Buffers de Base de Datos 16-5 D E
S
Tabla Hash de Buffer para Consultas 16-6
A DO
Juegos de Trabajo 16-7
R ES
G nlyฺ
Objetivos y Técnicas de Ajuste 16-9
E
Síntomas 16-11
N DE use o
Contención de Bloqueo Interno de Cadenas de Buffers de Caché 16-12
C IO AL
A RIT
Búsqueda de Segmentos Activos 16-13
D
UN DIST
Esperas por Ocupación del Buffer 16-14
F
nd AD
Ratio de Aciertos de Caché de Buffers 16-15
a
r s ity RSID
Ratio de Aciertos de Caché de Buffers: Consideraciones 16-16
ive IVE
Interpretación del Ratio de Aciertos de la Caché de Buffers 16-17
n
le U UN
Esperas de Lectura 16-19
c Esperas de Buffers Libres 16-21
Ora Soluciones 16-22
Ajuste de Tamaño de Caché de Buffers 16-23
Parámetros de Tamaño de Caché de Buffers 16-24
Prueba 16-25
Parámetro Dinámico del Asesor de Caché de Buffers 16-26
Vista del Asesor de Caché de Buffers 16-27
Uso de la Vista V$DB_CACHE_ADVICE 16-28
Uso del Asesor de Caché de Buffers con EM 16-29
Almacenamiento en Caché de Tablas 16-30
Varios Pools de Buffers 16-31
Activación de Varios Pools de Buffers 16-33
Cálculo del Ratio de Aciertos para Varios Pools 16-34
Varios Tamaños de Bloque 16-36
Varios Escritores de Base de Datos 16-37
xv
Varios Esclavos de E/S 16-38
Uso de Varios Escritores o Esclavos de E/S 16-39
Pool Privado para Operaciones que Generan Mucha E/S 16-40
Lecturas Multibloque Ajustadas Automáticamente 16-41
Visión General de Caché Flash Inteligente de BD w 16-42
Uso de la Caché Flash Inteligente de BD 16-43

Visión General de la Arquitectura de Caché Flash Inteligente de BD 16-44
Configuración de la Caché Flash Inteligente de BD 16-45
Ajuste de Tamaño de la Caché Flash Inteligente de BD 16-46
Especificación de Caché Flash Inteligente de BD para una Tabla 16-47
Vaciado de la Caché de Buffers (Sólo para Pruebas) 16-48
Prueba 16-49
Resumen 16-50
Práctica 16: Visión General del Ajuste de la Caché de Buffers 16-51 LA
D E
S
17 Ajuste de PGA y Espacio Temporal
A DO
Objetivos 17-2
R ES
Uso de la Memoria SQL 17-3
E G nlyฺ
Impacto en el Rendimiento 17-4
Memoria PGA Automática 17-5 N DE use o
Gestor de Memoria SQL 17-6 C IO AL
D A RIT
F UN DIST
Configuración de la Memoria PGA Automática 17-8
Definición Inicial de PGA_AGGREGATE_TARGET 17-9
a nd AD
r s ity RSID
Control del Uso de la Memoria SQL 17-10
ive IVE
Supervisión del Uso de la Memoria SQL: Ejemplos 17-12
n
Ajuste del Uso de la Memoria SQL 17-13
c le U UN
Estadísticas de Consejo de Destino de PGA 17-14
OraHistogramas de Consejo de Destino de PGA 17-15
PGA Automática y Enterprise Manager 17-16
PGA Automática e Informes de AWR 17-17
Gestión de Tablespaces Temporales: Visión General 17-18
Tablespaces Temporales: Recomendaciones 17-19
Configuración de Tablespaces Temporales 17-20
Grupos de Tablespaces Temporales: Visión General 17-22
Grupos de Tablespaces Temporales: Ventajas 17-23
Creación de Grupos de Tablespaces Temporales 17-24
Mantenimiento de Grupos de Tablespaces Temporales 17-25
Visualización de Grupos de Tablespaces 17-26
Control de los Tablespaces Temporales 17-27
Reducción de Tablespaces Temporales 17-28
Opción de Tablespace para Crear una Tabla Temporal 17-29
xvi
Prueba 17-30
Resumen 17-31
Visión General de la Práctica 17: Ajuste de la Memoria PGA 17-32
18 Gestión Automática de Memoria

Objetivos 18-2
Arquitectura de Oracle Database 18-3
SGA Dinámica 18-4
Gránulo 18-5
Asesores de Memoria 18-6
Adición Manual de Gránulos a los Componentes 18-7
Aumento del Tamaño de un Componente de SGA 18-8
Gestión Automática de Memoria Compartida: Visión General 18-9
Parámetros de Ajuste de Tamaño de SGA: Visión General 18-10 LA
Modos de Transferencia de SGA Dinámica 18-11 D E
S
Arquitectura de Broker de Memoria 18-12
A DO
ES
Cambio de Tamaño Manual de Parámetros de SGA Dinámica 18-13
R
G nlyฺ
Comportamiento de los Parámetros de SGA de Ajuste Automático 18-14
E
Uso de la Vista V$PARAMETER 18-16 N DE use o
Comportamiento de los Parámetros de SGA de Ajuste Automático 18-15
C O AL
I18-17
Cambio de Tamaño de SGA_TARGET
D A RIT
U N IST
Desactivación de la Gestión Automática de Memoria Compartida 18-18
Configuración de ASMM d F 18-19 D
a n
18-20 DA
D
Asesor de SGA y
it R
sASMM SI
Controle r
de 18-21
E de Memoria: Visión General 18-22
U niv Automática
Gestión I V
cle UN
Parámetros de Memoria de Oracle Database 18-24
Ora Dependencia de Parámetros de Memoria Automática 18-25
Activación de la Gestión Automática de Memoria 18-26
Control de la Gestión Automática de Memoria 18-27
DBCA y Gestión Automática de Memoria 18-29
Prueba 18-30
Resumen 18-31
Práctica 18: Visión General Uso del Ajuste Automático de Memoria 18-32
19 Ajuste de E/S
Objetivos 19-2
Arquitectura de E/S 19-3
Características del Sistema de Archivos 19-4
Modos de E/S 19-5
E/S Directa 19-6
xvii
Ancho de Banda frente a Tamaño 19-7
Métricas de E/S Importantes para Bases de Datos Oracle 19-8
Calibración de E/S y Enterprise Manager 19-10
Calibración de E/S y la Interfaz PL/SQL 19-11
Estadísticas de E/S: Visión General 19-13
Estadísticas de E/S y Enterprise Manager 19-14

Stripe and Mirror Everything 19-16
Uso de RAID 19-17
Costo frente a Beneficios de RAID 19-18
¿Se Debe Utilizar RAID 1 o RAID 5? 19-20
Diagnóstico 19-21
Ajuste de E/S de Base de Datos 19-22
Prueba 19-23
¿En qué consiste la Gestión Automática de Almacenamiento? 19-24 LA
Ajuste de ASM 19-25 D E
S
DO
Número de Grupos de Discos por Base de Datos 19-26
A
ES
¿Qué Configuración de RAID Ofrece una Mejor Disponibilidad? 19-27
R
Instrucciones de Duplicación de ASM 19-28
E G nlyฺ
N DE use o
Granularidad de Segmentación de ASM 19-29
¿Cuál Es el Tipo de Segmentación que Funciona Mejor? 19-30
C IO AL
A RIT
Sólo Segmentación de ASM 19-31
D
F UN DIST
LUN Segmentadas en RAID de Hardware 19-32
Instrucciones de ASM 19-33
a nd AD
Parámetros de Inicialización de Instancias de ASM 19-34
r s ity RSID
Vistas de Rendimiento Dinámico 19-35
n ive IVE
Control de Operaciones de Larga Ejecución con V$ASM_OPERATION 19-37
c le U UN
Diagnóstico del Rendimiento de Instancias de ASM 19-38
OraPágina Performance de ASM 19-39
Cambios de Parámetros de Instancias de Base de Datos 19-40
Escalabilidad de ASM 19-41
Prueba 19-42
Resumen 19-43
20 Resumen de Ajuste del Rendimiento

Objetivos 20-2
Parámetros de Inicialización Necesarios con Impacto Mínimo en
el Rendimiento 20-3
Parámetros de Inicialización Importantes con Impacto en el Rendimiento 20-4
Ajuste Inicial del Tamaño de Memoria 20-6
UGA y Servidor Compartido Oracle 20-7
Pool Grande 20-8
xviii
Ajuste del Pool Grande 20-9
Alta Disponibilidad de Base de Datos: Instrucciones Óptimas 20-10
Tablespace de Deshacer: Instrucciones Óptimas 20-11
Temporary Tablespace Instrucciones Óptimas 20-12
Tablespace General: Instrucciones Óptimas 20-14
Consideraciones de Fragmentación Interna 20-15

Tamaño de Bloque: Ventajas y Desventajas 20-16
Ajuste Automático de Puntos de Control 20-17
Ajuste de Tamaño del Buffer de Redo Log 20-18
Ajuste de Tamaño de Archivos Redo Log 20-19
Aumento del Rendimiento del Archivado 20-20
Recopilación Automática de Estadísticas 20-22
Recopilación Automática de Estadísticas: Consideraciones 20-23
Eventos de Espera Más Comunes 20-24 LA
Estadísticas Adicionales 20-25 D E
S
DO
Los 10 Errores Más Comunes en los Sistemas de Cliente 20-26
A
Prueba 20-28
R ES
Resumen 20-29
E G nlyฺ
Apéndice A: Prácticas y Soluciones N DE use o
C IO AL
D A RIT
B Uso de Statspack
Objetivos B-2 F UN DIST
Introducción ay a nd B-3
Statspack A D
it RSB-4I D
ders
Scripts e Statspack
Instalación
E
niv NdeIVStatspack B-6
e U U
l Captura de Instantáneas de Statspack B-7
c
Ora Configuración de Captura de Datos de Instantáneas B-8
Niveles de Instantánea de Statspack B-9
Líneas Base de Statspack y Depuración B-11
Creación de Informes con Statspack B-13
Consideraciones de Statspack B-14
Informes de Statspack y AWR B-16
Lectura de un Informe de Statspack o AWR B-17
Secciones de Despliegue del Informe de Statspack/AWR B-18
Ejemplos de Despliegue de Informe B-20
Sección Load Profile B-21
Sección Time Model B-22
Statspack y AWR B-23
Resumen B-24
Visión General de la Práctica: Uso de Statspack B-25
xix
Ora
c
n
r s
le U UN
ive IVE
a
F
ity RSID
nd AD
D
C
UN DIST
N
A RIT
IO AL
E
R
DE use o
ES
G nlyฺ
A DO
S D E LA
Ora
c
n
r s
le U UN
ive IVE
a
F
ity RSID
nd AD
D
C
UN DIST
N
A RIT
IO AL
E
R
DE use o
ES
G nlyฺ
A DO
S
Prefacio
D E LA
Ora
c
n
r s
le U UN
ive IVE
a
F
ity RSID
nd AD
D
C
UN DIST
N
A RIT
IO AL
E
R
DE use o
ES
G nlyฺ
A DO
S D E LA
Perfil
Cualificación Necesaria para el Curso
Antes de empezar este curso, debería estar capacitado para realizar las funciones de
un DBA a nivel de entrada que ha realizado los cursos Oracle Database 11g: Taller
de Administración 1 y 2 o experiencia equivalente. Se recomienda que haya
realizado también el curso Oracle Database 11g: Conceptos Fundamentales de SQL
y PL/SQL o que tenga experiencia equivalente.

Organización del Curso
Oracle Database 11g: Ajuste de Rendimiento es un curso dirigido por un instructor
que incluye teoría y ejercicios prácticos. Las demostraciones en línea y las sesiones
de prácticas escritas sirven para reforzar los conceptos y las habilidades
presentados.
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
c le U UN
Ora
Prefacio - 3
Publicaciones Relacionadas
Publicaciones de Oracle
Título Número de Artículo
Oracle Database Administrator's Guide 11g (11.2) E10595-06
Oracle Database 2 Day + Performance Tuning Guide
11g Release 2 (11.2) E10822-02

Oracle Database Performance Tuning Guide
11g Release 2 (11.2) E10821-04
Oracle Database Reference
11g Release 2 (11.2) E10820-03
Publicaciones Adicionales
• Boletines de las versiones del sistema
• Guías de instalación y del usuario LA
• Archivos léame D E
S
DO
• Artículos del grupo internacional de usuarios de Oracle (International Oracle
A
User’s Group, IOUG)
R ES
• Oracle Magazine E G nlyฺ
N DE use o
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
c le U UN
Ora
Prefacio - 4
Convenciones Tipográficas
En las dos listas siguientes se explican las convenciones tipográficas de Oracle
University para palabras que aparecen en texto normal o en ejemplos de código.
1. Convenciones Tipográficas para Palabras en Texto Normal

Convención Objeto o Término Ejemplo
Courier New Entradas del usuario; Utilice el comando SELECT para ver
comandos; la información almacenada en la columna
columna, tabla y LAST_NAME de la tabla EMPLOYEES.
nombres de esquema;
funciones; Introduzca 300.
objetos PL/SQL,
rutas de acceso Conéctese como scott
L A
Mayúscula inicial Disparadores; Asigne un disparador When-Validate-ItemDE
nombres de objeto OS
al bloque ORD. Haga clic en el botón
D
de usuario, como Cancel.
S A
nombres de interfaz E
de botones E GR nlyฺ
N DE use o
C IO AL
D A RIT
Cursiva Títulos de FU
N Para
D ISTobtener más información sobre el
nyd AD tema, consulte
cursos
a
s y SID
itmanuales; Oracle SQL Reference
e r E R
n iv IoVfrases
palabras Manual
l e U UN enfatizadas; No guarde los cambios en la base de datos.
Orac marcadores de Introduzca hostname, donde

posición o variables hostname es el host en el que
se va a cambiar la contraseña.
Comillas Títulos de lecciones Este tema se trata en la Lección 3,

o módulos “Trabajar con Objetos”.
a los que se hace
referencia en un curso
Prefacio - 5
Convenciones Tipográficas (continuación)
2. Convenciones Tipográficas para Palabras en Ejemplos de Código

Convención Objeto o Término Ejemplo
Mayúsculas Comandos, SELECT employee_id
funciones FROM employees;

Minúsculas, Variables de sintaxis CREATE ROLE role;
cursiva
Mayúscula Disparadores Form module: ORD
inicial de Forms Trigger level: S_ITEM.QUANTITY
item
Trigger name: When-Validate-Item
. . .
Minúsculas Nombres de columna, . . . LA
nombres de tabla, OG_ACTIVATE_LAYER D E
S
nombres de archivo,
objetos PL/SQL . . . A DO
(OG_GET_LAYER ('prod_pie_layer'))
R ES
SELECT last_name
E G nlyฺ
FROM
N DE use o
employees;
Negrita Texto que debe IO USER
CREATE
C A L scott
introducir un
RI T
DAIDENTIFIED BY tiger;
N T
usuario
d FU DIS
a n A D
y
sit RSI D
e r
U niv NIVE
c le U
Or a
Prefacio - 6
Introducción
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
Copyright © 2010, Oracle IST
Uy/oNsusDfiliales. Todos los derechos reservados.
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora
Objetivos del Curso
Al finalizar este curso, debería estar capacitado para lo

siguiente:
• Utilizar asesores de base de datos para ajustar de forma
proactiva Oracle Database
• Utilizar las herramientas basadas en AWR (repositorio de
carga de trabajo automática) para ajustar Oracle Database
• Diagnosticar y ajustar problemas habituales de rendimiento
relacionados con SQL
E LA
• Diagnosticar y ajustar problemas habituales de rendimiento D
relacionados con instancias D OS
S A
E
• Utilizar páginas de Enterprise Manager relacionadas
R yฺ con el
G
E E onl
rendimiento para supervisar Oracle Database
D use
IO ALN
A RITC
D
F
a n d A D
y
sit RSI D
e r
U niv NIVE
cle U
Ora
Oracle Database 11g: Ajuste de Rendimiento 1-2

Organización
• Supervisión y Diagnóstico
– Supervisión mediante las herramientas disponibles

– Identificación del problema
– Uso de herramientas basadas en AWR
• Ajustes SQL
– Identificación y ajuste de sentencias SQL mediante la
influencia en el optimizador
– Gestión de cambios L A
— Gestión del Rendimiento SQL D E
— Real Application Testing D OS
• Ajuste de Instancias E SA
– Ajuste de componentes de memoria E GR nlyฺ
E o
– Ajuste del uso de espacio y E/S N D use
C IO AL
D A RIT
F
a n d A D
Organización y
sit RSI D
e r E de ajuste del rendimiento que se espera que realice un DBA en el
iv en lasItareas
Esta clase se centra
n V
entorno de
l U
ebase UNdedeunadatos
de datos única instancia. Los ajustes SQL se limitan a las tareas relacionadas
a
conrel c
ajuste de estructuras y al mantenimiento de estadísticas, porque el DBA no tiene
O
normalmente acceso o permiso para cambiar el código SQL. Este curso se organiza en tres divisiones
principales:
• Supervisión y Diagnóstico
• Ajustes SQL
• Ajuste de Instancias
Supervisión y Diagnóstico incluye las herramientas de supervisión, diagnóstico e informes que
necesita el DBA para identificar los problemas de ajuste de forma proactiva. Se utilizan tanto las
herramientas básicas que se incluyen con cada base de datos como aquéllas que necesitan los
paquetes de Enterprise Manager.
Ajustes SQL incluye la identificación de sentencias SQL de carga alta, mediante la influencia en el
optimizador y la gestión de cambios. Se abordan los conceptos básicos para la detección de las
sentencias SQL con problemas y la lectura y el seguimiento del plan de ejecución. Además, esta
división incluye métodos para la gestión de cambios del plan SQL debido al crecimiento o pequeños
cambios, así como métodos de prueba para anticipar los principales cambios en el entorno.
Ajuste de Instancias incluye los componentes de memoria, la gestión de espacio y E/S. Esta división
aborda el uso de las herramientas de diagnóstico para determinar el área problemática específica e
implementar una solución.

Agenda
Día Lección Tema

1 1 Introducción
1 2 Diagnósticos de Ajuste Básicos
1 3 Uso del Repositorio de Carga de Trabajo Automática
1 4 Definición de Problemas
1 5 Uso de Métricas y Alertas
2 6 Uso de Líneas Base

LA
2 7 Uso de Herramientas Basadas en AWR D E
S
2 8 Supervisión de Aplicaciones
A DO
R ES
2 9 Identificación de Sentencias SQL con Problemas
E G nlyฺ
3 10 Influencia del Optimizador DE e o
N s
C IO AL u
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Or a

Agenda
Día Lección Tema
Reducción de Costos
3 11
3 12 Uso de SQL Performance Analyzer
4 13 Gestión del Rendimiento SQL
4 14 Uso de la Reproducción de Base de Datos
4 15 Ajuste del Pool Compartido
5 16 Ajuste de la Caché de Buffers
5 17 Ajuste de PGA y Espacio Temporal LA

D E
S
DO
5 18 Gestión Automática de Memoria
A
5 19 Ajuste de E/S
R ES
5 20 Resumen de Ajuste del Rendimiento E G nlyฺ
N DE use o
opc. Apéndice B Uso de Statspack (opcional)
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Or a

No se Incluye
• Disponibilidad 7x24
• Operaciones en línea
• Rendimiento de copia de seguridad
• Operaciones paralelas
• Problemas de rendimiento de Streams y Data Guard
• Real Application Clusters
• Sistema operativo: problemas específicos
L A
• Problemas específicos de la aplicación, como el manejo D E
de LOB OS
S AD
G RE yฺ
E E onl
N D use
C IO AL
D A RIT
F
a n d A D
No se Incluye y
sit RSI D
e r E de rendimiento en cualquier configuración de una instancia de
n ivde problemas
• El diagnóstico
I V
l U UNlassemismas
Oracle empieza con
e y opciones técnicas básicas. Los problemas específicos de determinadas
c
O• raLos problemas de rendimiento con opciones de alta disponibilidad se abordan en sus respectivas
funciones abordan en clases específicamente diseñadas para ello.
clases sobre Oracle Streams, Oracle Data Guard y Oracle Real Application Clusters.
• La configuración de rendimiento de copia de seguridad se aborda en la clase Taller de
Administración II.
• Las operaciones paralelas y particiones se tratan en los planes de estudios de almacenes de
datos.
• Los problemas específicos de la aplicación, como el manejo de los valores de parámetros de
almacenamiento para objetos grandes (LOB), se tratan en las guías del desarrollador de
aplicaciones.

¿Quién se Encarga del Ajuste?
Entre las personas implicadas en el ajuste están los:

• Administradores de base de datos

• Arquitectos de aplicaciones
• Diseñadores de aplicaciones
• Desarrolladores de aplicaciones
• Administradores del sistema
• Administradores de almacenamiento
L A
• Administradores de red D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
¿Quién se Encarga del t y
siAjuste? SI D
e r E R
U nivimplicada
Cualquier persona
N I V en el software de Oracle Database, incluidos los arquitectos del sistema,
diseñadores,
c U
le desarrolladores, administradores de la base de datos, administradores del sistema,
O r a
administradores de almacenamiento y administradores de red debe pensar en el rendimiento.
Si se producen problemas, el administrador de la base de datos (DBA) es el que normalmente intenta
resolverlos en primera instancia. Por lo tanto, el DBA debe tener una visión general precisa de todas
las aplicaciones de la base de datos y de las interacciones que se producen entre ellas. Los DBA
consiguen con frecuencia la ayuda de los desarrolladores para el ajuste de aplicaciones o de los
administradores del sistema para el ajuste del sistema operativo. Este curso está destinado a los DBA
responsables del ajuste y de la supervisión de Oracle Database. Sin embargo, cualquier persona
implicada en el diseño, desarrollo y despliegue de Oracle Database también se puede beneficiar.

¿Qué Ajusta el DBA?
Áreas de ajuste de rendimiento:

• Aplicación:
– Rendimiento de la sentencia SQL Compartido con los
– Gestión de cambios desarrolladores
• Ajuste de instancias:
– Memoria
– Estructura de la base de datos
– Configuración de instancias L A
D E
• Interacciones del sistema operativo:
D OS
– E/S Compartido con el
E SA
– Intercambio administrador del sistema GR yฺ
E n l
– Parámetros
N DE use o
C IO AL
D A RIT
F
a n d A D
¿Qué Ajusta el DBA?sit y SI D
e r R
Ea la perfección, debe diseñar detenidamente los sistemas y las
niv ajustado
Para tener un sistema
U I V
aplicaciones.
c l UN de rendimiento habituales se pueden agrupar en:
e Los problemas
O• raProblemas de aplicaciones: SQL escrito con deficiencias, recursos serializados y gestión de
sesiones deficiente
• Problemas de instancias: memoria, E/S y configuración de instancias
• Problemas del sistema operativo: intercambio, E/S, valores de parámetros y problemas de red
Sacará un gran provecho de su inversión de tiempo y esfuerzo si ajusta la aplicación. El ajuste de las
sentencias SQL, las rutas de acceso y las estructuras de almacenamiento son partes importantes del
ajuste de aplicaciones.
El ajuste de instancias y el ajuste de aplicaciones utilizan juegos diferentes de conocimientos y
herramientas. Hay disponibles cursos específicos sobre los conocimientos y las herramientas
concretas que se utilizan en el ajuste de aplicaciones. El ajuste de aplicaciones depende del tipo de
aplicación. Las aplicaciones de almacenamiento de datos y las aplicaciones de procesamiento de
transacciones en línea (OLTP) utilizan distintos métodos de acceso y estructuras de datos para un
mejor rendimiento. El ajuste del sistema operativo depende del sistema operativo que se utilice. Hay
disponibles cursos específicos sobre estas áreas: Oracle Database 11g: Taller de Ajustes SQL para el
ajuste de aplicaciones OLTP y el ajuste de sentencias y Oracle Database 11g: Implementación y
Administración de Almacenes de Datos para problemas de almacenes de datos.

¿Qué Ajusta el DBA? (continuación)
Algunos problemas de la base de datos requieren la ayuda del administrador del sistema. Este curso
trata algunos de los casos más genéricos. Hay cursos específicos para sistemas basados en Linux y en
Windows que tratan problemas específicos del sistema operativo. El curso para Linux abarca muchos
problemas que son genéricos de UNIX y de sistemas operativos similares.
L A
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
cle U UN
Ora

¿Cómo se Ajusta?
Herramientas disponibles:
• Diagnóstico básico:
– Vistas de rendimiento dinámico
– Estadísticas
– Métricas
– Páginas de Enterprise Manager
• AWR o Statspack
• Monitor de Diagnóstico de Base de Datos Automático L A
D E
(ADDM)
D OS
• Scripts del DBA SA
G RE yฺ
E E onl
N D use
C IO AL
D A RIT
F
a n d A D
¿Cómo se Ajusta? sit y SI D
e r R
E de ajuste disponibles, los detalles de uso de estas herramientas
n iv herramientas
• Existen diversas
I V
U UN
varían, pero la metodología
le es la misma.
Sictiene Oracle Database 11g Enterprise Edition con los paquetes de ajuste opcionales, el
• ra
O Monitor de Diagnóstico de Base de Datos Automático (ADDM) está disponible junto con otras
herramientas basadas en el Repositorio de Carga de Trabajo Automática (AWR).
• Si dispone de Oracle Database 11g Standard Edition, la herramienta que debe utilizar es
Statspack.
• Los pasos para el uso de ambas herramientas, ADDM y Statspack, se tratan en este curso.
• Además, muchos DBA han desarrollado sus propias herramientas y scripts para el ajuste.
• Todas las herramientas de ajuste dependen de los diagnósticos básicos de las vistas de
rendimiento dinámico, las estadísticas y las métricas que recopila la instancia.

Metodología de Ajuste
Pasos de ajuste:
• Identificar el ámbito del problema (sistema operativo, base

de datos, etc.).
• Ajustar lo siguiente en orden descendente:
– El diseño antes que el código de aplicación
– El código antes que la instancia
• Ajustar el área con las mayores ventajas potenciales:
– Identificar el problema de rendimiento (AWR, Statspack). L A
D E
– Analizar el problema, buscar componentes sesgados y S
ajustables. A DO
R ES
– Utilizar las herramientas adecuadas para ajustar los
componentes implicados. E G n l yฺ
E o D e
• Parar el ajuste cuando se cumpla
Oel us
N objetivo.
A CI ITAL
U ND IST R
d F
Copyright © 2010, Oracle y/o sus filiales.
D Todos los derechos reservados.
n D
Metodología de Ajuste s i t y a SIDA
i
Oracle Corporation v ehardesarrollado
V ER una metodología de ajuste basada en años de experiencia. La
n
Upresentada I
e
metodología
c l UNen este curso también se presenta en la guía Oracle Database Performance
ra Guide (Guía de Ajuste de Rendimiento de Oracle Database). Esta metodología se aplica con
Tuning
O
independencia de las herramientas que utilice. La herramienta ADDM sigue esta metodología de
forma automática. Los pasos básicos son los siguientes:
• Compruebe las estadísticas del sistema operativo y el estado general del equipo antes de ajustar
la instancia para asegurarse de que el problema está en la instancia de la base de datos.
• Ajuste en orden descendente. Empiece con el diseño, después la aplicación y, a continuación, la
instancia. Por ejemplo, intente eliminar las exploraciones de tablas completas que provocan la
contención de E/S antes de ajustar el diseño del tablespace en el disco. El diseño debe utilizar
estructuras de datos adecuadas para las características de aplicación y de carga. Por ejemplo, los
índices de clave inversa pueden funcionar correctamente en un entorno RAC a la hora de reducir
los bloques activos debido a una clave primaria secuencial pero también puede derivar en un
gran número de bloques enviados a través de las interconexiones si cada instancia realiza
inserciones en la misma tabla. Las aplicaciones deben evitar procesos que necesitan
serialización mediante un único recurso. Un ejemplo sencillo de ello es un único generador de
números de comprobación utilizado por varios procesos. El ajuste a nivel de instancia se ve
limitado con frecuencia por las opciones de diseño y aplicación. Con las aplicaciones existentes,
este paso no suele estar disponible, ya que el diseño y el código no se pueden modificar.

Metodología de Ajuste (continuación)
• Ajuste el área con las mayores ventajas potenciales. La metodología de ajuste presentada en este
curso es sencilla. Identifique el mayor cuello de botella y ajústelo. Repita. Las herramientas de
ajuste de Oracle utilizan DB Time para identificar las áreas de problema. Todas las herramientas
tienen alguna forma para identificar las sentencias SQL, la contención de recursos o los servicios
que tardan más tiempo. Oracle Database 11g proporciona un modelo de tiempo y métricas para
automatizar el proceso de identificación de cuellos de botella.

• Pare el ajuste cuando cumpla el objetivo. Este paso implica la definición de objetivos de ajuste.
Éste es un enfoque general del ajuste de la instancia de base de datos y puede que necesite varios
pases.
Lo ideal es que alguien con experiencia en el ajuste de bases de datos participe en el diseño y
desarrollo desde el principio. Esta persona, por ejemplo, podría sugerir índices para limitar las
exploraciones de tabla completas en las tablas a las que se acceda con mayor frecuencia.
Desde una perspectiva práctica, el ajuste durante las fases de diseño y desarrollo de un proyecto suele
ser en orden descendente. Los esfuerzos de ajuste durante las fases de prueba y producción suelen ser
L A
E
reactivos y ascendentes. En todas las fases, el ajuste depende de casos de prueba reales porque el
D
S
ajuste teórico no tiene presente todas las variables que pueden surgir. Cuando se sospecha o descubre
DO
una área problemática, se crea un caso de prueba y se ajusta el área como en los ejemplos que ofrece
A
ES
este curso. Ajuste el área con las mayores ventajas potenciales. Reduzca las esperas y los tiempos de
R
servicio más largos. E G nlyฺ
DE use o
Como puede observar, las técnicas suelen ser las mismas, independientemente de la fase del ciclo de
N
IO AL
vida. Se ejecuta un caso de prueba o una aplicación real, se aplican las herramientas de diagnóstico
C
A RIT
disponibles, se propone una solución y se prueba.
D
F UN DIST
a nd AD
r s ity RSID
n ive IVE
c le U UN
Ora

Objetivos de Ajuste Efectivos
Los objetivos de ajuste efectivos son:

• Específicos
• Medibles
• Factibles
• Rentables
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI
Objetivos de Ajuste Efectivos D
e r E
El objetivo del n iv es laIV
ajuste eliminación de un problema definido. Los objetivos también se obtienen
U
le que hay
de los acuerdos N
U de servicio (SLA) relacionados. El SLA suele ser un requisito contractual o
de nivel
r a c
de negocio que cumplir. El objetivo puede estar basado en un SLA o en un problema. Por
O
ejemplo: el LA afirma que el tiempo de respuesta del usuario a una solicitud particular no debe
superar los 30 segundos. El problema es que el tiempo de respuesta medio es de 25 segundos y va en
aumento.
Un objetivo del ajuste es que el tiempo de respuesta del usuario a una solicitud particular sea de
20 segundos.
Tanto los objetivos de ajuste como los SLA deben tener tres características para ser efectivos. Deben
ser:
• Específicos
• Medibles
• Factibles
El objetivo “Hacer que la instancia se ejecute lo más rápido posible” no es específico. El objetivo
específico sería “La serie de informes de fin de mes se debe realizar en menos de 4 horas”.
Además, un objetivo debe ser rentable. Realizar el ajuste por el simple hecho de ajustar, o por gusto,
no es rentable.

Objetivos de Ajuste Efectivos (continuación)
Un objetivo medible posee cantidades objetivas que se pueden medir. Si un objetivo se puede medir,
no hay ninguna duda sobre si se está cumpliendo o no. Un objetivo específico también se puede
convertir en medible con facilidad. El objetivo “El tiempo de respuesta del usuario a una solicitud es
de 10 segundos” es fácil de exponer, pero, ¿se aplica a todas las solicitudes de usuario? ¿Es el tiempo
de respuesta medio? ¿Cómo se mide el tiempo de respuesta medio? Es esencial disponer de
definiciones específicas para el texto del objetivo. Si se cambia la exposición del objetivo por “El
tiempo de respuesta del usuario a una solicitud particular es de 20 segundos o menos”, se puede
determinar objetivamente cuándo se ha cumplido el objetivo.
Los objetivos factibles son objetivos posibles y que están dentro del control de las personas
responsables del ajuste.
A continuación, se enumeran ejemplos de objetivos factibles para un DBA típico:
• Cuando el objetivo es ajustar la instancia para crear una aplicación de alto rendimiento, pero no
se le permite cambiar el SQL ni las estructuras de datos, sólo es posible realizar una cantidad
limitada de ajustes.
• Cuando el objetivo es conseguir un tiempo de respuesta de 1 segundo, pero la latencia de red L A
D E
entre el servidor y el cliente es de 2 segundos. Sin cambiar la red, es imposible lograr un tiempo
S
de respuesta de 1 segundo.
A DO
ES
Ni siquiera en estas situaciones es imposible realizar cambios en un sentido absoluto, pero el DBA
R
G nlyฺ
siempre tiene restricciones de negocio que limitan la cantidad de dinero y recursos que puede dedicar
E
N DE use o
a la solución. Por lo que cada objetivo debe tener en cuenta la relación costo-beneficio. Si un
objetivo tiene un costo elevado pero que soluciona un problema con un costo mínimo, es mejor no
realizarlo. C IO AL
D A RIT
F UN DIST
Debería establecer siempre unos objetivos de ajuste medibles. Sin un objetivo de ajuste, es difícil
determinar si los ajustes que ha realizado son suficientes.
a nd AD
r s ity RSID
n ive IVE
c le U UN
Ora

Sesión de Ajuste General
Las sesiones de ajuste tienen el mismo procedimiento:

1. Definir el problema y exponer el objetivo.

2. Recopilar estadísticas de rendimiento actuales.
3. Tener en cuenta algunos errores de rendimiento comunes.
4. Crear una solución de prueba.
5. Implementar y medir el cambio.
6. Decida si la solución cumple el objetivo.
L A
– ¿No? Vaya al paso 3 y repítalo.
D E
– ¿Sí? Cree una nueva línea base.
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Sesión de Ajuste General y
sit RSI D
e r E que concentrarse en las áreas específicas en las que se obtienen
U niv ajustes,
A la hora de realizar I V hay
e
mayoreslresultados. LosNpasos son genéricos y se aplican a cualquier herramienta de control del
U
c
O1.raDefinir elLaproblema
rendimiento. metodología de ajuste recomendada es la siguiente:
y exponer el objetivo: éste es el paso de análisis. Las herramientas de
diagnóstico y rendimiento de Oracle utilizan un modelo de tiempo que se puede utilizar para
identificar rápidamente las áreas con problemas. El origen de la información puede referirse a
usuarios, estadísticas de base de datos, métricas o informes de diagnóstico de base de datos.
Asegúrese de recopilar datos precisos y objetivos que correspondan al problema. Exponga el
problema en términos que se puedan medir y que estén directamente relacionados con las
operaciones de la base de datos. Por ejemplo, si el tiempo de ejecución en el informe “XYZ” es
dos veces la línea base, el objetivo será conseguir que el tiempo de ejecución en el informe
“XYZ” sea igual o menor que la línea base.
2. Recopilar estadísticas actuales: examine las estadísticas del sistema host y de la base de datos.
Recopile un juego completo de estadísticas del sistema operativo y de la base de datos, y
compárelas con las estadísticas de línea base. Las estadísticas de línea base son un juego de
estadísticas recopiladas cuando la instancia se está ejecutando de manera aceptable. Examine las
diferencias para determinar qué ha cambiado en el sistema. ¿Ha cambiado el informe “XYZ”?
¿Han cambiado los datos? ¿La sesión que produce el informe está esperando algo?

Sesión de Ajuste General (continuación)
3. Tener en cuenta los errores de rendimiento comunes: a partir de la lista de diferencias en las
estadísticas recopiladas, realice una comparación con los errores de rendimiento comunes.
Determine si se ha producido alguno de estos errores en el sistema.
4. Crear una solución de prueba: incluya un modelo conceptual en la solución. La finalidad de este
modelo es ayudarle a definir una imagen general de la base de datos. Tiene que buscar la
respuesta a las siguientes preguntas:

- ¿Por qué se ha degradado el rendimiento?
- ¿Cómo se puede resolver el problema para cumplir el objetivo?
5. Implementar y medir el cambio: después de desarrollar la solución de prueba, realice el cambio
adecuado. Realice los cambios de uno en uno. Si realiza varios cambios a la vez, no sabrá cuál
de ellos es efectivo. Si el problema no se soluciona con los cambios, no sabrá si algunos de ellos
han servido de ayuda y otros han empeorado el problema. Recopile estadísticas para medir el
cambio.
6. “¿La solución cumple el objetivo?” Compare los juegos actuales con los de línea base.
Si determina que se necesitan más ajustes, regrese al paso 3 y repita el proceso. L A
E
Si la solución cumple el objetivo, convierta el juego actual de estadísticas en el nuevo juego de
D
línea base. Ha cumplido el objetivo. Deje de realizar ajustes. S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
c le U UN
Ora

Prueba
Todas las sesiones de ajuste de base de datos tienen algunos

pasos en común. ¿Cuál de los siguientes pasos no es un paso

de ajuste?
a. Desarrollar una solución de prueba.
b. Capturar estadísticas.
c. Identificar el problema.
d. Realizar una copia de seguridad.
e. Probar la solución y medir el cambio. L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Respuesta: d y
sit RSI D
e r
niv NnoIVsonEnormalmente necesarias para una sesión de ajuste del rendimiento.
Las copias de seguridad
U
c le U
Or a

Resumen
En esta lección, debe haber aprendido lo siguiente:

• Identificar las herramientas de ajuste

• Utilizar una metodología de ajuste
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Diagnósticos de Ajuste Básicos
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora
Objetivos
Al finalizar esta lección, debería estar capacitado para lo

siguiente:
• Ver los eventos de espera principales para determinar el
mayor tiempo de espera
• Ver el modelo de tiempo para diagnosticar problemas de
rendimiento
• Utilizar vistas de rendimiento dinámico para visualizar
estadísticas y eventos de espera
E LA
• Usar el proceso de control de Enterprise Manager S D
• Identificar los componentes clave de ajuste de los logs D O
S A de
alertas E
E GR nlyฺ
• Identificar los componentes clave de D E de
ajuste
e olos archivos
N s
de rastreo de usuarios IO Lu
D AC RITA
F
a n d A D
y
sit RSI D
e r
U niv NIVE
cle U
Ora

Diagnósticos de Ajuste de Rendimiento
Las herramientas de diagnóstico recopilan y aplican formato a

los siguientes tipos de datos de rendimiento:

• Estadísticas acumulativas:
– Eventos de espera con información de tiempo
– Modelo de tiempo
• Métricas: ratios de estadísticas
• Estadísticas de ejemplo: historial de sesiones activas
– Estadísticas por sesión L A
D E
– Estadísticas por SQL
D OS
– Estadísticas por servicio
E SA
– Otras dimensiones
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Diagnósticos de Ajuste y SI
sitde Rendimiento D
e r R
E básicas muestran y aplican formato a los datos de ajuste; algunas de
n iv diagnóstico
• Las herramientas
I V
l U UNDatabase
las herramientas también
e de Oracle pueden almacenar datos de ajuste de rendimiento. El software del
c
Oratres tipos de datos principales: Estadísticas acumulativas, métricas y estadísticas de ejemplo.
servidor captura información sobre su propio funcionamiento. Se recopilan
• Las estadísticas acumulativas son recuentos e información de temporización para una gran
variedad de eventos que se producen en el servidor de base de datos. Algunas son importantes,
como las "esperas por ocupación del buffer". Otras no tienen demasiado impacto en el ajuste,
como las divisiones de bloque de índice. Los recuentos raw tienen poco significado hasta que se
comparan en el tiempo. Los eventos que se recopilan durante más tiempo suelen ser los más
importantes. Las estadísticas de Oracle Database 11g se correlacionan mediante el uso de un
modelo de tiempo. Las estadísticas del modelo de tiempo se basan en un porcentaje del tiempo de
base de datos, que les sirve de base común para realizar comparaciones.
• Las métricas son recuentos de estadísticas por unidad. La unidad puede ser una medida de
tiempo, como segundos, u otra medida como transacción, sesión, espacio asignado o evento. Las
métricas sirven de base para controlar el rendimiento de forma proactiva. Puede definir umbrales
en una métrica para generar una alerta. Por ejemplo, puede definir umbrales para que cuando las
lecturas por milisegundos superen un valor, el área de archive log esté completa al 95% o se
produzca un error por una instantánea demasiado antigua.

Diagnósticos de Ajuste de Rendimiento (continuación)
• Las estadísticas de ejemplo, que forman parte del historial de sesiones activas, son potentes
herramientas incluidas en Diagnostics Pack que permiten echar la vista atrás. Puede visualizar
las estadísticas que se han recopilado en el pasado, en varias dimensiones, aunque ni siquiera se
le haya ocurrido especificar la recopilación de datos para ellas de antemano
L A
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
c le U UN
Ora

Herramientas de Ajuste del Rendimiento
Herramientas disponibles:
• Básicas:
– Modelo de tiempo
– Eventos de espera principales
– Tablas y vistas de rendimiento dinámico
– Log de alertas
– Archivos de rastreo
– Páginas de Enterprise Manager L A
D E
• Complementarias: Statspack
D OS
• Opciones:
E SA
– Diagnostics Pack
E GR nlyฺ
– Tuning Pack
N DE use o
C IO AL
D A RIT
F
a n d A D
Herramientas de Ajuste s y I D
itdel Rendimiento
S
e r R
EDatabase se almacenan en diversas tablas y vistas. Algunas
U nseivalmacenan
• Las estadísticas
estadísticas
de Oracle
I V
N en tablas permanentes, como las estadísticas que recopila
c l e
DBMS_STATS U
en objetos de base de datos para que las utilice el optimizador. Muchas de las
r a
O estadísticas que se utilizan para el ajuste del rendimiento se almacenan en tablas y vistas
dinámicas que están basadas en memoria. Estas estadísticas no se guardan cuando se cierra la
instancia.
• El log de alertas es un listado cronológico de los eventos de la base de datos y los mensajes
informativos. El log de alertas puede aportar información importante sobre el funcionamiento de
la base de datos, las áreas que se podrían ajustar e información de referencia relacionada con los
informes de ajuste.
• Los procesos en segundo plano y de usuario crean archivos de rastreo cuando se producen
determinados eventos. En ocasiones, estos archivos de rastreo le permiten comprender los
problemas de rendimiento., como advertencias en el archivo de rastreo de LGWR sobre
escrituras redo que tardan más de 500 ms, pero que principalmente se utilizan para capturar
condiciones de error e información de depuración.
• Statspack es un juego de procedimientos y scripts que se incluye con todas las ediciones del
software de Oracle Database. Diagnostics Pack es una opción con licencia independiente que es
necesaria para utilizar el repositorio de carga de trabajo automática (AWR) y las herramientas
basadas en AWR. Tuning Pack también posee una licencia independiente. Tuning Pack necesita
Diagnostics Pack. Diagnostic Pack y Tuning Pack sólo están disponibles con el software de
Enterprise Edition de Oracle Database.

Herramientas de Ajuste del Rendimiento (continuación)
• Statspack y Diagnostics Pack (AWR) mantienen las instantáneas independientes de un subjuego
importante de estadísticas en memoria dinámicas que, de lo contrario, se perderían al cerrar una
instancia. Las ventajas de AWR son que gestiona el almacenamiento de estos datos de forma
automática y proporciona una interpretación mejorada de los datos de rendimiento.
Nota: las instantáneas de Statspack y de AWR no son compatibles.
Algunas de las páginas de Enterprise Manager relacionadas con el ajuste están disponibles para
cualquier nivel del software de Oracle Database: Personal, Standard Edition o Enterprise Edition.
Varias de las páginas de Enterprise Manager relacionadas con el ajuste requieren Diagnostic Pack o
Tuning Pack.
L A
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
c le U UN
Ora

Objetivos de Ajuste
Los objetivos del ajuste son:

• Minimizar el tiempo de respuesta

• Aumentar el rendimiento global
• Aumentar las capacidades de carga
• Reducir el tiempo de recuperación
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Objetivos de Ajuste sit y SI D
e r
v seIpueden R
E resumir con la siguiente frase: "Hacer más en menos tiempo". En
niajuste
Los objetivos de
U V
función de
c l UNesto se traduce en lo siguiente:
ecada entorno,
O•• raMinimizar el tiempo de respuesta o reducir el tiempo de espera del usuario.
Aumentar el rendimiento global, lo que significa reducir el tiempo para realizar un trabajo o un
juego de trabajos.
• Aumentar las capacidades de carga, lo que significa permitir más tareas o liberar capacidad para
realizar otras tareas.
En algunos entornos, hay que buscar un equilibrio. En entornos de procesamiento de transacciones en
línea (OLTP) de gran volumen, se puede permitir un tiempo de respuesta del usuario mayor para
obtener más transacciones totales de muchos usuarios. Los estudios demuestran que, en un entorno
basado en la Web, el tiempo de respuesta del usuario debe ser inferior a 7 segundos o el usuario se irá
a otro sitio. En este caso, todo lo demás está subordinado al tiempo de respuesta.
Los requisitos de negocio afectan a los objetivos de ajuste. El rendimiento puede estar limitado por
problemas de seguridad, como en el objetivo "Reducir el tiempo de recuperación". En un entorno de
negocio, donde el tiempo de inactividad se traduce en cientos o miles de dólares por minuto, la
sobrecarga que supone proteger la instancia de fallos y reducir el tiempo de recuperación es más
importante que el tiempo de respuesta del usuario. Por lo que la recuperación del ajuste debe
equilibrar la sobrecarga en curso de las escrituras en disco adicionales para mantener los archivos
redo log y el objetivo de proteger el negocio de las pérdidas.

Eventos de Tiempo Principales
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI
Eventos de Tiempo Principales D
e r
v Foreground E Wait Events es un buen punto de partida cuando se realiza el
La sección Topn5iTimed I V
ajuste. Ale U N ver los eventos de tiempo principales. Los eventos de tiempo
Upuede
simple vista,
c
ra siempre tienen valores. En este ejemplo, "free buffer waits" y "buffer busy waits"
principales
O
consumen más del 75% del tiempo de base de datos al combinarse.
La sección de eventos de tiempo principales está disponible en ambos informes de AWR y Statspack.
En este informe de eventos se proporciona orientación para realizar un estudio más detallado. En este
caso, los dos principales eventos de tiempo indican un problema en la caché de buffers de la base de
datos.

Tiempo de Base de Datos
Tiempo de Base de Datos =

Tiempo de Espera
de Base de Datos +
Tiempo de CPU de L A
D E
Base de Datos
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Tiempo de Base de Datos y
sit RSI D
e r
v IenVreducirE las esperas. Su objetivo es mejorar el tiempo de respuesta del
niconsiste
El ajuste no sólo
U
usuario final
c l UN el promedio de recursos que utiliza cada solicitud. En ocasiones, las dos
e y/o minimizar
ravan unidas pero, en otros casos, hay un equilibrio (por ejemplo, con una consulta paralela). En
cosas
O
general, se puede decir que el ajuste consiste en evitar el consumo o la retención de recursos sin
sentido.
Cualquier solicitud a la base de datos se compone de dos segmentos distintos: un tiempo de espera
(tiempo de espera de base de datos) y un tiempo de servicio (tiempo de CPU de base de datos). El
tiempo de espera es la suma de todas las esperas para acceder a diversos recursos de la instancia de
la base de datos. El tiempo de CPU es la suma del tiempo que se dedica a trabajar realmente en la
solicitud. Estos tiempos no se componen necesariamente de una espera y un bloque de tiempo de
CPU. A menudo, los procesos esperarán un período de tiempo corto para un recurso de base de datos
y, a continuación, se ejecutarán brevemente en la CPU y, así de forma repetida.
El ajuste consiste en reducir o eliminar el tiempo de espera, y en reducir el tiempo de CPU. Esta
definición se aplica a cualquier tipo de aplicación, procesamiento de transacciones en línea (OLTP) o
almacén de datos (DW).
Nota: un sistema muy ocupado muestra un tiempo de CPU de base de datos mayor y esto puede
inflar otros tiempos.

Dimensiones de Ajuste de Tiempo de CPU
y de Espera
Tiempo de base de datos = tiempo de CPU de base
de datos + tiempo de espera de base de datos
Tiempo
de CPU Posiblemente
necesite ajuste Aplicación
SQL escalable
No se L A
Necesita obtiene D E
ajuste de mejora
D OS
instancia/RAC al agregar
E SA
CPUs/nodos
E GR nlyฺ
E de
DTiempo e o
N s
C IO Aespera Lu
D A RIT
F
a n d A D
Dimensiones de Ajuste y
sitde Tiempo D
SI de CPU y de Espera
e r R
Al ajustar el sistema,
U I VE que compare el tiempo de CPU con el tiempo de espera del
niv esNimportante
e comparación
sistema. lEsta
c U permite determinar qué parte del tiempo de respuesta se invierte en
O r a
trabajo útil y cuánto en esperar recursos potencialmente retenidos por otros procesos. Como norma
general, los sistemas en los que predomina el tiempo de CPU, normalmente necesitan menos ajuste
que aquellos en los que predomina el tiempo de espera. Sin embargo, unas sentencias SQL mal
escritas pueden provocar un uso intenso de CPU.
La proporción de tiempo de espera respecto al tiempo de CPU siempre tiende a aumentar a medida
que aumenta la carga en el sistema, los aumentos bruscos del tiempo de espera indican una
contención y se deben solucionar para contar con una buena escalabilidad.
Cuando el aumento del tiempo de espera indica una contención, al agregar más CPU a un nodo o
nodos a un cluster se proporcionarían ventajas muy limitadas. Por el contrario, un sistema en que la
proporción de tiempo de CPU no disminuye significativamente a medida que aumenta la carga, se
puede escalar mejor y probablemente se beneficiaría de la adición de CPU o instancias de Real
Application Clusters (RAC).
Nota: los informes del repositorio de carga de trabajo automática (AWR) y Statspack muestran el
tiempo de CPU junto con el tiempo de espera en la sección Top 5 Events, si la parte de tiempo de
CPU está entre los cinco eventos principales.

Modelo de Tiempo: Visión General
• El modelo de tiempo es un juego de estadísticas que ofrece
una visión general del lugar en el que se emplea el tiempo
dentro de Oracle Database. Tiempo de base de datos

• Todas las estadísticas utilizan la misma
Analizar
dimensión: tiempo.
ar
ct
Jav
ne
a QL
• Se puede acceder a las estadísticas a
Co
PLS
través de:
SQL
– V$SYS_TIME_MODEL
– V$SESS_TIME_MODEL
• El tiempo de base de datos representa el tiempo total E LA
D
dedicado a realizar llamadas a la base de datos en las OS
sesiones de usuario. S AD
• El objetivo del ajuste es reducir el tiempo deG RE de
base yฺ datos.
E n l
• Con el tiempo de base de datos, puede DEmedir
s eeloimpacto en
N u de datos.
IO deAlaLbase
el rendimiento de cualquier entidad
D AC RIT
F
a n d A D
Modelo de Tiempo: Visión y
sit General SI D
e r E R
En el ajuste de nuniv
sistema deV Oracle Database participan muchos componentes y cada uno tiene su
propio juego Ude N I
estadísticas. ¿Cómo se puede medir el beneficio previsto de una acción de ajuste en
c l U ejemplo, ¿el rendimiento
egeneral? Por
O r a
el sistema general mejoraría si se pasase memoria desde la
caché de buffers al pool compartido? Si se observa el sistema en su conjunto, el tiempo es el único
denominador común para realizar comparaciones entre componentes. En el servidor de Oracle
Database, la mayoría de los asesores informan sobre sus conclusiones en términos de tiempo.
También existen unas estadísticas denominadas "Estadísticas de modelo de tiempo" que aparecen
como las vistas de rendimiento V$SYS_TIME_MODEL y V$SESS_TIME_MODEL. Esta
instrumentación ayuda al servidor de Oracle Database a identificar efectos cuantitativos en las
operaciones de la base de datos.
Lo más importante de las estadísticas del modelo de tiempo es el tiempo de base de datos. Esta
estadística representa el tiempo total dedicado a llamadas a la base de datos por sesiones de usuario e
indica la carga de trabajo total de la instancia. Es la suma de los tiempos de CPU y de espera de todas
las sesiones que no están esperando en eventos de espera inactivos (sesiones de usuario activas).
La finalidad del ajuste de un sistema de Oracle Database se podría definir como la reducción del
tiempo que dedican los usuarios a realizar alguna acción en la base de datos o simplemente la
reducción del tiempo de base de datos.
Otras estadísticas del modelo de tiempo indican efectos cuantitativos (en tiempo) en acciones
específicas, como operaciones de conexión, análisis pesados y ligeros, ejecución de PL/SQL y
ejecución de Java.

Jerarquía de las Estadísticas de
Modelo de Tiempo
Tiempo de base de datos Tiempo transcurrido en segundo plano
CPU de base de datos Tiempo de CPU en segundo plano

Tiempo transcurrido en llamadas de gestión de conexiones Tiempo de CPU RMAN
Tiempo transcurrido en cargas de secuencias (copia de seguridad/restauración)
Tiempo transcurrido en la ejecución de SQL
Tiempo transcurrido en enlaces repetidos

Tiempo transcurrido en análisis
Tiempo transcurrido en análisis pesados
Tiempo transcurrido en análisis pesados (criterio de uso compartido)
Tiempo transcurrido en análisis pesados (no coincidencia de enlace) L A
D E
OS
Tiempo transcurrido en análisis fallidos
Tiempo transcurrido en análisis fallidos (falta memoria compartida) D
Tiempo transcurrido en la ejecución de PL/SQL E SA
Tiempo transcurrido en RPC de PL/SQL entrantes
E GR nlyฺ
Tiempo transcurrido en la compilación de PL/SQL
N DE use o
Tiempo transcurrido en la ejecución de Java
C IO AL
D A RIT
F
a n d A D
y
sit RdeSModelo
Jerarquía de las Estadísticas I D de Tiempo
e r Elas relaciones entre las estadísticas de modelo de tiempo. Forman dos
En la diapositiva,
n ivse enumeran
I V
U UN en segundo plano y tiempo de base de datos. El tiempo que indica un
e transcurrido
árboles: ltiempo
c
O• raTiempo
elemento secundario del árbol está incluido en el elemento principal de dicho árbol.
de base de datos: cantidad de tiempo transcurrido (en microsegundos) dedicado a
realizar llamadas a nivel de usuario de la base de datos. Aquí no se incluye el tiempo dedicado a
los procesos en segundo plano de instancias, como PMON. El tiempo de base de datos se mide
de manera acumulativa desde el momento en que se inició la instancia. Dado que el tiempo de
base de datos se calcula combinando los tiempos de todas las sesiones de usuario activas, es
posible que el tiempo de base de datos supere al tiempo real transcurrido desde que se inició la
instancia. Por ejemplo, una instancia que se haya estado ejecutando durante 30 minutos podría
tener cuatro sesiones de usuario activas cuyo tiempo de base de datos acumulativo fuera de
aproximadamente 120 minutos.
• CPU de base de datos: cantidad de tiempo de CPU (en microsegundos) dedicado a realizar
llamadas a nivel de usuario de la base de datos. Este tiempo incluye procesos en la cola de
ejecución.
• Tiempo transcurrido en cargas de secuencias: cantidad de tiempo transcurrido dedicado a
obtener el siguiente número de secuencia del diccionario de datos. Si una secuencia se almacena
en caché, ésta es la cantidad de tiempo dedicado a rellenar la caché cuando se agota. No se suma
ningún tiempo cuando se encuentra un número de secuencia en la caché. Para las secuencias que
no están almacenadas en caché, se suma algún tiempo por cada llamada a NEXTVAL.

Jerarquía de las Estadísticas de Modelo de Tiempo (continuación)
• Tiempo transcurrido en análisis: cantidad de tiempo transcurrido dedicado a analizar
sentencias SQL. Incluye el tiempo de análisis pesado y ligero.
• Tiempo transcurrido en análisis pesados: cantidad de tiempo transcurrido dedicado a realizar
análisis pesados de sentencias SQL.
• Tiempo transcurrido en la ejecución de SQL: cantidad de tiempo transcurrido en la ejecución
de sentencias SQL. Tenga en cuenta que, para las sentencias SELECT, también se incluye la
cantidad de tiempo dedicado a realizar recuperaciones de resultados de consultas.
• Tiempo transcurrido en llamadas de gestión de conexiones: cantidad de tiempo transcurrido
dedicado a realizar llamadas de conexión y desconexión de sesiones.
• Tiempo transcurrido en análisis fallidos: cantidad de tiempo dedicado a realizar análisis SQL
que, en última instancia, producen algún error de análisis.
• Tiempo transcurrido en análisis fallidos (falta memoria compartida): cantidad de tiempo
dedicado a realizar análisis SQL que producen errores de falta de memoria compartida.
• Tiempo transcurrido en análisis pesados (criterio de uso compartido): cantidad de tiempo
A
transcurrido dedicado a realizar análisis pesados de SQL cuando el análisis pesado se debe a que
L
no es posible compartir un cursor existente en la caché de SQL. D E
S
• Tiempo transcurrido en análisis pesados (no coincidencia de enlace): cantidad de tiempo
A DO
transcurrido dedicado a realizar análisis pesados de SQL cuando el análisis pesado se debe a un
ES
error de coincidencia de tamaño o tipo de enlace con un cursor existente en la caché de SQL.
R
E G nlyฺ
• Tiempo transcurrido en la ejecución de PL/SQL: cantidad de tiempo transcurrido dedicado a
DE use o
ejecutar el intérprete de PL/SQL. Aquí no se incluye el tiempo dedicado a ejecutar o analizar
N
IO AL
sentencias SQL de forma recurrente ni el tiempo dedicado a ejecutar Java Virtual Machine de
C
forma recurrente. D A RIT
UN DIST
• Tiempo transcurrido en la compilación de PL/SQL: cantidad de tiempo transcurrido
F
nd AD
dedicado a ejecutar el compilador de PL/SQL.
a
r s ity RSID
• Tiempo transcurrido en RPC de PL/SQL entrantes: tiempo dedicado a la ejecución de
n ive IVE
llamadas a procedimiento remoto (RPC) de PL/SQL entrantes. Se incluye todo el tiempo
dedicado a ejecutar SQL y Java de forma recurrente y, por lo tanto, no es fácil de relacionar con
le U UN
el tiempo transcurrido en la ejecución de PL/SQL.
c
Ora
• Tiempo transcurrido en la ejecución de Java: cantidad de tiempo transcurrido dedicado a
ejecutar Java VM. Aquí no se incluye el tiempo dedicado a ejecutar o analizar sentencias SQL
de forma recurrente, ni el tiempo dedicado a ejecutar PL/SQL de forma recurrente.
• Tiempo transcurrido en enlaces repetidos: tiempo transcurrido dedicado a repetir enlaces.
• Tiempo de CPU en segundo plano: cantidad de tiempo de CPU (en microsegundos) que
consumen los procesos en segundo plano de la base de datos.
• Tiempo transcurrido en segundo plano: tiempo total dedicado en la base de datos a las
sesiones en segundo plano (tiempo de CPU y tiempo de espera activo).
• Tiempo de CPU RMAN (copia de seguridad/restauración): tiempo de CPU dedicado a
operaciones de copia de seguridad y restauración de RMAN.

Ejemplo de Modelo de Tiempo
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Ejemplo de Modelo de t y
siTiempo SI D
e r R
Ede un informe de AWR. La información de modelo de tiempo también
U niv proviene
El ejemplo mostrado I V
N de Statspack. Estas estadísticas están ordenadas por el valor del
c l e en elU
está disponible informe
ra de tiempo de base de datos, de manera que el área que ocupa la mayoría del tiempo y sus
porcentaje
O
secundarias son las primeras que aparecen en la lista. En este ejemplo "sql execute elapsed time"
aparece en primer lugar. "Parse time elapsed" aparece a continuación, y "hard parse elapsed time" es
secundaria de "parse time elapsed". Puede ver rápidamente que los análisis pesados ocupan la
mayoría del tiempo de análisis, y el tiempo de análisis ocupa una parte significativa del tiempo de
base de datos.
Nota: la suma del porcentaje de tiempo de base de datos de las estadísticas individuales es superior
al 100%. Aunque "parse time elapsed" no se considera un secundario de "sql execute elapsed time",
hay algunos elementos que se tienen en cuenta en ambos.

Prueba
Las medidas de modelo de tiempo en la base de datos

muestran que existen esperas significativas. Esperas que

ocupan más tiempo que el tiempo de CPU. Esto indica que la
aplicación es escalable y la adición de más CPU ayudará al
rendimiento.
a. Verdadero
b. Falso
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Respuesta: b y
sit RSI D
e r E
iv estáIVdominado
Si el modelo dentiempo por las esperas, la aplicación no es escalable. La adición de
U
más CPUleno ayudaráU N
al rendimiento.
a c
Or

Vistas de Rendimiento Dinámico
Las vistas de rendimiento

dinámico proporcionan acceso

a información sobre las Datos de sesión
condiciones y los estados Eventos de espera
cambiantes en la instancia. Asignaciones de memoria
SQL en ejecución
Uso de UNDO
Cursores abiertos
Uso de redo log
LA
Etc.
D E
D OS
Instancia de Oracle E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Vistas de Rendimiento t y
siDinámico SI D
e r R
Emantiene un juego de datos dinámico en cuanto al funcionamiento y
niv Database
El servidor de Oracle
U I V
rendimiento
c l UN Estas vistas de rendimiento dinámico se basan en tablas virtuales que se
e de la instancia.
ra a partir de estructuras de memoria del servidor de base de datos. Es decir, no son tablas
generan
O
convencionales que residen en una base de datos. Las vistas V$ externalizan los metadatos
contenidos en las estructuras de memoria de una instancia de Oracle. Algunas de las vistas V$
pueden mostrar datos antes de montar o abrir una base de datos. La vista V$FIXED_TABLE
enumera todas las vistas dinámicas.
Las vistas de rendimiento dinámico incluyen información raw utilizada por AWR y Statspack y, la
siguiente información detallada, entre otras:
• Sesiones
• Eventos de espera
• Bloqueos
• Estado de copia de seguridad
• Asignación y uso de la memoria
• Parámetros del sistema y de sesión
• Ejecución de SQL
• Estadísticas y métricas
Nota: las vistas DICT y DICT_COLUMNS también contienen los nombres de estas vistas de
rendimiento dinámico.

Vistas de Rendimiento Dinámico:
Ejemplos de Uso
SQL> SELECT sql_text, executions

a 2 FROM v$sqlstats
3 WHERE cpu_time > 200000;
SQL> SELECT * FROM v$session

b 2 WHERE machine = 'EDRSR9P1' and
3 logon_time > SYSDATE - 1;
L A
D E
c
SQL> SELECT sid, ctime
D OS
2 FROM v$lock WHERE block > 0;
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
siDinámico: D
SI Ejemplos de Uso
e r R
E de rendimiento dinámico, y los DBA también pueden consultarlas
U niv utiliza
Enterprise Manager I V
vistas
N tres ejemplos mostrados en la diapositiva responden a las siguientes
cuando sea
c l e necesario.ULos
Oa.ra¿Cuáles son las sentencias SQL y su número asociado de ejecuciones en las que el tiempo de
preguntas:
CPU empleado es superior a 200.000 microsegundos?

b. ¿Qué sesiones se conectaron desde la computadora EDRSR9P1 el último día?
c. ¿Cuáles son los identificadores de sesión de las sesiones que actualmente retienen un bloqueo
que está bloqueando a otro usuario y cuánto tiempo se ha retenido ese bloqueo? (block puede
ser 1 o 0; 1 indica que esta sesión es la que realiza el bloqueo).
Las vistas de rendimiento dinámico se crean en estructuras de memoria que contienen las estadísticas
y permiten ver muchas de las estadísticas que se utilizan en el ajuste de rendimiento. La mayoría
contiene información sobre un componente específico de la instancia. En este curso, utilice la
información de las vistas de rendimiento dinámico que se utilizan de forma indirecta para ajustar
componentes específicos. Para obtener una lista completa de las diversas vistas de rendimiento
dinámico, consulte Oracle Database Reference (Referencia de Oracle Database).
La mayoría de las vistas de rendimiento dinámico no las utiliza directamente el DBA con frecuencia.
Las herramientas del repositorio de carga de trabajo automática (AWR) y Statspack resumen y
presentan las estadísticas con un formato más fácil de usar. En ocasiones, resulta útil para saber que
estas vistas existen y así investigar los detalles.

Vistas de Rendimiento Dinámico:
Consideraciones
• Estas vistas son propiedad de SYS.
• Las vistas disponibles son diferentes en momentos distintos:

– Si se ha iniciado la instancia.
– Si se ha montado la base de datos.
– Si se ha abierto la base de datos.
• Puede consultar V$FIXED_TABLE para ver todos los nombres
de vistas.
• Estas vistas a menudo se denominan "vistas con formato v-$".
E LA
• Todas las lecturas en estas vistas son lecturas actuales. S D
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
siDinámico: D
SI Consideraciones
e r R
E datos que no se aplican a todos los estados de una instancia o de
n iv Icontienen
Algunas vistas dinámicas V
U N
una base de datos. Por ejemplo,
le puedeUconsultar si se acaba de iniciar una instancia, pero no se ha montado ninguna
baseadecdatos, V$BGPROCESS para ver la lista de los procesos en segundo plano
Orse están ejecutando. Si consulta V$DATAFILE para ver el estado de los archivos de datos de la
que
base de datos, recibirá el error ORA-01507: database not mounted , porque el montaje de
una base de datos es el que lee el archivo de control para conocer los archivos de datos asociados a
una base de datos. No es apropiado consultar determinadas vistas V$ en algunos estados de la
instancia.
Estas vistas se basan en estructuras de memoria y los datos en las mismas son acumulativos desde el
inicio. Los datos se restablecen al inicio. Por lo tanto, no puede saber cuántas veces X (por ejemplo,
"lecturas físicas") se producen entre T1 y T2 calculando "delta" de su contador si se ha reiniciado la
instancia durante dicho período de tiempo.
Debido a que todas las lecturas de estas vistas son lecturas actuales, no hay ningún mecanismo de
bloqueo en estas vistas, por lo que no hay garantías de que los datos sean una lectura consistente.
Ocasionalmente, pueden aparecer anomalías en las estadísticas cuando se han actualizado una o más
tablas relacionadas con una estadística determinada, pero no todas las tablas han completado la
actualización cuando se produce la selección.
SELECT_CATALOG_ROLE es el rol predefinido mínimo que se puede otorgar para permitir a un
usuario seleccionar las vistas V$. Una buena práctica de seguridad es crear un rol diseñado después
de SELECT_CATALOG_ROLE, pero con sólo un mínimo de otorgaciones requerido.

Niveles de Estadísticas
V$STATISTICS_LEVEL
STATISTICS_LEVEL
BASIC TYPICAL ALL
L A
D E
D OS
Desactivar todas Estadísticas E SA
adicionales 
Valor por defecto R yฺ
Gdiagnósticos
las funciones de
recomendado E E
para
o n l
ajuste automático
N D uSQL s e manuales
C IO AL
D A RIT
F
a n d A D
Niveles de Estadísticas y
sit RSI D
e r E
ivnivel deIVrecopilación
Para determinarnel de estadísticas en la base de datos, defina el valor del
parámetro
l e U U N
STATISTICS_LEVEL. Los valores de este parámetro son:
c
OraBASIC:
• no se recopila ningún asesoramiento ni ningún otro dato estadístico. Puede definir
manualmente otros parámetros de recopilación de estadísticas como, por ejemplo,
TIMED_STATISTICS y DB_CACHE_ADVICE. No se recopilan muchas de las estadísticas
necesarias para una línea base de rendimiento. Oracle recomienda no desactivar la recopilación
de estadísticas.
• TYPICAL: éste es el valor por defecto. Se recopilan datos para las estadísticas a nivel de
segmento, las estadísticas de tiempo y todos los asesores. Se sustituye el valor de otros
parámetros de recopilación de estadísticas.
• ALL: se realiza una recopilación de todos los datos a nivel de TYPICAL, las estadísticas de
tiempo del sistema operativo y las estadísticas de ejecución de orígenes de fila. Se sustituye el
valor de otros parámetros de recopilación de estadísticas.
Consulte V$STATISTICS_LEVEL para determinar qué otros parámetros se ven afectados por el
parámetro STATISTICAL_LEVEL.
SQL> select statistics_name, activation_level
2 from v$statistics_level
3 order by 2;

Niveles de Estadísticas (continuación)
STATISTICS_NAME ACTIVAT
---------------------------------------- -------
Plan Execution Statistics ALL
Timed OS Statistics ALL
Timed Statistics TYPICAL
Segment Level Statistics TYPICAL

PGA Advice TYPICAL
Shared Pool Advice TYPICAL
Modification Monitoring TYPICAL
Longops Statistics TYPICAL
Bind Data Capture TYPICAL
Ultrafast Latch Statistics TYPICAL
Threshold-based Alerts TYPICAL
Global Cache Statistics TYPICAL
Active Session History TYPICAL
Undo Advisor, Alerts and Fast Ramp up TYPICAL
L A
Streams Pool Advice TYPICAL
D E
OS
Time Model Events TYPICAL
Plan Execution Sampling TYPICAL D
Automated Maintenance Tasks TYPICAL
E SA
SQL Monitoring
Adaptive Thresholds Enabled E GR nlyฺ
TYPICAL
TYPICAL
V$IOSTAT_* statistics
N DE use o
TYPICAL
Buffer Cache Advice
C IO AL TYPICAL
MTTR Advice
D A RIT TYPICAL
Estos parámetros de estadísticas también UseNpueden I T de manera individual. Son los siguientes:
Sdefinir
TIMED_STATISTICS: está
F
ddefinido D
en TRUE para recopilar estadísticas de tiempo.
•
a n A D
• DB_CACHE_ADVICE:
r S IDsiguientes
sity estadísticas
acepta los valores:
- OFF: no seerecopilan
i v E R y no se utiliza memoria.
- READY:
U IV estadísticas, pero se asigna memoria. Al definir
n no seNrecopilan
c l e U
DB_CACHE_ADVICE en READY antes de definirlo en ON, se evitan errores de memoria a
a
Or - laON:hora de recopilar estadísticas sobre el uso de la caché de buffers.
se recopilan estadísticas y se asigna memoria. Al cambiar el estado de
DB_CACHE_ADVICE de OFF a ON, se puede producir un error si no está disponible la
memoria necesaria.
• TIMED_OS_STATISTICS: especifica el intervalo (en segundos) en el que una instancia de
Oracle recopila estadísticas del sistema operativo cuando se realiza una solicitud desde el cliente
al servidor o cuando termina una solicitud.
Cuando ALTER SESSION modifica STATISTICS_LEVEL, se activan o se desactivan los
siguientes asesores o estadísticas únicamente en la sesión local. Su estado en el sistema no cambia.
• Estadísticas de tiempo
• Estadísticas de tiempo del sistema operativo
• Estadísticas de ejecución de plan

Estadísticas de Actividad de la Instancia y
Eventos de Espera
Actividad de instancia Vistas

Eventos de espera de rendimiento
dinámico L A
D E
D OS
E SA
E GR nlyฺ
Informes
N DE use o
C IO AL
D A RIT
F
a n d A D
Estadísticas de Actividad y I D
sit deRlaSInstancia y Eventos de Espera
v e r E
Oracle Database
U nimantiene
N I V
varias métricas que reflejan una actividad interna en una instancia. Estas
c e exponenU
métricaslse al DBA mediante vistas de rendimiento dinámico. Muchas de estas vistas
O r a
reflejan un juego de contadores estadísticos que se inicializan en 0 al inicio de la instancia y se
incrementan hasta que se cierra la instancia.
Las estadísticas de actividad de la instancia y eventos de espera son las dos clases de métricas que
generalmente controlan el proceso de investigación de ajuste de rendimiento.
Los desarrolladores proporcionan estadísticas de actividad de la instancia para ayudar a depurar
diferentes funciones de software. Se pueden relacionar o no directamente con eventos de espera u
otras métricas. Algunas de estas estadistas son útiles para obtener diagnósticos de rendimiento como
"cpu de tiempo de análisis", "lecturas físicas" y "confirmaciones de usuario". Se puede ver una lista
completa de estadísticas de actividad de instancia consultando V$STATNAME con valores de nivel
de la instancia acumulados disponibles mediante V$SYSSTAT. Para obtener más información sobre
las estadísticas de actividad, consulte Oracle Database Reference 11g Release 2, Appendix E
Statistics Descriptions (Referencia de Oracle Database 11g Versión 2, Descripciones de
Estadísticas, Apéndice E) No se tratan todos los nombres de estadísticas.
.

Estadísticas de Actividad de la Instancia y Eventos de Espera (continuación)
Los eventos de espera son contadores que incrementan un proceso de servidor o un thread para
indicar que tuvo que esperar a que un recurso estuviera disponible o que se produciera algún otro
evento para poder continuar con el procesamiento. Las estadísticas de eventos de espera revelan
diferentes síntomas de problemas que pueden afectar al rendimiento como, por ejemplo, la
contención de bloqueos internos, contención de buffers y contención de E/S. Recuerde que se trata
sólo de síntomas de problemas y no de las causas reales. La lista completa de eventos de espera está
en la vista V$EVENT_NAME con valores de nivel de instancia acumulados expuestos mediante
V$SYSTEM_EVENT. Para obtener más información sobre los eventos de espera, consulte Oracle
Database Reference 11g Release 2, Appendix C Oracle Wait Events.
(Referencia de Oracle Database 11g, Versión 2, Eventos de Espera de Oracle, Apéndice C).Las
métricas de la base de datos proporcionan los datos raw que se utilizan para determinar lo que hay
que ajustar y si el ejercicio de ajuste ha cumplido el objetivo. Statspack y AWR realizan las
instantáneas de estos datos, realizan cálculos según estas instantáneas y proporciona informes de la
información derivada. AWR va un paso más allá que Statspack y realiza recomendaciones a través de
monitor de diagnóstico de base de datos automático (ADDM). AWR incluye información adicional L A
D
no encontrada en el informe de Statspack por defecto y puede presentar su informe en formatoE
S
HTML.
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
cle U UN
Ora

Clases de Estadísticas del Sistema
V$SYSSTAT Usuario
Depuración
Redo
SQL
Clases de
estadísticas del
sistema
RAC L A
D E
Puesta en cola
D OS
E SA
OS
E GR nlyฺ
V$STATNAME Caché D E e o V$SESSTAT
I O N L us
D AC RITA
F
a n d A D
Clases de Estadísticas y
t Sistema
sidel SI D
e r R
E las clases de estadísticas que se almacenan en las vistas
iv se describen
En esta diapositiva,
n I V
V$SESSTATl U UN Es necesario crear clases para esas estadísticas, porque hay un gran
e y V$SYSSTAT.
c
ra de ellas. Cada estadística puede pertenecer a una o más clases. La columna CLASS de cada
número
O
estadística contiene un número que representa una o más clases de estadísticas. Los siguientes
números de clases son adicionales:
• 1, User
• 2, Redo
• 4, Enqueue
• 8, Cache
• 16, OS
• 32, Real Application Clusters
• 64, SQL
• 128, Debug
Por ejemplo, el valor de clase 72 representa una estadística que está relacionada con las sentencias
SQL y el almacenamiento en caché.
Nota: algunas estadísticas sólo se rellenan si el parámetro de inicialización TIMED_STATISTICS
está definido en true.

Visualización de Estadísticas
Las estadísticas de actividad de la instancia se recopilan para:

• Sesiones
– Todas las sesiones V$SESSTAT
– Sesión actual V$MYSTAT
• Servicios V$SERVICE_STATS
• Sistema V$SYSSTAT
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI
Visualización de Estadísticas D
e r E de todas las estadísticas de actividad de la instancia a nivel del
El servidor muestra
n iv un resumen
I V
sistema en
l U UN
ela vista V$SYSSTAT. Puede consultar esta vista para buscar los totales acumulativos
c
raque se inició la instancia. En todos los niveles hay un identificador de estadísticas que se puede
desde
O
unir a la tabla V$STATNAME.
Estadísticas a nivel de sistema
SQL> SELECT name, class, value FROM v$sysstat;
NAME CLASS VALUE
------------------ ------ ----------
logons cumulative 1 6393
logons current 1 10
opened cursors cumulative 1 101298
table scans (short tables) 64 6943
table scans (long tables) 64 344
redo entries 2 1126226
redo size 2 816992940
Los resultados mostrados son sólo una muestra parcial de la salida.
Todas las vistas de estadísticas mostradas incluyen las columnas NAME, CLASS y VALUE. La vista
de nivel de servicio incluye SERVICE_NAME y la vista de nivel de sesión incluye la columna SID
(identificador de sesión). Le permiten la unión a las vistas V$SERVICE_NAME y V$SESSION.

Visualización de Estadísticas (continuación)
Estadísticas a Nivel de Servicio
Los datos de servicio se acumulan desde el inicio de la instancia. El nombre de servicio permite
recopilar estadísticas por un nombre de servicio de conexión. Esto es muy útil para controlar el
rendimiento por aplicación. Todos los usuarios que se conectan utilizan un nombre de servicio
específico por aplicación.
Ejemplo
Siempre hay dos servicios definidos: SYS$BACKGROUND y SYS$USERS. Se pueden crear hasta
116 servicios adicionales basados en el parámetro SERVICE_NAMES o se pueden definir con el
paquete DBMS_SERVICE. Los datos de servicio se acumulan desde el inicio de la instancia.
El servidor de Oracle Database muestra todas las estadísticas de servicios calculadas en la vista
V$SERVICE_STAT. Puede consultar esta vista para buscar los totales acumulativos de servicios
desde que se inició la instancia.
SQL> select service_name, stat_name, value
2 from v$service_stats;
L A
SERVICE_NAME STAT_NAME VALUE D E
--------------- -------------------- ----------
D OS
SYS$USERS user calls 6977
E SA
GR nlyฺ
SERV1 user calls 532
SYS$BACKGROUND user calls 0 E
orcl.oracle.com
orclXDB
user calls
user calls N DE use o
18948
0
C IO AL
SYS$USERS
SERV1
DB time
DB time D A RIT 84608280
222965588
SYS$BACKGROUND F UN DIST
DB time 0
orcl.oracle.com
a nd AD
DB time 55877745
orclXDB
r s ity RSIDDB time 0
ive IVcon
Estadísticas Relacionadas
n E la Sesión
l U
Puede visualizar UN de Oracle
e Elinformación de la sesión actual para cada usuario conectado en la vista
a c
V$SESSION.
r servidor Database muestra todas las estadísticas de sesiones calculadas
O
en la vista V$SESSTAT y las estadísticas para la sesión actual se muestran en V$MYSTAT.
Ejemplo
Determinar las sesiones que consumen más de 30.000 bytes de memoria PGA.
SQL> SELECT username, name, value
2 FROM v$statname n, v$session s, v$sesstat t
3 WHERE s.sid=t.sid
4 AND n.statistic#=t.statistic#
5 AND s.type='USER'
6 AND s.username is not null
7 AND n.name='session pga memory'
8 AND t.value > 30000;
USERNAME NAME VALUE

---------- ------------------- -----------
SYSTEM session pga memory 468816

Visualización de Estadísticas de SGA
SQL> SELECT * FROM V$SGAINFO;

NAME BYTES RES

-------------------------------- ---------- ---
Fixed SGA Size 1303132 No
Redo Buffers 17780736 No
Buffer Cache Size 50331648 Yes
Shared Pool Size 142606336 Yes
Large Pool Size 4194304 Yes
Java Pool Size 12582912 Yes L A
Streams Pool Size 0 Yes D E
Shared IO Pool Size 0 Yes
D OS
Granule Size 4194304 No
E SA
Maximum SGA Size
Startup overhead in Shared Pool
836976640 No
41943040 No E GR nlyฺ
Free SGA Memory Available 608174080 N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RdeSISGA
Visualización de Estadísticas D
e r
iv IVE
Estadísticas denSGA
La vista l e U
V$SGAINFO
N
Uproporciona el tamaño actual de los componentes de SGA, el tamaño de
a c
Or y memoria libre. Un breve resumen se presenta en la vista V$SGA. Todas las estadísticas de
gránulo
memoria calculadas se muestran en la vista V$SGASTAT. Puede consultar esta vista para buscar los
totales acumulativos del uso detallado de SGA desde que se inició la instancia.
Ejemplo
SQL> SELECT * FROM v$sgastat;
POOL NAME BYTES
------ ------------------------- ----------
fixed_sga 46136
db_block_buffers 409600
log_buffer 524288
shared pool free memory 8341616
shared pool SYSTEM PARAMETERS 42496
shared pool transaction 64800
shared pool dictionary cache 156524
shared pool library cache 358660
shared pool sql area 551488
…

Eventos de Espera
• Una recopilación de eventos de espera proporciona

información sobre las sesiones que tuvieron o tienen que

esperar por diferentes motivos.
• Estos eventos se muestran en la vista V$EVENT_NAME, que
tiene las siguientes columnas:
– EVENT#
– NAME Espera
– PARAMETER1 A
E L
– PARAMETER2 D
S
– PARAMETER3
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Eventos de Espera sit y SI D
e r R
Enombran en la vista V$EVENT_NAME, incluidos:
U nivde espera
Todos los eventos I V se
• Esperas
c l UNlibres
e de buffers
O• raLiberación de bloqueo interno
• Esperas por ocupación del buffer
• Lectura secuencial de archivo de base de datos
• Lectura dispersa de archivo de base de datos
• Escrituras paralelas de archivo de base de datos
• Ranura de transacción de segmento de deshacer
• Extensión de segmento de deshacer
Cada evento se asigna a una clase de espera. Esta asignación se muestra en la vista
V$EVENT_NAME. Cada evento puede tener parámetros adicionales devueltos con el evento, las
columnas PARAMETER1 a PARAMETER3 muestran el significado de estos parámetros.
Nota: las columnas de información de tiempo de eventos de espera se rellenan sólo si el parámetro
de inicialización TIMED_STATISTICS está definido en true.

Uso de la Vista V$EVENT_NAME
SQL> SELECT name, parameter1, parameter2, parameter3

2 FROM v$event_name;
NAME PARAMETER1 PARAMETER2 PARAMETER3

------------------------------- ---------- ---------- ----------
PL/SQL lock timer duration
alter system set mts_dispatcher waited
buffer busy waits file# block# id
library cache pin handle addr pin address 0*mode+name L A
log buffer space D E
log file switch (checkpoint incomplete) D OS
transaction undo seg# wrap# E SA
count
...
E GR nlyฺ
1118 rows selected.
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI
Uso de la Vista V$EVENT_NAME D
e r E hasta tres parámetros. El significado de cada uno de ellos se muestra
iv puedeIVtener
Un evento de espera
n
U UN
e PARAMETERn.
en las columnas
l
c
Ora de Esperas por Ocupación del Buffer
Evento
Este evento "buffer busy waits" registra las esperas necesarias para que un buffer esté disponible.
Estas esperas indican que hay varios buffers en la caché de buffers a los que están intentando acceder
simultáneamente varios procesos.
Este evento va acompañado de tres parámetros:
• FILE# y BLOCK#: Estos parámetros identifican el número de bloque en el archivo de datos que
se identifica por el número de archivo del bloque por el que tiene que esperar el servidor.
• ID: El evento de "buffer busy waits" se llama desde diferentes lugares en la sesión. Cada lugar
del núcleo apunta a una razón diferente. ID se refiere al lugar de la sesión que llama a este
evento.
Evento de Cambio de Archivo Log (Punto de Control Incompleto)
El evento "log file switch (checkpoint incomplete)" registra esperas por un cambio de log, porque la
sesión no se puede ajustar en el siguiente log. El ajuste no se puede realizar porque el punto de
control de ese log no se ha completado. Este evento no tiene ningún parámetro.

Clases de Espera
V$SESSION_WAIT_CLASS V$SYSTEM_WAIT_CLASS
Recursos internos de base de datos
Concurrency
Procesos de E/S
log file sync Commit System I/O en segundo plano
Procesos de E/S
Mensajes User I/O en primer plano
Network
de red
Sesiones Comandos
Idle Clases de Administrative
inactivas DBA
espera
Código de L A
aplicación Application Other
Deberían ser
escasos D E
de usuario
D OS
S A
Recursos de Cluster R E
Configuration GConfiguración de instancia/
RAC E on base l
de y ฺ
datos inadecuada
Scheduler
E
D use V$EVENT_NAME
V$SERVICE_WAIT_CLASS Gestor
IO ALN de recursos
A RITC
D
F
a n d A D
Clases de Espera y
sit RSI D
e r E de eventos de espera posibles en Oracle Database 11g se clasifican
en clases de U n ven función
Los numerosos yidiferentes
espera I Vtipos
N de las soluciones relacionadas con ese evento. Cada evento sólo está
c l
relacionadoe con una U
clase de espera. Esto permite realizar un análisis de alto nivel de los eventos de
O r a
espera. Por ejemplo, los bloqueos exclusivos de transacción (TX) suelen ser un problema a nivel de
aplicación y los bloqueos de gestión de espacio de segmento (HW) suelen ser un problema de
configuración. Las siguientes clases de espera son las más comunes:
• Application: esperas de bloqueo causadas por bloqueos a nivel de fila o comandos de bloqueo
explícitos.
• Administration: comandos de DBA que hacen esperar a otros usuarios (por ejemplo, una
reconstrucción de índices).
• Commit: esperas de una confirmación de escritura de redo log después de un comando commit.
• Concurrency: análisis y contención de bloqueo y bloqueo interno de caché de buffers
simultáneos.
• Configuration: espacio de buffers de log demasiado bajo, tamaños de archivos log, tamaño de
caché de buffers, tamaño de pool compartido, asignación de ranura de transacciones (ITL),
contención de cola de HW o contención de cola de asignación de espacio (ST).
• User I/O: esperas de bloques que se leen fuera del disco.
• Network Communications: esperas de datos que se envían por la red.
• Idle: eventos de espera relacionados con sesiones inactivas, como “SQL*Net message from
client”.
Nota: la clase Other contiene esperas que no se deberían producir normalmente en un sistema. Por
ejemplo, "wait for EMON to spawn".

Visualización de Estadísticas de Eventos de Espera
EVENT X X X
• Niveles de estadísticas de TOTAL_WAITS X X X
evento de espera: TOTAL TIMEOUTS X X X

TIME_WAITED X X X
– Sistema AVERAGE_WAIT X X X
– Servicio TIME_WAITED_MICRO X X X
– Sesión EVENT_ID X X X
TOTAL_WAIT_FG X
• Las columnas de estadísticas
TOTAL_TIMEOUTS_FG X
de eventos de espera TIME_WAITED_FG X
varían por vistas. AVERAGE_WAIT_FG X
L A
V$SYSTEM_EVENT
TIME_WAITED_MICRO_FG X
D E
SID
S X
SERVICE_NAME DO
X
V$SERVICE_EVENT SERVICE_NAME_HASH E SA X
WAIT_CLASS_ID G
R yฺX X
E E o nl X X
V$SESSION_EVENT N D use
WAIT_CLASS#
C IO AL
WAIT_CLASS X X
D A RIT
F
a n d A D
y D
sit RdeSIEventos de Espera
Visualización de Estadísticas
e r Ecatalogan en la vista V$EVENT_NAME.
U nivde espera
Todos los eventos I V se
l
Las estadísticas
c UN de espera acumulativas de todas las sesiones están almacenadas en
e de eventos
Ora
V$SYSTEM_EVENT, que muestra las esperas totales de un evento concreto desde el inicio de la
instancia. V$SERVICE_EVENT muestra las estadísticas de evento de espera acumulativas de cada
servicio. V$SESSION_EVENT muestra las estadísticas de evento de espera acumulativas de cada
sesión.
La mayoría de las estadísticas de evento de espera son las mismas para cada vista. Las diferencias se
han mostrado anteriormente. La vista V$SYSTEM_EVENT incluye un desglose de las estadísticas
para procesos en primer plano. V$SERVICE_EVENT incluye el servicio y V$SESSION incluye el
identificador de sesión.
Nota: V$SERVICE_EVENT no incluye las tres columnas de clase de espera, pero se obtienen
fácilmente mediante la unión a V$EVENT_NAME.
Cuando esté solucionando problemas, necesitará saber si un proceso ha esperado algún recurso.

Visualización de Estadísticas de Eventos de Espera (continuación)
Estadísticas de Eventos de Espera de Servicio
La vista V$SERVICE_EVENT muestra, por servicio, las esperas totales de un evento concreto
desde el inicio de la instancia. La vista V$SERVICE_WAIT_CLASS agrega las esperas por
servicio y clase de espera.
SQL> select service_name, event, average_wait
2 from v$service_event
3 where time_waited > 0;
SERVICE_NAME EVENT AVERAGE_WAIT

--------------- --------------------------- ------------
SERV1 log file sync 3
SERV1 db file sequential read 1
orcl.oracle.com log file sync 1
orcl.oracle.com db file sequential read 1
orcl.oracle.com db file scattered read 2
orcl.oracle.com latch: shared pool 1 L A
orcl.oracle.com latch: library cache 4 D E
S
Estadísticas de Eventos de Espera de Sesión
A DO
ES
La vista V$SESSION_EVENT muestra, por sesión, las esperas totales de un evento concreto
R
G nlyฺ
desde el inicio de la instancia. La vista V$SESSION_WAIT enumera los recursos o los eventos
E
espera actual. N DE use o
por los que están esperando las sesiones activas. V$SESSION también incluye la información de
C IO AL
A RIT
Cuando está solucionando problemas, necesita saber si un proceso ha esperado algún recurso. La
D
F
alguna sesión esperando y por qué.
UN DIST
estructura de V$SESSION_WAIT hace que sea más fácil comprobar en tiempo real si hay
SQL> SELECT sid, a ndeventAD

2 FROM s y SID
itv$session_wait
r ER
e Vwait_time
3 ivWHERE = 0;
U n I
c le UN
Ora
SID EVENT
----- ---------------------------------------
1 pmon timer
2 rdbms ipc message
3 rdbms ipc message
9 rdbms ipc message
16 rdbms ipc message
5 smon timer
8 rows selected.
Posteriormente, puede seguir investigando para saber si esas esperas se producen con frecuencia
y si se pueden correlacionar con otros fenómenos, como el uso de módulos concretos.
Nota: los eventos de espera indicados anteriormente son eventos de clase de espera inactivos que
aparecen siempre. No indican ningún problema. Existen más de 60 eventos inactivos de ese tipo
que pertenecen a la clase de espera "Idle" (número de clase de espera 6).

Eventos de Espera Más Comunes
Evento de Espera Área

Esperas por ocupación del buffer Caché de buffers, DBWR
Esperas de buffers libres Caché de buffers, DBWR, E/S
Lectura dispersa de archivo de Ajuste de E/S, SQL

base de datos
Lectura secuencial de archivo de
base de datos
Esperas por cola (enq:) Bloqueos L A
D E
Esperas de caché de biblioteca Mutex/Bloqueos internos
D OS
Espacio de buffer de log E/S de buffer de log ES
A
G R yฺ
Sincronización de archivo log ConfirmaciónE Een exceso,
o l
nE/S
N D use
C IO AL
D A RIT
F
a n d A D
Eventos de Espera Más y
sitComunes SI D
e r R
E de eventos de espera y las áreas de componentes que podrían ser el
U niv N
La diapositiva muestra una
I Vlista
U Las definiciones internas de estos eventos de espera pueden cambiar de una
origen deleestas esperas.
c
O r a
versión a otra, y pueden hacer que otros eventos sean más comunes. Para obtener una descripción de
todos los eventos de espera para una versión de base de datos determinada, consulte Oracle Database
Reference (Referencia de Oracle Database) asociada a la versión de la base de datos.
Las estadísticas de los eventos de espera a nivel del sistema resultan más útiles si se pueden
correlacionar a un período de tiempo con la actividad conocida. La vista V$SYSTEM_EVENT
proporciona sólo los totales desde el inicio de la instancia. Un método práctico es capturar las
estadísticas en una tabla a una hora y, a continuación, volver a capturar las estadísticas más tarde.
Esto le permitirá comparar el cambio en los valores de las estadísticas en un período de tiempo
determinado. Esto elimina las estadísticas relacionadas con el inicio de la instancia y reduce el juego
de posibles problemas.
Statspack y AWR siguen este método con el uso de instantáneas para capturar estadísticas, eventos
de espera y métricas.

Uso de la Vista V$SESSION_WAIT
SQL> SELECT sid, seq#, event, wait_time, state

2 FROM v$session_wait;
SID SEQ# EVENT WAIT STATE

TIME
--- - -- ---- -------------------------------- -------
1 1284 pmon timer 0 WAITING
2 1697 rdbms ipc message 0 WAITING
L A
5
6
114
14
smon timer
SQL*Net message from client
0
-1
WAITING
WAITED D E
SHORT
D OS
TIME
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI
Uso de la Vista V$SESSION_WAIT D
e r
iv IV
En esta vista, senenumeran losErecursos o los eventos por los que están esperando las sesiones
U UN también está disponible en la vista V$SESSION. Esta vista es útil en
e Esta información
actualmente.
l
ra c
el diagnóstico de sesiones que proceden de forma muy lenta o parecen que se han colgado.
O
Parámetro de Inicialización TIMED_STATISTICS
Defina el parámetro TIMED_STATISTICS en TRUE para recuperar valores de la columna
WAIT_TIME. Se trata de un parámetro de inicialización dinámico.
Columnas
• SID: identificador de sesión.
• SEQ#: número de secuencia que identifica la espera.
• EVENT: recurso o evento por el que se espera.
• STATE: estado de espera actual. Los valores posibles son:
• WAITING: la sesión está actualmente esperando.
• WAITED UNKNOWN TIME: se desconoce la duración de la última espera; éste es el valor
si el parámetro TIMED_STATISTICS está definido en False.
• WAITED SHORT TIME: la última espera tiene un valor inferior a una centésima de
segundo.
• WAITED KNOWN TIME: duración de la última espera especificada en la columna
WAIT_TIME_MACRO.

Uso de la vista V$SESSION_WAIT (continuación)
Columnas (continuación)
Cada uno de los tres parámetros (P1, P2, P3) tiene las siguientes columnas
Nota: no se utilizan todas las columnas de parámetros para todos los eventos.
• P1TEXT: descripción del primer parámetro adicional, que se corresponde con el parámetro
PARAMETER1 descrito para la vista V$EVENT_NAME.
• P1: primer valor de parámetro adicional.

• P1RAW: primer valor de parámetro adicional, en formato hexadecimal.
• WAIT_TIME
Valor Explicación
>0 El último tiempo de espera de la sesión.
=0 La sesión está esperando.
= –1 El valor es inferior a 1/100 de segundo.
= –2 El sistema no puede proporcionar información de tiempo.
• SECONDS_IN_WAIT: número de segundos que ha esperado el evento.
• STATE: Waiting, Waited Unknown Time, Waited Short Time (menos de una centésima de L A
segundo) o Waited Known Time (el valor se almacena en la columna WAIT_TIME). D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
cle U UN
Ora

Precisión de las Estadísticas del Sistema
• Vistas que incluyen tiempos en microsegundos:

– V$SESSION_WAIT, V$SYSTEM_EVENT,
V$SERVICE_EVENT,
V$SESSION_EVENT (columna TIME_WAITED_MICRO)
– V$SQL, V$SQLAREA (columnas CPU_TIME,
ELAPSED_TIME)
– V$LATCH, V$LATCH_PARENT, V$LATCH_CHILDREN
(columna WAIT_TIME)
– V$SQL_WORKAREA, V$SQL_WORKAREA_ACTIVE L A
(columna ACTIVE_TIME) D E
S
• Vistas que incluyen tiempos en milisegundos: A DO
– V$ENQUEUE_STAT (columna CUM_WAIT_TIME) R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit Rdel
Precisión de las Estadísticas D
SISistema
e r E
v determinados
Oracle Database
U nicaptura
N I V datos de rendimiento con una granularidad de milisegundos y
microsegundos. Las U
le La granularidad
vistas que incluyen tiempos en microsegundos y milisegundos se enumeran en la
r a c
diapositiva. real del evento de tiempo depende del sistema operativo.
O
Nota: las columnas de tiempo existentes de otras vistas capturan tiempos en centésimas de segundo.
La información de tiempo que se recopila en las estadísticas del sistema es acumulativa desde que se
inició la instancia. Algunas vistas de estadísticas a nivel de sesión registran el tiempo de un solo
evento.

Prueba
Las vistas de estadísticas del sistema y rendimiento dinámico

proporcionan recuentos acumulativos para las medidas

importantes en la instancia. Estas estadísticas son la base de
todos los ajustes de la instancia. Las estadísticas del sistema
son los diagnósticos más fiables disponibles.
a. Verdadero
b. Falso
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Respuesta: b y
sit RSI D
e r
v IVEde las estadísticas del sistema son la base de muchas de las
niinstantáneas
Mientras que las
U
herramientas
c l UN que se utilizan para el ajuste de rendimiento, las estadísticas
e de diagnóstico
O ra
acumulativas raw incluyen todo desde el inicio de la instancia, incluyendo calentamientos y tiempo
inactivos. Las estadísticas raw no son tan útiles como los valores delta proporcionados por las
instantáneas que cubren los períodos de interés.

Uso de las Funciones de los Paquetes
Supervisión y ajuste Supervisión y ajuste
con paquetes sin paquetes
Database Diagnostics Pack

• Repositorio de Carga de Trabajo Automática
• Monitor de Diagnóstico de Base de Datos Automático (ADDM)
• Rastreos SQL
• Historial de Sesiones Activas (ASH) • Statspack
• Supervisión de Rendimiento (Base de Datos y Host)
• Notificaciones de Eventos: Métodos, Reglas y Programas de Notificación • Estadísticas del sistema
• Historial de Eventos/Historial de Métricas (Base de Datos y Host)
• Interrupciones • Modelo de espera
• Líneas Base de Métricas Dinámicas
• Supervisión de Plantillas
• Modelo de tiempo
• Estadísticas del sistema
Database Tuning Pack Configuración de la Base de Datos operativo
Paquete de Gestión
• Asesor de Acceso SQL
• Asesor de Ajustes SQL • Configuración de Base de Datos y Host • Métricas LA
• Ajustes SQL Automáticos • Despliegues
• D
Estadísticas de servicioE
OS
• Juegos de Ajustes SQL • Parche de Base de Datos y
Ver Caché de Parches
• Evolución del Plan • Histogramas
D
SA
Automática de Gestión de • Almacenamiento de Parche en
Área Temporal
Planes SQL
• E
Estadísticas del
GR nlyฺ
• Supervisión de SQL • Clonar Base de Datos
optimizador
• Reorganizar Objetos • Clonar Directorio Raíz de Oracle
E
DE• use o
• Buscar Configuración
• Comparar Configuración Estadísticas SQL
• Políticas
IO ALN
A RITC
D
F
a n d A D
Uso de las Funcionessde y
it losR SI D
Paquetes
e r E los paquetes de gestión se enumeran en la parte izquierda de la
Los nombres y nlasivfunciones
I V de
U UNnecesitan una licencia individual que se puede comprar sólo con Enterprise
e Todos ellos
diapositiva.
l
c
ra Se puede acceder a las funciones de estos paquetes mediante Oracle Enterprise Manager
Edition.
O
Database Control, Oracle Enterprise Manager Grid Control y las API proporcionadas con el software
de Oracle Database:
• El paquete Oracle Database Diagnostic Pack proporciona funciones de diagnóstico de
rendimiento automático y de control avanzado de sistema. Los siguientes componentes forman
parte de este paquete:
- Paquete DBMS_WORKLOAD_REPOSITORY
- Paquete DBMS_ADDM
- Paquete DBMS_ADVISOR, si especifica ADDM como el valor para el parámetro
ADVISOR_NAME o si especifica cualquier valor que empiece por el prefijo ADDM para el
valor del parámetro TASK_NAME
- Vista de rendimiento dinámico V$ACTIVE_SESSION_HISTORY
- Todas las vistas de diccionarios de datos que empiecen con el prefijo DBA_HIST_, junto
con sus tablas subyacentes
- Todas las vistas de diccionarios de datos con el prefijo DBA_ADVISOR_ si las consultas a
estas vistas devuelven filas con el valor ADDM en la columna ADVISOR_NAME o un valor
de ADDM* en la columna TASK_NAME o correspondiente TASK_ID

Uso de las Funciones de los Paquetes (continuación)
- La vista DBA_STREAMS_TP_PATH_BOTTLENECK forma parte de este paquete.
- Todas las vistas que empiecen por DBA_ADDM_ forman parte de este paquete.
- Los siguientes informes, que están en el directorio /rdbms/admin/ dentro del directorio
ORACLE_HOME forman parte de este paquete: awrrpt.sql, awrrpti.sql,
addmrtp.sql, addmrpti.sql, ashrpt.sql, ashrpti.sql, awrddrpt.sql,
awrddrpi.sql, awrsqrpi.sql, awrsqrpt.sql, awrextr.sql, and

awrload.sql, awrextr.sql, awrload.sql, awrinfo.sql, spawrrac.sql.
• Oracle Tuning Pack proporciona una gestión de rendimiento a nivel experto para el entorno
Oracle Database, incluidos el ajuste SQL y las optimizaciones de almacenamiento. El paquete
Oracle Diagnostic Pack es un requisito imprescindible para el paquete Oracle Tuning Pack. Por
lo tanto, para utilizar Tuning Pack debe tener también un paquete Diagnostic Pack. Los
siguientes componentes forman parte de este paquete:
- El paquete DBMS_SQLTUNE
- El paquete DBMS_ADVISOR, cuando el valor del parámetro ADVISOR_NAME es SQL
Tuning Advisor o SQL Access Advisor L A
- V$SQL_MONITOR D E
S
- V$SQL_PLAN_MONITOR
A DO
- El informe sqltrpt.sql que está en el directorio /rdbms/admin/ dentro del
directorio ORACLE_HOME R ES
E G nlyฺ
• El paquete Oracle Configuration Management Pack automatiza el proceso, a menudo lento y
DE use o
proclive a errores, de configuración del software, seguimiento de inventario de software y
N
IO AL
hardware, aplicación de parches, clonación y gestión de políticas.
C
A RIT
• Oracle Provisioning Pack for Database automatiza el despliegue del software, aplicaciones y
D
UN DIST
parches para la base de datos y el sistema operativo subyacente.
F
nd AD
Si no puede adquirir los paquetes mencionados anteriormente, en especial Database Diagnostics y
a
r s ity RSID
Database Tuning, aún puede utilizar el método tradicional de ajuste y control de rendimiento a través
ive IVE
de los informes de Statspack, los rastreos SQL y la mayoría de las estadísticas básicas, tal y como se
n
le U UN
muestra en la diapositiva anterior.
c
Ora
En Oracle Database 11g, puede utilizar el parámetro de inicialización CONTROL_MANAGEMENT_
PACK_ACCESS para desactivar los paquetes. La configuración de este parámetro es: NONE,
DIAGNOSTIC, DIAGNOSTIC+TUNING. Al definir el parámetro en NONE, se desactivan los
paquetes Diagnostic y Tuning, DIAGNOSTIC permite sólo el acceso al paquete Diagnostic y
DIAGNOSTIC+TUNING permite el acceso a ambos paquetes.

Acceso a la Página Inicial de la Base de Datos
https://host name:1158/em
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit deRlaSBase
Acceso a la Página Inicial D
I de Datos
e r EControl abriendo el explorador Web y escribiendo la siguiente
Puede acceder n iv Database
a EM I V
direcciónle U UN
URL: https://nombre_host:número_puerto/em.
ra c
nombre_host es el nombre o la dirección de su computadora. número_puerto es el número de puerto
O
HTTP de EM Database Control que se ha especificado durante la instalación. El puerto por defecto
es 1158. Podrá encontrar el valor correspondiente a su sistema UNIX en el archivo
$ORACLE_HOME/install/portlist.ini. En Windows, puede encontrar el archivo en el
directorio %ORACLE_HOME%\install.
La página inicial de la base de datos Enterprise Manager es el punto de partida para controlar y
administrar la base de datos. Utilice la página inicial de la base de datos para:
• Determinar el estado actual de la base de datos visualizando una serie de métricas.
• Iniciar o parar la base de datos.
• Acceder al rendimiento, la administración y el mantenimiento del entorno de la base de datos a
través de separadores cuyas páginas con separadores disponen de subsecciones.

Información de Rendimiento
en la Página Inicial de la Base de Datos
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Información de Rendimiento y D
sit RenSlaI Página Inicial de la Base de Datos
e r
nidev la base
La página inicial I VdeEdatos es el punto de partida. En esta página, se presenta información
U
e al estado
general relativa
l UNy el rendimiento de la base de datos con enlaces y aumento de detalles que
c
a a información detallada. En la página inicial de la base de datos, las métricas se presentan
danracceso
O
en las siguientes categorías:
• General: esta categoría ofrece una vista rápida del estado de la base de datos y proporciona
información básica sobre la base de datos. El estado puede ser Up, Down, Under Blackout,
Unmonitored o Unknown. Desde esta sección, puede acceder a otras páginas como, por ejemplo,
la página Properties, la página inicial del host, la página inicial del listener o la página inicial de
ASM, para obtener más información.
• Host CPU: en esta categoría, se muestra un gráfico de barras que indica el uso de CPU relativo
del host de Oracle Database. El 100% (en el gráfico) representa la CPU total que puede
proporcionar el sistema de host. En el gráfico de barras, aparecen dos valores. La barra de color
más oscuro de la parte inferior representa la cantidad de CPU que está consumiendo esta
instancia. El color más claro de la parte superior representa todos los demás procesos. Estos
colores se corresponden con la leyenda.

Información de Rendimiento en la Página Inicial de la Base de Datos (continuación)
• Active Sessions: el gráfico de barras indica la cantidad de tiempo que ha consumido la instancia
utilizando CPU y E/S, así como la cantidad de tiempo que ha consumido en cuellos de botella.
El gráfico muestra el último valor en lugar de un valor histórico. Las tres categorías de sesiones
son siempre CPU, User I/O y Wait. La categoría Wait representa el valor combinado de todas
las clases de esperas, exceptuando User I/O.
• SQL Response Time: en esta categoría, se muestra la respuesta actual del juego de SQL del que
se ha realizado un seguimiento frente a la respuesta de línea base. Si el tiempo de respuesta y de
línea base son iguales, eso significa que el sistema funciona normalmente. Es posible que el
tiempo de respuesta sea superior al tiempo de respuesta de línea base, lo que significa que una o
más sentencias SQL son más lentas de lo normal. Cuanto menor sea el tiempo de respuesta, con
más eficiencia se ejecutan las sentencias SQL.
• Diagnostic Summary: en esta categoría se muestra información sobre violaciones de políticas y
los últimos resultados del monitor de diagnóstico de base de datos automático (ADDM). El
enlace desde Performance Findings le conduce a la página de ADDM, en la que hay una tabla de
análisis del rendimiento con resultados a los que se debería prestar atención. ADDM utiliza L A
D E
instantáneas de la actividad de la base de datos para realizar un análisis de la actividad de la base
S
de datos en orden descendente.
A DO
R ES
• Space Summary: con esta categoría, puede identificar problemas relacionados con el
almacenamiento y ofrecer recomendaciones para mejorar el rendimiento.
E G nlyฺ
El valor de Database Size (GB) se obtiene del campo Total Size (MB) situado en la parte
DE use o
inferior de la página Tablespaces. Por ejemplo, si este valor es 99.000,0, el valor del campo
N
IO AL
Database Size (GB) de la página inicial sería 99.
C
A RIT
• High Availability: esta categoría muestra el estado de los elementos relacionados con la alta
D
UN DIST
disponibilidad. El primer elemento es un enlace a la Consola de Alta Disponibilidad. La hora y
F
nd AD
el éxito de la última copia de seguridad se muestran como un enlace a la página View Backup
a
r s ity RSID
Report. Todos los estados de Instance Recovery Time, Usable Flash Recovery Area % y
n ive IVE
Flashback Database Logging se muestran como enlaces a la sección correspondiente de la
página Recovery Settings. Si se desactiva el reinicio de Oracle, el estado es un enlace a la página
le U UN
para activar el reinicio; una vez activado el reinicio, el estado ya no será un enlace.
c
Ora
A continuación, se muestran categorías adicionales que aparecen en la página inicial de la base de
datos y que no aparecen en la diapositiva.
• Alerts y Related Alerts muestran todas la alertas abiertas. Para obtener más información sobre
una alerta, haga clic en el mensaje correspondiente.
• ADDM Findings: muestra las conclusiones más recientes registradas por una tarea de ADDM.
• Policy Violations: muestra un resumen de las reglas de política violadas en las áreas Security,
Configuration y Storage. Haga clic en los enlaces para obtener más información sobre las reglas
específicas o la puntuación de cumplimiento general.
• Job Activity: en esta categoría, se muestra un informe de las ejecuciones de trabajos de
Enterprise Manager, que indica las ejecuciones programadas, en ejecución, suspendidas y con
problemas. Si en un campo aparece un valor distinto de 0, puede hacer clic en dicho número
para ir a la página Job Activity, donde puede visualizar información sobre todos los trabajos
programados, en ejecución y pasados.

Visualización del Log de Alertas
Página Inicial de la Base de Datos > Región Related Links >

Alert Log Contents
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Visualización del Logsde y
it Alertas SI D
e r R
E alert_<sid>.log. El archivo está en el servidor con la base
nivtieneNunIVarchivo
Cada base de datos
U U en el árbol de directorios especificado en el parámetro de inicialización
de datoslyese almacena
c
r a
DIAGNOSTIC_DEST.
O El log de alertas se almacena con dos formatos en directorios diferentes. El
log de alertas con formato XML se encuentra en el directorio
$DIAGNOSTIC_DEST/rdbms/<db_name>/<instance_name>/alert y el directorio
$DIAGNOSTIC_DEST/rdbms/<db_name>/<instance_name>/trace contiene una
versión de texto. El archivo log de alertas de una base de datos es un log cronológico de mensajes y
errores, incluidos los siguientes:
• Cualquier parámetro de inicialización no por defecto utilizado en el inicio.
• Todos los errores internos (ORA-600), errores de corrupción de bloques (ORA-1578) y errores
de interbloqueo (ORA-60) que se produzcan.
• Operaciones administrativas, como las sentencias SQL CREATE, ALTER, DROP DATABASE y
TABLESPACE, y sentencias de Enterprise Manager o SQL*PlusSTARTUP, SHUTDOWN,
ARCHIVE LOG y RECOVER. Se registran todas las acciones de recuperación.
• Varios mensajes y errores relacionados con las funciones del servidor compartido y los procesos
del distribuidor.
• Errores durante la actualización automática de una vista materializada.
Enterprise Manager supervisa el archivo log de alertas y notifica los errores críticos. También puede
consultar el log para ver errores no críticos y mensajes informativos.

Uso de la Información del Log de Alertas
para Facilitar el Ajuste
El archivo log de alertas contiene la siguiente información que
se puede utilizar para facilitar el ajuste de la base de datos:

• Tiempo de realización del archivado
• Tiempos de inicio y finalización de la recuperación de
instancias
• Errores de interbloqueos y timeouts
• Puntos de control incompletos
• Tiempos de inicio y finalización de puntos de control L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Uso de la Informaciónsdel y
it LogRde D
SIAlertas para Facilitar el Ajuste
e r Ela diapositiva y otra información adicional se escribe en el log de
La informaciónnqueiv aparece
I V en
alertas. La
l U UNque se escribe en el log de alertas cambia ligeramente con cada versión de
einformación
c
ra Database. Algunos valores, como los tiempos de inicio y finalización de los puntos de control,
Oracle
O
sólo se escriben cuando se solicita. Estos valores sólo se escriben en el archivo log de alertas si el
parámetro LOG_CHECKPOINTS_TO_ALERT se ha definido en TRUE.
El archivo log de alertas puede crecer hasta alcanzar un tamaño difícil de gestionar. Puede suprimir
el log de alertas de forma segura mientras la instancia está iniciada, aunque debería pensar en la
posibilidad de realizar primero una copia archivada del mismo. La copia archivada podría ser muy
valiosa en el caso de que tuviera un problema en el futuro para el que hubiera que investigar el
historial de una instancia. Nota: ambas versiones del log de aletas, texto y XML se deben recortar
periódicamente.
Por ejemplo, si el DBA ha detectado un cambio en las estadísticas de rendimiento, y descubre que un
parámetro de instancia ha cambiado desde la última línea base, para confirmar que el cambio de
rendimiento se corresponde con el cambio de parámetro se puede realizar una búsqueda en el log de
alertas. En el log de alertas, se enumeran todos los valores de parámetros que no son por defecto en
cada inicio, y se registran comandos ALTER SYSTEM con un registro de hora.

Uso de la Información del Log de Alertas para Facilitar el Ajuste (continuación)
El siguiente ejemplo del log de alertas muestra los parámetros de inicio, el mensaje de advertencia
para FAST_START_MTTR_TARGET y una secuencia de cambios del archivo log que muestra el
tiempo de cada uno:
System parameters with non-default values:
processes = 150
memory_target = 460M
db_block_size = 8192
compatible = "11.2.0.0.0"
db_create_file_dest = "+DATA"
db_recovery_file_dest = "+FRA"
db_recovery_file_dest_size= 3852M
undo_tablespace = "UNDOTBS1"
remote_login_passwordfile= "EXCLUSIVE"
db_domain = "us.oracle.com"
dispatchers = "(PROTOCOL=TCP) (SERVICE=orclXDB)"
audit_file_dest = "/u01/app/oracle/admin/orcl/adump" L A
audit_trail = "DB"
D E
db_name = "orcl" S
open_cursors = 300
A DO
diagnostic_dest ES
= "/u01/app/oracle"
R
Fri Mar 26 07:37:34 2010
E G nlyฺ
… N DE use o
PMON started with pid=2, OS id=16765
Fri Mar 26 07:41:34 2010

C IO AL
D A RIT
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not
set
F UN DIST
…
a nd AD
r s ity RSID
Fri Mar 26 08:04:34 2010
Thread 1 advanced to log sequence 7 (thread open)
ive IVE
Thread 1 opened at log sequence 7
n
c le U UN
Current log# 1 seq# 7 mem# 0:
Ora
+DATA/orcl/onlinelog/group_1.261.714641891
Current log# 1 seq# 7 mem# 1:
+FRA/orcl/onlinelog/group_1.257.714641899
Successful open of redo thread 1
…

Archivos de Rastreo de Usuarios
• El rastreo de procesos de servidor se puede activar o

desactivar a nivel de sesión o instancia.

• Un archivo de rastreo de usuarios contiene estadísticas de
sentencias SQL de las que se ha realizado un seguimiento
en esa sesión.
• Los archivos de rastreo de usuarios se crean por proceso de
servidor.
• Los archivos de rastreo de usuarios también se pueden LA
crear: DE
– Ejecutando BACKUP CONTROL FILE TO TRACE D OS
– Con errores de proceso E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Archivos de Rastreo de y
sitUsuarios SI D
e r R
E generar archivos de rastreo de usuarios a petición del usuario o el
iv pueden
Los procesos denservidor
I V
DBA. e
l U UN
c
ra a Nivel de Instancia
Rastreo
O
El rastreo a nivel de instancia sólo se debe activar cuando es absolutamente necesario. El rastreo de
todas las sesiones creará una carga de E/S y puede rellenar el sistema de archivos rápidamente. Este
registro de rastreo se activa o se desactiva con EXEC
DBMS_MONITOR.DATABASE_TRACE_ENABLE().
Rastreo a Nivel de Sesión
La siguiente sentencia activa la escritura en un archivo de rastreo para una sesión concreta:
EXECUTE DBMS_MONITOR.SESSION_TRACE_ENABLE (8,12, waits=>TRUE,
binds=>TRUE);
donde 8 y 12 son el identificador del sistema y el número de serie del usuario conectado.
Normalmente, sólo un DBA tiene los permisos necesarios para activar el rastreo en cualquier sesión.
Se crea el paquete DBMS_MONITOR al ejecutar el script catproc.sql. Este script está en el
siguiente directorio:
• En UNIX: $ORACLE_HOME/rdbms/admin
• En Windows: %ORACLE_HOME%\rdbms\admin
Para activar la escritura de un archivo de rastreo en la sesión actual, ejecute el siguiente comando:
EXECUTE DBMS_SESSION.SET_SQL_TRACE(TRUE)

Archivos de Rastreo de Procesos en
Segundo Plano
• El servidor de Oracle Database vuelca la información sobre
los errores detectados por los procesos en segundo plano

en archivos de rastreo.
• Los Servicios de Soporte Oracle utilizan estos archivos de
rastreo para realizar diagnósticos y solucionar problemas.
• Estos archivos no suelen contener información de ajuste.
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Archivos de Rastreo de y
sitProcesos D
SI en Segundo Plano
e r R
Ecrean estos archivos. En general, contienen información de
iv plano
Los procesos ennsegundo I V
U UN relativa al ajuste del rendimiento. Sin embargo, si se utilizan eventos, la
e no información
diagnóstico,
l
ra c
información relativa al rendimiento se puede escribir en estos archivos. El DBA puede definir
O
eventos de base de datos pero, normalmente, sólo bajo la supervisión de los Servicios de Soporte
Oracle. Estos archivos son difíciles de leer, porque están pensados para que los Servicios de Soporte
Oracle los utilicen para realizar diagnósticos y solucionar problemas, pero pueden contener
información útil que puede utilizar el DBA.
Una excepción a esta regla es el evento 10053 que se puede utilizar para rastrear las elecciones del
optimizador. Este evento se explicará más adelante.

Prueba
¿Qué herramienta de diagnóstico utilizaría para detectar

cuándo se realizaron por última vez el inicio y la copia de

seguridad de la base de datos?
a. Archivos de rastreo
b. Log de alertas
c. Página inicial de Enterprise Manager
d. Vistas V$
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Respuesta: b, c y
sit RSI D
e r E y de Enterprise Manager contiene esta información.
v log deIValertas
nidel
La página inicial
U
c l e UN
Ora

Resumen

• Ver los eventos de espera principales para determinar el

mayor tiempo de espera
• Ver el modelo de tiempo para diagnosticar problemas de
rendimiento
• Utilizar vistas de rendimiento dinámico para visualizar
estadísticas y eventos de espera
• Usar el proceso de control de Enterprise Manager
E LA
• Identificar los componentes clave de ajuste de los logs deS D
alertas A DO
• Identificar los componentes clave de ajusteG
ES
deRlos archivos
E n l yฺ
de rastreo de usuarios DE o
O N u se
A CI ITAL
U ND IST R
d F
n D
s i t y a SIDA
i v er VER
U n NI
cl e U
Ora

Visión General de la Práctica 2:
Uso de Herramientas Básicas
En esta práctica se abordan los siguientes temas:
• Visualización de los eventos de espera principales y el

modelo de tiempo
• Uso de la información del log de alertas para el ajuste
• Visualización de estadísticas del sistema
• Visualización de eventos de espera
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Ora
c
n
r s
le U UN
ive IVE
a
F
ity RSID
nd AD
D
C
UN DIST
N
A RIT
IO AL
E
R
DE use o
ES
G nlyฺ
A DO
S D E LA
Uso del Repositorio de Carga de Trabajo

Automática
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora
Objetivos

siguiente:
• Crear y gestionar instantáneas de AWR
• Generar informes de AWR
• Crear informes de comparación de períodos
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Repositorio de Carga de Trabajo Automática:
Visión General
Clientes externos
EM SQL*Plus …
SGA
Recopilación V$ DBA_*
de estadísticas Instantáneas
en memoria de AWR
eficaz MMON L A
D E
D OS
E SA
G RComponente
yฺ
ADDM
Componente de E…
E o n l de
Clientes internos ajuste automático
N D useajuste automático
C IO AL
D A RIT
F
a n d A D
Repositorio de Cargasde y
it Trabajo D
SIAutomática: Visión General
e r R
Eproporciona a los componentes de Oracle Database 11g los servicios
iv Ique
AWR es la infraestructura
n V
necesarios
l U UN mantener y utilizar estadísticas para detectar problemas y aplicar ajustes
epara recopilar,
ra c
automáticos.
O
La infraestructura de AWR consta de dos partes principales:
• Un servicio de recopilación de estadísticas en memoria que utiliza varios de los componentes para
recopilar estadísticas. Estas estadísticas se almacenan en memoria por motivos de rendimiento.
Para acceder a las estadísticas almacenadas en memoria se utilizan las vistas de rendimiento
dinámico (V$).
• Las instantáneas de AWR representan la porción persistente de la utilidad. Para acceder a las
instantáneas de AWR se utilizan las vistas del diccionario de datos (DBA) y Database Control.
Las estadísticas se almacenan de forma persistente por varios motivos:
• Las estadísticas deben sobrevivir a posibles fallos de la instancia.
• Los datos históricos para las comparaciones de línea base son necesarias para determinados tipos
de análisis.
• Desbordamiento de la memoria: cuando las estadísticas antiguas se sustituyen por nuevas por falta
de memoria, los datos sustituidos se pueden guardar con objeto de utilizarlos más adelante.
La versión de la memoria de las estadísticas se transfiere al disco regularmente mediante un proceso en
segundo plano denominado MMON (monitor de gestión).
Con AWR, el servidor de Oracle Database ofrece un sistema para capturar datos estadísticos históricos
automáticamente, sin intervención por parte de los DBA.
Datos del Repositorio de Carga de Trabajo
Automática
Estadísticas Estadísticas Resultados

base SQL del asesor
L A
D E
D OS
E SA
Métricas ASH
E GR nlyฺ
AWR N DE use o
C IO AL
D A RIT
F
a n d A D
Datos del Repositoriosde y
it Carga D
SdeI Trabajo Automática
e r E R
• AWR captura
n ivvarias estadísticas.
I V AWR almacena estadísticas básicas, es decir, contadores y
l U UN (pordeejemplo,
estadísticas de valores
ecaptura estadísticas cambios de archivo log y memoria de proceso asignada).
c
Ora
AWR SQL como, por ejemplo, lecturas de disco por sentencia SQL.
También se capturan métricas como las lecturas físicas por minuto.
• Los datos del historial de sesiones activas (ASH) se capturan antes que la memoria en intervalos
de un segundo sólo para aquellas sesiones que estén activas actualmente (realizando una llamada
a la base de datos). A continuación, los datos de ASH se reducen según un factor de diez
mediante el almacenamiento en disco de un ejemplo aleatorio de los datos en memoria. El
Monitor de Diagnóstico de Base de Datos Automático (ADDM) utiliza mucho los datos de ASH
para identificar las causas raíz de los problemas de rendimiento.
• Los informes del asesor que produce ADDM, el asesor de segmentos y otros asesores también se
almacenan en AWR para su posterior visualización.
• Las estadísticas se realizan en dos niveles: estadísticas recientes en memoria en las vistas V$ y
estadísticas persistentes que se almacenan en el disco como instantáneas y vistas DBA_*.
Nota: los ejemplos de esta página no constituyen la totalidad de la lista.

Repositorio de Carga de Trabajo
ADDM encuentra
MMON problemas.
SYSAUX
SGA
06:00:00 a.m. Instantánea 1
Estadísticas 07:00:00 a.m. Instantánea 2
en memoria 08:00:00 a.m. A
09:00:00 a.m.
Instantánea 3
E L
Instantánea 4 D
D OS
E SA
E GR nlyฺ
09:30:00 a.m.
N DE use o
C IO AL
D A RIT
F
a n d A D
Repositorio de Cargasde y
it Trabajo SI D
e r R
deEtrabajo es una recopilación de estadísticas persistentes de rendimiento
• El repositorioivde cargaIV
npropiedad
l e U
del sistema
U N SYS. El repositorio de carga de trabajo reside en el tablespace
de
r c
SYSAUX
a y es uno de los principales ocupantes de SYSAUX.
O • Una instantánea es un juego de estadísticas de rendimiento capturadas en un momento concreto.
Las instantáneas se utilizan para calcular el ratio de cambio de una estadística. Cada instantánea
viene identificada por un número de secuencia de instantánea (snap_id) que es único en el
repositorio de carga de trabajo.
• Las instantáneas se generan por defecto cada 60 minutos. La frecuencia de generación se puede
ajustar cambiando el parámetro de instantánea INTERVAL. Dado que los asesores internos se
basan en estas instantáneas, debe tener en cuenta que el ajuste de este valor de intervalo puede
afectar a la precisión del diagnóstico. Por ejemplo, si INTERVAL se define en 4 horas, podrían
omitirse espigas que hayan podido producirse dentro de intervalos de 60 minutos.
• En los entornos Real Application Clusters, las instantáneas abarcan cada una el total de nodos de
un cluster. Las instantáneas comparten el mismo snap_id para los datos de cada nodo, que se
diferencian por su ID de instancia. Las instantáneas de Real Application Clusters se capturan al
mismo tiempo aproximadamente.
• Puede tomar instantáneas manualmente con Database Control. Es posible combinar la toma de
instantáneas manuales con las instantáneas automáticas que genera el sistema. Las instantáneas
manuales se utilizarán cuando desee capturar el comportamiento del sistema en dos momentos
concretos que no coincidan con la programación automática.

Database Control y AWR
Editar parámetros
de instantánea
L A
D E
Ejecutar informe
D OS
de AWR
E SA
E GR instantáneas
Gestionar
n l yฺ
DEGestionar e o líneas base
N s
C IO AL u
D A RIT
F
a n d A D
Database Control y AWR y
sit RSI D
e r E configurar los parámetros RETENTION e INTERVAL para
U nivControl,
Mediante Database I V puede
N acceder a la página Automatic Workload Repository, haga clic primero en
e UPara
capturar linstantáneas.
c
O ra
el separador Server de la página inicial de Database Control. A continuación, haga clic en el enlace
Automatic Workload Repository de la sección Statistics Management.
Mediante la página Automatic Workload Repository, podrá:
• Editar los valores del repositorio de carga de trabajo.
• Consultar información detallada acerca de las instantáneas creadas y crear manualmente
instantáneas nuevas.
• Crear líneas base, también denominadas juegos de instantáneas mantenidas.
• Generar un informe AWR.

Política de Depuración de Instantáneas de AWR
Tablespace SYSAUX
Esquema sys
60 min
Instantánea
8 Instantánea
MMON
días Instantánea
L A
Instantánea Cada noche D E
Instantánea
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Política de Depuración y SI
t Instantáneas
side D de AWR
v e r E R
U nicantidad
Para controlar la
N
de
I Vestadísticas de AWR históricas, defina un período de retención y un
intervalole
c U En general, las instantáneas se eliminan automáticamente en orden
de instantánea.
O r a
cronológico. Las instantáneas pertenecientes a las líneas base se retendrán hasta que se borren o
caduquen las líneas base. En un sistema típico con 10 sesiones activas, las recopilaciones de AWR
necesitan de 200 MB a 300 MB de espacio cuando los datos se guardan durante siete días. El
consumo de espacio depende fundamentalmente del número de sesiones activas en el sistema. En un
script de ajuste de tamaño utlsyxsz.sql se incluyen factores como el tamaño de los ocupantes
actuales del tablespace SYSAUX, el número de sesiones activas, la frecuencia de las instantáneas y el
tiempo de retención. El script awrinfo.sql genera un informe de los ratios estimados de
crecimiento de varios ocupantes del tablespace SYSAUX. Ambos archivos de comandos están
ubicados en el directorio $ORACLE_HOME/rdbms/admin.
AWR maneja la gestión de espacio de las instantáneas. Cada noche el proceso MMON depura las
instantáneas más antiguas que el período de retención. Si AWR detecta que falta espacio en
SYSAUX, reutiliza automáticamente el espacio ocupado por el juego de instantáneas más antiguo
mediante su supresión. A continuación, se envía una alerta al DBA para indicarle que SYSAUX
necesita más espacio.

Valores de Instantáneas de AWR
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS (
retention IN NUMBER DEFAULT NULL,
interval IN NUMBER DEFAULT NULL,
topnsql IN NUMBER DEFAULT NULL);
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Valores de Instantáneas y
sit de AWR SI D
e r E R
U niv NIVMODIFY_SNAPSHOT_SETTINGS,
Mediante el procedimiento puede controlar los parámetros de
U este procedimiento para cambiar lo siguiente:
le Puede utilizar
instantánea.
Elcperíodo de retención. RETENTION se especifica en minutos. El valor por defecto es de ocho
• ra
O días; el mínimo es un día. Al definir RETENTION en el valor 0 se desactiva la función de
depuración automática.
• El intervalo INTERVAL entre instantáneas. El valor mínimo es de 10 minutos, el máximo es de
100 años y el valor por defecto es de 60 minutos.
• El número de sentencias SQL principales para las que capturar datos de rendimiento. Puede
especificar los siguientes valores: DEFAULT, MAXIMUM, n, donde n es el número de sentencias
SQL principales que vaciar para cada criterio SQL como, por ejemplo, el tiempo transcurrido y
el tiempo de CPU. Especifique DEFAULT para capturar las 30 principales para el nivel
TYPICAL y las 100 principales para el nivel ALL de STATISTICS_LEVEL. Especifique
MAXIMUM para capturar el juego completo de SQL en la caché de cursores. Especifique NULL
para mantener el valor actual.
Nota: bajo circunstancias excepcionales, la recopilación automática de instantáneas se puede
desactivar completamente mediante la definición del intervalo de la instantánea en 0. La recopilación
automática de los datos estadísticos y de carga de trabajo se detiene y gran parte de la función de
gestión automática de Oracle no está operativa. Además, no podrá crear instantáneas manualmente.
Por este motivo, Oracle Corporation recomienda no desactivar la recopilación automática de
instantáneas.
Instantáneas Manuales de AWR
Crear una instantánea

DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT (};
Borrar una o más instantáneas

DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(
LOW_SNAP_ID => 102,
HIGH_SNAP_ID => 105);
Crear y suprimir instantáneas mediante EM

L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Instantáneas Manuales y
sitde AWR SI D
e r E R
Las instantáneas
U nseivrecopilan
N I V normalmente de forma automática. Hay ocasiones en las que puede que
c U
lede recopilación
desee recopilar las instantáneas antes o después de que determinados eventos no coincidan con los
O r a
períodos automática. Estos eventos podrían ser cargas de trabajo de prueba o eventos
de problema que puede disparar.

Gestión de Instantáneas con PL/SQL
Paquete DBMS_WORKLOAD_REPOSITORY
Nombre del Procedimiento Descripción

CREATE_SNAPSHOT Crear una instantánea manual
inmediatamente
DROP_SNAPSHOT_RANGE Borrar un rango de instantáneas
MODIFY_SNAPSHOT_SETTINGS Modificar los valores de las instantáneas L A

D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Gestión de Instantáneas y SI
sit conRPL/SQL D
e r E
U niv DBMS_WORKLOAD_REPOSITORY
El paquete PL/SQL
N I V contiene procedimientos que le permitirán
gestionarle
c U de carga de trabajo. Por ejemplo, dispone de procedimientos para gestionar
el repositorio
O r a
instantáneas y líneas base en este paquete. Los procedimientos que se muestran son sólo algunos de
los procedimientos proporcionados. Las mayoría de los procedimientos los utiliza Enterprise
Manager para gestionar el repositorio de carga de trabajo automática y en raras ocasiones necesitará
utilizar el procedimiento directamente.
Nota: para obtener más información sobre estos procedimientos y otros procedimientos para
gestionar el AWR contenido en el paquete DBMS_WORKLOAD_REPOSITORY, consulte la guía
Oracle Database PL/SQL Packages and Types Reference (Referencia de Tipos y Paquetes PL/SQL
de Oracle Database).

Generación de Informes de AWR en EM
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Generación de Informes y
sit de AWR D
SIen EM
e r R
niv unNinforme
AWR puede producir
U I VE de resumen sobre las estadísticas almacenadas en el repositorio de
carga deltrabajo.
c U contiene información general sobre el comportamiento global del
e El informe
O r a
sistema durante un período de tiempo definido por dos instantáneas.
Para generar un informe de AWR, acceda a la página Automatic Workload Repository de Database
Control en la página con separadores Server. En esta página, haga clic en el enlace correspondiente al
número de instantáneas. Así se abrirá la página Snapshots. En esta página, seleccione la instantánea
de inicio, a continuación elija View Report de la lista desplegable Actions y haga clic en Go. En la
página View Report, seleccione la instantánea de finalización y haga clic en OK.

Generación de Informes de AWR en SQL*Plus
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
sit de AWR D
SIen SQL*Plus
e r R
E información, tanto si se ha generado desde SQL*Plus como
El informe de AWR
n iv tieneIlaVmisma
desde EM.l U UN
eEl script de SQL*Plus awrrpt.sql se ejecuta en el directorio
c
Ora
ORACLE_HOME/rdbms/admin que genera el informe. El usuario que ejecute el script debe tener
el privilegio SELECT_CATALOG_ROLE. Este script pedirá las siguientes opciones del informe:
• Informe en HTML o en texto.
• El número de días de instantáneas entre las que elegir. Al indicar un número de días, aparecerán
las últimas instantáneas obtenidas. También puede determinar qué SNAP_ID debe utilizar
consultando la tabla DBA_HIST_SNAPSHOT para recuperar la asignación entre un ID
SNAP_ID y la hora real.
• SNAP_ID de inicio y SNAP_ID de finalización: un par de instantáneas que defina el período de
tiempo del informe.
• Nombre de archivo: el archivo especificado por el usuario en el que se escribirá el informe.
El informe contiene la misma información, independientemente de si se produce como informe en
HTML o como texto. Sin embargo, los informes HTML se pueden visualizar en un explorador web y
la ventaja de un informe HTML es la presencia de enlaces a las secciones de detalle del informe.

Lectura del Informe de AWR
• La primera sección proporciona

– Visión General
– Diagnósticos más importantes
• Páginas adicionales
– Información estadística detallada para áreas específicas
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Lectura del Informe de t y
siAWR SI D
e r R
E de AWR se proporciona un juego de diagnósticos que describen
U niv del
En la primera sección V
informe
I
las siguientes
c l UN
e métricas:
O• raSnapshot times
• Memory usage
• Load Profile
• Instance Efficiency percentages
• Shared Pool Statistics
• Top 5 Timed Foreground Events
• Estadísticas de sistema operativo, CPU y memoria utilizadas por la instancia
La sección Top 5 Timed Foreground Events es un punto de partida perfecto para diagnosticar
problemas de rendimiento. El objetivo de la primera sección es resaltar el problema más
significativo. Este ejemplo muestra que el porcentaje de tiempo de base de datos que se utiliza en las
esperas por ocupación del buffer es muy alto.
Las demás secciones del informe de AWR contienen información detallada que ayuda a diagnosticar
los problemas que se muestran en la primera sección.

Instantáneas y Comparaciones de Períodos
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Juegos de Instantáneas y SI
sit y ComparacionesD de Períodos
v e r E R
Esta operación ndei comparación
I V de períodos le permitirá definir dos períodos de tiempo distintos y
U
compararlesus juegosU N
de datos respectivos de AWR.
En a c
rla página Snapshots, seleccione la primera instantánea del primer período. Un asistente le guiará
O
en la selección de la instantánea de finalización del primer período y dos instantáneas del segundo
período. Como último paso del asistente, se muestra una página de revisión. Haga clic en Finish para
generar el informe Compare Periods.
También puede generar un informe Compare Periods sobre las líneas base que ya ha definido.
Después de crear al menos dos líneas base, podrá hacer clic en el número de líneas base de la página
Automatic Workload Repository Baselines. A partir de este punto, podrá realizar la operación de
comparación de períodos. Tan sólo siga el asistente para seleccionar ambas líneas base y haga clic en
Finish.

Compare Periods: Ventajas
DBA
L A
D E
D OS
≠
E SA
E GR nlyฺ
DBA N DE use o
C IO AL
D A RIT
F
a n d A D
Compare Periods: Ventajas y
sit RSI D
e r E Repository Compare Periods para comparar dos períodos en
Puede utilizar el iv Workload
ninforme I V
U UN de AWR muestra datos de AWR entre dos instantáneas (o dos puntos en
e un informe
AWR. Mientras
l
c
ra el informe Workload Repository Compare Periods muestra la diferencia entre dos
el tiempo),
O
períodos (o dos informes de AWR, que equivale a cuatro instantáneas).
Utilice el informe Workload Repository Compare Periods para identificar los atributos de
rendimiento detallados y los valores de configuración diferentes entre los dos períodos de tiempo.
Por ejemplo, si se tiene la certeza de que la carga de trabajo de la aplicación es estable durante un
tiempo determinado del día, pero el rendimiento del martes fue deficiente entre las 10:00 AM y las
11:00 AM., al generar un informe Workload Repository Compare Periods para el martes entre las
10:00 AM y las 11:00 AM y el lunes entre las 10:00 AM y las 11:00 AM debe identificar los valores
de configuración, el perfil de carga de trabajo y las estadísticas diferentes entre estos dos períodos de
tiempo. Según los cambios notificados entre estos dos períodos de tiempo, se podrá diagnosticar de
forma precisa la causa de la degradación del rendimiento. Los dos períodos de tiempo seleccionados
para el informe Workload Repository Compare Periods pueden tener duraciones distintas porque el
informe normaliza las estadísticas según la cantidad de tiempo empleado en el servidor para cada
período de tiempo y presenta datos estadísticos ordenados según la principal diferencia entre los
períodos.

Compare Periods: Resultados
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Compare Periods: Resultados y
sit RSI D
e r Euna parte de los resultados de la operación Compare Periods, que
U nivse muestra
En esta diapositiva
N I V
identificalediferenciasUestadísticas entre dos períodos de instantáneas. Este informe compara la misma
r
cargaa c
de trabajo ejecutada en diferentes configuraciones de tablespace a lo largo de un período de
O
tiempo. La comparación se puede realizar por segundo o por transacción. Puesto que la carga de
trabajo es la misma en cada período de tiempo, la comparación por transacción sería adecuada. El
primer período muestra más recursos utilizados en prácticamente todas las áreas, que durante el
segundo período. Los gráficos de barras indican el número proporcional de esas métricas en
comparación con el otro período de tiempo. Por ejemplo, en este informe se muestra que hubo un
número significativamente superior de “DB time (seconds)” empleado por transacción en el primer
período. En la página con separadores General, también puede visualizar las estadísticas generales
por segundo en lugar de por transacción como se muestra en la diapositiva. Para ello, simplemente
seleccione el valor correspondiente en el campo View Data.
Al hacer clic en el enlace Report de esta página se muestra un informe en HTML que compara los
dos períodos, muestra las diferencias en áreas como, por ejemplo, eventos de espera, estadísticas del
sistema operativo, servicios, estadísticas de SQL, actividad de la instancia, estadísticas de E/S y
estadísticas de segmento.
Nota: si los tamaños de dos períodos de tiempo son diferentes, los datos se normalizan con DBTIME
antes de calcular la diferencia para que se puedan comparar los períodos de distinta duración.

Compare Periods: Informe
INFORME WORKLOAD REPOSITORY COMPARE PERIODS
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Compare Periods: Informe y
sit RSI D
e r E de la página Compare Periods: Results, se genera el informe
Al hacer clic ennelivseparador
I V Report
Workloadl U N Periods. Este informe contiene las mismas secciones que un informe
eRepositoryUCompare
ra c
de Statspack/AWR. Además, el informe Compare Periods muestra una comparación de
O
configuración para ambos períodos de tiempo.
En la diapositiva, se muestra la información de cabecera del informe. Este informe se realizó a lo
largo de dos períodos con la misma duración y se nos ha indicado que se ejecutó el mismo script de
carga de trabajo en cada período. En este ejemplo el valor de tiempo de base de datos se reduce
significativamente en el segundo período. Un cambio que produce un beneficio en el rendimiento no
siempre es tan claro.
Las principales secciones de diagnóstico se muestran en esta diapositiva y en las siguientes. Las
demás secciones del informe contienen información más detallada sobre las diferentes áreas de
rendimiento que podrá utilizar cuando una sección indique que se ha producido un problema en dicha
área.
Nota: también puede generar un informe con la misma información mediante el script
awrddrpt.sql ubicado en el directorio $ORACLE_HOME/rdbms/admin.

Compare Periods: Perfil de Carga
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Compare Periods: Perfil y
sit de Carga SI D
e r R
U I VE
nives muyNútil
El perfil de carga en la comparación de dos períodos. Ayuda a aislar las diferencias en la
c e que U
carga deltrabajo pueden contribuir a generar diferencias en el rendimiento. En este informe, el
Or a
script de carga de trabajo es idéntico en ambos períodos. Sólo ha cambiado la configuración de la
base de datos. Podemos observar que el tiempo de base de datos por segundo y por transacción se ha
reducido. También observamos que se han mezclado varias métricas relacionadas con E/S por
transacción: Logical reads, Block changes, Physical reads y Physical writes. Las transacciones por
segundo indican que se ha realizado más trabajo en la misma cantidad de tiempo.
Nota: este ejemplo se ha diseñado para mostrar un cambio que produce claramente un beneficio en el
rendimiento. A menudo, un cambio en un área muestra un beneficio mixto. La reducción de las
esperas en un área, puede provocar contención y esperas en otra área.

Compare Periods: Eventos Principales
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Compare Periods: Eventos y SI
sit Principales D
e r R
E ajustadas a la perfección, tendrán varios eventos de espera
iv aquellas
Cada instancia,nincluso I V
U UN de espera son punteros a las áreas que más beneficiarán al ajuste. El
e Estos eventos
principales.
l
c
ra observado en el primer período era la gran cantidad de tiempo de base de datos dedicado a
problema
O
las esperas por ocupación de buffer. Este evento de espera eclipsa todos los demás eventos de espera.
En el segundo período, podemos observar que las esperas por ocupación de buffer ya no son los
principales eventos de espera. Ya sabemos por las secciones anteriores del informe que el
rendimiento ha mejorado.
En el segundo período, aparecen esperas de buffer libre y la sincronización del archivo log ha
aumentado tanto en tiempo total como en porcentaje de tiempo de base de datos. Esta observación
debe conducir a la investigación de las causas y posibles soluciones de estas esperas. El siguiente
paso sería examinar las secciones de detalles de este informe relacionadas con estos eventos de
espera.

Prueba
El repositorio de carga de trabajo automática existe en el

tablespace SYSAUX. La porción persistente de AWR está

constituida por las instantáneas. La información incluida en
cada instantánea se controla mediante:
a. El tamaño del tablespace SYSAUX
b. El valor del parámetro STATISTICS_LEVEL
c. El tiempo de retención de instantánea
d. El intervalo de instantánea L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Respuesta: b y
sit RSI D
e r Ea la cantidad de espacio utilizado en el tablespace SYSAUX. Pero sólo
iv afectan
Todas estas respuestas
n I V
el valor del
l U N
e parámetroUSTATISTICS_LEVEL cambia la información que se recopila.
c
Ora

Resumen

• Crear y gestionar instantáneas de AWR

• Generar informes de AWR
• Crear informes de comparación de períodos
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Uso de Herramientas Basadas en AWR
• Creación y gestión de instantáneas del repositorio de carga

de trabajo automática (AWR)
• Generación y visualización de las secciones de un informe
de AWR
• Generación y visualización de las secciones de un informe
Compare Periods
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Definición de Problemas
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora
Objetivos

siguiente:
• Identificar problemas de rendimiento
• Definir prioridades de ajuste
• Interpretar diagnósticos de ajuste
• Ajustar la fase del ciclo de vida
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Definición del Problema
Monitor
Evaluación
Usuarios DBA Instancia de la A

base de datos E L
D
D OS
E SA
E GR nlyฺ
DE usyearchivos o
IO ALN Informes
A RITC
D
F
a n d A D
Definición del Problema y
sit RSI D
e r E
n iv surgir
Los problemas pueden
I V en cualquier momento. Un DBA proactivo busca los problemas y los
l U
corrige antes de que losN
U usuarios
efrecuentemente, los detecten. En el pasado, el paso de detección y definición era
a c
tedioso y, dependía de los comentarios de los usuarios. Los comentarios de los usuarios
Orimportantes,
son pero suelen ser subjetivos y no reproducibles. En Oracle Database 11g, muchas de las
siguientes fuentes de información se pueden visualizar desde la interfaz Enterprise Manager:
• Supervise el estado actual de la instancia de la base de datos y compárela con un estado anterior.
- Utilice Statspack o AWR para recopilar métricas de rendimiento de forma regular. Los
cambios pueden apuntar a problemas antes de que sean perceptibles para los usuarios.
- Utilice las herramientas del sistema operativo o de EM para comprobar la puesta en cola de la
CPU y el disco, el uso del disco y el intercambio de memoria. Todos ellos son síntomas de que
el sistema está sobrecargado.
• Examine los archivos de instancias e informes de AWR o Statspack con atención.
- Utilice las herramientas disponibles (por ejemplo, informes de Statspack o AWR) para
identificar las sentencias SQL de las aplicaciones que consumen más recursos. ¿Han
cambiado?
- Compruebe si en los logs y archivos de rastreo hay mensajes de error que pudieran dar una
pista rápida de la naturaleza del problema. No se olvide de los logs específicos del sistema y
de la aplicación.
- Asegúrese de que los valores de los parámetros de inicialización tienen sentido en el sistema.
- Recopile estadísticas de la instancia y del sistema operativo. Los informes de Statspack
apuntan a componentes en los que se producen las mayores esperas y el mayor uso de recursos.
ADDM va más allá y se concentra en esos componentes con el mayor beneficio potencial.
Limitación del Ámbito
¿Dónde está el problema?

• Aplicación (SQL)
• Instancia
• Sistema operativo
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Limitación del Ámbitosit y SI D
e r R
U n noNsiempre
SQL? Esta pregunta IVE esdefácil
¿Se han originadoivlos problemas rendimiento en el sistema operativo, la instancia o la aplicación
de responder. Un rendimiento deficiente de SQL puede
l e
demasiadasU
c con un tamaño no adecuado físicas,
provocar lecturas y escrituras lo que puede parecer un problema de E/S. Los
O r a
componentes (un problema de configuración de instancia) pueden causar
un intercambio excesivo en el sistema operativo. Una configuración de disco deficiente puede parecer
un problema de configuración de instancia, lo que provoca esperas de archivos redo de gran tamaño o
esperas de confirmación y otros problemas.
Elimine las posibilidades. Cuando parece que la instancia tiene problemas de E/S, compare las
estadísticas de E/S del archivo de instancia con las estadísticas a nivel de sistema operativo. Las
diferencias pueden guiarle al problema real. Por ejemplo: un tiempo medio de espera más alto de lo
normal en un tablespace determinado, se puede deber a:
• Hardware: un archivo se encuentra en una unidad lenta o tiene una configuración de RAID
inadecuada.
• Sistema operativo: el sistema operativo está ocupado con otros archivos en la misma unidad o
partición.
• Instancia: el tablespace se ha creado con propiedades diferentes al resto de tablespaces, otros
archivos de base de datos ocupados están en el mismo disco o partición (la E/S de base de datos
no está equilibrada en todas las unidades) o la mayoría de los objetos a los que se está accediendo
están en el mismo tablespace, archivo o disco.
• Aplicación: la aplicación está realizando excesivas E/S debido a que el optimizador ha elegido
una ruta de acceso deficiente a causa de estadísticas anticuadas, índices ineficaces u otros motivos.
Determine el ámbito del problema para centrar los esfuerzos en las soluciones que proporcionan el
mayor beneficio.

Definición de la Prioridad
Seleccionar el problema que tenga el mayor impacto:

• Analizar el rendimiento del sistema en función del trabajo

realizado (tiempo de CPU o de servicio) frente al tiempo
dedicado a esperar a que haya trabajo (tiempo de espera).
• Determinar qué componente consume mayor cantidad de
tiempo.
• Aumentar detalle para ajustar dicho componente, si es
preciso. L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Definición de la Prioridad y
sit RSI D
e r
niv NqueIVvaEa ajustar en primer lugar. En los informes de rendimiento, aparecen
Determine el problema
U
a c leprincipales.U
muchas estadísticas; incluso en las bases de datos ajustadas a la perfección hay un juego de eventos
O r
de espera El servidor de Oracle proporciona un juego de estadísticas de eventos de
espera para los procesos que están inactivos o en espera. El servidor de Oracle también registra el uso
de la CPU para los procesos que se están ejecutando. Para determinar el impacto de un evento en
particular, se debe comparar con el tiempo general dedicado.
El tiempo de respuesta de cada solicitud al servidor de bases de datos consta de un tiempo de espera
y un tiempo de servicio. El tiempo de servicio es el tiempo dedicado a trabajar activamente en la
solicitud (tiempo de CPU). El tiempo de espera es, por definición, el tiempo que se espera por
cualquier motivo. Se pueden ajustar ambos tiempos, el de servicio y el de espera. Para ajustar el
tiempo de servicio algo tiene que cambiar: el procesamiento, SQL, la ruta de acceso o la estructura
de almacenamiento de datos. Para ajustar los tiempos de espera, se puede reducir la contención del
recurso donde se está produciendo la espera.
Normalmente, cada proceso del servidor está en uno de estos tres estados:
• Inactivo: esperando para hacer algo (en suspensión)
• Ejecutando código: utilizando la CPU o en una cola de ejecución
• Esperando (bloqueado):
- a que un recurso esté disponible
- a que se complete una actividad solicitada

5 Eventos de Tiempo Principales
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
it RSI
5 Eventos de TiemposPrincipales D
e r E siempre tienen valores. En el ejemplo de la diapositiva, los
Los eventos den iv principales
espera I V
U N el tiempo de respuesta es lento. Top 5 Timed Foreground Events sólo
e quejan deUque
usuarioslse
c
ra que la instancia está utilizando la CPU.
muestra
O
La sección Instance CPU muestra que la instancia está utilizando el 65% de la CPU del sistema
operativo; esta información no es concluyente. Se supone que la instancia utiliza la CPU y no espera.
Este juego de diagnósticos puede significar que la instancia tiene limitaciones de CPU. Como se ha
señalado anteriormente, el ajuste de rendimiento puede reducir el tiempo de espera o tiempo de
servicio. En este caso, se debe reducir el tiempo de servicio. Para reducir el tiempo de servicio, SQL
es el área habitual que se debe examinar.

Definición de la Prioridad: Ejemplo
Time Model Statistics
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Definición de la Prioridad: y
sit Ejemplo SI D
e r R
E no proporcionan una dirección clara. Por lo tanto, continúe con el
Los eventos den iv principales
espera I V
modelo de l U UN
etiempo para buscar las áreas que consumen el tiempo de base de datos. Para determinar
a c
las rtareas de ajuste de mayor prioridad, compare el tiempo dedicado a diversas tareas y esperas con el
O general de espera y de servicio. Las dos herramientas más importantes registran las
tiempo
estadísticas de modelo de tiempo para guiar los esfuerzos de ajuste. Por ejemplo, el informe de AWR
de la diapositiva indica que el tiempo de CPU de la base de datos (tiempo de llamadas de usuario) es
474,04 segundos. El tiempo dedicado a llamadas de usuario supone el 44,85% del tiempo total de la
base de datos. "sql execute elapsed time" indica 1050,06 segundos; este tiempo incluye los tiempos
de espera. Con tan sólo esta vista limitada, es evidente que los tiempos de espera para la ejecución de
SQL son importantes y le llevarían a examinar las estadísticas de espera relacionadas con la
ejecución de SQL y los informes de SQL para identificar sentencias SQL individuales para el ajuste.
Los valores de "% of DB time" indican que el ajuste de esta área podría tener un impacto relativo. Si
se pudiera reducir "hard parse elapsed time", la mejora máxima posible sería de 1050 segundos o el
99%. SQL tardará algún tiempo en la ejecución. Por lo tanto, la mejora real podría ser muy inferior,
en función de la cantidad de mejora que se pueda obtener en esa área.

Informes de SQL Principal
SQL por Tiempo Transcurrido
SQL por Tiempo de CPU
SQL por Ejecuciones
L A
D E
D OS
SQL por Obtenciones en Buffer
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Informes de SQL Principal y
sit RSI D
e r E principal ordenan las sentencias SQL por el uso principal de
niv Ndel
Las siguientes secciones
U I VSQL
c eordered
recursoslde Umaneras, como indican sus títulos:
diferentes
• ra
SQL by Elapsed Time
O• SQL ordered by CPU Time
• SQL ordered by Gets
• SQL ordered by Reads
• SQL ordered by Executions
• SQL ordered by Parse Calls
• SQL ordered by Sharable Memory
• SQL ordered by Version Count
Estas ordenaciones permiten buscar la sentencia SQL problemática. También puede ver la sección
Complete List of SQL Text para ver el texto SQL completo. En este ejemplo, una única sentencia
SQL es responsable de la mayoría de la actividad de la instancia.
SQL_ID: fu02q80b2kva1
Select time_id, quantity_sold, amount_sold from sales s,
customers c where c.cust_id=s.custid and cust_FIRST_NAME='Dina'
order by time_id

Problemas de Ajuste Comunes
Los problemas de ajuste más comunes son:

• Sentencias SQL de carga alta o ineficaces

• Uso subóptimo de Oracle Database por parte de la aplicación
• Estructuras de memoria demasiado pequeña
• Problemas de simultaneidad
• Problemas de E/S
• Problemas de configuración de la base de datos
• Problemas de rendimiento de muy poca duración E LA
D
• Reducción del rendimiento de la base de datos en el D OS
tiempo
A
Slos
• Regresión de rendimiento inesperada después E
R yฺ cambios
de
de entorno G
E onl
E
D use
• Problemas de bloqueo O N
A CI ITAL
U ND IST R
d F
n D
Problemas de Ajuste s i t y a SIDA
Comunes
v er VSQL
• El ajuste de sentencias
i ERde carga alta o ineficaces produce un amplio impacto que puede
reducir U n N I
el uso de memoria, la CPU y los recursos de E/S. Los problemas de ajuste de SQL
l e U
c SQL mal escrito, uso ineficaz de índices, costos de ruta de acceso y ordenación. En este
incluyen
Oracurso, se supone que el DBA tiene una pequeña oportunidad o ninguna de cambiar las sentencias
SQL. Este curso trata los problemas de SQL que un DBA puede ajustar sin necesidad de
cambiar SQL. Existe otro curso que aborda el ajuste de SQL, indicado principalmente para
desarrolladores, Oracle Database 11g: SQL Tuning Workshop (Oracle Database 11g, Taller de
Ajustes de SQL).
• Los problemas como el establecimiento de nuevas conexiones a la base de datos de forma
repetida, excesivo análisis de SQL y altos niveles de contención de una cantidad pequeña de
datos (también conocida como contención de bloques a nivel de aplicación) pueden reducir el
rendimiento de la aplicación de forma significativa. Todos son usos deficientes de la base de
datos por parte de la aplicación.
• Los problemas de memoria ocupan un lugar destacado en la lista de problemas de ajuste de
instancias. El ajuste correcto de tamaño de SGA (Área Global del Sistema) incluye el pool
compartido y la caché de buffers, y el PGA (Área Global del Proceso) reduce la contención de
recursos de memoria y reduce indirectamente la E/S y la CPU.
• Un alto grado de actividades simultáneas, varios procesos o usuarios pueden dar como resultado
una contención de recursos compartidos que se puede manifestar en forma de diferentes tipos de
esperas. Sólo un único proceso puede acceder a muchos recursos al mismo tiempo. El intento de
acceso de varios procesos al mismo recurso crea contención.

Problemas de Ajuste Comunes (continuación)
• En cualquier base de datos, los problemas de E/S como el diseño de archivo de base de datos en
disco o dispositivos RAID, pueden generar problemas de rendimiento. En aplicaciones OLTP, la
cantidad de acciones redo y deshacer generados puede crear cuellos de botella en memoria o
E/S.
• Los usuarios notifican algunos problemas pero es posible que no sean visibles en informes que
abarcan intervalos de 30 minutos o más. Oracle Database tiene herramientas adicionales

(historial de sesiones activas (ASH)), que permiten al DBA ver estadísticas y métricas en
segmentos pequeños de tiempo en el pasado reciente.
• Muchas bases de datos tendrán cambios graduales: el número de usuarios, la cantidad de datos,
el número de informes y módulos en uso. Estos cambios pueden conducir a una reducción del
rendimiento. El DBA proactivo capturará y guardará estadísticas definidas en el momento en
que la base de datos se ejecuta de manera aceptable, para compararlas con las estadísticas
cuando el rendimiento de la base de datos sea deficiente para identificar las diferencias.
• El entorno de la base de datos rara vez es estático. Los parches, las actualizaciones, el nuevo
hardware o los cambios en los parámetros de la instancia pueden cambiar el rendimiento de la
L A
E
base de datos. A veces un cambio mejora el rendimiento en un área y hace que se reduzca en
D
otra. S
DO
• Los problemas de bloqueo no son problemas comunes, pero si se producen son muy importantes.
A
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
cle U UN
Ora

Ajuste de las Fases del Ciclo de Vida
El ciclo de vida de una aplicación se puede dividir en diferentes

fases:
• Diseño y desarrollo de la aplicación
• Prueba: configuración de la base de datos
• Despliegue: adición de una aplicación nueva a una base de
datos existente
• Producción: solución de problemas y ajuste
• Migración, actualización y cambios de entorno L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Ajuste de las Fases del y
sitCicloRdeSVidaI D
e r
El ajuste seguirá ilavmetodologíaE general en todas las fases del ciclo de vida. Las diferentes fases del
ciclo de vidaU n diferentes
tendrán N I V enfoques.
l e U
O r ac Diseño y Programación de Aplicaciones
Desarrollo:
Siempre que sea posible, debería comenzar a realizar los ajustes en este nivel. Con un buen diseño,
no se producen muchos de los problemas de ajuste. Utilice una instancia de la base de datos de
prueba y de desarrollo para una prueba del concepto, y para comprobar el rendimiento de varias
alternativas de diseño.
Prueba: Configuración de la Base de Datos
La fase de prueba es la continuación de la fase de desarrollo, en donde se realizan pruebas más
realistas que utilizan el hardware de producción y el sistema operativo.
Despliegue: Adición de una Aplicación Nueva a una Base de Datos Existente
Al agregar una aplicación nueva a un sistema existente, la carga de trabajo cambia. Todos los
cambios importantes en la carga de trabajo deberían ir acompañados de una supervisión del
rendimiento.
Producción: Solución de Problemas y Ajuste
Siga la metodología. Utilice una instancia de prueba para determinar si la solución ha eliminado el
cuello de botella.
Migración, Actualización y Cambios de Entorno
Un cambio del sistema operativo o de la versión de base de datos requiere pruebas exhaustivas para
evitar problemas de rendimiento.

Ajuste durante el Ciclo de Vida
El ajuste se puede dividir en dos clases:
• Proactivo (lo mejora, por lo que no se interrumpirá)
– Probar supuestos.
– Buscar áreas de problemas.
– Resolver el problema.
• Reactivo (espera hasta que se interrumpe y, a continuación,
se corrige)
– Supervisar instancias activas.
– Ajustar problemas según sea necesario. L A
D E
D OS
E SA
E GR nlyฺ
D E eo
Proactivo
I O N L us Reactivo
D AC RITA
F
a n d A D
Ajuste durante el Ciclo y
sitde Vida SI D
e r R
E implica dos vías de acción: ajuste proactivo o reactivo. Durante las
El ajuste durante
U nielvcicloNdeIVvida
e desarrollo
fases de ldiseño,
c U y prueba, el ajuste es más proactivo; es decir, los casos de prueba y
O r a
supuestos se diseñan y se prueban. Los resultados se miden y se comparan con otras configuraciones.
En entornos de despliegue y producción, el ajuste suele ser reactivo. Se elimina la necesidad de las
cargas hipotéticas ya que se crean usuarios y cargas de trabajo reales, pero también disminuye la
capacidad de anticipar problemas. Puede supervisar la instancia de base de datos para observar los
cambios y las tendencias en métricas de rendimiento. En la información que recopila mediante la
supervisión, es posible que pueda mitigar los problemas de rendimiento antes de que los detecten los
usuarios.
Es posible que el DBA se pueda ver implicado en ajustes desde las primeras etapas de diseño y
desarrollo. Es menos caro corregir bugs y problemas de rendimiento al principio del ciclo de vida
que al final. Las diferencias en el ajuste de las últimas fases del ciclo de vida radican, principalmente,
en lo que está permitido hacer. Muchos DBA de un entorno de producción no tienen permitido
cambiar el SQL ni las estructuras de datos. Sin embargo, un cambio de diseño destinado a mejorar el
rendimiento puede justificar el envío de una solicitud de cambio al proveedor de la aplicación o el
equipo de desarrollo.

Diseño y Desarrollo de Aplicaciones
La aplicación se puede ajustar incluso en las fases de diseño y

desarrollo creando y ajustando casos de prueba.

• Comprobar la normalización con respecto a las funciones
principales.
• Comprobar las estructuras de datos con respecto a los
tiempos de acceso.
• Fijarse en los puntos en los que se serializan los procesos.
• Ajustar los informes principales.
E LA
• Ajustar los procesos de gran volumen. S D
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Diseño y Desarrollo de y SI
sitAplicaciones D
e r R
Ese sigue durante las fases de diseño y desarrollo se centra en los cuellos
La metodologíande ivajuste Ique
V
de botella
l U N
ecomunes deUcualquier sistema: Normalización, estructuras de datos, puntos de
r a c
serialización, informes principales y solicitudes de gran volumen. En las primeras fases del diseño, se
O
conocen las funciones principales de la aplicación. El nivel de normalización de los datos tiene
consecuencias graves en el rendimiento. Un exceso de normalización puede dar lugar a grandes
uniones multidireccionales que pueden utilizar todos los recursos de host disponibles. La falta de
normalización da lugar a otra serie de problemas: Datos inconsistentes, comprobaciones de datos
complejos y dificultad para migrar datos a otros esquemas o bases de datos. La solución necesita un
diseño totalmente normalizado y una desnormalización cuidadosa con comprobaciones de
consistencia incorporadas.
Si se seleccionan las estructuras de datos adecuadas, se pueden obtener grandes beneficios en el
rendimiento como, por ejemplo, tablas particionadas para grandes juegos de datos. El diseño debe
evitar la contención de recursos para aumentar la escalabilidad. Se deberían crear prototipos de los
principales informes que necesita la aplicación y ajustarlos para los tiempos de ejecución esperados.
También se deberían crear prototipos de las funciones de gran volumen en lo relativo a los datos o las
ejecuciones.
Cada uno de estos posibles cuellos de botella tendrá casos de prueba. Estos casos de prueba se
ajustan con la misma metodología que se utiliza en la base de datos de producción: Recopilación de
estadísticas, ajuste del cuello de botella, pruebas y repetición hasta lograr el objetivo.

Prueba: Configuración de la Base de Datos
La fase de prueba permite realizar el ajuste a un nivel más

profundo.
• Comprobar el diseño físico.
• Supervisar la contención de recursos.
– Uso de memoria
– Bloqueos
– Puntos conflictivos del disco
• Probar el agotamiento de los recursos. L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Prueba: Configuración y
t la Base
side D
SI de Datos
e r R
E pruebas a un nivel más profundo. En el caso de prueba, se
U nivpermite
La fase de prueba I V
realizar
deberíanle
c UN de la aplicación, las cargas esperadas y realizar pruebas de esfuerzo de
probar las funciones
ra improbables. Estos tipos de pruebas pueden aportar valiosos datos sobre los mejores diseños
cargas
O
físicos y las mejores configuraciones del hardware y sistema operativo. Es importante controlar los
puntos conflictivos, incluso en los discos rápidos. Debería planificar la configuración de los datos
para lograr un tiempo de recuperación menor y un acceso más rápido a los datos. Incorpore los
requisitos de negocio sobre el tiempo de recuperación y la disponibilidad en la medida que sea
posible para tener en cuenta la sobrecarga que implican estos requisitos.
Realice pruebas con cargas que agoten los recursos del equipo. Estas pruebas identifican los recursos
más utilizados. Estos recursos son los que limitan la escalabilidad del sistema.
El DBA utiliza el modelo de tiempo y eventos de espera en cada fase para identificar los cuellos de
botella y las sesiones de ajuste para corregir los cuellos de botella en cada nivel.

Despliegue
Despliegue de:
• Nueva aplicación y base de datos

– Tomar la línea base.
– Controlar el crecimiento y el rendimiento.
• Nueva aplicación en base de datos existente
– Tomar la línea base antes del despliegue.
– Tomar la línea base después del despliegue.
– Comparar las líneas base. L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Despliegue y
sit RSI D
e r
Cuando inicialmente
U I VE una nueva aplicación, las expectativas sobre su rendimiento suelen
niv seNdespliega
la realidad.U
diferir dele Aquí hay dos variaciones que hay que tener en cuenta: la primera para una
r a c
aplicación nueva en una base de datos nueva y la segunda para una aplicación agregada a una base de
O
datos existente.
La aplicación nueva en una base de datos nueva no tiene línea base, por lo que el ajuste se basa en el
rendimiento actual. Genere informes de rendimiento con regularidad y guárdelos como líneas base. A
medida que aumenta el tamaño del juego de datos o el número de usuarios de la aplicación, compare
nuevos informes de rendimiento con los informes anteriores. Esto le permite realizar el ajuste antes
de que el rendimiento se degrade hasta un nivel inaceptable.
Si agrega una aplicación nueva a una base de datos existente, compare los informes de rendimiento
de línea base de antes y después de desplegar la aplicación. Estos informes indican los recursos que
está utilizando la aplicación nueva y la posible contención de recursos con las aplicaciones
existentes.

Producción
El ajuste es reactivo. Debe saber:

• ¿Qué ha cambiado?
• ¿Dónde está la línea base?
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Producción y
sit RSI D
e r Eotras fases del ciclo de vida de la aplicación es proactivo. Hay que
• Generalmente,
n iv el ajuste
I V en
U UN antes de que los usuarios los detecten.
buscar posibles problemas
le
Elcajuste de una base de datos de producción suele ser un ajuste reactivo. Algo va mal: un
• ra
O informe que se ejecutaba en minutos ahora tarda horas, los usuarios se quejan de que el tiempo
de respuesta ha aumentado y las copias de seguridad no terminan en el tiempo asignado.
• Algo ha cambiado: ¿hay más usuarios? ¿Se está ejecutando un informe o una aplicación nueva?
¿Ha cambiado algo en el sistema de operativo?
• El ajuste de un sistema de producción que anteriormente funcionaba de manera aceptable y que
ahora tiene un problema depende de saber o deducir lo que ha cambiado. Compare el informe de
estadísticas de línea base obtenido cuando la base de datos funcionaba de manera aceptable con
un nuevo informe obtenido cuando el problema era visible. Las diferencias deberían ser
evidentes.
• El ajuste de una base de datos de producción cuando no hay estadísticas de línea base es más
difícil, pero posible. Hay que utilizar la misma metodología y ajustar los componentes
prioritarios. Hay que utilizar el modelo de tiempo para identificar el problema. Hay que tener en
cuenta las posibles soluciones, comenzando con el diseño para seguir en orden descendente. A
continuación, hay que utilizar una sesión de ajuste para probar las soluciones.

Migración, Actualización y Cambios de Entorno
1. Crear un sistema de prueba.

2. Capturar una carga de trabajo representativa.

3. Ejecutar la carga de trabajo en el sistema de prueba.
4. Recopilar estadísticas.
5. Restablecer el sistema de prueba, realizar un cambio.
6. Ejecutar la carga de trabajo.
7. Capturar estadísticas y comparar.
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Migración, Actualización y
sit y Cambios D
SI de Entorno
e r R
nielventorno
Frecuentemente, I VdeEla instancia de base de datos debe cambiar de forma que impacte en el
U UN se debe actualizar o sustituir. El sistema operativo se actualiza o se cambia
e El hardware
rendimiento.
l
c
rasistema de operativo. El software de la base de datos se actualiza a una nueva revisión. El
a otro
O
subsistema de disco se modifica o sustituye. Incluso los cambios más pequeños como los cambios
realizados en el parámetro de la base de datos y del sistema operativo pueden tener efectos
significativos.
En general, desea probar la carga de trabajo actual en el sistema de destino antes de que se produzca
el cambio en el sistema de producción. La dificultad se presenta al capturar una carga de trabajo
representativa y reproducir la carga de trabajo en una base de datos de prueba.
Oracle Database 11g Enterprise Edition tiene la opción Real Application Testing, que incluye dos
herramientas, SQL Performance Analyzer y Database Replay, para superar estas dificultades. Estos
temas se tratan en más detalle en la lección titulada "Uso de SQL Performance Analyzer" y "Uso de
Database Replay".

Sesión de Ajuste de ADDM
La sesión de ajuste de ADDM utiliza el mismo procedimiento

que la sesión de ajuste manual, pero combina pasos.
Sesión de Ajuste de ADDM Sesión de Ajuste Manual
Genere el informe de ADDM. Recopile estadísticas actuales.

Compare las estadísticas actuales con un juego
anterior; consulte en la base de conocimientos de
problemas de rendimiento.
L A
Defina el problema y realice recomendaciones.
D E
Revise las recomendaciones. Cree una solución de prueba.
D OS
S A
Implemente las recomendaciones. Implemente y mida el cambio.R E
E G nlyฺ
Revise el siguiente informe de Decida si la solución D o
Ecumple eel objetivo.
N s
ADDM.
C IO AL u
D A RIT
F
a n d A D
Sesión de Ajuste de ADDM y
sit RSI D
e r
niv NIVdeEBase de Datos Automático (ADDM) sigue internamente los pasos de la
El Monitor de Diagnóstico
U
sesión dele
c U En la diapositiva, se muestran los pasos que se siguen cuando se utiliza
ajuste manual.
O r
ADDM.a Los pasos manuales se muestran como subpasos de los pasos de ADDM.
ADDM consolida la sesión de ajuste manual para identificar rápidamente las áreas que producen los
mayores beneficios. ADDM se ejecuta automáticamente cada vez que se realiza una instantánea de
AWR. Las conclusiones del último informe de ADDM se muestran en la página inicial de la base de
datos de Enterprise Manager.

Rendimiento frente a Requisitos del Negocio
Factores que afectan al rendimiento:

• Puntos de control frecuentes

• Realización de archivado
• Totales de control de bloque
• Redundancia
– Copias de seguridad frecuentes de los archivos de datos
– Varios archivos de control
– Varios miembros de redo log en un grupo L A
D E
• Seguridad
D OS
– Auditoría
E SA
– Cifrado E GR nlyฺ
– Base de datos privada virtual/Control DdeE acceso e o detallado
N s
C IO AL u
D A RIT
F
a n d A D
Rendimiento frente a s y D
it RSIdel Negocio
Requisitos
e r E negocios de determinadas formas. A menudo los requisitos del
iv al realizar
Siempre hay unncosto I V
U
e influir
negocio lpueden UN en el rendimiento. Se debe tener en cuenta la sobrecarga que supone proteger
r a
frente c
a eventos como el impacto en el tiempo de inactividad y recuperación de fallos e incluso el
O
evento improbable de corrupción de bloques. Los requisitos de compresión de datos, configuración
de idioma nacional y seguridad son todos los requisitos de negocio que pueden influir en el
rendimiento. Debido a que se trata de requisitos de negocio, configure la base de datos para el
negocio y, a continuación, ajuste la base de datos en consecuencia. El requisito de tiempo de
actividad, el tiempo medio de recuperación y la cantidad de datos que se podrían perder en un fallo
del disco o del sistema son aspectos del negocio.
La redundancia mejora la disponibilidad pero necesita más E/S: Oracle recomienda que haya al
menos dos archivos de control, aunque sólo es necesario uno. Muchos DBA utilizan tres o cuatro.
Cuantos más archivos de control haya, más escrituras se necesitan y, por lo tanto, mayor es la
sobrecarga. Si se tienen varios miembros de redo log, se reducen las posibilidades de perder datos
debido a un fallo del disco, pero aumenta la sobrecarga de la escritura de redo. Los puntos de control
frecuentes reducen el tiempo medio de recuperación, pero pueden aumentar el número de escrituras
físicas. Cada elemento que se incluye en la diapositiva tiene asociado un costo de rendimiento.
A menudo, son necesarias las medidas de seguridad y cada una de ellas ejerce cierta influencia en el
rendimiento, incluso si se trata de una influencia muy pequeña. La pregunta no es si se deben utilizar
las funciones de seguridad sino cuáles son necesarias y utilizar sólo dichas funciones.

Recursos de Ajuste de Rendimiento
Oracle proporciona un juego de recursos grande para resolver

problemas.
• Documentación
• My Oracle Support
• Foros
• Solicitudes de servicio de rendimiento
• Informe de diagnóstico remoto
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Recursos de Ajuste de t y
siRendimientoSI D
e r R
U
es el juego de niv un N
Oracle proporciona
documentaciónIVEde ladebase
gran juego recursos de ajuste de rendimiento. El primero y el más accesible
de datos. La guía Oracle Database Performance Tuning Guide
c
(Guía de l e
Ajuste de U
Rendimiento de Oracle Database) trata una amplia variedad de problemas de ajuste
de
O r a
rendimiento y los pasos para encontrar una solución. La guía Oracle Database 2 Day + Performance
Tuning Guide (Guía 2 Días + Ajuste de Rendimiento de Oracle Database) es una visión general de la
metodología de ajuste de rendimiento de Oracle y un enfoque orientado a tareas para ajustar problemas
comunes.
La documentación de My Oracle Support (MOS) está disponible para todos los que se han suscrito a los
servicios de soporte. Es necesario un identificador de Servicios de Soporte Oracle para configurar una
cuenta MOS. MOS tiene un gran repositorio de documentación que describe las mejores prácticas,
instrucciones y diagnóstico de bugs y problemas. El centro de especialización ofrece Nota: 390374.1
Oracle Performance Diagnostic Guide (Guía de Diagnostico de Rendimiento de Oracle) para ayudar a
los clientes en la clasificación y ajuste de diferentes problemas de rendimiento.
Los Servicios de Soporte de Oracle aceptarán solicitudes de servicio de rendimiento. Oracle
Configuration Manager (OCM) es una herramienta disponible en MOS y que se integra en Enterprise
Manager para ayudar a los clientes y a los Servicios de Soporte de Oracle a obtener información sobre
la solución de problemas de una forma rápida. OCM también proporciona alertas proactivas relativas a
las actualizaciones de software y configuración de la base de datos.
Los Servicios de Soporte de Oracle han desarrollado una herramienta de informe de diagnóstico remoto
que se puede descargar, la herramienta recopila una gran cantidad de información sobre un sistema de
la base de datos para facilitar las solicitudes del servicio.
Finalmente, los foros de discusión de la comunidad están disponibles para el público en Oracle
Technical Network.
Archivado de una Solicitud de Servicio de
Rendimiento
Archivar una solicitud de servicio de rendimiento.
• ¿El problema es de toda la instancia o es específico de la

consulta?
• Identificar la causa raíz.
• Obtener informes de Statspack o AWR, y estadísticas del
sistema operativo.
• Obtener informes de Remote Diagnostics Agent (RDA).
• Obtener informes de SQL_TRACE. L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Archivado de una Solicitud y
sit de S I D
Servicio de Rendimiento
v e r E R
Los problemas n dei rendimiento
I V con los que se encuentra suelen ser exclusivos de la configuración de
U N
le y la baseUde datos. Ocasionalmente, el problema no se soluciona con un ajuste.
la aplicación
Los a c
rServicios de Soporte de Oracle (OSS) disponen de un documento, "Note: 210014.1 How to Log
O
a Good Performance Service Request" (Nota: 210014.1 Cómo Registrar Solicitudes de Servicio de
Rendimiento Correctas), que le guiará a través del proceso de registro de una solicitud de servicio de
rendimiento.
El sistema operativo necesita cierta información:
• ¿El problema es de toda la instancia o es específico de la consulta? ¿Cuándo se produce el
problema? ¿Qué funciona y qué no funciona? Proporcione ejemplos de SQL que se comporte de
manera aceptable y de SQL que no se comporte de manera aceptable.
• ¿Cuál es la causa raíz? Elabore informes de Statspack o AWR cuando el rendimiento sea
"bueno" y cuando sea "malo", y compárelos. Busque alguna pista en los archivos log de la base
de datos, la red y el sistema operativo. Elimine los cambios recientes de uno en uno y registre
los resultados; incluso algo que no cambie el problema, puede ayudar a delimitar la búsqueda de
la causa raíz. Es posible que no pueda determinar la causa raíz.
• Obtenga informes de Statspack o AWR y estadísticas del sistema operativo durante el tiempo en
que la base de datos experimente el problema y obtenga una línea base cuando el problema no
aparezca, si es posible. Tome instantáneas de cortos períodos de tiempo cuando el problema sea
evidente.

Informe de RDA
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Informe de RDA y
sit RSI D
e r E Agent (RDA) se ha diseñado para proporcionar un juego
niv Diagnostics
El informe de Remote
U I V
completole
c UNa los Servicios de Soporte de Oracle. RDA es una herramienta útil para el
de información
raporque recopila la información en un informe de fácil acceso. Los Servicios de Soporte de
ajuste
O
Oracle anima a los clientes a utilizar el grupo de Oracle Configuration Manager/RDA para obtener
solicitudes de servicio. Para obtener más información, consulte MOS Nota 250434.1, “Learn More
About Software Configuration Manager”
(Obtener más Información sobre el Gestor de Configuración de Software). Los script de RDA tienen
como finalidad recopilar información que ayude a diagnosticar el problema. Sin embargo, la salida
también es útil para ver la configuración general del sistema. Para obtener más información y
conocer la ubicación de descarga, consulte la nota de MOS: 414966.1 "RDA Documentation Index“
(Índice de Documentación de RDA). En la diapositiva, sólo se muestra una parte de la sección
Overview del informe de RDA. Este informe es muy largo y detallado. Se puede visualizar
fácilmente con los exploradores habituales.

Herramienta de Supervisión y Ajuste:
Visión General
Servicios
Log de alertas
tkprof
Archivos de rastreo
trcsess
Vistas de rendimiento
Estadísticas del sistema

Estadísticas del optimizador Estadísticas de sesión
Estadísticas SQL Modelo de espera A
Estadísticas básicas Modelo de tiempo E L
D
Histogramas
D OS
Métricas Alertas A
Estadísticas de servicio R ES
ASH E G nASH
Informes l yฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Herramienta de Supervisión y
sit R D
SI Visión General
y Ajuste:
e r
v IVutilizará E muchas de las herramientas que se indican en la diapositiva. Los
nilecciones,
En las siguientes
U
recuadros
c l UNindican herramientas que contienen elementos de datos raw. Los recuadros
ede color claro
másraoscuros son herramientas que han utilizado los datos raw para obtener más información útil. Con
O
frecuencia, la información se proporciona en informes como, por ejemplo, el informe del historial de
sesiones activas (ASH).
Las vistas de rendimiento dinámico, o vistas con formato V$, también se denominan vistas de
rendimiento y mantienen en memoria las estadísticas raw.
Los archivos de rastreo son difíciles de interpretar y principalmente están destinados para que los
utilicen los Servicios de Soporte de Oracle. Sólo a determinados rastreos se les puede aplicar formato
con la utilidad tkprof. La utilidad trcsess es una herramienta única para combinar y filtrar
archivos de rastreo para extraer las estadísticas de una sola sesión, servicio o módulo en varios
archivos de rastreo. El uso de las herramientas se tratará en una lección posterior.
El recuadro Services indica que la dirección del control de rendimiento está organizada en torno a
servicios. Las estadísticas se agregan por servicios y se pueden elaborar diversos informes por
servicios. Las estadísticas recopiladas por servicios, en lugar de por esquema, instancia o sesión,
pueden proporcionar una perspectiva única del rendimiento de la aplicación.

Herramienta de Supervisión y Ajuste: Visión
General
Servicios
AWR Líneas base de AWR
Páginas de rendimiento
de EM Comparar períodos
Línea base de métrica
Políticas de EM
ADDM L A
D E
Asesores
Control de SGA directo D OS
Analizador de bloqueo E SA
E GR nlyฺ
D E eo
Statspack
I O N us base
Líneas
L
D AC RITA
F
a n d A D
y
sit R
Herramienta de Supervisión D
SI Visión General (continuación)
y Ajuste:
e r
v se enumeranE en esta dispositiva formatean los datos para que la información
Las herramientas
U nique I V
e MuchasUdeNlas herramientas analizan los datos para poder detectar los problemas de
sea más lútil.
c
ra proactiva y ofrecer recomendaciones. En las siguientes lecciones, se explican y se utilizan la
manera
O
mayoría de las herramientas.

Prueba
El rendimiento de la base de datos es bajo. Los usuarios se
quejan de tiempos de respuesta lentos desde el inicio del
procesamiento de fin de mes. Compruebe los principales

eventos de tiempo del informe de AWR para mostrar los eventos
relacionados con CPU y E/S. A continuación, compruebe el
modelo de tiempo. Muestra el tiempo transcurrido de ejecución
de SQL, como el principal componente del tiempo de base de
datos. ¿Cuál debe ser el siguiente paso de diagnóstico?
a. Las estadísticas de SQL en informe de AWR o Statspack
b. Lista de V$SQL ordenada por ejecuciones
c. Recomendaciones del Monitor de Diagnóstico de Base de E LA
Datos Automático (ADDM) O SD
AD
d. Remote Diagnostics Agent para comprobar la configuración
S
de la base datos G RE yฺ
e. Uso de las herramientas del sistema E E onpara
operativo
l buscar
N D use
procesos sin control IO L
D AC RITA
F
a n d A D
Respuesta: c, a y
sit RSI D
e r E de aplicación con el procesamiento de fin de mes. Parece que
niv aNunIVproblema
Los síntomas apuntan
U
a c le SQL deU
hay algunos larga ejecución que consumen grandes cantidades de recursos de base de datos.
Las
O rrecomendaciones de ADDM deben apuntar al problema, posiblemente un rendimiento deficiente
de SQL.
La sección de estadísticas SQL de un informe de AWR o Statspack mostrará la sentencia SQL
principal que consume recursos de la base de datos.

Resumen

• Identificar problemas de rendimiento

• Definir prioridades de ajuste
• Interpretar diagnósticos de ajuste
• Ajustar la fase del ciclo de vida
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Identificación del Problema
Esta práctica trata la identificación de un problema del sistema
operativo mediante EM
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Ora
c
n
r s
le U UN
ive IVE
a
F
ity RSID
nd AD
D
C
UN DIST
N
A RIT
IO AL
E
R
DE use o
ES
G nlyฺ
A DO
S D E LA
Uso de Métricas y Alertas
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora
Objetivos

siguiente:
• Visualizar métricas mediante vistas del historial de métricas
• Crear umbrales de métricas
• Visualizar alertas
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Métricas y Alertas
• Métrica: ratio de cambio en una estadística acumulativa

• Alertas: evento que se genera cuando una métrica

supervisada supera un umbral
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Métricas, Alertas y Líneas y
sit Base SI D
e r R
Ese necesita cierta información además de la que proporcionan las
Para supervisarneliv V
rendimiento
I
U UN si una estadística concreta es importante, deberá saber cuánto ha
e Para determinar
estadísticas.
l
c
ra a lo largo de un período de tiempo concreto. Para ser proactivo, necesita recibir una
cambiado
O
notificación cuando existan determinadas condiciones como, por ejemplo, cuando el tiempo de
respuesta del sistema se acerque al máximo acordado. Para diagnosticar problemas de rendimiento,
necesitará saber qué ha cambiado. Las métricas y las alertas proporcionan parte de esta información.
En general, una métrica es un ratio de cambio de tiempo en una estadística acumulativa. Por ejemplo,
las lecturas físicas por segundo. Pero existen otras métricas que se basan en eventos como
"tablespace lleno" o errores como "instantánea demasiado antigua".
Los valores de umbral se pueden definir para varias métricas y, cuando el valor de la métrica supera
el valor del umbral, se genera una alerta.

Limitación de las Estadísticas Básicas
2M
Ratio alto
E/S
Lecturas físicas de 30 minutos
V$SYSSTAT
Tiempo
2M Ratio bajo
L A
30 minutos D E
E/S D OS
Las estadísticas
E SA
continúan creciendo. R
E G nlyฺ
N DE use o Tiempo
C IO AL
D A RIT
F
a n d A D
y
sit RBásicas
Limitación de las Estadísticas SI D
e r Ede los eventos que tienen lugar en la base de datos. Las estadísticas y
iv contadores
Las estadísticasnson I V
U Nlos datos raw. Las estadísticas básicas son siempre únicamente un valor en
e de esperaUson
los eventos
l
c
Oa
un rmomento determinado.
Si crea un gráfico de los valores de estadística básicos durante un largo período de tiempo, se dará
cuenta de que los valores continúan creciendo en el tiempo. En la diapositiva se ilustra un posible
ejemplo de un gráfico para la estadística physical reads extraída de la vista de rendimiento
V$SYSSTAT. Como se puede visualizar en la diapositiva, aunque el valor de estadística sea el
mismo para ambos gráficos, al final del período de observación, la tendencia es totalmente distinta.
En el gráfico superior, queda claro que la base de datos está experimentando un ratio mucho mayor
que el gráfico inferior. Por lo tanto, no tiene sentido mirar únicamente al valor de estadística.
Para entender mejor el comportamiento de la base de datos, necesita poder visualizar las curvas o
tendencias además de los valores. De este modo, necesita calcular los ratios de estadística durante un
período de tiempo para determinar la tendencia durante ese período.

Herramientas Delta Típicas
• Se necesita la comparación de estadísticas en dos puntos

de tiempo.
• Las siguientes herramientas producen deltas:
– Informes de AWR
– Statspack
– Scripts personalizados
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Herramientas Delta Típicas y
sit RSI D
e r E
iv sonIVúnicamente
Las estadísticasnbásicas números raw que se acumulan desde que se inicia la
U N
U es un juego de estadísticas capturadas en un punto de tiempo concreto.
instancia.leUna instantánea
r
Para a c
obtener valores de estadística significativos, realice instantáneas en momentos distintos y
O
calcule la diferencia de los valores. La diferencia es un delta. Existen varias herramientas que
producen un delta. Statspack, el repositorio de carga de trabajo automática (AWR) y los scripts
personalizados producen informes del valor delta a lo largo de dos instantáneas.
AWR y Statspack le permiten guardar juegos de instantáneas como referencia futura.

Oracle Database 11g Solución: Métricas
V$SYSMETRIC V$FILEMETRIC
V$METRICNAME
V$SESSMETRIC V$EVENTMETRIC
V$SERVICEMETRIC V$WAITCLASSMETRIC
Cliente 1 Cliente 2 Cliente 3 Cliente 4
Generación de redo/ L A
MMON Métrica 1 Métrica 2 Transacción D E
D OS
Estadística básica 1 E SA
E GR nlyฺ
Generación de redo N DE use oRollback de usuario
Confirmación
C IO de A L
usuario
A I T
U ND IST R
d F
n D
Oracle Database 11g s i t y a SMétricas
Solución: I DA
i
El servidor de Oraclev erDatabase
V
R estadísticas básicas durante las operaciones normales. Las
Erecopila
n
U son I
estadísticas
c l e básicas UNrecuentos simples. Por ejemplo, el recuento del número de lecturas físicas en
ra desde el inicio es una estadística básica.
el sistema
O
Las métricas son estadísticas secundarias que se derivan de las estadísticas básicas. La mayoría de las
métricas realizan un seguimiento de los ratios de cambio en las actividades del servidor de Oracle.
Por ejemplo, las lecturas físicas medias en el sistema en los últimos 60 minutos sería una métrica.
Los componentes internos (clientes) utilizan las métricas para controlar el estado del sistema,
detectar problemas y aplicar ajustes automáticos. El proceso de monitor de gestión (MMON)
actualiza datos de métricas de forma periódica a partir de las estadísticas básicas correspondientes.
Los componentes del servidor de Oracle Database utilizan las métricas para realizar funciones de
gestión. Por ejemplo, el Monitor de Diagnóstico de Base de Datos Automático (ADDM) utiliza las
lecturas físicas medias del sistema de los últimos 60 minutos como entrada. Puede que otro
componente necesite una métrica distinta según la misma estadística básica, las lecturas físicas. Por
ejemplo, puede que el asesor de memoria necesite recuentos de lecturas físicas durante las horas de
más trabajo. Oracle Database 11g soporta métricas para estadísticas de eventos del sistema, de
sesión, de archivos y de espera. Cada métrica aparece identificada de forma única por un número de
métrica y va asociada a un nombre de métrica. El diagrama muestra algunas de las vistas fijas a las
que puede acceder para explorar los datos de métrica. Para obtener más información sobre estas
vistas, consulte la guía Oracle Database Reference (Referencia de Oracle Database).

Ventajas de las Métricas
DBA
L A
D E
Consultar S
Analizar diferencias. una métrica. D O
E SA
E GR nlyฺ
Sin métricas
D ECon métricas
e o
N s
C IO AL u
D A RIT
F
a n d A D
Ventajas de las Métricas y
sit RSI D
e r
La ventaja principal
U I VE el registro de métricas es que, cuando un componente necesite
niv queNsupone
U de alguna actividad, los datos que necesitará estarán disponibles
calcular leleratio de cambio
c
r a
inmediatamente.
O
En las versiones anteriores era necesario capturar estadísticas antes y después de ejecutar la carga de
trabajo para calcular el ratio de cambio para una estadística básica concreta. Al contar con métricas,
bastará con que ejecute la carga de trabajo y seleccione las métricas correspondientes.
Los componentes del servidor ahora tienen una base para el ajuste automático y comprobaciones de
estado con las métricas recopiladas por el servidor. Las métricas proporcionan la información de
rendimiento necesaria para la gestión automática de memoria y el monitor de diagnóstico de base de
datos automático.

Visualización de la Información del
Historial de Métricas
• En memoria:
– V$SYSMETRIC_HISTORY (última hora)

– V$FILEMETRIC_HISTORY
– V$WAITCLASSMETRIC_HISTORY (última hora)
– V$SERVICEMETRIC_HISTORY
– V$SESSION_WAIT_HISTORY (últimos 10 eventos)
• En disco:
– DBA_HIST_SYSMETRIC_SUMMARY
L A
– DBA_HIST_SYSMETRIC_HISTORY E
D
– DBA_HIST_SESSMETRIC_HISTORY
D OS
– DBA_HIST_SYSTEM_EVENT (acumulativa)
E SA
– DBA_HIST_FILEMETRIC_HISTORY (sólo G R yฺ
alertas)
– E
DBA_HIST_FILESTATXS (acumulativa)
E o nl
N D use
– DBA_HIST_WAITCLASSMET_HISTORY
IO L(alerta)
D AC RITA
F
a n d A D
y
sit RSdel
Visualización de la Información D
I Historial de Métricas
e r E en algunas vistas V$, donde los valores son los promedios durante
Los valores de n iv se Iexponen
métrica V
un intervalo
l U UN
e de tiempo bastante pequeño. Los intervalos pueden variar según la clase de métrica, de
a c
15 rsegundos a 10 minutos. Las instantáneas de los datos en las vistas V$ persisten en las tablas
O
DBA_HIST.
En la diapositiva se muestran algunas vistas de métrica y de AWR.
Por ejemplo:
La métrica V$SYSMETRIC_HISTORY muestra todos los valores de métricas del sistema
disponibles en la base de datos. Esta vista muestra métricas de duración larga (60 segundos con
historial de 1 hora) y de duración corta (15 segundos con un único intervalo).
DBA_HIST_SESSMETRIC_HISTORY muestra el historial de varias métricas de sesión
importantes. Contiene ejemplos (instantáneas) de la vista V$SYSMETRIC_HISTORY.
Nota: para acceder a las vistas DBA_HIST_* es necesaria una licencia de Diagnostics Pack.
Para obtener más información sobre estas vistas y los detalles de la columna, consulte la guía Oracle
Database Reference (Referencia de Oracle Database).

Uso de EM para Ver Detalles de Métricas
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Uso de EM para Ver Detalles y
sit R I D
deSMétricas
e r
v Metrics E visualizar una lista con todas las métricas de rendimiento
U niAll
Utilice la página I V para
disponibles
c l e en la baseUdeNdatos. Puede acceder a esta página desde la página inicial de la base de
rahaciendo clic en el enlace All Metrics de la sección Related Links.
datos
O
En la página All Metrics, podrá expandir todos los grupos de métricas o grupos específicos para
visualizar métricas concretas. Una vez seleccionada una métrica, se mostrará la página de la métrica
en cuestión. Podrá visualizar el valor de la métrica a lo largo de un período de tiempo concreto. Esta
vista se puede personalizar. El gráfico correspondiente muestra el historial de valores de la métrica.
Para acceder a la página que se muestra en la página inicial de la base de datos, haga clic en All
Metrics en la sección Related Links. En la página All Metrics amplíe Waits by Wait Class y, a
continuación, haga clic en Database Time Spent Waiting(%). En la página Database Time Spent
Waiting(%), haga clic en Concurrency.

Histogramas Estadísticos
Ratio alto
E/S
Lecturas físicas de 30 minutos
V$SYSSTAT
Tiempo ¿Es un
problema
5500 real?
L A
V$FILE_HISTOGRAM D E
Número
de D OS
esperas E SA
E GR nlyฺ
D E Período e o de
8 16 32 64 128 256 512N … 2 us tiempo
1 2 4
I O 22
L
D AC RITA
F
a n d A D
Histogramas Estadísticos y
sit RSI D
e r
U niv le N
Aunque las métricas VEproporcionar una idea de la tendencia de estadísticas concretas, no
pueden
I
pueden comunicarle
c U
le Por ejemplo,
si un cuello de botella concreto está afectando a todo el sistema o si sólo está
r a
localizado.
O puede observar un ratio de métrica alto, pero este aumento repentino puede
estar localizado en sólo una o dos sesiones del sistema. En este caso, puede que no merezca la pena
investigar el problema. Sin embargo, si el aumento repentino se generaliza a todo el sistema, es
necesario investigar más. Esta información está disponible a través de las vistas de rendimiento de
histograma.
Tal y como se muestra en la diapositiva, se observa un aumento repentino en el ratio de E/S. Puede
correlacionar esta información con el histograma de E/S correspondiente que está en
V$FILE_HISTOGRAM. Esta vista muestra un histograma de todas las lecturas de bloque
individuales, archivo por archivo. El histograma tiene cubos de intervalos de tiempo, medidos en
milisegundos, desde 1 ms hasta 222 ms (69,9 minutos). El valor de cada cubo lo compone el número
de veces que el sistema esperó esa cantidad de tiempo. Por ejemplo, en la diapositiva se puede ver
que el sistema esperó 5.500 veces durante más de 32 ms y menos de 64 ms para leer los bloques de
los discos. Si los tiempos de acceso son normalmente menores de 10 ms, es una causa de
preocupación para el sistema y debe investigarlo más. Si nota que los números son altos en períodos
de tiempo de espera más cortos, no debe preocuparse mucho.
Las métricas le avisarán de la existencia de un posible problema. Al acceder a ellas mediante
histogramas, puede determinar con claridad si realmente existe un problema.

Vistas de Histograma
• V$EVENT_HISTOGRAM: para cada evento como “db file

sequential read”
• V$FILE_HISTOGRAM: para lecturas de bloque

individuales por archivo de datos
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Vistas de Histogramasit y SI D
e r R
V$EVENT_HISTOGRAM
U VE un histograma del número de esperas por evento.
niv NImuestra
le
V$FILE_HISTOGRAM
c U muestra un histograma de todas las lecturas de bloque individuales por
Or a
archivo.
El histograma contiene cubos de intervalos de tiempo de < 1 ms, < 2 ms, < 4 ms, < 8 ms, ... < 2^21
ms, < 2^22 ms, >= 2^22 ms.
También puede visualizar las estadísticas de histograma desde Enterprise Manager. Desde la página
Performance, haga clic en uno de los elementos del área de leyenda para el gráfico Active Sessions
como, por ejemplo, User I/O para acceder a la página Active Sessions Waiting: User I/O. De nuevo,
haga clic en el nombre del evento de espera situado a la derecha del gráfico Active Sessions para
acceder a la página “Histogram for Wait Event” correspondiente. En la diapositiva se muestra el
gráfico “Histogram for Wait Event: ddb file sequential read”.
Nota: el histograma no se rellenará a menos que el parámetro de inicialización
TIMED_STATISTICS esté definido en TRUE, que es el valor por defecto. TIMED_STATISTICS
se define automáticamente cuando el parámetroSTATISTICS_LEVEL está definido en TYPICAL o
ALL.

Alertas Generadas por el Servidor
Enterprise Manager
Cola de
alertas L A
Instancia D E
de
D OS
Oracle La métrica supera
S A
E
el umbral.
E GR nlyฺ
N DE use o AWR
C IO AL
D A RIT
F
a n d A D
Alertas Generadas por y SI
sielt Servidor D
e r R
E cuándo una base de datos está en un estado no deseado y necesita
U nivpara notificar
Las alertas sirven I V
N Database envía alertas a través de Enterprise Manager, donde se
atención.le
c UOracle
Por defecto,
ra Opcionalmente, Enterprise Manager se puede configurar para enviar un correo electrónico
muestran.
O
al administrador acerca de las condiciones del problema. El servidor de Oracle Database también
guarda un historial de la métrica y de las alertas en el repositorio de carga de trabajo.
La cola de alertas es una cola persistente de varios consumidores y está disponible para los usuarios
que desean escribir manejadores de alertas personalizados.
Los umbrales de varias métricas clave como, por ejemplo, Tablespace Used (%), están definidos por
defecto. También puede definir los umbrales en las métricas pertinentes para el sistema. Si la base de
datos se desvía de las lecturas normales lo bastante como para superar estos umbrales, Oracle
Database 11g se lo notificará de forma proactiva mediante el envío de una alerta. Una notificación
anticipada de posibles problemas permite responder rápidamente y, con frecuencia, resolver
problemas antes incluso de que los usuarios los adviertan.
Algunas métricas clave que pueden proporcionar una notificación anticipada del problema son:
• Average File Read Time (centiseconds)
• Response Time (per transaction)
• SQL Response Time (%)
• Wait Time (%)

Modelo de Uso de Alertas
Activar alertas definiendo umbrales.

Configurar reglas de notificación (paginación o correo electrónico).
Recibir notificación.
Revisar los detalles y consejos de la alerta. A

E L
D
D OS
Corregir el problema.
E SA
E GR nlyฺ
Verificar que el problema seDha E resuelto.
e o
N s
C IO AL u
D A RIT
F
a n d A D
Modelo de Uso de Alertas y
sit RSI D
e r
nivbásicoNpara
El modelo de uso
U I VElas alertas generadas por el servidor es el siguiente:
• Si eslenecesario, U
cambie la configuración del umbral para las métricas de alertas del servidor.
a c
O• r Configure reglas de notificación
Puede hacerlo mediante Enterprise Manager o un procedimiento PL/SQL.
(por ejemplo, direcciones de correo electrónico o períodos de
interrupción) mediante Enterprise Manager.
• Cuando se genera una alerta, Enterprise Manager la muestra en las páginas de alerta. El agente
de Enterprise Manager envía una notificación a los administradores registrados.
• Cuando reciba una alerta, podrá seguir el consejo correspondiente para corregir el problema.
Nota: compruebe que el parámetro de inicialización STATISTICS_LEVEL esté definido en
TYPICAL o ALL.

Definición de Umbrales
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Definición de Umbrales y
sit RSI D
e r
U niv unN
Para definir o editar VE seleccione Metrics and Policy Settings en la región Related Links de
umbral,
I
inicial de laUbase de datos. Para cambiar los umbrales, introduzca los valores deseados para
la páginale
r a
Warning c Threshold y Critical Threshold. Seleccione la vista All Metrics, para agregar los umbrales.
O
Aparecerán las alertas adecuadas cuando la base de datos alcance los valores especificados. Haga clic
en el botón Edit para especificar una acción de respuesta adicional en objetos individuales de una
alerta de grupo, o para agregar umbrales a dichos objetos, como un umbral de porcentaje de uso en
un tablespace específico.
La programación de recopilación especifica la frecuencia de las recopilaciones. La programación de
recopilación puede cambiar, pero no para umbrales individuales. Las programaciones de recopilación
se definen para grupos de métricas. Haga clic en la programación Collection para editar la
programación o ver las métricas recopiladas con dicha programación.
El botón Edit es un icono de un lápiz o grupo de lápices. Haga clic en el botón Edit de un único lápiz
y podrá cambiar los atributos de incidencias y umbrales de dicha métrica. El botón Edit de varios
lápices permite agregar umbrales a objetos individuales en dicho grupo de métricas como umbrales
diferentes en varios tablespaces.

Creación y Prueba de una Alerta
1. Especifique un umbral.
2. Cree un caso de prueba.

3. Compruebe la existencia
de una alerta.
1 L A
D E
3 D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Creación y Prueba desuna y
it Alerta SI D
e r R
E para un objeto concreto.
U niv definir
También se pueden
N I V
umbrales
Ejemplo:
c l eel usuarioUdecide que necesita recibir una alerta crítica si el espacio utilizado en el
ra INVENTORY supera el 75%. (Este tablespace no permite que los archivos de datos se
tablespace
O
amplíen automáticamente.) Para crear y probar la alerta, realice los siguientes pasos:
1. En Enterprise Manager, navegue a la página Tablespace y defina el umbral deseado.
2. En SQL*Plus, utilice el comando CREATE TABLE … TABLESPACE … AS SELECT …
para duplicar una tabla existente en el tablespace que le interese. Continúe agregando filas a la
tabla para rellenar el tablespace.
3. Después de haber recibido un error informándole de que la tabla no se puede ampliar,
compruebe la página inicial de la instancia de base de datos para ver alertas relacionadas.
La mayoría de las alertas contienen el nombre de un asesor asociado al que se puede llamar para
obtener asesoramiento detallado. Enterprise Manager ofrece un enlace para llamar al asesor
correspondiente en cada mensaje de alerta.
Nota: la alerta Tablespace Full se evalúa en intervalos de 10 minutos.

Vistas de Métricas y Alertas
Métricas recientes Historial de métricas Alertas de servidor
DBA_HIST_SYSMETRIC_HISTORY
...
DBA_OUTSTANDING_ALERTS L A
V$SYSMETRIC_HISTORY D E
OS
DBA_ALERT_HISTORY
V$SYSMETRIC
DBA_THRESHOLDS D
V$SERVICEMETRIC
V$ALERT_TYPES E SA
V$METRICNAME
...
...
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI
Vistas de Métricas y Alertas D
e r E con cierta frecuencia los valores de las métricas, que se guardan
U nivMMON
Cuando se activan, I Vcalcula
en memoria
l e durante U unaNhora. Los valores en memoria correspondientes a las métricas de nivel de
c
ra se pueden visualizar en las vistas V$SYSMETRIC y V$SYSMETRIC_HISTORY. También
sistema
O
existen vistas similares para las métricas de nivel de servicio.
Para activar la recopilación en el disco de todas estas métricas, basta con activar el mecanismo de
instantáneas automáticas de AWR. Los valores en el disco para las métricas se pueden visualizar en
las vistas DBA_HIST_*. La política de depuración para el historial de métricas es la misma que para
el resto de datos de instantáneas.
Las siguientes vistas del diccionario le permiten acceder a la información acerca de las alertas del
servidor:
• DBA_OUTSTANDING_ALERTS describe alertas que el servidor Oracle Database considera
pendientes.
• DBA_ALERT_HISTORY representa un historial de alertas que ya no están pendientes limitado
en el tiempo.
• DBA_THRESHOLDS le indica la configuración de umbral definida para la instancia.
• V$ALERT_TYPES le proporciona información acerca de cada tipo de alerta de servidor.
Nota: para obtener más información acerca de estas vistas, consulte la guía Oracle Database
Reference (Referencia de Oracle Database).

Prueba
Ha aparecido una alerta en la base de datos de Enterprise

Manager hace unas dos horas y, a continuación, ha

desaparecido. No recuerda el texto. Puede buscar en
DBA_ALERT_HISTORY para ver la alerta borrada.
a. Verdadero
b. Falso
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Respuesta: a y
sit RSI D
e r E las alertas borradas. Estas alertas se depuran con regularidad. La
U niv NIV
DBA_ALERT_HISTORY mantiene
a c ledepuraciónUpara el historial de métricas es la misma que para el resto de datos de

política de
Or
instantáneas.

Resumen

• Visualizar métricas mediante vistas del historial de métricas

• Crear umbrales de métricas
• Visualizar alertas
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Trabajar con Métricas
• Visualización de métricas mediante vistas del historial de

métricas
• Creación de umbrales de métricas
• Visualización de alertas
• Eliminación de alertas
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Ora
c
n
r s
le U UN
ive IVE
a
F
ity RSID
nd AD
D
C
UN DIST
N
A RIT
IO AL
E
R
DE use o
ES
G nlyฺ
A DO
S D E LA
Uso de Líneas Base
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora
Objetivos

siguiente:
• Crear líneas base de AWR
• Activar umbrales adaptativos
• Crear líneas base de AWR para períodos de tiempo futuros
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Análisis de Rendimiento Comparativo con
Líneas Base de AWR
• Las líneas base de AWR contienen un juego
Rendimiento de instantáneas de AWR de un período de

tiempo “interesante o de referencia”
• Las líneas base son claves para que el
Real ajuste de rendimiento permita:
– Guiar los valores de los umbrales de alerta
– Supervisar el rendimiento
– Comparar informes del asesor
L A
D E
Normal Línea Base D OS
de AWR
E SA
E GR nlyฺ
Tiempo N
DE use o
C IO AL
D A RIT
F
a n d A D
Análisis de Rendimiento y D
SI con Líneas Base de AWR
sit Comparativo
e r E R
¿Cuál es el umbral
n ivadecuadoI V que se debe definir en una métrica de rendimiento? ¿Qué es lo que
l U
desea detectar? Si deseaN conocer que el valor de la métrica de rendimiento indica que el servidor se
e capacidad,Uun valor absoluto
r a
acerca c
a su es lo correcto. Pero si desea saber que el rendimiento es
O
diferente actualmente en comparación con el mismo momento de la semana o el mes anterior, el
rendimiento actual se debe comparar con una línea base.
Una línea base incluye juegos de métricas y estadísticas. A un único juego se le denomina
instantánea. Una línea base se compone de dos o más instantáneas. Normalmente, una línea base se
captura durante un período de funcionamiento normal o aceptable, pero se puede capturar cualquier
período de interés. Estas instantáneas se agrupan estadísticamente para generar un juego de valores
de línea base que varían con el tiempo. Por ejemplo, el número de transacciones por segundo de una
determinada base de datos varía según la hora del día. Los valores para las transacciones por segundo
son mayores durante el horario laboral y menores durante el horario no laboral. La línea base registra
esta variación y se puede definir para que le envíe una alerta si el número actual de transacciones por
segundo es significativamente diferente de los valores de la línea base. Cuando el rendimiento no es
el esperado, se puede capturar otro juego de métricas y compararlo con la línea base. Este método
permite que los datos apunten con claridad a los problemas de rendimiento.
Las líneas base de Oracle Database 11g proporcionan los datos necesarios para calcular los umbrales
que varían con el tiempo según los datos de la línea base. La línea base permite una comparación en
tiempo real de las métricas de rendimiento con los datos de la línea base y se puede utilizar para
generar informes de AWR que comparen dos períodos.

Líneas Base de Repositorio de Carga de Trabajo
Automática
Oracle Database 11g mejora las líneas base de repositorio de
carga de trabajo automática desde las que puede:

• Especificar umbrales adaptativos.
• Programar la creación de una línea base mediante plantillas
de línea base.
• Cambiar el nombre de las líneas base.
• Definir las fechas de caducidad para las líneas base.
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit de
Líneas Base de Repositorio D
I de Trabajo Automática
SCarga
e r R
Ede carga de trabajo automática (AWR) de Oracle Database 11g,
Las líneas basen ivrepositorio
del I V
e U
ofrecen poderosas
l UN para la definición de líneas base dinámicas y futuras, además de
capacidades
c
ra considerablemente el proceso de creación y gestión de los datos de rendimiento para fines
simplificar
O
comparativos.
Oracle Database 11g tiene, por defecto, una línea base de ventana móvil definida por el sistema que
se corresponde con todos los datos de AWR dentro del período de retención de AWR. Sólo puede
haber una línea base de ventana móvil.
Oracle Database 11g proporciona la capacidad de recopilar dos tipos de líneas base: líneas base
estáticas y de ventana móvil. Laslíneas base estáticas puede ser únicas o repetirse. Una línea base de
AWR única se recopila durante un único período de tiempo. Una línea base de repetición se recopila
durante un período de tiempo periódico (por ejemplo, cada lunes de junio).
En Oracle Database 11g, las líneas base están activadas por defecto si
STATISTICS_LEVEL=TYPICAL u ALL.

Línea Base de Ventana Móvil
Existe una línea base de ventana

móvil:
• SYSTEM_MOVING_WINDOW: una
línea base de ventana móvil que
se corresponde con los últimos
ocho días de datos de AWR
• Creada automáticamente en 11g
Por defecto, la funcionalidad de L A
D E
umbrales adaptativos calcula las
estadísticas en esta línea base. D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Línea Base de Ventana y
sitMóvilRSI D
e r E
Oracle Database iv IV
nmantiene automáticamente una línea base de ventana móvil definida por el sistema.
El tamaño U
lederetención
ventana N
Upor defecto para la línea base de ventana móvil definida por el sistema es el
r a
períodocde de AWR actual, que, por defecto, es de ocho días. Para las bases de datos de
O
producción, considere el uso de una ventana móvil más grande (como 30 días) para calcular de forma
precisa los valores de umbral. Puede cambiar el tamaño de la línea base de ventana móvil cambiando
el número de días en la ventana móvil por un valor que sea igual o inferior al número de días en el
período de retención de AWR. Por lo tanto, para aumentar el tamaño de una ventana móvil, primero
es necesario incrementar el período de retención de AWR en consecuencia. El período de retención
de AWR y el tamaño de la ventana de la línea base de ventana móvil definida por el sistema son dos
parámetros independientes. El período de retención de AWR debe ser superior o igual al tamaño de
ventana de la línea base de ventana móvil definida por el sistema.
Esta línea base definida por el sistema proporciona una línea base por defecto para las pantallas de
rendimiento de EM con el fin de comparar el rendimiento con el rendimiento actual de la base de
datos.
Nota: el período de retención por defecto para los datos de instantáneas se ha cambiado de siete días
a ocho días en Oracle Database 11g para garantizar la captura de una semana completa de datos de
rendimiento.

Líneas Base en Valores de Página de Rendimiento
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Líneas Base en Valores y
sitde Página D
SI de Rendimiento
e r R
E definida en el pasado están disponibles en Oracle Database 11g.
U niv N
Los datos de cualquier línea
I Vbase
a c lede la líneaUbase se pueden mostrar en la página Performance de Enterprise Manager.
Los datos
Or de tres opciones de visualización:
Dispone
• No mostrar información de líneas base.
• Mostrar la información de la línea base estática especificada.
• Mostrar la información de la línea base móvil del sistema.
Nota: la línea base de ventana móvil del sistema es válida después de que se hayan recopilado datos
suficientes y se produzca el cálculo de estadísticas. Por defecto, el cálculo de estadísticas está
programado para cada sábado a media noche.

Plantillas de Línea Base
• Las plantillas le permiten programar la creación de líneas

base para períodos de interés en el futuro:

– Período de tiempo único en el futuro
– Programación de repetición
• Ejemplos
– Un fin de semana de vacaciones conocido
– Cada lunes por la mañana de 10 AM a 2 PM
• Cuando el tiempo de finalización para una plantilla de línea LA
base pasa del futuro al pasado, MMON detecta el cambio y DE
crea la línea base. D OS
A
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Plantillas de Línea Base y
sit RSI D
e r Eperíodos de tiempo futuros le permite marcar períodos de tiempo que
La creación de n iv baseIV
líneas para
sabe quele U UN Por ejemplo, puede que desee que el sistema genere automáticamente
serán interesantes.
c
a base para cada lunes por la mañana de todo el año, o bien puede pedir al sistema que genere
unarlínea
O
una línea base para un fin de semana de vacaciones futuro si sospecha que se trata de un fin de
semana de gran volumen.
Anteriormente, podía crear líneas base sólo en instantáneas que ya existían. Con Oracle Database
11g, una tarea MMON nocturna revisa todas las plantillas de generación de líneas base y comprueba si
ha cambiado algún rango de tiempo del futuro al pasado en el último día. Para los períodos de tiempo
relevantes, la tarea MMON crea a continuación una línea base para el período de tiempo.

Líneas Base de AWR
Período relevante
en el pasado
L A
D E
D OS
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE (
start_snap_id IN NUMBER, E SA
end_snap_id IN NUMBER, E GR nlyฺ
baseline_name IN VARCHAR2);
N DE use o
C IO AL
D A RIT
F
a n d A D
Líneas Base de AWR sit y SI D
Una línea base esiv e r
un juego VdeE R
instantáneas de AWR. Normalmente, es un juego de datos de
instantáneas U n períodos
para N I importantes que etiqueta y retiene en AWR. Una línea base se define en
c l
una pareja ede U
instantáneas; las instantáneas se identifican por sus números de secuencia de
O r a
instantánea (snap_ids) u horas de inicio y de finalización. Cada juego de instantáneas tiene
instantáneas de inicio y finalización e incluye todas las instantáneas situadas en medio. Los juegos de
instantáneas se utilizan para retener datos de instantáneas. Por lo tanto, las instantáneas
pertenecientes a los juegos de instantáneas se retendrán por defecto hasta que se borren dichos
juegos. Un valor de caducidad se puede definir en un número de días que retendrá la instantánea.
Un nombre proporcionado por el usuario identifica la línea base. Ejecute el procedimiento
CREATE_BASELINE para crear una línea base desde un juego de instantáneas y especifique un
nombre y una pareja de identificadores de instantánea. Se asignará un identificador de línea base
único para toda la vida de una base de datos a la línea base recién creada. Normalmente, las líneas
base se configuran a partir de ciertos períodos representativos del pasado con objeto de comparar el
comportamiento del sistema en ese momento con el comportamiento actual. También se pueden
definir alertas basadas en umbrales mediante líneas base desde Database Control. Puede definir la
hora de caducidad en un número de días con el parámetro de caducidad de este procedimiento. El
valor por defecto es NULL, lo que significa "nunca caduca".
Puede obtener los valores de snap_id directamente desde DBA_HIST_SNAPSHOT o Database
Control.
Nota: para obtener más información sobre el paqueteDBMS_WORKLOAD_REPOSITORY, consulte la
guía Oracle Database PL/SQL Packages and Types Reference (Guía de Referencia de Tipos y
Paquetes PL/SQL de Oracle Database).
Creación de Líneas Base de AWR
Server > AWR Baselines
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Creación de Líneas Base y
sit de R AWRSI D
e r Ebase de AWR: única y de repetición. La página Create Baseline:
iv de líneas
Puede crear dosntipos I V
Baselinele U UNproporciona las siguientes explicaciones.
Interval Type
La
c
a base de tipo único tiene un intervalo de tiempo único y fijo: por ejemplo, desde el 1 de
rlínea
O
febrero de 2010, a las 10:00 AM, al 1 de febrero de 2010 a las 12:00 PM. La línea base del tipo de
repetición tiene un intervalo de tiempo que se repite durante un período de tiempo: por ejemplo, cada
lunes de 10:00 AM a 12:00 PM durante el año 2010.
Para ver la página AWR Baseline, haga clic en el enlace AWR Baselines del separador Server de la
página Database Instance (Server > AWR Baselines). En la página Baseline, haga clic en Create y
siga las instrucciones del asistente para crear la línea base.
Nota: antes de configurar los umbrales de métricas de línea base de AWR para una línea base
particular, debe calcular las estadísticas de la línea base. Seleccione Schedule Statistics Computation
en el menú de acciones para calcular las estadísticas de la línea base. Hay otras acciones disponibles.

Línea Base de AWR Única
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Línea Base de AWR Única y
sit RSI D
e r E en el paso anterior, accederá a la página que se muestra en esta
U nivla opción
Si ha seleccionado I V Single
e
diapositiva.
c l UN
O• raSeleccione
Seleccione el período de tiempo que le interese de una de estas dos formas:
la opción Snapshot Range y, a continuación, defina la hora de inicio y la hora de
finalización del período siguiendo las indicaciones de la página. Si el icono que desea
seleccionar no se muestra, puede cambiar el período de tiempo del gráfico.
• Especifique el intervalo de tiempo, con una fecha y hora de inicio y finalización. Con la opción
Time Range, puede elegir momentos en el futuro.
Cuando termine, haga clic en Finish para crear la línea base estática.
Nota: si la fecha de finalización de la línea base está en el futuro, se creará una plantilla de línea base
con el mismo nombre.

Creación de Plantillas de Línea Base
de Repetición
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Creación de Plantillassde y
it Línea SBaseD
I de Repetición
e r E R
U niv baseNde
Puede definir líneas I Vrepetición mediante Enterprise Manager. En el asistente, después de
le Repeating
seleccionar
c Uen el paso 1, puede especificar el intervalo de repetición como se muestra en la
O r a
diapositiva. Especifique la fecha de inicio y la duración de la línea base. A continuación, especifique
cuándo se recopilarán las estadísticas de línea base (diaria o semanalmente; si es semanalmente,
durante qué días). Especifique el rango de fechas para el que esta plantilla de línea base recopilará
estadísticas. La opción Retention Time define un valor de caducidad para la línea base, un valor
NULL indica que la línea base nunca caduca.

Gestión de Líneas Base con PL/SQL
Paquete DBMS_WORKLOAD_REPOSITORY
Nombre del Procedimiento Descripción
CREATE_BASELINE Crear líneas base de AWR únicas
DROP_BASELINE Borrar líneas base de AWR únicas
RENAME_BASELINE Cambiar el nombre de las líneas base

L A
CREATE_BASELINE_TEMPLATE Crear plantillas de línea base
D E
DROP_BASELINE_TEMPLATE Borrar plantillas de línea base D OS
E SA
MODIFY_BASELINE_WINDOW_SIZE Modificar el tamaño de
E
línea base de ventana
GRmóvil
ventanaฺ de la
nlypor defecto
E
D use o
IO ALN
A RITC
D
F
a n d A D
Gestión de Líneas Base y
sitcon R SI
PL/SQL D
e r
U niv NIVE
El paquete DBMS_WORKLOAD_REPOSITORY PL/SQL contiene procedimientos que le permitirán
gestionarle
c U de carga de trabajo. Por ejemplo, dispone de procedimientos para gestionar
el repositorio
O r a
instantáneas y líneas base en este paquete. Los procedimientos que se muestran son sólo algunos de
los procedimientos proporcionados. Las mayoría de los procedimientos los utiliza Enterprise
Manager para gestionar el repositorio de carga de trabajo automática y, en raras ocasiones, necesitará
utilizar el procedimiento directamente.
Nota: para obtener más información sobre estos y otros procedimientos para gestionar el AWR que
contiene el paquete DBMS_WORKLOAD_REPOSITORY, consulte la guía Oracle Database PL/SQL
Packages and Types Reference (Referencia de Tipos y Paquetes PL/SQL de Oracle Database).

Generación de una Plantilla de Línea Base para
un Período de Tiempo Único
Período de tiempo
de interés
….. T4 T5 T6 ….. Tx Ty Tz
BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE ( L A
start_time => to_date('21-JUN-2010','DD-MON-YYYY'), D E
end_time => to_date('21-SEP-2010','DD-MON-YYYY'), D OS
baseline_name => 'FALL10', E SA
template_name => 'FALL10', E GR nlyฺ
expiration => NULL );
N DE use o
END;
C IO AL
D A RIT
F
a n d A D
Generación de una Plantilla y
sit de D
I Base para un Período de Tiempo Único
SLínea
e r R
Ahora puede crear
U nivuna N VE de cómo se deben crear las líneas base para diferentes períodos de
plantilla
I
lefuturo,
tiempo del
c U programaciones predecibles. Si cualquier parte del período se encuentra en el
para
O r a
futuro, utilice el procedimiento CREATE_BASELINE_TEMPLATE.
En la plantilla de línea base, cuando el tiempo de finalización pasa al pasado, una tarea que utilice
estas entradas creará automáticamente una línea base para el período de tiempo especificado cuando
llegue el momento. El ejemplo crea una plantilla de línea base que genera una línea base cuando
0:0:0 21-Sep-2008 esté en el pasado.
El uso de definiciones basadas en tiempo durante la creación de la línea base no necesita los
identificadores de instantánea de inicio y de instantánea de finalización. Para el procedimiento
CREATE_BASELINE_TEMPLATE puede especificar una duración de caducidad para la línea base
que se cree a partir de la plantilla. La duración de la caducidad, especificada en días, representa el
número de días que desea que se mantengan las líneas base.
Un valor de NULL significa que las líneas base no caducan nunca.
Para crear una línea base en un período del pasado, utilice el procedimiento CREATE_BASELINE.

Creación de Plantillas de Línea Base
de Repetición
BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE (
day_of_week => 'SATURDAY',
hour_in_day => 6,
duration => 20,
start_time => to_date('21-JUN-2009','DD-MON-YYYY'),
end_time => to_date('21-JUN-2010','DD-MON-YYYY'),
baseline_name_prefix => 'SAT_MAINT_WIN'
template_name => 'SAT_MAINT_WIN', L A
expiration => 90, D E
dbid => NULL ); D OS
END; E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Creación de Plantillassde y
it Línea SBaseD
I de Repetición
e r R
U I VE
niv NCREATE_BASELINE_TEMPLATE
Utilice el procedimiento para generar plantillas de línea base
le
que automáticamente
c Ucreen líneas base para un período de tiempo contiguo basándose en una
Or a
programación de tiempo de repetición.
También puede especificar si desea que la línea base se elimine automáticamente después del
intervalo de caducidad especificado (expiration).
El ejemplo de la diapositiva genera una plantilla que crea una línea base para un período que se
corresponde con cada SATURDAY_MAINTENANCE_WINDOW durante un año. La línea base se crea
durante un período de 20 horas (duration) que comienza a las 6:00 AM (hour_in_day) de cada
sábado (day_of_week). La línea base se denomina ‘SAT_MAINT_WIN’ con la información de
tiempo agregada para hacer que el nombre sea único. La plantilla se denomina ‘SAT_MAINT_WIN’,
y cada línea base se conservará durante 90 días (expiration). La plantilla se crea para la base de
datos local ( dbid => NULL ).
Utilice esta línea base para comparar los recursos que se utilizan cada sábado durante la ventana de
mantenimiento.
El paquete DBMS_WORKLOAD_REPOSITORY tiene varios procedimientos para gestionar líneas
base. Consulte Oracle Database PL/SQL Packages and Types Reference (Referencia de Paquetes y
Tipos PL/SQL de Oracle Database) para obtener más información.

Vistas de Línea Base
Soporte de diccionarios de datos para líneas base:

• DBA_HIST_BASELINE
• DBA_HIST_BASELINE_DETAILS
• DBA_HIST_BASELINE_TEMPLATE
• DBA_HIST_BASELINE_METADATA
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Vistas de Línea Base sit y SI D
e r R
E que soportan las líneas base de AWR han cambiado.
n iv IdeVdatos
Las vistas del diccionario
• e U
DBA_HIST_BASELINE
l UN muestra la información sobre las líneas base realizadas en el sistema.
c
OraPara cada línea base, esta vista muestra el rango de tiempo completo y si la línea base es la que
se utiliza por defecto. La información adicional incluye la fecha de creación, la hora del último
cálculo de estadísticas y el tipo de línea base.
• DBA_HIST_BASELINE_DETAILS muestra información que le permite determinar la validez
de una línea base determinada, como si se ha producido un cierre durante el período de la línea
base y el porcentaje del período de línea base que está cubierto por datos de instantánea.
• DBA_HIST_BASELINE_TEMPLATE contiene las plantillas de línea base. La vista proporciona
la información que necesita MMON para determinar cuándo se creará una línea base a partir de
una plantilla y cuándo se deberá eliminar esta línea base.
• DBA_HIST_BASELINE_METADATA muestra la información de los metadatos de las líneas
base, incluyendo nombre, tipo, hora de creación, plantilla y caducidad.
Para obtener más información, consulte Oracle Database Reference 11g (Referencia de Oracle
Database 11g).

Control de Rendimiento y Líneas Base
• Los umbrales de alerta de rendimiento son difíciles de

determinar porque los valores de métricas esperados varían

por:
– Tipo de carga
– Carga del sistema
• Las estadísticas de valores de métrica de línea base son:
– Calculadas automáticamente sobre la ventana móvil del
sistema A
E L
– Calculadas manualmente sobre líneas base estáticas D
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Control de Rendimiento y
sit y Líneas D
SIBase
e r R
U I VE
niv Nadecuadamente,
Cuando están definidos los umbrales de alerta ofrecen un servicio valioso (una
indicar unaU
alerta) alle métrica de rendimiento que tiene un valor inesperado. Desafortunadamente, en
r a
muchos c casos el valor esperado varía con el tipo de carga de trabajo, carga del sistema, hora del día o
O
día de la semana. Las líneas base asociadas con determinados tipos de carga de trabajo o días de la
semana capturan los valores de métricas de ese período. Las líneas base se pueden utilizar entonces
para definir los valores de umbral cuando existan condiciones similares.
Las estadísticas para las líneas base se calculan de forma que exista una carga mínima en el sistema,
las estadísticas para las líneas base estáticas se calculan manualmente. Puede planificar el cálculo de
estadísticas en la página AWR Baselines. Las estadísticas de la ventana móvil del sistema se calculan
automáticamente según la programación BSLN_MAINTAIN_STATS_SCHED. Por defecto, esta
programación inicia el trabajo cada semana a mediodía del sábado.

Control de Rendimiento y Líneas Base
Las estadísticas de métrica de línea base determinan los

umbrales de alerta.
• Valores poco usuales frente a datos de línea base =
umbrales de nivel de importancia.
• Valor máximo cercano o que supera los datos de línea base =
porcentaje de umbrales máximos.
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Control de Rendimiento y
sit y Líneas D
SIBase (continuación)
e r E R
ivmétricaIVcalculadas
Las estadísticasnde sobre una línea base le permiten definir umbrales que
comparan U N
U de línea base con la actividad actual. Hay tres métodos de comparación:
lelas estadísticas
r
nivela c
de importancia, porcentaje de máximo y valores fijos.
O
Los umbrales basados en el nivel de importancia utilizan la relevancia estadística para determinar
qué valores actuales son poco comunes. Es decir, si el nivel de importancia se define en 0,99 para un
umbral crítico, el umbral se define donde el 1% de los valores de línea base están fuera de este valor
y cualquier valor actual que supere este valor dispara una alerta. Un nivel de importancia más alto, de
0,999 o 0,9999, provoca que se disparen menos alertas.
Los umbrales basados en el porcentaje de máximo se calculan según el valor máximo capturado por
la línea base.
Los valores de umbral basados en valores fijos los define el DBA. No se necesita ninguna línea base.

Definición de Umbrales de Alerta mediante una
Línea Base Estática
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Definición de Umbrales y
sitde Alerta D
SImediante una Línea Base Estática
e r R
U niv las N
Una vez calculadas VE de línea base de AWR para una línea base en particular, puede
estadísticas
I
definir umbrales
c U específicos de la línea base.
le de métricas
a
r las estadísticas de línea base directamente desde la página Baselines (como se ha explicado
Calcule
O
anteriormente). A continuación, vaya a la página AWR Baseline Metric Thresholds y seleccione el
tipo de métrica que desea definir. Cuando termine, seleccione una métrica específica y haga clic en
Edit Thresholds.
En la página Edit AWR Baseline Metric Thresholds correspondiente, especifique sus umbrales en la
sección Thresholds Settings y, a continuación, haga clic en Apply Thresholds.
Puede especificar umbrales según las estadísticas calculadas para la línea base. Esto se muestra en la
diapositiva. Además de “Significance Level”, las otras posibilidades son “Percentage of Maximum”
y “Fixed Values”.
Nota: después de que se defina un umbral mediante los umbrales de métrica de línea base, los
valores de umbral anteriores se descartan para siempre y las estadísticas de la línea base asociada se
utilizan para determinar los valores de umbral hasta que se borren (con la interfaz PL/SQL o de
umbrales de métricas de línea base).

Uso de EM para Configurar Rápidamente
Umbrales Adaptativos
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Uso de EM para Configurar y SI
sit Rápidamente D Umbrales Adaptativos
v e r E R
Oracle Database i Enterprise
n11g, I V Manager permite seleccionar umbrales adaptativos para métricas de
U N
U de datos, con una completa integración con las líneas base de AWR como el
lelasdeestadísticas
rendimiento la base
r a
origen cde de métrica. EM ofrece una opción de configuración rápida en un juego
O
inicial de un clic de umbrales basados en OLTP o en perfiles de carga de trabajo de almacén de
datos.
Realice la selección de los perfiles de carga de trabajo apropiados en la ventana emergente
correspondiente. Al realizar esta sencilla selección, el sistema automáticamente configura y
evoluciona los umbrales adaptativos basándose en la línea base SYSTEM_MOVING_WINDOW para el
grupo de métricas que mejor se correspondan con la carga de trabajo elegida.

Uso de EM para Configurar Rápidamente
Umbrales Adaptativos
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Uso de EM para Configurar y SI
sit Rápidamente D Umbrales Adaptativos (continuación)
v e r E R
U ni Threshold
En la página OLTP
N I V Settings, configure las líneas base de carga de trabajo deseadas.
Cuando lestén
c U puede editar los niveles de umbral mediante el botón Edit Threshold.
e configuradas,
Las
O a
rcolumnas Warning Level y Critical Level indican el tipo de alerta generado. Significance Level
indica si el nivel de observación es igual o superior a un valor determinado. Los umbrales de nivel de
importancia que se soportan son los siguientes:
• High: importante a un nivel de 0,95 (5 de 100).
• Very High: importante a un nivel de 0,99 (1 de 100).
• Severe: importante a un nivel de 0,999 (1 de 1.000).
• Extreme: importante a un nivel de 0,9999 (1 de 10.000).
Consejo: al editar los niveles de umbral, defina los umbrales de nivel de importancia de forma
conservadora y experimental al principio y, a continuación, observe el número y la importancia de
las alertas. Los niveles de importancia más altos reducen el número de alertas.
Los valores de umbral se determinan al examinar las estadísticas de los valores de métricas
observados en el período de tiempo de la línea base. El sistema define los umbrales según los datos
anteriores del propio sistema y algunos metadatos proporcionados por el usuario. Esto es
significativamente más sencillo en el caso de varios destinos, porque ya no necesita conocer la
métrica específica del sistema. Las estadísticas que se deben supervisar son el valor máximo, así
como los niveles de importancia. Los niveles de importancia le permiten definir el umbral en un
valor que sea estadísticamente importante en el nivel definido (por ejemplo, 1 de 1.000).

Cambio de Valores de Umbrales Adaptativos
El umbral se
adapta
automáticamente.
L A
E
SValorD
Oobservado
S AD
Cálculo de
G RE yฺ
de línea base
E E onl
N D use
C IO AL
D A RIT
F
a n d A D
y I
it RSAdaptativos
Cambio de Valores desUmbrales D
e r E adaptativos, puede cambiar los valores (si es necesario) como se
nivlos umbrales
Una vez definidos
U I V
muestra len
c UN
e la diapositiva.
En
O rlaapágina Edit AWR Baseline Metric Thresholds correspondiente a la métrica que desea
modificar, verá el historial gráfico del valor observado para la métrica, la materialización del valor de
línea base calculado y el umbral adaptativo correspondiente.

Prueba
Desea crear una línea base que siempre cubra los últimos tres
meses porque hay un valor máximo en el procesamiento cada

viernes. Desea definir un umbral para que le avise si la carga
supera el 110% del máximo de los 90 días anteriores. ¿Qué
tarea de las que se muestran a continuación utilizará para
realizar estas acciones?
a. Crear una línea base estática en los últimos 90 días.
b. Cambiar el tamaño de ventana de la línea base del
sistema a 90 días. E LA
S D
c. Programar un trabajo para calcular las estadísticasD Ola
en
ventana móvil del sistema cada 90 días. E SA
d. Crear una línea base de repetición que E GRuna
cree n l ฺ
ynueva
E o
línea base cada 90 días. N D use IO AL
A RITC
D
F
a n d A D
Respuesta: b y
sit RSI D
e r Esólo el período de 90 días especificado y no cambia. La línea base
Una línea base n iv cubrirá
estática I V
estática no
l U
ese mueve.UN
El
c
ra de las estadísticas en la línea base del sistema lo programa el sistema cada sábado y no se
cálculo
O
puede cambiar.
Una línea base de repetición crea un juego de líneas base estáticas en períodos fijos.
Sólo la línea base móvil del sistema se ajustará como progresos de tiempo. Al definir la ventana en
90 días, verá los valores máximos finales de los 3 últimos meses y se podrán definir umbrales según
la carga de los 3 meses anteriores.

Resumen

• Crear líneas base de métricas

• Activar umbrales adaptativos
• Crear líneas base de AWR para períodos de tiempo futuros
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Práctica 6: Visión General
Uso de Líneas Base de AWR
En esta práctica se aborda la creación de líneas base de AWR:
• Creación de una línea base en un intervalo de tiempo

pasado
• Aplicación de la línea base en los gráficos de la página de
rendimiento
• Creación de una línea base de períodos de repetición en
períodos futuros
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora
Objetivos

siguiente:
• Describir tareas de mantenimiento de ajuste automáticas
• Generar informes ADDM
• Generar informes del historial de sesiones activas (ASH)
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Tareas de Mantenimiento Automáticas
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Tareas de Mantenimiento y SI
sit Automáticas D
e r R
Ede mantenimiento automáticas a Oracle Database 11g: recopilación de
• Se incorporan
n ivtres tareas
I V
l U UN de ventanas
estadísticas del optimizador,
e en un juego asesor de segmentos y ajustes SQL automáticos. Estas tareas se
c
Ora
ejecutan de trabajo predefinidas. Las tareas se asignan a grupos de
consumidores de recursos. El plan de recursos activo durante la ventana controla los recursos
que estas tareas pueden consumir, como CPU.
• Estas tareas automáticas ayudan al DBA a supervisar el uso del espacio, recopilar estadísticas
del optimizador y ajustar sentencias SQL de carga alta.
• El DBA debe supervisar estas tareas. Los resultados pueden aparecer en forma de
recomendaciones a las que se hace referencia desde el Monitor de Diagnóstico de Base de Datos
Automático (ADDM) o desde la página Advisor Central. La ejecución de estas tareas es
prioritaria. Si las tareas no disponen de tiempo o recursos suficientes para finalizar, se vuelven a
programar para la siguiente ventana. Si las tareas rellenan las ventanas disponibles, es posible
que se deba cambiar la asignación de recursos y duración.

Ventanas de Mantenimiento
Grupo de Ventanas de Mantenimiento

10 PM – 2 AM de lunes a viernes 6 AM – 2 AM de sábado a domingo
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI
Ventanas de Mantenimiento D
e r Ela función de tareas de mantenimiento automáticas se basa en la
n iv I11g,
• Con Oracle Database V
l U
e asociadoUN adelarecursos
activación del gestor durante las ventanas de mantenimiento. De este modo, el plan
c
Ora
de recursos ventana se activa automáticamente cuando ésta se abra. El objetivo es
evitar que el trabajo de mantenimiento consuma cantidades excesivas de recursos del sistema.
Cada ventana de mantenimiento está asociada a un plan de recursos que especifica cómo se
asignarán los recursos en la duración de la ventana.
• En Oracle Database 11g, WEEKNIGHT_WINDOW y WEEKEND_WINDOW (definidos en Oracle
Database 10g) se sustituyen por ventanas de mantenimiento diarias. Las tareas automáticas se
asignan a ventanas específicas. Todas las ventanas diarias pertenecen a
MAINTENANCE_WINDOW_GROUP por defecto.
• Todavía puede definir otras ventanas de mantenimiento, así como cambiar las horas de inicio y
las duraciones de las ventanas de mantenimiento diarias. Asimismo, cualquier ventana de
mantenimiento que se considere innecesaria se puede desactivar o eliminar. Las operaciones se
pueden realizar mediante el uso de las interfaces de EM o programador.

Plan de Mantenimiento por Defecto
SQL> SELECT name FROM V$RSRC_PLAN
2 WHERE is_top_plan = 'TRUE';
NAME
--------------------------------
DEFAULT_MAINTENANCE_PLAN
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Plan de Mantenimiento y SI
sitpor Defecto D
e r R
Emantenimiento, se define de forma automática
iv ventana
Cuando se abrenuna I V de
e U UN
DEFAULT_MAINTENANCE_PLAN
l en el gestor de recursos para controlar la cantidad de recursos de
CPU c
raque utilizan las tareas de mantenimiento automáticas. Para poder otorgar distintas prioridades a
O
cada posible tarea durante una ventana de mantenimiento, se asignan varios grupos de consumidores
a DEFAULT_MAINTENANCE_PLAN. La jerarquía entre grupos y planes se muestra en la
diapositiva.
Las tareas urgentes se asignan a ORA$AUTOTASK_URGENT_GROUP. Todas las tareas urgentes
tienen prioridad sobre las tareas de prioridad alta.
Las tareas de prioridad media se asignan a ORA$AUTOTASK_MEDIUM_GROUP.
Para tareas de prioridad alta:
• La tarea automática de recopilación de estadísticas del optimizador se asigna al grupo de
consumidores ORA$AUTOTASK_STATS_GROUP.
• La tarea automática de asesor de segmentos se asigna al grupo de consumidores
ORA$AUTOTASK_SPACE_GROUP.
• La tarea de ajustes SQL automáticos se asigna al grupo de consumidores
ORA$AUTOTASK_SQL_GROUP.
Nota: si es necesario, puede cambiar de forma manual el porcentaje de recursos de CPU que se
asigna a los distintos grupos de consumidores de tareas de mantenimiento automáticas dentro de
ORA$AUTOTASK_HIGH_SUB_PLAN.

Prioridades de Tareas de Mantenimiento
Automáticas
Ventana de Ejecutar Ejecutar Ejecutar Ejecutar Ejecutar

mantenimiento Trabajo1 Trabajo2 Trabajo3 Trabajo3 Trabajo4
… con con con con con
…
prioridad prioridad prioridad prioridad prioridad
urgente. urgente. alta. media. media.
DBA_AUTOTASK_TASK
urgente
Estadísticas alta MMON

L A
media
D E
ABPS
D O
SA
Espacio
E
R yฺ …
E G nl
Trabajo1 Trabajon
SQL
D E o
O N u se
A CI ITAL
U ND IST R
d F
n
a IDA D
Prioridades de Tareassde i t yMantenimiento
S Automáticas
v e r de mantenimiento
E R
• La función de
n i tareas
I V automáticas se implementa mediante el proceso de tareas
l U UNy el programador.
automáticas en segundo
eautomáticas plano (ABP). Las funciones ABP actúan como intermediario entre las
c
Ora
tareas Su principal objetivo es la conversión de tareas
automáticas en trabajos AUTOTASK para que los ejecute el programador. De igual importancia
es el hecho de que ABP mantenga un historial de ejecución de todas las tareas. ABP almacena el
repositorio privado en el tablespace SYSAUX; puede ver el repositorio a través de
DBA_AUTOTASK_TASK.
• MMON inicia ABP al inicio de la ventana de mantenimiento. Sólo se necesita un ABP para todas
las instancias. El proceso MMON supervisa ABP y lo reinicia, si fuera necesario.
• ABP determina la lista de trabajos que se necesita crear para cada tarea de mantenimiento. Esta
lista está ordenada en función de la prioridad: urgente, alta y media. Dentro de cada grupo de
prioridades, los trabajos se disponen en el orden de ejecución preferido. ABP crea trabajos de la
siguiente forma: primero se crean todos los trabajos de prioridad urgente, a continuación los
trabajos de prioridad alta y, finalmente, todos los trabajos de prioridad media.
• ABP asigna trabajos a varias clases de trabajo del programador. Estas clases de trabajo asignan
el trabajo a un grupo de consumidores en función de la prioridad.
Nota: con Oracle Database 11g, no hay ningún trabajo que se asocie de forma permanente a una
tarea automática específica. Por lo tanto, no es posible utilizar los procedimientos
DBMS_SCHEDULER para controlar el comportamiento de tareas automáticas; utilice los
procedimientos DBMS_AUTO_TASK_ADMIN en su lugar.
Tareas de Mantenimiento de Ajuste Automáticas
Server > Automatic Maintenance Tasks > Configure
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Tareas de Mantenimiento y
sit de R Ajuste D
SI Automáticas
e r
U I VE
niv deNmantenimiento
La función de tareas automáticas determina cuándo y en qué orden se realizan las
U controlar lo siguiente:
le DBA, puede
tareas. Como
Sicla ventana de mantenimiento pasa a ser inadecuada para la carga de trabajo de mantenimiento,
• ra
O ajuste la duración y la hora de inicio de la ventana de mantenimiento.
• Controle el plan de recursos que asigna recursos a las tareas de mantenimiento automáticas
durante cada ventana.
• Active o desactive tareas individuales en algunas o en todas las ventanas de mantenimiento.
• En un entorno RAC, cambie el trabajo de mantenimiento a una o más instancias mediante la
asignación de trabajo de mantenimiento a un servicio. La activación del servicio en un subjuego
de instancias cambia el trabajo de mantenimiento a estas instancias.
Tal y como se muestra en la diapositiva, Enterprise Manager es la forma favorita de controlar las
tareas de mantenimiento automáticas. Sin embargo, también puede utilizar el paquete
DBMS_AUTO_TASK_ADMIN.

Control del Rendimiento de ADDM
60 minutos
MMON
Estadísticas
en memoria
Instantáneas
SGA
ADDM L A
D E
D OS
E
AWRSA
E GR nlyฺ
Resultados de ADDM
N DE use o
C IO AL
D A RIT
F
a n d A D
Control del Rendimiento y
sit de ADDM SI D
e r
• Por defecto, ielvservidor de R
EOracle Database captura automáticamente información estadística de
U n I V
c l UN y la almacena
SGA cada 60 minutos
e de instantáneas. en el repositorio de carga de trabajo automática (AWR) con
Ora
el formato Estas instantáneas se almacenan en disco y son similares a las
instantáneas de Statspack. Sin embargo, contienen información más precisa que las instantáneas
de Statspack.
• Asimismo, ADDM está planificado para que lo ejecute el proceso MMON automáticamente en
todas las instancias de base de datos con objeto de detectar problemas de forma proactiva. Cada
vez que se toma una instantánea, se dispara ADDM para realizar un análisis del período
correspondiente a las dos últimas instantáneas. Este acercamiento supervisa de forma proactiva
la instancia y detecta cuellos de botella antes de que pasen a convertirse en un problema de
relevancia.
• El repositorio de carga de trabajo automática almacena los resultados de cada análisis de
ADDM. También se puede acceder a estos resultados desde Database Control.
Nota: si bien ADDM analiza el rendimiento de Oracle Database durante un período de tiempo
definido por las dos últimas instantáneas, es posible ejecutar manualmente un análisis de ADDM
entre dos instantáneas cualquiera.

ADDM y Tiempo de Base de Datos
El usuario envía El usuario obtiene
una solicitud. una respuesta.
Red de área extensa
Servidor de aplicaciones
Red de área local
Oracle Database
Tiempo de base de datos Hora
Conectar Ejecutar Recuperar Recuperar Recuperar Ejecutar

E LA
UsuarioD1
S
O 2
A DUsuario
R ES
E G nlyฺ
N DE use o Usuario n
C IO AL
D A RIT
F
a n d A D
ADDM y Tiempo de Base y
it de Datos
sdatos D
SI como la suma del tiempo empleado dentro de la base de datos
e r E R
iv solicitudes
• Tiempo de base
nlas
de
I V se define
l e U
en procesar
U Nun único del usuario. En el gráfico superior de la diapositiva se ilustra un
r a cusuario es el intervalo de tiempo
supuesto
del
sencillo de usuario mediante el envío de una solicitud. El tiempo de respuesta
entre el instante en que se envía la solicitud y el instante en
O que se recibe la respuesta. El tiempo de base de datos implicado en esa solicitud del usuario sólo
es una parte de ese tiempo de respuesta del usuario que se emplea dentro de la base de datos.
• En el gráfico inferior de la diapositiva se muestra el tiempo de base de datos conforme se suma a
lo largo de varios usuarios y cada usuario realiza una serie de operaciones que dan como
resultado una serie de solicitudes a la base de datos. Puede ver que el tiempo de base de datos es
directamente proporcional al número y a la duración de las solicitudes del usuario y puede ser
superior o inferior a la hora correspondiente (tiempo transcurrido).
• Al utilizar el tiempo de base de datos como medida, puede medir el impacto en el rendimiento
de cualquier entidad de la base de datos. Por ejemplo, el impacto en el rendimiento de una caché
de buffers de tamaño bajo se mediría como el tiempo total de la base de datos empleado en
realizar solicitudes de E/S adicionales que se podrían haber evitado si la caché de buffers fuera
más grande.
• El tiempo de base de datos es simplemente una medida de la cantidad total de trabajo que ha
realizado el servidor de la base de datos. El ratio al que se consume el tiempo de base de datos es
la media de carga de la base de datos, medida como el tiempo de base de datos por segundo. El
objetivo de ADDM consiste en reducir la cantidad de tiempo de base de datos que se emplea en
una carga de trabajo determinada, lo que supone consumir menos energía para realizar la misma
tarea.

Gráfico de Tiempo de Base de Datos y
Metodología de ADDM
Nodo raíz
Síntomas
Conexión Optimización Ejecución Capacidad Capacidad Bloqueos

de usuario SQL de SQL de CPU de base
de E/S
de datos
Causas raíz
L A
D E
O S
Caché de AnchoD
A de banda
buffers demasiado E S de E/S
pequeña G R yinsuficiente
ฺ
E E onl
Dimensión 1 Dimensión
N D 2 use
C IO AL
D A RIT
F
a n d A D
Gráfico de Tiempo desBase y
it deRS DatosD
I y Metodología de ADDM
e r
v componente
La identificaciónidel E que más contribuye al tiempo de base de datos equivale a encontrar el
U n
único componente de laN I V
tiempoc l U base
ebase de datos de datos que proporciona el mayor beneficio si se ajusta. ADDM utiliza el
ra para cuantificar los cuellos delos
de
yOtambién
para identificar componentes de la base de datos que se necesita investigar
botella de rendimiento. El primer paso del ajuste de
rendimiento automático consiste en identificar correctamente las causas de los problemas de
rendimiento. Sólo será posible explorar las recomendaciones de ajuste efectivas para resolver o aliviar
el problema cuando se haya identificado correctamente la causa raíz del problema de rendimiento.
ADDM analiza el tiempo de base de datos empleado en dos dimensiones independientes:
• La primera dimensión analiza el tiempo de base de datos que se ha empleado en varias de las fases
de procesamiento de solicitudes del usuario. En esta dimensión se incluyen categorías como
"conexión a la base de datos", "optimización de sentencias SQL" y "ejecución de sentencias SQL".
• La segunda dimensión analiza el tiempo de base de datos que se ha empleado utilizando o
esperando varios recursos de base de datos utilizados en el procesamiento de las solicitudes del
usuario. Entre los recursos de base de datos que se consideran en esta dimensión, se incluyen
ambos recursos de hardware como, por ejemplo, los dispositivos de CPU y de E/S y los recursos de
software como, por ejemplo, los bloqueos de base de datos y los bloqueos de aplicación.
Para realizar un diagnóstico automático, ADDM examina el tiempo de base de datos que se ha
empleado en cada categoría bajo estas dos dimensiones y accede a las categorías que han consumido un
tiempo de base de datos significativo. Este proceso de aumento de detalle de dos dimensiones se puede
representar mediante el gráfico de tiempo de base de datos.

Gráfico de Tiempo de Base de Datos y Metodología de ADDM (continuación)
Los problemas de rendimiento a menudo distribuyen el tiempo de base de datos en muchas de las
categorías de una dimensión pero no en la otra. Por ejemplo, una base de datos sin una capacidad de
CPU suficiente ralentiza todas las fases implicadas en el procesamiento de las solicitudes del usuario,
que está en la primera dimensión del análisis de ADDM. Sin embargo, desde la segunda dimensión
resultaría evidente que el principal problema de rendimiento que afecta a la base de datos es la falta
de capacidad de CPU. Esta vista de dos dimensiones para determinar dónde se consume el tiempo de
base de datos le proporciona a ADDM un buen juicio para profundizar en los problemas de
rendimiento más significativos.
ADDM explora este gráfico de tiempo de base de datos en el nodo raíz y todos los secundarios de
cualquier nodo en el que el tiempo de base de datos consumido sea significativo. Los nodos de
bifurcación de este gráfico identifican el impacto en el rendimiento de lo que normalmente es un
síntoma de algún cuello de botella de rendimiento. Los nodos terminales identifican las causas raíz
concretas que pueden explicar todos los síntomas significativos a lo largo de la ruta de acceso en la
que se alcanzó el nodo terminal. Por ejemplo, en la diapositiva, el nodo de bifurcación I/O Capacity
mide el tiempo de base de datos que se emplea en todas las solicitudes de E/S, que resulta L A
significativo debido a varios cuellos de botella. Cuando se emplea un tiempo de base de datosD E
S
A DO
significativo en las solicitudes de E/S, se exploran todos los secundarios del nodo I/O Capacity. Se
corresponden con los dos nodos terminales de la diapositiva. El nodo Undersized Buffer Cache
R ES
apunta hacia una causa raíz concreta: si el tamaño de la caché de buffers de bloque de datos es bajo,
E G nlyฺ
se producirá un número excesivo de solicitudes de E/S. El nodo Insufficient I/O Bandwidth busca los
DE use o
problemas de hardware que pueden ralentizar todas las solicitudes de E/S. Una vez que el nodo
N
IO AL
terminal identifica la causa raíz, ADDM mide el impacto de la causa raíz en el tiempo de base de
C
A RIT
datos. A continuación, explora las maneras en que se puede resolver o aliviar el problema
D
UN DIST
identificado. ADDM utiliza varias de las medidas de métricas y estadísticas que ha recopilado AWR
F
nd AD
para plantear recomendaciones de ajuste. El sistema mantiene las medidas en varias granularidades,
a
r s ity RSID
por lo que un análisis de ADDM puede abarcar desde los síntomas (por ejemplo, las operaciones de
confirmación que han consumido un tiempo de base de datos significativo) hasta la causa raíz (por
n ive IVE
ejemplo, la escritura de E/S en uno de los archivos log fue muy lenta, posiblemente debido a un
le U UN
problema de hardware). El nodo también permite que ADDM estime el tiempo máximo de base de
c
Ora
datos posible que pueden ahorrar las recomendaciones de ajuste sugeridas, que no tiene por qué ser
igual al tiempo de base de datos atribuido a la causa raíz.
Además de identificar cuellos de botella, ADDM también identifica los componentes clave que no
estén experimentando ningún cuello de botella de rendimiento. La idea consiste en evitar que ajuste
componentes que tengan un efecto mínimo en el rendimiento total de la base de datos.
Es interesante observar que ADDM no necesita recorrer todo el gráfico de tiempo de base de datos.
Puede eliminar los subgráficos que no sean de interés. Esto se puede conseguir sólo porque el gráfico
de tiempo de base de datos se ha construido de manera que el tiempo de base de datos de un nodo
está incluido en el tiempo de base de datos atribuido a sus principales. Al eliminar y no recorrer los
subgráficos que no sean de interés, que representan los componentes de la base de datos que no están
consumiendo un tiempo de base de datos significativo, el costo de un análisis de ADDM depende
únicamente del número real de problemas de rendimiento que estuvieran afectando a la base de
datos. El costo del análisis no depende de la carga real de la base de datos o del número de problemas
que ADDM puede diagnosticar.
Al final del análisis, ADDM informa de las causas raíz principales identificadas, clasificadas según el
impacto en el rendimiento que se ha atribuido a cada causa raíz junto con las respectivas
recomendaciones de ajuste.
Principales Problemas de Rendimiento
Detectados
Conexiones o desconexiones en exceso
Reducción del tamaño de la memoria

Bloques activos y objetos con SQL
No detectado Problemas de servicio de RAC
por Statspack
Bloqueos y contención de ITL
Establecimiento de puntos de
control de causas
Tiempo de PL/SQL y Java
Streams, AQ y RMAN
L A
SQL principal
D E
Problemas de E/S O S
D
Análisis
E SA
ADDM
identifica
Problemas de configuración
E GR l yฺ
los problemas
n
Uso de la aplicaciónDE e o
principales.
N s
C IO AL u
D A RIT
F
a n d A D
Principales Problemas y SI
t Rendimiento
side D Detectados
v e r E R
i
En las versionesnanteriores I Vde Oracle Database, Statspack no podía identificar algunos de los
problemas U
lemostrados N
Uen la diapositiva debido a la ausencia de granularidad en las estadísticas. Con la
r a c
introducción del modelo de estadísticas de espera y tiempo de Oracle Database 11g, ADDM consigue
O
identificar los problemas de rendimiento principales que puede visualizar en la lista. Otra de las
ventajas de ADDM con respecto a Statspack, es que ADDM concentra su análisis en los problemas
principales (es decir, los que mayor impacto tienen en el sistema).
Además, ADDM puede realizar análisis en áreas relacionadas con la CPU, la paginación y la caché
integrada. Ahora se ha ampliado el ámbito de ADDM para agregar más componentes de servidor
como, por ejemplo, Streams, AQ y RMAN.
Nota: la lista de problemas de rendimiento de la diapositiva no incluye todos los problemas que
ADDM puede detectar automáticamente. De hecho, sólo representa un subjuego de los problemas
potenciales que puede detectar ADDM.

Database Control y Búsquedas de ADDM
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSdeI ADDM
Database Control y Búsquedas D
e r
v deIVlaEbase de datos se puede visualizar la sección Diagnostic Summary, que
• En la páginaiinicial
U n
le UNconclusiones de ADDM en la última ejecución automática.
indica el número de
Alchacer clic en el enlace Performance Findings, se abrirá la página Automatic Database
• ra
O Diagnostic Monitor (ADDM), donde podrá visualizar información detallada acerca del último
análisis de ADDM ejecutado.

Resultados de los Análisis de ADDM
2
L A
D E
D OS
3 E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Resultados de los Análisis y
sit deRADDM SI D
e r EDiagnostic Monitor (ADDM) le permite ver las conclusiones
U niv Database
La página Automatic I V
N de ADDM ejecutado. Database Time representa la suma del tiempo con
detalladas
c l edel últimoUanálisis
ra empleado en las sesiones de la base de datos para el período de análisis. Se proporciona un
actividad
O
porcentaje de impacto concreto para cada conclusión. El impacto representa el tiempo consumido por
el problema correspondiente comparado con el tiempo de la base de datos durante el período de
análisis.
La siguiente información está relacionada con los números de la diapositiva:
1. El gráfico muestra el promedio de usuarios activos. Además, el problema más importante fue un
problema de espera.
2. El icono muestra que la salida de ADDM que aparece en la parte inferior de la página
corresponde a este momento. Puede visualizar el historial (para ver un análisis previo) haciendo
clic en los otros iconos.
3. Los resultados proporcionan un breve resumen de lo que descubrió ADDM en las áreas de
rendimiento de la instancia y lo que se pudo ajustar. Al hacer clic en un problema concreto,
pasará a la página Performance Finding Details.
Si hace clic en el botón View Report, podrá acceder a información detallada del análisis de
rendimiento en forma de informe de texto.

Recomendaciones de ADDM
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Recomendaciones desADDM y
it RSI D
e r
niv NFinding
La página Performance
U I VE Details ofrece recomendaciones para solucionar los problemas
c U
le deLasajuste
encontrados. recomendaciones se agrupan en categorías, entre la que se incluyen las categorías
O r a
de esquema, SQL y de configuración de la base de datos. La columna Benefit (%) muestra
la reducción máxima de tiempo transcurrido en la base de datos al implementar la recomendación.
ADDM considera la posibilidad de aplicar varios cambios al sistema y entre sus recomendaciones se
incluyen:
• Cambios de hardware: agregar CPU o cambiar la configuración del subsistema de E/S.
• Configuración de la base de datos: cambiar valores de parámetros de inicialización.
• Cambios de esquema: hacer particiones hash de tablas o índices, o utilizar la gestión
automática de espacio de segmento (ASSM).
• Cambios de aplicación: utilizar la opción de caché para secuencias o usar variables ligadas.
• Utilizar otros asesores: ejecutar el Asesor de Ajustes SQL en SQL de carga alta o ejecutar el
Asesor de Segmentos en objetos activos.

Database Control y Tarea ADDM
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Database Control y Tarea y
sit ADDM SI D
e r
v tareasIV
• Por defecto, ilas R
E se ejecutan para todas las instantáneas de Oracle Database
ADDM
U n
almacenadas en el N
c l e U repositorio de carga de trabajo. No obstante, puede crear una tarea ADDM
Ora
personalizada para analizar un período de tiempo identificado por una instantánea de inicio y
una instantánea de finalización.
• Para crear una tarea ADDM, acceda a la página inicial de la base de datos. En la sección Related
Links, haga clic en el enlace Advisor Central. En la página Advisor Central, haga clic en el
enlace ADDM.
• Seleccione la opción Period Start Time y haga clic en la instantánea que desea utilizar como
punto de inicio del período de tiempo. A continuación, seleccione la opción End Time y haga
clic en la instantánea que desea utilizar como punto final del período de tiempo.
• Haga clic en el botón OK. Aparecerá la página Automatic Database Diagnostic Monitor
(ADDM), donde recibirá confirmación de que se ha creado una nueva tarea.
• En la sección Performance Analysis de esta página, obtendrá el resultado de la tarea creada
manualmente.
Nota: los resultados de una tarea ADDM creada manualmente también pueden verse desde la página
Advisor Central. La sección Search de esta página permite localizar tareas.

Modificación de Atributos ADDM
1. Compruebe que STATISTICS_LEVEL esté definido en

TYPICAL o en ALL.
2. El análisis de ADDM del rendimiento de E/S depende de la
velocidad esperada del subsistema de E/S:
a. Mida la velocidad del subsistema de E/S.
b. Defina la velocidad esperada.
SQL> exec DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER(-

'ADDM', 'DBIO_EXPECTED', 8000); L A
D E
SELECT parameter_value, is_default D OS
FROM dba_advisor_def_parameters E SA
WHERE advisor_name = 'ADDM' AND E GR nlyฺ
parameter_name = 'DBIO_EXPECTED';
N DE use o
C IO AL
D A RIT
F
a n d A D
Modificación de Atributos y
sit ADDM SI D
e r R
E y se controla mediante los parámetros de inicialización
ADDM está activado
n iv por Idefecto
V
e U
STATISTICS_LEVEL.
l UNADDM no se ejecuta automáticamente, si STATISTICS_LEVEL está
c
ra en BASIC. El valor por defecto de STATISTICS_LEVEL es TYPICAL.
definido
O
El análisis de ADDM del rendimiento de E/S depende parcialmente del parámetro ADDM
DBIO_EXPECTED. Este parámetro describe el rendimiento esperado del subsistema de E/S. El valor
de DBIO_EXPECTED representa el tiempo medio en microsegundos que se tarda en leer un solo
bloque de base de datos. ADDM utiliza el valor por defecto de 10.000 microsegundos
(10 milisegundos), un valor adecuado para la mayoría de los discos duros modernos. Si su hardware
difiere significativamente de estos nuevos discos duros, es posible que convenga emplear un valor
diferente. Para determinar el valor adecuado para DBIO_EXPECTED, realice los siguientes pasos:
1. Mida el tiempo medio de lectura del hardware de un solo bloque de base de datos. Tenga en
cuenta que esta medida corresponde a un valor de E/S aleatorio que incluye el tiempo de
búsqueda en los discos duros estándar. Los valores típicos para los discos duros oscilan entre
5.000 y 20.000 microsegundos.
2. Defina el valor DBIO_EXPECTED. Por ejemplo, si el valor medido es de 8.000 microsegundos,
deberá ejecutar el primer comando de la diapositiva, conectado como usuario SYS. La consulta
de la diapositiva indica el valor actual de este parámetro.

Recuperación de Informes ADDM Mediante SQL
SELECT dbms_advisor.GET_TASK_REPORT(task_name)
FROM dba_advisor_tasks
WHERE task_id = (
SELECT max(t.task_id)
FROM dba_advisor_tasks t,
dba_advisor_log l
WHERE t.task_id = l.task_id AND
t.advisor_name = 'ADDM' AND
l.status = 'COMPLETED');
SQL> @?/rdbms/admin/addmrpt
Instance DB Name Snap Id Snap Started Level
L A
----------- ------------ --------- ------------------ -----
orcl ORCL 434 06 Feb 2010 00:00 1 D E
…
D OS
Enter value for begin_snap: 434
E SA
Enter value for end_snap: 436
… E GR nlyฺ
Enter value for report_name:
N DE use o
Generating the ADDM report for this analysis ...
C IO AL
D A RIT
F
a n d A D
Recuperación de Informes y
sit ADDM D
SI Mediante SQL
e r R
El primer ejemplo
U IVEmostrar el último informe ADDM con un comando SQL.
nivilustraNcómo
le
Para diagnosticar
c U de rendimiento de la base de datos, se puede ejecutar el análisis de
problemas
a
Or entre dos instantáneas de AWR cualesquiera, siempre que cumplan los siguientes requisitos:
ADDM
• Ninguna de las dos instantáneas deberá haber experimentado errores durante su creación y
ninguna de las dos se deberá haber depurado todavía.
• No se deben haber producido acciones de cierre e inicio entre las dos instantáneas.
El segundo ejemplo utiliza el script addmrpt.sql. Se puede utilizar este script SQL*Plus para
ejecutar ADDM en cualquiera de las dos instantáneas de AWR especificadas. Las dos instantáneas
deberán haber sido tomadas por la misma instancia.
El script identifica el DBID y muestra los identificadores de las instantáneas en los últimos tres días.
Esto le ayudará a determinar en qué par de instantáneas realizar el análisis.

Prueba
El porcentaje de tiempo de base de datos con la etiqueta

porcentaje de impacto o de beneficio en el informe ADDM es

un porcentaje de:
a. Tiempo transcurrido relacionado con el tiempo de
respuesta
b. Tiempo total de CPU utilizado por el elemento
especificado
c. Tiempo total en llamadas a la base de datos utilizado por LA
todos los procesos D E
d. Tiempo total transcurrido utilizado por las llamadas D
a OlaS
base de datos E SA
R G nlyฺ
E
N DE use o
C IO AL
D A RIT
F
a n d A D
Respuesta: c y
sit RSI D
e r
nivde datos
El tiempo de base I esE
V la suma de todo el tiempo empleado por todas las sesiones en las
llamadasle U
a la base deU N
datos. Tiene un máximo teórico de tiempo transcurrido que mide el número de
r a c
sesiones. Muchas sesiones pueden estar en las llamadas a la base de datos de forma simultánea, la
O
mayoría en espera de varias operaciones.

Historial de Sesiones Activas: Visión General
• Almacena el historial de tiempo de base de datos

• Toma ejemplos de la actividad de la sesión del sistema, entre

los que se incluyen:
– Identificador SQL de una sentencia SQL
– Número de objeto, número de archivo y número de bloque
– Identificador y parámetros de eventos de espera
– Identificador de sesión y número de serie de sesión
– Nombre de módulo y acción A
– Identificador de cliente de la sesión E L
D
– Identificador hash de servicio D OS
A
– Sesión bloqueante ES R
G análisis ฺ
E
• Siempre está activado para realizar el primer
E o nly de fallos
D use
• No necesita reproducir la carga deNtrabajo
C IO AL
D A RIT
F
a n d A D
y
it RVisión
Historial de SesionessActivas: D
SI General
e r
n iv IVE
• La vista V$ACTIVE_SESSION_HISTORY proporciona un ejemplo de la actividad de sesión
l U
en la instancia. Se N
econectada aUlapuede utilizar como primer análisis de sistema de fallos. Cualquier sesión que
c
Ora
esté base de datos y que esté esperando un evento que no pertenece a la clase de
espera de inactividad se considera una sesión activa. Se incluye cualquier sesión que estuviera
en la CPU en el momento de la toma de ejemplo.
• Los ejemplos de la sesión activa se almacenan en un buffer circular en SGA. Conforme la
actividad del sistema aumenta, el número de segundos de la actividad de la sesión que se puede
almacenar en el buffer circular desciende. El tiempo de un ejemplo de sesión se retiene en la
vista V$. El número de segundos de actividad de sesión que se muestra en la vista V$ depende
totalmente de la actividad de la base de datos.
• Al crear las instantáneas del repositorio de carga de trabajo automática (AWR), el contenido de
V$ACTIVE_SESSION_HISTORY se vacía en el disco. Al capturar sólo sesiones activas, se
representa un juego de datos gestionable con un tamaño relacionado directamente con el trabajo
realizado en lugar de con el número de sesiones que se permiten en el sistema. Puede examinar
los datos del historial de sesiones activas (ASH) en la vista V$ACTIVE_SESSION_HISTORY
y los datos históricos en la vista DBA_HIST_ACTIVE_SESS_HISTORY. También puede
realizar análisis detallados de estos datos y, a menudo, se evita tener que reproducir la carga de
trabajo para recopilar información adicional de rastreo de rendimiento. Los datos presentes en
ASH se pueden acumular en varias dimensiones que captura.

Historial de Sesiones Activas: Mecanismos
Los visores no perciben

bloqueos internos.
V$ACTIVE_SESSION_HISTORY
Esta-
dísticas 1 seg
Inserciones de
ASH rutas de acceso directas
1 seg
Buffer
Sin usar 1 seg de
SQL acumulación
V$SESSION Cada
Historial reciente
60 minutos
1 de L A
SGA
MMON 10
D E
D OS
MMNL Repositorio de
carga de trabajoE
SA
Cuando está lleno al 66%
E GR nlyฺ
N DE use o(particionado)
WRH$_ACTIVE_SESSION_HISTORY
DBA_HIST_ACTIVE_SESS_HISTORY
C IO AL
D A RIT
F
a n d A D
y SI
it RMecanismos
Historial de SesionessActivas: D
e r E todas las actividades de todas las sesiones. ASH extrae
iv costoso
• Resultaría muy
nejemplos I V registrar
l e U
únicamente
U N información de V$SESSION. Se extrae un ejemplo cada segundo. Se
de
c de manera eficaz sin utilizar SQL.
Ora
realiza
• ASH se ha diseñado como un buffer de acumulación en memoria y la información anterior se
sobrescribirá cuando sea necesario. El volumen de datos del buffer de ASH puede ser muy
grande, por lo que no es posible vaciarlo en el disco. Un enfoque más eficaz es el de filtrar los
datos de historial mientras se vacían en el repositorio de carga de trabajo. Este proceso lo realiza
automáticamente el proceso MMON (monitor de gestión) cada 60 minutos y el proceso MMNL
(Manageability Monitor Light) cuando el buffer está lleno.
• En la diapositiva se muestran todas las funciones de implementación no agresivas que se utilizan
para capturar datos ASH. Para reducir aún más una posible contención, los procesos que sólo
leen los datos (visores) no adquieren bloqueos internos.
Nota: la memoria de ASH proviene del Área Global del Sistema (SGA) y permanece fija mientras
dure la instancia. Representa 2 MB de memoria por CPU. ASH no puede superar el límite máximo de
5% del tamaño del pool compartido o el 5% de SGA_TARGET.

Creación de Ejemplos de ASH: Ejemplo
Sesión 1 V$ACTIVE_SESSION_HISTORY
Bloqueo
de espera Sesión 2
E/S de espera activa
1 seg Bloque de espera
E/S de espera de la sesión 1
E/S de espera E/S de espera de la sesión 1
Bloqueo Bloque de espera Sesión 3
de espera
de la sesión 1 activa
E/S de espera …
1 seg E/S de espera … L A
… ASH
D E
Bloque
de espera
Sesiónn
D OS
Tiempo …
activa
E SA
Activas SesionesE GR nlyฺ
N DE use o
inactivas
C IO AL
D A RIT
F
a n d A D
Creación de Ejemplossde y
it ASH: I D
SEjemplo
e r R
E representa el historial de la actividad de sesiones recientes. En el
Como ya se ha n iv IASH
explicado, V
diagramale U
se muestraU N se toman ejemplos de las sesiones cuando están activas. Cada segundo, el
cómo
c
ra de la base de datos Oracle examina las sesiones activas y registra los eventos que están
servidor
O
esperando estas sesiones. De las sesiones no activas no se toman ejemplos. El servicio de toma de
ejemplos resulta muy eficaz, ya que accede directamente a las estructuras internas de Oracle
Database. A continuación, se muestra la información de ejemplo:
• Identificador SQL de sentencia SQL
• Número de objeto, número de archivo y número de bloque
• Identificador y parámetros de eventos de espera
• Identificador de sesión y número de serie de sesión
• Nombre de módulo y acción
• Identificador de cliente de la sesión
• Identificador hash de servicio
Para acceder a las estadísticas ASH, utilice la vista fijaV$ACTIVE_SESSION_HISTORY. Esta
vista contiene una fila para cada sesión activa por ejemplo. Todas las columnas que describen la
sesión en ASH están presentes en la vista V$SESSION.

Acceso a Datos ASH
• V$ACTIVE_SESSION_HISTORY
• DBA_HIST_ACTIVE_SESS_HISTORY
• Informe ASH
• Páginas de rendimiento de EM Diagnostic Pack
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Acceso a Datos ASH sit y SI D
e r R
E de diferentes maneras. Puede utilizar SQL*Plus para acceder a
Se puede acceder
n iva los datos
I V ASH
e U UN
V$ACTIVE_SESSION_HISTORY
l y DBA_HIST_ACTIVE_SESS_HISTORY. También puede
c
ra un informe de ASH a partir de SQL*Plus con el script
generar
O
$ORACLE_HOME/rdbms/admin/ashrpt.sql. En Enterprise Manager, puede generar un
informe de historial de sesiones activas o puede utilizar las páginas Top Activity, a las que se accede
desde la página Enterprise Manager Performance, para mostrar los datos ASH.

Análisis de Datos ASH
• GROUP BY y COUNT
– Proxy para tiempo transcurrido de actividad

– Proporciones del tiempo real empleado
• Puede analizar cualquier porción de tiempo
• Ejemplo: devuelve el SQL más activo en el último minuto
SELECT sql_id, count(*),

round(count(*)/sum(count(*)) over (), 2) pctload
L A
FROM v$active_session_history
D E
WHERE sample_time > sysdate -1/24/60 and
D OS
session_type <> 'BACKGROUND'
E SA
GROUP BY sql_id
ORDER BY count(*) desc; E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Análisis de Datos ASH y
sit RSI D
e r E
U niv SQL
• Utilice sentencias
N I Vnormales
V$ACTIVE_SESSION_HISTORY.
para analizar cualquier porción de tiempo que desee mediante
Sin embargo, cuantos más ejemplos incluya en el análisis,
l e U
c precisos serán los resultados. Como ya se ha explicado, puede extraer los datos de ASH
Ora
más
mediante dimensiones distintas como, por ejemplo, SQL_ID, ACTION o un número de objeto.
• La sentencia SQL que se muestra en la diapositiva devuelve la lista de las sentencias SQL más
activas que se han ejecutado en la instancia durante el último minuto.
• Los recuentos en ASH están relacionados directamente con el tiempo de base de datos mostrado
en los informes ADDM y AWR. Cada recuento de ASH utiliza parte del tiempo de base de
datos, aunque los datos ASH sean de ejemplo, estadísticamente los elementos que utilizan la
mayor parte del tiempo de base de datos tendrán recuentos más altos en los datos ASH. La
ventaja del informe ASH es que puede ver fácilmente si la espera se está acumulando en el
tiempo, muchas esperas en un período largo o unas pocas esperas en un período corto de tiempo.
Los informes ADDM y AWR normalmente consultan un período que oscila entre 30 minutos y
24 horas; el informe ASH permite examinar períodos medidos en minutos.
Nota: también puede utilizar la vista DBA_HIST_ACTIVE_SESSION_HISTORY del repositorio
de carga de trabajo cuando desee acceder a datos que ya no estén en memoria. Sin embargo, el
número de ejemplos almacenados en la versión del disco de ASH es menor que su correspondiente
versión en memoria: un ejemplo cada 10 segundos.

Generación de Informes ASH
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
sit ASHRSI D
e r Ede los ejemplos de ASH que se tomaron durante un período de
El informe ASH
U nesivun resumen
I V
tiempo. Entre
c l UN que muestra, se encuentran los principales eventos de espera, los SQL
e la información
ra los tipos de comandos SQL principales y las sesiones principales. El informe ASH, que
principales,
O
se ejecuta en datos ASH recopilados, se puede centrar en un período de tiempo de días, horas o
minutos. Las horas de inicio y finalización no se restringen al momento en que se realizaron las
instantáneas de AWR; el período puede abarcar límites de instantáneas. Esto hace posible centrar el
análisis en un período de tiempo corto; incluso tan pequeño como un período de tan sólo unos
minutos.
Mediante Enterprise Manager, genere un informe ASH accediendo a la página Performance y, a
continuación, haciendo clic en Run ASH Report. En la página Performance, también puede hacer clic
en el enlace Top Activity. En la página Top Activity, para seleccionar un intervalo de 5 minutos
arrastre el área sombreada y, a continuación, haga clic en Run ASH Report.

Script del Informe ASH
SQL> define dbid = '';

SQL> define inst_num = '';
SQL> define report_type = 'html';
SQL> define begin_time = '09:00';
SQL> define duration = 480;
SQL> define report_name = '/tmp/sql_ashrpt.txt';
SQL> define slot_width = '';
SQL> define target_session_id = '';
SQL> define target_sql_id = 'abcdefghij123';
L A
SQL> define target_wait_class = '';
D E
SQL> define target_service_hash = '';
D OS
SQL> define target_module_name = '';
E SA
SQL>
SQL>
define target_action_name = '';
define target_client_id = ''; E GR nlyฺ
SQL> @?/rdbms/admin/ashrpti N DE use o
C IO AL
D A RIT
F
a n d A D
Script del Informe ASH y
sit RSI D
e r Einforme ASH consiste en ejecutar el script SQL*Plus
U n v generar
• Otra maneraide
N I V un
$ORACLE_HOME/rdbms/admin/ashrpt.sql.
• ra clecon pulsarUIntro cuando se le solicite cada valor de variable, para generar rápidamente un
Basta
O informe ASH que cubra los últimos 15 minutos del historial activo. Asimismo, puede definir
variables SQL*Plus antes de llamar al script.
• Como se muestra en la diapositiva, puede centrar el informe en una dimensión ASH concreta
mediante el script ashrpti.sql. Puede definir variables o introducirlas cuando se le solicite.
• Para centrarse en una dimensión ASH concreta, defina un número de las variables que se
muestran en la diapositiva en el valor que desee para el informe. Esto le permitirá centrar el
análisis en un único artículo o combinación de artículos durante un intervalo de tiempo concreto.

Informe ASH: Sección General
L A
D E
D OS
E SA
G R yฺ
V$ACTIVE_SESSION_HISTORY E E o nl
N D use
DBA_HIST_ACTIVE_SESSION_HISTORY
C IO AL
D A RIT
F
a n d A D
y
it RSI
Informe ASH: SecciónsGeneral D
e r
v del E
La columna Datan iSource I V resumen del informe muestra el origen de los datos. Puede tener dos
l e U
valores diferentes U N
porque los datos de V$ACTIVE_SESSION_HISTORY, que son datos en
c
ra migran regularmente a DBA_HIST_ACTIVE_SESS_HISTORY, que son datos en disco.
memoria,
O
Esta migración ayuda a liberar los requisitos de memoria. Durante la migración, los datos se reducen
de ejemplos de un segundo a ejemplos de diez segundos, por lo que ocupan una décima parte del
espacio en disco. Debido a esa diferencia de granularidad, los datos que provienen de la memoria
pueden ser más precisos que los que proceden de la vista del historial.

Estructura del Informe ASH
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Estructura del Informe t y
siASH SI D
e r R
Evarias de las secciones del informe ASH. El informe ASH sigue el
En la diapositiva
n isev muestran
I V
U N Empezando por la parte superior derecha de la diapositiva, las secciones
patrón deleinforme deUAWR.
l
c
O• raTop Events: informa de los eventos de usuario, los eventos en segundo plano y los valores de
del informe son:
parámetro de eventos.
• Load Profile: informa del servicio/módulo principal y los clientes principales e identifica el tipo
de comandos SQL y las fases de ejecución principal.
• Top SQL: informa de las sentencias SQL principales asociadas a los eventos principales, SQL
asociado a los orígenes de las filas principales, SQL principal que utiliza literales y el texto SQL
para estas sentencias SQL.
• Top PL/SQL Procedures: muestra los procedimientos PL/SQL que se han tenido en cuenta
para los porcentajes más altos del ejemplo de la actividad de sesión.
• Top Java Workload: describe los programas de Java principales en el ejemplo de la actividad
de sesión.
• Top Sessions: informa de las sesiones principales que estaban esperando, las sesiones
bloqueantes principales y los agregados para las sesiones PQ.
• Top Objects/Files/Latches: informa de los objetos, archivos o bloqueos internos principales
que se vieron implicados en una espera.
• Activity Over Time: informa de los tres eventos de espera principales para 10 períodos de
tiempo de igual tamaño durante el período del informe.
Este informe le permite visualizar la actividad detallada de la última hora.

Informe ASH: Activity Over Time
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Informe ASH: ActivitysOver y
it Time SI D
e r E R
U niv más
Una de las secciones
N I V
informativas del informe ASH es la sección Activity Over Time. En esta
eperíodo deUtiempo del informe ASH se divide en 10 intervalos. Si el período de tiempo es
sección, lel
c
r a
demasiado
O corto o los datos demasiado dispersos, el informe resultante tendrá menos intervalos. Los
intervalos 2 a 9 se definen como un número entero de minutos, todos de igual tamaño para realizar
una comparación sencilla. Por lo tanto, es mejor comparar entre sí los intervalos internos.
Mediante la sección Activity Over Time, puede realizar análisis sesgados buscando picos en la
columna Event Count. Esto indicaría un aumento del número de procesos en espera de un evento
concreto. Un pico en Slot Count indica un aumento de las sesiones activas porque los datos ASH se
toman como ejemplo sólo de las sesiones activas. En el ejemplo que se muestra, tenga en cuenta el
evento marcado. El número de ejemplos de sesiones activas ha aumentado y el número de sesiones
asociadas al evento buffer busy waits también ha aumentado. Este tipo de datos sesgados en
un intervalo representa posiblemente la causa raíz del problema que se investiga.

Nuevas o Mejoradas Vistas de Repositorio de
Carga de Trabajo Automática
• DBA_HIST_DB_CACHE_ADVICE
• DBA_HIST_DISPATCHER
• DBA_HIST_DYN_REMASTER_STATS
• DBA_HIST_IOSTAT_DETAIL
• DBA_HIST_SHARED_SERVER_SUMMARY
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Nuevas o Mejoradas s y
it de
Vistas I D
SRepositorio de Carga de Trabajo Automática
v e r E R
U ni deNestadísticas
Las siguientes vistas I V de AWR nuevas están disponibles en Oracle Database 11g,
ce
Versión l2: U
• ra
DBA_HIST_DB_CACHE_ADVICE: muestra predicciones históricas del número de lecturas
O físicas para el tamaño de caché que corresponde a cada fila.
• DBA_HIST_DISPATCHER: muestra información histórica de cada proceso del distribuidor en
el momento de la instantánea.
• DBA_HIST_DYN_REMASTER_STATS: muestra información estadística sobre el proceso de
remasterización dinámica.
• DBA_HIST_IOSTAT_DETAIL: muestra las estadísticas de E/S históricas agregadas por tipo
de archivo y función.
• DBA_HIST_SHARED_SERVER_SUMMARY: muestra información histórica de servidores
compartidos, como actividad del servidor compartido, colas comunes y colas de distribuidor.

Prueba
En el informe de historial de sesiones activas, puede ver sólo la

última hora de los datos, porque sólo se almacena una hora de

datos en la memoria.
a. Verdadero
b. Falso
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Respuesta: b y
sit RSI D
e r Euna hora de datos ASH en la memoria, pero los datos de memoria son
Es cierto que sólo
n ivse almacena
I V
ejemplosle U
y se colocanUenNla tabla DBA_HIST_ACTIVE_SESS_HISTORY del repositorio de carga
c
ra automática y estos datos están disponibles durante el tiempo que se retengan las
de trabajo
O
instantáneas de AWR.

Resumen

• Ajustar tareas de mantenimiento automáticas

• Generar informes ADDM
• Generar informes ASH
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

• Generación de un informe AWR

• Creación de un juego mantenido de instantáneas
• Generación de un informe ADDM
• Generación de un informe ASH
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Ora
c
n
r s
le U UN
ive IVE
a
F
ity RSID
nd AD
D
C
UN DIST
N
A RIT
IO AL
E
R
DE use o
ES
G nlyฺ
A DO
S D E LA
Supervisión de Aplicaciones
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora
Objetivos

siguiente:
• Configurar y gestionar servicios
• Utilizar servicios con aplicaciones cliente
• Usar servicios con el Gestor de Recursos de la Base de
Datos
• Utilizar servicios con el Programador
• Definir umbrales de métricas de rendimiento en servicios LA
D E
• Configurar el rastreo y la adición de servicios OS D
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
cle U
Ora

¿Qué es un Servicio?
Un servicio es:
• Un método para agrupar sesiones por tipo de trabajo

• Una abstracción que presenta datos independientes de la
instancia
• Una parte de las tareas de administración habituales que
proporcionan asignación dinámica de servicio a instancia
• La base de la alta disponibilidad de conexiones
• Una dimensión de ajustes de rendimiento adicional L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
¿Qué es un Servicio?sit y SI D
• Los serviciosiv e r R
Eejecución de los trabajos en la base de datos para que el trabajo sea
U n organizan
más gestionable, I V la
N ajustable y recuperable. Un servicio es un grupo de tareas
medible,
c l e U
Ora
relacionadas en la base de datos con funciones, expectativas de calidad y prioridad comunes en
relación con otros servicios.
• Los servicios son una capa de abstracción que permite a los clientes y niveles medios acceder a
los datos necesarios de la base de datos independientemente de donde resida la instancia o
instancias; por lo tanto los servicios proporcionan una imagen de sistema individual para
gestionar aplicaciones en competencia que se ejecutan en una única instancia y entre varias
instancias. Mediante interfaces estándar, como DBCA, Enterprise Manager y SRVCTL, los
servicios se pueden configurar, administrar, activar, desactivar y medir como una entidad única.
• Los servicios proporcionan disponibilidad. Tras una interrupción, el servicio se recupera de
forma automática en las instancias supervivientes.
• Los servicios proporcionan una dimensión adicional para el ajuste de rendimiento. Con los
servicios, se pueden ver y medir las cargas de trabajo. El ajuste por “servicio y SQL” sustituye al
ajuste por “sesión y SQL” en los sistemas en los que las sesiones son anónimas y se comparten.
• Los servicios son dinámicos: El número de instancias que ejecuta un servicio se puede aumentar
si aumenta la carga, o bien reducir si ésta disminuye. Esta asignación de recursos dinámica
permite utilizar una solución rentable para satisfacer las demandas a medida que se producen.
• Los servicios se han diseñado para su uso en diferentes bases de datos de instancia, pero
proporcionan un modo práctico de supervisar varias aplicaciones en una base de datos de
instancia única.
Atributos de Servicio
• Nombre global único

• Nombre de red
• Objetivo de asesor de equilibrio de carga
• Indicador de transacciones distribuidas
• Características de notificación en cola avanzada de clientes
OCI y ODP.NET
• Características de failover
• Algoritmo de equilibrio de carga de conexión E LA
D
• Umbral
D OS
• Prioridad E SA
R
• Configuración de alta disponibilidad EG nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Atributos de Serviciosit y SI D
e r R
Ela base de datos, se deben definir las características de gestión de carga de
n ivnuevos Ipara
Al crear servicios V
U UNseEnnecesita
trabajo deecada servicio.
l una base de datos de instancia única, la mayoría de estas características no
r a c
se aplican. Todo lo que en una base de datos de instancia única es el nombre de servicio,
O
nombre de red y nombre global único. Además del nombre de servicio y nombre de red necesarios, las
características de un servicio incluyen:
• Un objetivo de servicio que determine si las solicitudes de trabajo se realizan en el servicio en
función de la mejor calidad de servicio (tiempo de respuesta del servicio) o el mejor rendimiento
(cuánto trabajo se lleva a cabo en una unidad de tiempo), según determine el Asesor de Equilibrio
de Carga.
• Las características de los failover de sesión cuando se utiliza un failover de aplicación transparente.
• El método de conexiones de equilibrio de carga (que se puede definir) para cada servicio:
- SHORT: con el asesor de equilibrio de carga (cargas de trabajo abiertas)
- LONG: con el recuento de sesiones por servicio (carga de trabajo cerrada)
• Umbrales de métrica de servicios para el tiempo de respuesta y el consumo de CPU.
• Asignación de servicios a los grupos de consumidores en lugar de nombres de usuarios a grupos de
consumidores.
• La forma de distribución del servicio en todas las instancias cuando el sistema se inicia por primera
vez.
Nota: para obtener más información, consulte la guía Oracle Clusterware and Oracle Real Application
Clusters Administration and Deployment (Despliegue y Aplicación de Oracle Clusterware y Oracle Real
Application Clusters).

Tipos de Servicios
• Servicios de aplicaciones
• Servicios internos:
– SYS$BACKGROUND
– SYS$USERS
– No se pueden suprimir o cambiar
• Límite de 118 servicios por base de datos:
– 116 servicios de aplicaciones
– 2 servicios internos L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Tipos de Servicios sit y SI D
e r E R
n iv soporta
• Oracle Database
I V dos amplios tipos de servicios: servicios de aplicaciones y servicios
l U UN quederealizan
internos. Los servicios
e Las sesiones aplicaciones son principalmente asignaciones funcionales a cargas de
c
Ora
trabajo. un trabajo para una función de negocio común se agrupan
juntas. Para las Aplicaciones Oracle, AP, AR, GL, MFG, WIP, BOM, etc. crean una división
funcional de trabajo en la base de datos y, por lo tanto, se pueden clasificar como servicios.
• Además de los servicios de aplicaciones, RDBMS también soporta dos servicios internos.
SYS$BACKGROUND sólo lo utilizan los procesos en segundo plano. SYS$USERS es el servicio
por defecto para sesiones de usuario no asociadas a ningún servicio de aplicación. Ambos
servicios internos dan soporte a todas las funciones de gestión de cargas de trabajo y ninguno se
puede parar ni desactivar.
• Existe una limitación de 118 servicios por base de datos: 116 servicios de aplicaciones y
2 servicios internos. Puede que haya algunos servicios creados por DBCA, como el servicio
<dbname>XDB, necesario para la mayoría de las bases de datos. Los nombres de servicio
tienen una restricción de 64 caracteres.
Nota: los servicios de sombra utilizados por failover de aplicación transparente también se incluyen
en la categoría de servicios de aplicación. Además, también se crea un servicio para cada cola de
flujos en buffer.

Creación de Servicios
• Los servicios se mantienen en el diccionario de datos.

• Usar DBMS_SERVICE.CREATE para crear un servicio

para una base de datos de instancia única.
• Los servicios se crean automáticamente en función del
parámetro de inicialización SERVICE_NAMES.
• Crear servicios con:
– SRVCTL
– Enterprise Manager L A
D E
Si se usa Oracle Restart, utilizar sólo SRVCTL.
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Creación de Serviciossit y SI D
e r
v objetos
• Al igual que iotros R
Ede base de datos, se realiza el mantenimiento y el seguimiento de los
U n I V
• ra
UNundiccionario
servicios a través del
cleservicio tiene
Cada
de datos y las vistas de rendimiento dinámico.
nombre único que lo identifica localmente en el cluster y globalmente
O para Data Guard.
• Para un entorno de instancia única, los servicios se pueden crear con el paquete
DBMS_SERVICE.
• Los servicios también se crean implícitamente en el inicio de la instancia de acuerdo con los
valores definidos para el parámetro de inicialización SERVICE_NAMES.
• Los servicios también se pueden mantener con SRVCTL y Enterprise Manager.
• En entornos con Oracle Restart, Oracle recomienda utilizar SRVCTL para crear los servicios de
base de datos.

Gestión de Servicios en un
Entorno de Instancia Única
• Crear un servicio nuevo.
exec DBMS_SERVICE.CREATE_SERVICE('SERV1','SERV1.oracle.com');
• Iniciar un servicio.
exec DBMS_SERVICE.START_SERVICE('SERV1');
• Parar un servicio.
exec DBMS_SERVICE.STOP_SERVICE('SERV1');
• Suprimir un servicio.
L A
exec DBMS_SERVICE.DELETE_SERVICE('SERV1');
D E
• Desconectar las sesiones conectadas en un servicio.DO
S
exec DBMS_SERVICE.DISCONNECT_SESSION('SERV1'); E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Gestión de Servicios s y
it un Entorno
en D
SI de Instancia Única
e r R
Eprocedimiento crea un nombre de servicio en el diccionario de datos.
•
niv NIV
CREATE_SERVICE:
U
este
e
Loslservicios
c U se crean en el diccionario de datos de forma implícita cuando se define el
también
Or a
servicio en el parámetro de inicialización SERVICE_NAMES o mediante el comando ALTER
SYSTEM SET SERVICE_NAMES. Al crear un servicio, debe especificar su nombre y su
nombre de red. El nombre de red se debe utilizar en el parámetro SERVICE_NAME del
descriptor de conexión correspondiente.
• START_SERVICE: este procedimiento inicia un servicio. En un entorno de instancia única, este
procedimiento modifica SERVICE_NAMES para que contenga el nombre de este servicio. En
RAC, al implementar esta opción se actúa en la instancia especificada.
• STOP_SERVICE: este procedimiento detiene un servicio. En un entorno de instancia única, este
procedimiento modifica SERVICE_NAMES para que elimine el nombre de este servicio.
• DELETE_SERVICE: este procedimiento suprime un servicio del diccionario de datos. Debe
parar el servicio antes de poder suprimirlo.
• DISCONNECT_SESSION: este procedimiento desconecta sesiones con el servicio con nombre
en la instancia actual. Este subprograma no devuelve ningún valor hasta que todas las sesiones
correspondientes se han desconectado.
Nota: para obtener más información sobre el paquete DBMS_SERVICE, consulte PL/SQL Packages
and Types Reference (Referencia de Paquetes y Tipos PL/SQL).

¿Dónde se Utilizan los Servicios?
• El diccionario de datos mantiene los servicios.

• AWR mide el rendimiento de los servicios.

• El Gestor de Recursos de la Base de Datos utiliza servicios
en lugar de usuarios para las prioridades.
• Se puede especificar un servicio para trabajos del
programador, ejecución en paralelo (PQ, PDML y PDDL) y
colas de flujos.
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
¿Dónde se Utilizan los t y
siServicios? SI D
e r R
E de datos dan soporte a los servicios. Se realiza un seguimiento de la
iv de laIVbase
• Varias funciones
n
le U
sesión por parte delNservicio con el que está conectada. Además, los servicios también realizan
U
a
uncseguimiento de las estadísticas sobre rendimiento y de los eventos de espera.
Or• El repositorio de carga de trabajo automática (AWR) gestiona el rendimiento de los servicios.
AWR registra el rendimiento de los servicios, que incluye los tiempos de ejecución de SQL, las
clases de espera y los recursos consumidos por el servicio. El AWR avisa al DBA cuando se
exceden los umbrales de tiempo de respuesta del servicio. Las vistas de rendimiento dinámico
específicas informan del estado del servicio actual con una hora de historial.
• El Gestor de Recursos de la Base de Datos puede gestionar servicios para dar prioridad a las
cargas de trabajo de aplicación en una instancia, mediante la asignación de grupos de
consumidores y planes de recursos. Job Classes tiene una opción de servicio en el Programador
para controlar a qué servicio se conecta un trabajo en lugar de una instancia específica. Los
procesos esclavos en paralelo heredan el servicio de su coordinador.

Uso de Servicios con Aplicaciones Cliente
ERP=(DESCRIPTION=
(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=node-1vip)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=ERP)))
url="jdbc:oracle:oci:@ERP"
L A
url="jdbc:oracle:thin:@(DESCRIPTION= D E
(LOAD_BALANCE=on)
D OS
E SA
GR nlyฺ
(ADDRESS=(PROTOCOL=TCP)(HOST=node-3vip)(PORT=1521)) E
(CONNECT_DATA=(SERVICE_NAME=ERP)))" N DE use o
C IO AL
D A RIT
F
a n d A D
y
it RSI Cliente
Uso de Servicios consAplicaciones D
• Los serviciosiv e r E si varios servidores ofrecen el mismo servicio que en un entorno de
son más útiles
U n I V
• ra
e UyNlosutilizan
RAC. Los ejemplos
claplicaciones
Las
una base de datos RAC con cuatro nodos.
pools de conexiones de nivel medio seleccionan un servicio mediante el
O descriptor de conexión TNS.
• El servicio seleccionado debe coincidir con el servicio creado.
• Las listas de direcciones de cada ejemplo de la diapositiva utilizan direcciones IP virtuales. Con
las direcciones IP virtuales para la comunicación de clientes se asegura que las conexiones y las
sentencias SQL emitidas en relación con un nodo que está caído no den como resultado un
timeout de TCP/IP.
• En el primer ejemplo de la diapositiva se muestra el descriptor de conexión TNS que se puede
utilizar para acceder al servicio ERP.
• En el segundo ejemplo se muestra la URL de JDBC gruesa mediante el descriptor de conexión
TNS definido previamente.
• En el tercer ejemplo se muestra la URL de JDBC fina mediante el mismo descriptor de conexión
TNS.
Nota: la Red de Oracle utiliza la cláusula LOAD_BALANCE=ON para asignar de forma aleatoria su
progreso a través de direcciones de protocolo del descriptor de conexión. Esta función se denomina
equilibrio de carga de conexión de cliente.

Uso de Servicios con el Gestor de Recursos
• Los grupos de consumidores se asignan automáticamente a

sesiones en función de los servicios de sesión.

• Se prioriza el trabajo por servicio dentro de una instancia.
AP Recursos de la instancia
L A
Conexiones AP 75% D E
D OS
S A
LOTE LOTE E
R25% yฺ
G
E onl
E
D use
IO ALN
A RITC
D
F
a n d A D
y
Uso de Servicios conselitGestorS de D
I Recursos
e r R
v IVdeEla Base de Datos (también denominado Gestor de Recursos) permite
• El Gestor deiRecursos
U n
c l e UNmediante
identificar el trabajo servicios. Gestiona la prioridad relativa de los servicios dentro de
Ora
una instancia mediante el enlace directo de servicios a grupos de consumidores. Cuando un
cliente se conecta mediante un servicio, el grupo de consumidores se asigna de forma
transparente en el momento de la conexión. De esta forma, el Gestor de Recursos puede
gestionar las solicitudes de trabajo por servicio en orden de importancia.
• Por ejemplo, el usuario define los servicios AP y BATCH para que se ejecuten en la misma
instancia y asigna AP a un grupo de consumidores de prioridad alta y BATCH a uno de
prioridad baja. Las sesiones que se conecten a la base de datos con el servicio AP especificado
en su descriptor de conexión TNS tendrán prioridad sobre aquéllas que se conecten al servicio
BATCH.
• Esto aporta ventajas a la gestión de cargas de trabajo, ya que se da prioridad a las funciones de
negocio en lugar de a las sesiones que soportan dichas funciones.

Servicios y Gestor de Recursos con EM
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
it RScon
Servicios y Gestor desRecursos D
I EM
e r Epresenta una interfaz gráfica de usuario a través de la página Resource
n iv (EM)
• Enterprise Manager
I V
l U UNpágina, para
Consumer Group Mapping
eacceder a esta asignar automáticamente sesiones a grupos de consumidores.
c
Ora
Para haga clic en el enlace Resource Consumer Group Mappings de la
página Server.
• En la página con separadores General de la página Resource Consumer Group Mappings, puede
configurar una asignación de sesiones que se conecten con un nombre de servicio a grupos de
consumidores. Además, en esta página hay una opción para un nombre de módulo y asignación
de acciones.
• Al poder asignar sesiones a grupos de consumidores por servicio, módulo y acción, tiene una
mayor flexibilidad en lo que se refiere a la gestión del rendimiento de distintas cargas de trabajo
de aplicación.
Nota: la página con separadores Priorities de la página Resource Consumer Group Mappings permite
definir prioridades para las asignaciones configuradas en la página con separadores General. Las
opciones de asignación corresponden a columnas de V$SESSION. Cuando varias columnas de
asignación tienen valores, las prioridades definidas determinan la prioridad para asignar sesiones a
grupos de consumidores.

Servicios y
Gestor de Recursos: Ejemplo
exec DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA;
exec DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(-
CONSUMER_GROUP => 'HIGH_PRIORITY',-
COMMENT => 'High priority consumer group');
exec DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(-
ATTRIBUTE => DBMS_RESOURCE_MANAGER.SERVICE_NAME,-
VALUE => 'AP',-
CONSUMER_GROUP => 'HIGH_PRIORITY');
exec DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA; A
E L
D
exec - D OS
DBMS_RESOURCE_MANAGER_PRIVS.GRANT_SWITCH_CONSUMER_GROUP(- E SA
GRANTEE_NAME => 'PUBLIC',-
E GR nlyฺ
CONSUMER_GROUP => 'HIGH_PRIORITY',-
GRANT_OPTION => FALSE); N DE use o
C IO AL
D A RIT
F
a n d A D
y
it RSIEjemplo
Servicios y Gestor desRecursos: D
e r
• Supongamosiv
U
HIGH_PRIORITY
VE tiene dos grupos de consumidores denominados
n que laNubicación
yILOW_PRIORITY. Estos grupos de consumidores se asignan a un plan de
a c le para laU
recursos base de datos que refleja los ratios o el consumo de recursos deseados.
Or• Antes de asignar servicios a los grupos de consumidores, primero debe crear los grupos de
consumidores y el plan de recursos para ellos. El plan de recursos se puede basar en la prioridad
o en el ratio. Las llamadas PL/SQL que se muestran en la diapositiva se utilizan para crear el
grupo de consumidores HIGH_PRIORITY y para asignar el servicio AP a dicho grupo de
consumidores HIGH_PRIORITY. Puede utilizar llamadas similares para crear los grupos de
consumidores LOW_PRIORITY y para asignar el servicio BATCH a dicho grupo de
consumidores LOW_PRIORITY.
• La última llamada PL/SQL del ejemplo de la diapositiva se ejecuta porque las sesiones se
asignan automáticamente sólo a grupos de consumidores a los que se les han otorgado
privilegios de cambio. Se debe ejecutar una llamada similar para el grupo de consumidores
LOW_PRIORITY.
Nota: para obtener más información sobre el Gestor de Recursos de la Base de Datos, consulte la
guía Oracle Database Administrator’s Guide (Guía del Administrador de Oracle Database) y
PL/SQL Packages and Types Reference. (Referencia de Tipos y Paquetes PL/SQL).

Servicios y Programador con EM
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Servicios y Programador y
sit conREM SI D
e r
iv utilizaIVlosEservicios. Cuando el usuario crea una clase de trabajo, define el
• El Programador
n
l U
servicio que utilizaN
U la El
e en servicios. clase de trabajo. Los trabajos se asignan a las clases de trabajo y éstas se
c
Ora
ejecutan uso de servicios con clases de trabajo garantiza que se identifica el
trabajo del Programador para la gestión de cargas de trabajo y el ajuste de rendimiento.
• Por ejemplo, los trabajos heredan alertas generadas por el servidor y umbrales de rendimiento
para el servicio en el que se ejecutan.
• Para configurar que un trabajo se ejecute en un servicio específico, haga clic en el enlace Job
Classes de la sección Database Scheduler de la página Server. Se abre la página Scheduler Job
Classes. En la página Scheduler Job Classes, puede ver los servicios asignados a las clases de
trabajos.
• Al hacer clic en el botón Create de la página Scheduler Job Classes, aparece la página Create
Job Class. En esta página, puede introducir detalles de una nueva clase de trabajo, incluido el
servicio en el que se debe ejecutar.

Servicios y Programador con EM
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Servicios y Programador y
sit conREM D
SI(continuación)
e r
iv IVlaEclase de trabajo con el servicio en el que desea que se ejecute, puede
• Después de configurar
n
U
crear el trabajo. N
U haga clic en el enlace Jobs situado encima del enlace Job Classes de la
• ra clecrear el trabajo,
Para
O página Server. Aparecerá la página Scheduler Jobs en la que podrá hacer clic en el botón Create
para crear un nuevo trabajo. Al hacer clic en el botón Create, se mostrará la página Create Job.
Esta página tiene separadores diferentes: General, Schedule y Options. Utilice la página con
separadores General para asignar el trabajo a una clase de trabajo.

Servicios y Programador: Ejemplo
DBMS_SCHEDULER.CREATE_JOB_CLASS(
JOB_CLASS_NAME => 'HOT_BATCH_CLASS',
RESOURCE_CONSUMER_GROUP => NULL,
SERVICE => 'HOT_BATCH_SERV',
LOGGING_LEVEL => DBMS_SCHEDULER.LOGGING_RUNS,
LOG_HISTORY => 30, COMMENTS => 'P1 batch');
DBMS_SCHEDULER.CREATE_JOB(
JOB_NAME => 'my_report_job',
L A
JOB_TYPE => 'stored_procedure', D E
JOB_ACTION => 'my_name.my_proc();',
D OS
NUMBER_OF_ARGUMENTS => 4, START_DATE => SYSDATE+1,
REPEAT_INTERVAL => 5, END_DATE => SYSDATE+30, E SA
JOB_CLASS => 'HOT_BATCH_CLASS', ENABLED => TRUE, E GR nlyฺ
AUTO_DROP => false, COMMENTS => 'daily status');
N DE use o
C IO AL
D A RIT
F
a n d A D
Servicios y Programador: y
sit Ejemplo SI D
e r R
E se define una cola de lotes, HOT_BATCH_CLASS, gestionada por
U niv de
• En este ejemplo
el programador.
PL/SQL,
I V
N servicio HOT_BATCH_SERV a la cola HOT_BATCH_CLASS. Se da
Asocia el
l e U
c hecho que ya ha definido el servicio HOT_BATCH_SERV.
O• raUna vez definida la clase, puede definir el trabajo. En este ejemplo, el trabajo
por
MY_REPORT_JOB se ejecuta en la clase de trabajo HOT_BATCH_CLASS en instancias que

ofrecen el servicio HOT_BATCH_SERV.
• En este ejemplo, el usuario no asigna ningún grupo de consumidores de recursos a la clase de
trabajo HOT_BATCH_CLASS. Sin embargo, es posible asignar un grupo de consumidores a una
clase. En lo que respecta a los servicios, esto permite combinar trabajos del programador y
priorización de servicios con el Gestor de Recursos de la Base de Datos.
Nota: para obtener más información sobre el programador, consulte la guía Oracle Database
Administrator’s Guide (Guía del Administrador de Oracle Database) y PL/SQL Packages and Types
Reference (Referencia de Tipos y Paquetes PL/SQL).

Uso de Servicios con Umbrales de Métrica
• Puede definir umbrales a nivel de servicio:

– ELAPSED_TIME_PER_CALL
– CPU_TIME_PER_CALL
• Las alertas generadas por el servidor se disparan
cuando se producen violaciones de umbral.
• Puede reaccionar ante las alertas generadas:
– Cambiar prioridad
– Reubicar servicios L A
– Agregar instancias para servicios D E
D OS
S A
E
SELECT service_name, elapsedpercall, cpupercall
FROM V$SERVICEMETRIC; E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
it RSdeI Métrica
Uso de Servicios consUmbrales D
e r E permiten comparar los niveles de servicio reales con el nivel
iv de servicio
Los umbrales annivel I V
e U
mínimo lnecesario UN Esto proporciona responsabilidades con respecto a la entrega o el fallo
aceptado.
c
ra de un nivel de servicio aceptado. Puede especificar explícitamente dos umbrales de
de entrega
O
métrica para cada servicio en una instancia concreta:
• Tiempo de respuesta para llamadas: ELAPSED_TIME_PER_CALL. La alerta de este umbral
se activa cuando el tiempo transcurrido (tiempo real) supera el valor de umbral. Es una medida
fundamental que refleja todos los retrasos y fallos que experimenta la llamada.
• Tiempo de CPU para llamadas: CPU_TIME_PER_CALL
AWR supervisa el tiempo de servicio y publica alertas de AWR cuando el rendimiento excede los
umbrales. Puede responder a estas alertas cambiando la prioridad de un trabajo, parando los procesos
sobrecargados o reubicando, ampliando, reduciendo, iniciando o parando un servicio. Puede utilizar
las tareas automáticas para responder a estas alertas. Estas alertas permiten mantener la calidad del
servicio a pesar de los cambios en la demanda.
Nota: la sentencia SELECT que se muestra en la diapositiva aporta las estadísticas de instancia
acumuladas para el tiempo transcurrido y para las métricas de CPU utilizadas para cada servicio
durante el intervalo de 60 segundos más reciente. Para obtener el historial de la última hora, consulte
V$SERVICEMETRIC_HISTORY.

Cambio de Umbrales de Servicio con EM
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Cambio de Umbrales s y
it Servicio
de D
SIcon EM
e r R
E la página Metric and Policy Settings. En la captura de pantalla se
n iv se muestra
• En la diapositiva
I V
l U
muestra una parte N
Ude la página
ey Service Response en la que puede ver las métricas Service CPU Time (per user
c
Ora
call) Time (per user call).
• Para acceder a la página Metric and Policy Settings, haga clic en el enlace Metric and Policy
Settings en la página inicial. En la página Metric and Policy Settings, puede cambiar los valores
críticos y de advertencia para las métricas de servicio. Si modifica los valores críticos y de
advertencia en esta página, los umbrales se aplican a todos los servicios de la instancia.
• Si desea diferentes umbrales para distintos servicios, haga clic en el botón Edit situado a la
derecha. Aparecerá otra página en la que podrá definir umbrales críticos y de advertencia para
servicios individuales.

Servicios y Umbrales de Métrica: Ejemplo
exec DBMS_SERVER_ALERT.SET_THRESHOLD(-
METRICS_ID => dbms_server_alert.elapsed_time_per_call,
WARNING_OPERATOR => dbms_server_alert.operator_ge,
WARNING_VALUE => '500000',
CRITICAL_OPERATOR => dbms_server_alert.operator_ge,
CRITICAL_VALUE => '750000',
OBSERVATION_PERIOD => 15,
CONSECUTIVE_OCCURRENCES => 3,
INSTANCE_NAME => 'I0n', L A
OBJECT_TYPE => dbms_server_alert.object_type_service, D E
OBJECT_NAME => 'ERP');
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Servicios y Umbralessde y
it Métrica: D
SIEjemplo
e r R
U IVE umbrales
niv seNagregan
• En este ejemplo,
ELAPSED_TIME_PER_CALL.
para el servicio ERP de la métrica
Esta métrica mide el tiempo transcurrido para cada llamada de
c U correspondiente. El tiempo se debe expresar en microsegundos.
le para el servicio
Or a
usuario
• El servidor emite una alerta de advertencia siempre que el tiempo medio transcurrido por
llamada para el servicio ERP a lo largo de un período de 15 minutos supere los 0,5 segundos tres
veces consecutivas.
• El servidor emite una alerta crítica siempre que el tiempo medio transcurrido por llamada para el
servicio ERP a lo largo de un período de 15 minutos supere los 0,75 segundos tres veces
consecutivas.

Agregación y Rastreo de Servicios
• El servicio siempre agrega estadísticas para medir las

cargas de trabajo para el ajuste de rendimiento.

• Las estadísticas se pueden agregar en niveles más
detallados:
– MODULE
– ACTION
– Combinación de SERVICE_NAME, MODULE, ACTION
• El rastreo se puede realizar en distintos niveles: L A
– SERVICE_NAME D E
– MODULE D OS
S A
– ACTION E
R yฺ
G
– E
Combinación de SERVICE_NAME, MODULE, onl
E ACTION D e
s
IONsesiones
• Útil para ajustar sistemas mediante L u compartidas
D AC RITA
F
a n d A D
Agregación y Rastreosde y
it ServiciosSI D
e r R
Elos eventos de espera y las estadísticas importantes para el trabajo
U
atribuido
n v recopilan
• Por defecto, ise
I V
N Una aplicación puede cualificar un servicio con los nombres MODULE
a cada servicio.
yc l e U
Oraencontrar con exactitud las transacciones con un bajo rendimiento. En sistemas con sesiones
ACTION para identificar las transacciones importantes del servicio. De esta forma, puede
compartidas, las responsabilidades son difíciles. Por ejemplo, en los sistemas en los que se
utilizan pools de conexión o monitores de procesamientos de transacciones, se comparten las
sesiones.
• SERVICE_NAME, MODULE y ACTION son columnas en V$SESSION. SERVICE_NAME se
define automáticamente en el momento de la conexión del usuario. La aplicación define los
nombres MODULE y ACTION con el paquete PL/SQL DBMS_APPLICATION_INFO o
llamadas OCI especiales. MODULE se debe definir en un nombre que pueda reconocer el usuario
para el programa que se está ejecutando actualmente. Del mismo modo, ACTION se debe definir
en una acción o tarea específica que un usuario realiza en un módulo (por ejemplo, la
introducción de un cliente nuevo).
• La agregación de carga de trabajo también permite el rastreo por servicio. El método tradicional
de rastreo de cada sesión produce archivos de rastreo con comandos SQL que pueden abarcar
cargas de trabajo. Esto tiene como resultado un enfoque de acierto o fallo para diagnosticar SQL
problemático. Puede producir un único archivo de rastreo de salida que contenga SQL relevante
para una carga de trabajo específica mediante los criterios SERVICE_NAME, MODULE o
ACTION.

Página de Rendimiento de Servicios Principales
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Página de Rendimiento y D
SI Principales
sitde Servicios
e r R
E puede acceder a la página Top Consumers haciendo clic en el
n iv Performance,
• Desde la página
I V
U UN
enlace Top Consumers.
le
Lacpágina Top Consumers tiene varios separadores para mostrar la base de datos como una
• ra
O imagen de sistema individual. La página con separadores Overview contiene cuatro gráficas
circulares: Top Clients, Top Services, Top Modules y Top Actions. Cada gráfico proporciona
una perspectiva diferente con respecto a los principales consumidores de recursos de la base de
datos.
• La página con separadores Top Services muestra información relacionada con el rendimiento
para los servicios definidos en la base de datos. Mediante esta página, puede activar o desactivar
el rastreo a nivel de servicio, así como ver el archivo de rastreo SQL resultante.

Configuración de Agregación de Servicios
• Nivel de agregación automática de servicios de estadísticas

• DBMS_MONITOR utilizado para granularidad más detallada

de agregaciones de servicios:
– SERV_MOD_ACT_STAT_ENABLE
– SERV_MOD_ACT_STAT_DISABLE
• Posibles niveles de agregación adicionales:
– SERVICE_NAME/MODULE
– SERVICE_NAME/MODULE/ACTION A
E L
• Rastreo de servicios, módulos y acciones: D
– SERV_MOD_ACT_TRACE_ENABLE D OS
– SERV_MOD_ACT_TRACE_DISABLE E SA
E GR nlyฺ
• Los valores de la base de datos persisten E trase los o reinicios
de la instancia.
D
N L us
I O
D AC RITA
F
a n d A D
Configuración de Agregación t y
seliserviciode D
SIServicios
e r R
estadísticasn iv IVE
• En cada instancia, agrega y recopila de forma automática los eventos de espera y las
e U importantes.
U N Este nivel de agregación es automático si se especifica SERVICE_NAME
enclal cadena de conexión. Cada cadena de conexión se puede asociar a un servicio diferente. Puede
r a
O lograr un nivel más detallado de granularidad de la recopilación de estadísticas para los servicios,
utilizando el procedimiento SERV_MOD_ACT_STAT_ENABLE del paquete DBMS_MONITOR.
Este procedimiento permite recopilar estadísticas para combinaciones jerárquicas adicionales de
SERVICE_NAME/MODULE y SERVICE_NAME/MODULE/ACTION. El procedimiento
SERV_MOD_ACT_STAT_DISABLE detiene la recopilación de estadísticas activada. La activación
o desactivación de la agregación de estadísticas en el servicio se aplica a todas las instancias que
acceden a la base de datos. Además, esta configuración es persistente tras los reinicios de la
instancia.
• El procedimiento SERV_MOD_ACT_TRACE_ENABLE permite el rastreo de servicios con tres
posibilidades jerárquicas: SERVICE_NAME, SERVICE_NAME/MODULE y
SERVICE_NAME/MODULE/ACTION. El valor por defecto es rastrear todas las instancias que
acceden a la base de datos. Se proporciona un parámetro que restringe el rastreo a instancias
especificadas en las que se sabe que hay un rendimiento bajo. Este procedimiento también ofrece la
opción de capturar valores de variable ligada y esperas relevantes en los archivos de rastreo
generados.
• SERV_MOD_ACT_TRACE_DISABLE desactiva el rastreo en todas las instancias activadas para
una combinación determinada de servicio, módulo y acción. Al igual que la recopilación de
estadísticas mencionada anteriormente, el rastreo de servicios persiste tras los reinicios de la
instancia.

Agregación de Servicios: Ejemplo
• Recopilar estadísticas sobre un servicio y un módulo:

exec DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(-
'AP', 'PAYMENTS');
• Recopilar estadísticas sobre un servicio, un módulo y

una acción:
exec DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(-
'AP', 'PAYMENTS', 'QUERY_DELINQUENT');
• Rastrear todas las sesiones de todo un servicio: A

E L
exec DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE('AP'); D
D OS
S A
• Rastrear un servicio, un módulo y una acción:R E
E G nlyฺ
exec DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE(-
N DE use o
'AP', 'PAYMENTS', 'QUERY_DELINQUENT');
C IO AL
D A RIT
F
a n d A D
y
sit Ejemplo
Agregación de Servicios: SI D
e r
v del código R
E de ejemplo empieza recopilando estadísticas para el módulo
U
PAYMENTS
nidel
• La primera parte
I V
N AP. El segundo ejemplo recopila estadísticas sólo para el programa
servicio
c l e U
Oraforma, se permite la recopilación de estadísticas sobre tareas específicas que se ejecutan en la
QUERY_DELINQUENT que se ejecuta en el módulo PAYMENTS en el servicioAP. De esta
base de datos.
• En el tercer cuadro de código, se rastrean todas las sesiones que se conectan al servicio AP. Se
crea un archivo de rastreo para cada sesión que utiliza el servicio, independientemente del
módulo y la acción.
• También puede realizar un rastreo de tareas específicas en un servicio. Esto se ilustra en el
último ejemplo, en el que se rastrean todas las sesiones del servicio AP que ejecutan la acción
QUERY_DELINQUENT en el módulo PAYMENTS.
• El rastreo por servicio, módulo y acción permite centrar los esfuerzos de ajuste en SQL
específico, en lugar de cambiar entre archivos de rastreo con SQL de distintos programas. En el
archivo de rastreo sólo se registran las sentencias SQL que definen esta tarea. Esto complementa
la recopilación de estadísticas por servicio, módulo y acción porque se pueden identificar
eventos de espera relevantes para una acción.
Nota: para obtener más información sobre el paquete DBMS_MONITOR consulte PL/SQL Packages
and Types Reference (Referencia de Paquetes y Tipos PL/SQL).

Agregación y Rastreo de Identificador de Cliente
• Recopilar estadísticas sobre el identificador de cliente:

exec DBMS_MONITOR.CLIENT_ID_STAT_ENABLE('HR.HR');
• Visualizar los datos recopilados:
SELECT * FROM V$CLIENT_STATS;
• Desactivar la recopilación de estadísticas:

L A
exec DBMS_MONITOR.CLIENT_ID_STAT_DISABLE('HR.HR'); D E
D OS
• Rastrear los identificadores de cliente:
E SA
exec DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE(-
E GR nlyฺ
client_id => 'HR.HR',waits => TRUE, binds
N DE us=> e oFALSE);
C IO AL
D A RIT
F
a n d A D
Agregación y Rastreosde y D
SI de Cliente
it Identificador
e r R
E el paquete DBMS_MONITOR para activar y desactivar la agregación
n iv utilizar
• También es posible
I V
l U UNidentificador
de estadísticas de un
e el procedimiento de cliente determinado. El identificador de cliente se define
c
Oracolumna CLIENT_IDENTIFIER de V$SESSION.
mediante DBMS_SESSION.SET_IDENTIFIER y es visible gracias a la
• V$CLIENT_STATS muestra las medidas resultantes de todas las sesiones que estén activas con
el identificador de cliente por instancia. De forma similar a las estadísticas agregadas
disponibles para la agregación del servicio, las estadísticas publicadas en V$CLIENT_STATS
son un subjuego de las disponibles en V$SESSTAT y V$SESS_TIME_MODEL.
• Mediante el procedimiento CLIENT_ID_STAT_DISABLE es posible desactivar la
acumulación de las estadísticas del modelo de espera del identificador de cliente especificado.
• El procedimiento CLIENT_ID_TRACE_ENABLE activa el rastreo de forma global para la base
de datos de un identificador de cliente determinado. Como se puede ver en el ejemplo, también
se puede solicitar un volcado de los eventos de espera y de las variables de enlace a los archivos
de rastreo.
• Utilice el procedimiento CLIENT_ID_TRACE_DISABLE para desactivar la generación de
archivos de rastreo para un identificador de cliente especificado.
Nota: puede utilizar la página Top Clients a la que puede acceder desde la página Top Consumers de
Enterprise Manager para realizar lo mismo de forma gráfica que con la interfaz PL/SQL.

Utilidad trcsess
Cliente Cliente Cliente Clientes

CRM ERP CRM CRM ERP CRM
Servidor Servidor Servidor

Servidor Servidor Servidor compartido compartido compartido
dedicado dedicado dedicado
Archivo Archivo Archivo Archivo Archivo Archivo

de rastreo de rastreo de rastreo de rastreo de rastreo de rastreo
LA
TRCSESS TRCSESS D E
D OS
Archivo de rastreo S A
Archivo de rastreo
para el servicio CRM TKPROF E
R yฺ
para un cliente
E G nl
Archivo
E
D use o
de informe
IO ALN
A RITC
D
F
a n d A D
Utilidad trcsess y
sit RSI D
e r E la salida de rastreo de archivos de rastreo seleccionados en
iv IVconsolida
• La utilidad trcsess
n
l U UN Después
función de varios criterios:
e del módulo. ID de sesión, ID de cliente, nombre del servicio, nombre de la acción
c
Ora
y nombre de que trcsess fusione la información de rastreo en un único
archivo de salida, tkprof puede procesar dicho archivo. Con el procedimiento
DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE, la información de rastreo se presenta
en varios archivos de rastreo y debe utilizar la herramienta trcsess para recopilarla en un
único archivo. La utilidad trcsess es útil para consolidar el rastreo de una sesión o servicio
concreto con fines de rendimiento o depuración.
• El rastreo de una sesión específica no suele ser un problema en el modelo de servidor dedicado
porque un proceso dedicado único sirve a una sesión mientras dure. Toda la información de
rastreo de la sesión se puede ver en el archivo de rastreo que pertenece al servidor dedicado que
le aporta servicio. Sin embargo, el rastreo de un servicio puede convertirse en una tarea
compleja incluso en el modelo de servidor dedicado.
• Además, en una configuración de servidor compartido, distintos procesos sirven a una sesión de
usuario de vez en cuando. El rastreo perteneciente a la sesión de usuario se dispersa en distintos
archivos de rastreo que pertenecen a procesos diferentes. Esto dificulta la obtención de una
imagen completa del ciclo de vida de una sesión.

Vistas de Rendimiento de los Servicios
• Información de servicios, módulos y acciones en:

– V$SESSION
– V$ACTIVE_SESSION_HISTORY
• Rendimiento de los servicios en:
– V$SERVICE_STATS
– V$SERVICE_EVENT
– V$SERVICE_WAIT_CLASS
– V$SERVICEMETRIC
L A
– V$SERVICEMETRIC_HISTORY
D E
– V$SERV_MOD_ACT_STATS
D OS
– DBA_ENABLED_AGGREGATIONS
E SA
– DBA_ENABLED_TRACES
E GR nlyฺ
• Veintiocho estadísticas para los servicios
N DE use o
C IO AL
D A RIT
F
a n d A D
Vistas de Rendimiento y SI
t los Servicios
side D
e r E R
ivservicios,
La informaciónnde I V módulos y acciones se puede ver en V$SESSION y
le U U N
V$ACTIVE_SESSION_HISTORY.
a c
Ortiempos de llamadas y las estadísticas de rendimiento se pueden ver en V$SERVICE_STATS,
Los
V$SERVICE_EVENT, V$SERVICE_WAIT_CLASS, V$SERVICEMETRIC y
V$SERVICEMETRIC_HISTORY. Estas vistas muestran las estadísticas y métricas recopiladas a
nivel de servicio. Los ejemplos son:
SQL> SELECT service_name, stat_name, value
2 FROM V$SERVICE_STATS
3 WHERE service_name = 'SERV1';
SERVICE_NAME STAT_NAME VALUE

------------ ----------------------------------- ----------
SERV1 user calls 37
SERV1 DB time 225407870
SERV1 DB CPU 216824843
SERV1 parse count (total) 134
SERV1 parse time elapsed 975732
…

Vistas de Rendimiento de los Servicios (continuación)
SQL> SELECT service_name, elapsedpercall, cpupercall,
2 dbtimepercall, dbtimepersec
3 FROM V$SERVICEMETRIC
4* WHERE service_name = 'SERV1‘;
SERVICE_NAME ELAPSEDPERCALL CPUPERCALL DBTIMEPERCALL DBTIMEPERSEC

------------ -------------- ---------- ------------- ------------
SERV1 0 0 0 0
SERV1 58593980 55399177 58593980 97.6078294
Cuando está activa la recopilación de estadísticas para módulos y acciones específicos, las medidas
de rendimiento se pueden ver en cada instancia de V$SERV_MOD_ACT_STATS.
De las más de 300 estadísticas relacionadas con el rendimiento que se rastrean y se pueden ver en
V$SYSSTAT, 28 se rastrean para los servicios. Para ver las estadísticas medidas para servicios,
ejecute la siguiente consulta: L A
D E
SELECT DISTINCT stat_name FROM V$SERVICE_STATS S
DO
De las 28 estadísticas, cabe mencionar DB time y DB CPU. DB time es una estadística que mide el
A
ES
tiempo medio de respuesta por llamada. Representa el tiempo real que tarda una llamada en terminar.
R
G nlyฺ
DB CPU es una media del tiempo de CPU real empleado por llamada. La diferencia entre el tiempo
E
DE use o
de respuesta y el tiempo de CPU es el tiempo de espera del servicio. Una vez que se conoce el tiempo
N
de espera, y si consume un gran porcentaje de tiempo de respuesta, puede realizar un rastreo a nivel
C IO AL
A RIT
de acción para identificar las esperas.
D
UN DIST
Nota: DBA_ENABLED_AGGREGATIONS muestra información sobre la agregación de estadísticas a
F
nd AD
petición activada. DBA_ENABLED_TRACES muestra información sobre los rastreos activados.
a
r s ity RSID
n ive IVE
c le U UN
Ora

Prueba
Un servicio (seleccione lo que corresponda):

a. Es una representación de una instancia.

b. Es una agrupación de sesiones que realizan un trabajo
similar.
c. Sustituye tnsnames para conectar clientes a las
instancias.
d. Es una forma de recopilar estadísticas de rendimiento
para una aplicación. LA
DE
e. Es una abstracción de un juego de datos independienteSde
O
la instancia que lo proporciona. AD
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Respuesta: b, d, e sit y SI D
e r R
U niv NIVE
c le U
Or a

Resumen

• Configurar y gestionar servicios

• Utilizar servicios con aplicaciones cliente
• Usar servicios con el Gestor de Recursos de la Base de
Datos
• Utilizar servicios con el Programador
• Definir umbrales de métricas de rendimiento en servicios
• Configurar el rastreo y la adición de servicios LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Uso de Servicios
• Uso de los servicios en un entorno de instancia única

• Rastro de los servicios en un entorno de instancia única
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Ora
c
n
r s
le U UN
ive IVE
a
F
ity RSID
nd AD
D
C
UN DIST
N
A RIT
IO AL
E
R
DE use o
ES
G nlyฺ
A DO
S D E LA
Identificación de Sentencias SQL con

Problemas
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora
Objetivos

siguiente:
• Describir el procesamiento de sentencias SQL
• Describir el rol del optimizador
• Ver las estadísticas de sentencias SQL
• Identificar sentencias SQL con un bajo rendimiento
• Generar y ver un plan de ejecución
• Generar un informe tkprof LA
D E
• Generar un rastreo de optimizador S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Fases de Procesamiento de Sentencias SQL
Open Close
Análisis Enlace Ejecución Recuperación
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Fases de Procesamiento y SI
sit de Sentencias D SQL
v e r E R
ni N
Un buen conocimiento
U delIVprocesamiento SQL le ayudará a comprender las estadísticas SQL. El
procesamiento
c U SQL consta de cuatro fases importantes: análisis, enlace, ejecución y
le de sentencias
r a
recuperación.
O
Las flechas inversas indican supuestos de procesamiento (por ejemplo, Recuperar—(Volver a)
Enlazar—Ejecutar—Recuperar).
La fase de recuperación sólo se aplica a consultas y a sentencias DML con una cláusula
RETURNING.
Nota: dispone de una descripción detallada del procesamiento de sentencias SQL en la guía Oracle
Database 11g Application Developers Guide: Fundamentals (Guía del Desarrollador de
Aplicaciones de Oracle Database 11g: Conceptos Fundamentales) y en Oracle Database 11g:
Concepts (Oracle Database 11g: Conceptos).

Fase de Análisis
• Fase de análisis:
– Siempre:
— Comprueba la sintaxis
— Comprueba la semántica y los privilegios
– Análisis ligero:
— Busca la sentencia en el pool compartido
– Análisis pesado:
Fusiona definiciones de vista y subconsultas
—
L A
— Determina un plan de ejecución
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Fase de Análisis y
sit RSI D
e r
v las etapas Edel procesamiento de una sentencia SQL. Cuando una aplicación
U nide
El análisis es una I V
N realiza una llamada de análisis a la base de datos Oracle. Durante la
emite una
c l esentencia U
SQL,
O• raComprueba
llamada de análisis, Oracle Database:
si la sentencia tiene validez sintáctica y semántica.
• Determina si el proceso que emite la sentencia tiene privilegios para ejecutarla.
• Busca una coincidencia que se pueda compartir de la sentencia en el pool compartido.
• Asigna a la sentencia un área SQL privada.
Hay dos tipos de operaciones de análisis:
• Análisis ligero: se ejecuta una sentencia SQL y se encuentra una coincidencia en el pool
compartido. La coincidencia puede ser el resultado de una ejecución previa de otro usuario. La
sentencia SQL se comparte, esto es bueno para el rendimiento. Sin embargo, los análisis ligeros
también requieren comprobación de seguridad y sintaxis, que consume los recursos del sistema.
• Análisis pesado: se ejecuta una sentencia SQL la primera vez y no se encuentra ninguna
coincidencia que compartir en el pool compartido. Los análisis pesados son los que más recursos
utilizan y no son escalables, porque realizan todas las operaciones que conlleva un análisis.
Cuando se utilizan las variables ligadas correctamente, puede tener lugar mayor número de análisis
ligeros, al igual que la reducción de análisis pesados y el almacenamiento de las sentencias
analizadas en la caché de biblioteca durante un período mayor.

Almacenamiento de Cursores SQL
Pool compartido
SQLAREA
Área Área de
de contexto contexto de
de cursor cursor
para la para la
sentencia sentencia
SELECT 2 L A
SELECT 1
D E
D OS
S A
Sentencia Sentencia E
R Sentencia
SELECT 2 SELECT 1 EG l ฺ
ySELECT 1
E o n
N D use
C IO AL
D A RIT
F
a n d A D
Almacenamiento de Cursores y
sit RSQL SI D
e r Ecaché de biblioteca y sqlarea para almacenar sentencias SQL y
U
bloques PL/SQL. nivCuando
El servidor de Oracle utiliza
I V la
N sentencia se almacena en la caché, el servidor de Oracle:
una
c
• Reducel e la U
sentencia al valor numérico del texto ASCII
r a
O• Coloca el cursor para estadesentencia
• Utiliza una función hash este número
en una cadena hash
El valor hash no es un valor único y puede que haya varias sentencias con el mismo valor hash. Los
contextos de cursor de estas sentencias se almacenan todos en la misma cadena hash. Se busca la
cadena hash de la sentencia correcta. Cada vez que se emite una sentencia, se busca en la caché. Si
no se encuentra el manejador de cursor, el cursor se genera a partir de la sentencia. Cuando la
sentencia se ejecuta posteriormente, se encuentra el manejador de cursor y se vuelve a utilizar el
cursor.
Si la sentencia ya se ha analizado y ejecutado, y el manejador de cursor aún está en la caché del
cliente, el cursor se puede llamar y ejecutar sin buscar la sentencia en el pool compartido. La
estadística de recuento de análisis sigue aumentando cada vez que se realiza una solicitud de análisis,
pero la sobrecarga que supone buscar la sentencia en la caché de la sesión es mucho menor.
Éste es el comportamiento básico y se puede modificar mediante el parámetro CURSOR_SHARING y
la función de uso compartido del cursor adaptativo descrita en la lección titulada "Ajuste del Pool
Compartido".
Nota: normalmente, se realiza un análisis pesado de la sentencia SQL la primera vez que se emite y
un análisis ligero para cada sesión adicional que utilice la sentencia. Esto depende de que haya
suficiente memoria tanto en la caché de la sesión como en el pool compartido para retener la
información del cursor.
Uso y Análisis del Cursor
Memoria de sesión (UGA) Pool compartido (SGA)

Cursores abiertos Manejadores de cursor

1
3
Cursores cerrados 2
Cadenas hash
4 L A
Procedimiento de análisis: D E
1. Encuentre y ejecute un cursor abierto. D OS
2. Encuentre un cursor cerrado en la caché de la sesión. E SA
3. Busque las cadenas hash (análisis ligero). E GR nlyฺ
4. Construya el cursor (análisis pesado). N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI
Uso y Análisis del Cursor D
e r Eque su código se ejecute lo más rápido posible. Para los códigos con
n iv desea
• Cada desarrollador
I V
l U
sentencias SQL, elN
U acceso
e de la caché del cursor debe ser rápido. El acceso más rápido posible del cursor es
c
Ora
a través del cursor abierto en la memoria de sesión de la sesión del servidor. Cada
cursor abierto en la caché de cursor abierto tiene un puntero a la ubicación de la memoria SGA
de ese manejador de cursor. Para ejecutar el cursor, se utiliza el puntero; no es necesario realizar
un análisis. Ya se ha analizado un cursor abierto y el manejador de cursor está en la caché de
biblioteca.
• Cuando un cursor está cerrado, la información del cursor se mueve a la caché de cursor cerrado
de la sesión, si el parámetro SESSION_CACHED_CURSORS se ha definido en un valor
cualquiera. (El valor por defecto es 0 para las versiones anteriores a 10.2.0.2, con la que cambió
a 50).
• Cuando un cursor está abierto, la sesión comprueba aleatoriamente la sentencia SQL y realiza
una consulta hash en la caché del cursor cerrado. Si se encuentra el cursor, se mueve a la caché
del cursor abierto y, a continuación, se utiliza el puntero del manejador de cursor del pool
compartido para ejecutar el cursor. No se necesita ningún análisis.
• Si no se encuentra el cursor en la sesión, se utiliza el valor hash para buscar las cadenas hash en
el pool compartido del manejador de cursor. La búsqueda se registra como un análisis. Si se
encuentra el manejador de cursor y el resto del cursor no se ha quedado obsoleto, se ejecutará el
cursor. Esto es un análisis ligero.

Uso y Análisis del Cursor (continuación)
• Si el cursor se ha quedado obsoleto del pool compartido o si el cursor no existe en el pool
compartido, se construye. Esto es un análisis pesado. Para construir el cursor se necesitan
consultas de los metadatos para los objetos dependientes como, por ejemplo, las tablas, los
índices, las extensiones y las secuencias. Si los metadatos de estos objetos no están ya
almacenados en la caché del pool compartido, se genera SQL recursivo para recuperar la
información del diccionario de datos.

• En algunos casos en los que se envía un gran número de cursores al pool compartido y éste tiene
asignada una memoria limitada, es posible que un cursor quede obsoleto en el pool muy rápido,
incluso entre las recuperaciones. Esta situación producirá un gran número de análisis pesados.
Nota: los detalles sobre el ajuste del pool compartido para optimizar el manejo del cursor se
presentan en la lección Ajuste del Pool Compartido.
L A
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
cle U UN
Ora

Fases de Procesamiento de Sentencias SQL:
Enlazar
• Fase de enlace:
– Comprueba si la sentencia cuenta con variables ligadas

– Asigna o reasigna un valor a la variable ligada
• Las variables ligadas afectan al rendimiento si:
– Se reduce el análisis mediante el cursor compartido.
– Un plan de ejecución diferente podría mejorar el
rendimiento con diferentes valores ligados.
LA
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Fases de Procesamiento y SI
sit de Sentencias D SQL: Enlazar
v e r E R
Durante la fasen dei enlace:IV
• Oracle
l U N
e DatabaseUcomprueba si la sentencia cuenta con referencias de variables ligadas.
• ra c
Oracle Database asigna o reasigna un valor a cada variable.
O
Si se utilizan variables ligadas en una sentencia, el optimizador asume que se pretende el uso
compartido del cursor y que diferentes llamadas deben utilizar el mismo plan de ejecución. Esto
ayuda al rendimiento con la reducción de los análisis pesados.
Cuando existe un histograma, el optimizador asume que la distribución de datos no coincide con las
suposiciones por defecto del optimizador. Por lo tanto, varias llamadas del cursor con diferentes
variables ligadas se podrían beneficiar significativamente de diferentes planes de ejecución. En este
caso, el uso compartido del cursor adaptativo creará nuevos planes. Si no se intentan nuevos planes,
el rendimiento se puede reducir para determinados valores de variables ligadas.
El uso compartido del cursor se ve afectado por los parámetros de inicialización de la base de datos y
la función de uso compartido del cursor adaptativo de Oracle Database 11g. Para obtener más
información, consulte la lección Ajuste del Pool Compartido.
Si la variable ligada no coincide con el tipo de la columna, se realizará una conversión implícita que
puede impedir al optimizador seleccionar índices de acceso rápido. Utilice la vista
DBA_HIST_SQLBIND para buscar los tipos reales utilizados.

Fases de Procesamiento de Sentencias SQL:
Ejecución y Recuperación
• Fase de ejecución:
– Ejecuta la sentencia SQL

– Realiza E/S necesarias y ordena las sentencias del
lenguaje de manipulación de datos (DML)
• Fase de recuperación:
– Recupera filas para una consulta
– Ordena las consultas cuando es necesario
– Usa un mecanismo de recuperación de matriz L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Fase de Ejecución sit y SI D
e r E R
U niv consiste
El plan de ejecución
N I V en una serie de pasos que utiliza el proceso del servidor para acceder e
lelasdefilas
identificar
c Udatos necesarias de los buffers de datos. Varios usuarios pueden compartir el
de
O r
mismoa plan ejecución. Oracle Database realiza lecturas físicas o lecturas y escrituras lógicas para
sentencias DML y también ordena los datos cuando sea necesario.
Nota: las lecturas físicas son lecturas de disco. Las lecturas lógicas son bloques que ya están en
memoria en la caché de buffers de la base de datos. Las lecturas físicas utilizan más recursos y
tiempo porque necesitan E/S del disco.
Fase de Recuperación
Oracle Database recupera filas para una sentencia SELECT durante la fase de recuperación. Cada
recuperación rescata varias filas mediante una recuperación de matriz. Las recuperaciones de matriz
pueden mejorar el rendimiento gracias a la reducción de los recorridos de ida y vuelta en la red. Cada
herramienta de Oracle ofrece sus propias formas de influir en el tamaño de la matriz. Por ejemplo, en
SQL*Plus, puede cambiar el tamaño de recuperación mediante el valor ARRAYSIZE:
SQL> show arraysize
arraysize 15
SQL> set arraysize 50
SQL*Plus procesa 15 filas cada vez por defecto. Las matrices con tamaños muy altos no
proporcionan prácticamente ninguna ventaja.

Procesamiento de una Sentencia DML
Base de Datos SGA

2 Caché de buffers
de la base de datos
1
Archivos Buffer de
Proceso 3
de datos redo log
de servidor
Pool compartido
UPDATE
Archivos de employees ... A
control E L
4 S D
A DO
Proceso de R ES
Archivos redo
usuario E G nlyฺ
log
N DE use o
C IO AL
D A RIT
F
a n d A D
Pasos de Procesamiento y
sit DMLRSI D
e r
Una sentencia de v IV
nilenguaje de E manipulación de datos (DML) necesita sólo dos fases de
le U
procesamiento: U N
Elcanálisis es igual que la fase de análisis utilizada para procesar una consulta.
• ra
O• La ejecución necesita procesamiento adicional para realizar cambios de datos.
Fase de Ejecución DML
Para ejecutar una sentencia DML:
1. Si los datos y los bloques de rollback no están aún en la caché de buffers, el proceso de servidor
las lee a partir de los archivos de datos en la caché de buffers. El proceso de servidor bloquea las
filas que se van a modificar.
2. El proceso de servidor registra los cambios que se realizan en los buffers de datos, al igual que
los cambios que se deshacen. Estos cambios se escriben en el buffer de redo log antes de que se
modifiquen los datos en memoria y los buffers de rollback. Esto se conoce como “registro de
escritura anticipada”.
3. Los buffers de rollback contienen valores de los datos antes de su modificación. Los buffers de
rollback se utilizan para almacenar la imagen previa de los datos de manera que las sentencias
DML puedan realizar un rollback en caso necesario. Los buffers de datos registran los nuevos
valores de los datos.
4. El usuario obtiene el resultado de la operación DML (como el número de filas afectadas por la
operación).

Pasos de Procesamiento DML (continuación)
Fase de Ejecución DML (continuación)
Todos los bloques de datos y bloques de deshacer de la memoria (en la caché de buffers) que han
cambiado debido al DML se marcarán como buffers sucios, estos buffers no son los mismos que los
bloques correspondientes del disco. El proceso de escritor de la base de datos (DBWR) no escribe
inmediatamente estos buffers en el disco. Cuando se confirma una transacción, los registros de
cambios de redo de los cambios realizados en los bloques se registran inmediatamente en los
archivos redo log mediante el proceso de escritura de logs y finalmente DBWR los escribe en el
disco como determina el algoritmo de punto de control incremental, o según sea necesario debido a
las necesidades de espacio en la caché de buffers de la base de datos.
Nota: los registros de cambio de redo para un bloque sucio se deben escribir en el archivo redo log
antes de que DBWR pueda escribir el bloque sucio en el disco.
El procesamiento de los comandos UPDATE, DELETE o INSERT utilizan pasos similares. La
imagen anterior de DELETE contiene los valores de la columna en la fila suprimida y la imagen
anterior de INSERT sólo contiene la información de ubicación de la fila. A
E L
Hasta que la transacción se confirma, los cambios realizados en los bloques sólo se registran en las
S D
estructuras de la memoria y no se escriben en el disco de forma inmediata. Los procesos de instancia
A DO
se producen a continuación de un algoritmo lento de escritura que mejora el rendimiento general.
ES
Después de confirmar una transacción, ésta es permanente. El mensaje “committed” no se emite
R
E G nlyฺ
hasta que el proceso de LWGR ha registrado la información de redo en el disco garantizando una
DE use o
completa recuperabilidad. El proceso de DBWR escribe los bloques de datos en el disco según el
N
algoritmo de punto de comprobación. Un fallo de la computadora que cause la pérdida de SGA antes
C IO AL
A RIT
de que se confirme una transacción también puede causar la pérdida de estos cambios. La regla es
D
UN DIST
que ninguna transacción es permanente hasta que se confirma.
F
nd AD
Para obtener más información sobre el procesamiento de la caché de buffers de la base de datos,
a
r s ity RSID
consulte la lección Ajuste de la Caché de Buffers.
n ive IVE
cle U UN
Ora

Procesamiento COMMIT
Instancia
Base de Datos SGA

Caché de buffers
de la base de datos
Archivos Buffer de
Proceso redo log
de datos de servidor
Pool compartido
Archivos de
LA
control
D E
D OS
Proceso de
E SA
Archivos
usuario
E GR nlyฺ
redo log E eo
DLGWR
I O N L us
D AC RITA
F
a n d A D
COMMIT Rápido y
sit RSI D
e r
v unIV E
U niutiliza
Oracle Database
N
mecanismo de confirmación rápido que garantiza que los cambios
le se pueden
confirmados
c U recuperar en caso de fallo de la instancia.
a
Or de Cambio del Sistema
Número
Siempre que se confirme una transacción, Oracle Database asigna un número de cambio del sistema
único (SCN) a la transacción. Oracle Database lo utiliza como registro de hora interno para
sincronizar los datos y proporcionar consistencia de lectura cuando se recuperan datos de los
archivos de datos. El SCN permite a la instancia realizar comprobaciones de consistencia sin
depender de la fecha y la hora del sistema operativo.
Al ejecutar COMMIT, se realizan los siguientes pasos:
• El proceso de servidor coloca un registro de confirmación, junto con el SCN, en el buffer de
redo log.
• El proceso de escritura de logs (LGWR) en segundo plano realiza una escritura contigua de hasta
todas las entradas de buffers de redo log e incluye el registro de confirmación en los archivos
redo log. Esto garantiza que los cambios no se pierdan incluso si se produce un fallo de la
instancia.
• El proceso del servidor envía un mensaje de terminación de la transacción al proceso de usuario.
DBWR vuelve a escribir los cambios de bloque de datos reales en el disco basándose en su propio
mecanismo de temporización interno y en la configuración de punto de control incremental.

Rol del Optimizador de Oracle
• El optimizador de consulta de Oracle determina el plan

de ejecución más eficaz y es el paso más importante en

el procesamiento de sentencias SQL.
• El optimizador:
– Evalúa expresiones y condiciones
– Usa estadísticas de objeto y de sistema
– Decide el modo de acceso a datos
– Decide el modo de unión de tablas L A
– Decide la ruta de acceso más eficaz D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Rol del Optimizador de y
sitOracleRSI D
El optimizador esiv e r
la parte de E
Oracle Database que crea el plan de ejecución para una sentencia SQL.
U n I V
c l
sentencias
UNafectar
La determinación del plan
eSQL y puede de ejecución es un paso importante en el procesamiento de todas las
en gran medida al tiempo de ejecución.
O r a
El plan de ejecución conforma una serie de operaciones que se realizan en secuencia para ejecutar la
sentencia. Los detalles de los diferentes pasos se muestran en la lección Influencia en el Optimizador.
El optimizador tiene en cuenta muchos factores relacionados con los objetos a los que se hace
referencia y con las condiciones especificadas en la consulta. La información necesaria para el
optimizador incluye:
• Estadísticas recopiladas para el sistema (E/S, CPU, etc.) al igual que objetos de esquema
(número de filas, índice, etc.)
• Información de diccionario
• Cualificadores de cláusula WHERE
• Indicaciones que proporciona el desarrollador
Si se utilizan herramientas de diagnóstico como Enterprise Manager, EXPLAIN PLAN y SQL*Plus
AUTOTRACE, se puede ver el plan de ejecución que elige el optimizador.
Nota: en Oracle Database 11g, el optimizador tiene dos nombres según su funcionalidad:
optimizador de consulta u optimizador de tiempo de ejecución y optimizador automático de ajustes
(ATO). El valor de ATO depende del uso compartido de cursores SQL. El uso compartido de
cursores se ve afectado por el uso de literales, la definición del parámetro CURSOR_SHARING y los
histogramas.

Rol del Optimizador de Oracle (continuación)
Operaciones del Optimizador: para las sentencias SQL que procesa el servidor de Oracle, el
optimizador realiza las siguientes operaciones:
• Evaluación de expresiones y condiciones: el optimizador evalúa primero las expresiones y
condiciones que contienen constantes lo más completamente posible.
• Transformación de sentencias: para sentencias complejas que incluyen, por ejemplo, vistas o
subconsultas correlacionadas, el optimizador puede transformar la sentencia original en una

sentencia de unión equivalente.
• Selección de los enfoques del optimizador: el optimizador determina el objetivo de la
optimización.
• Selección de rutas de acceso: para cada tabla a la que accede la sentencia, el optimizador
selecciona una o más rutas de acceso disponibles para obtener los datos de tabla. El optimizador
omitirá determinadas rutas de acceso si no hay ninguna estadística disponible como el uso de
índices de bitmap.
• Selección de órdenes de unión: para una sentencia de unión que une más de dos tablas, el
L A
optimizador selecciona el par de tablas que se unen primero, a continuación, la tabla que se une
al resultado, etc. D E
S
A DO
• Selección de métodos de unión: para las sentencias de unión, el optimizador selecciona la
operación que se va a utilizar para realizar la unión.
R ES
E G nlyฺ
Nota: puede que el optimizador no tome las mismas decisiones de una versión de Oracle Database a
la siguiente. En versiones recientes, el optimizador puede tomar decisiones diferentes debido a que
hay más información disponible. N DE use o
C IO AL
El optimizador funciona de dos maneras, el primer y habitual modo es el optimizador de tiempo de
D A RIT
ejecución que crea el plan de ejecución en tiempo de ejecución. En este modo, el optimizador tiene
F UN DIST
limitaciones de tiempo y sólo se puede tener en cuenta un número limitado de alternativas. El
nd AD
segundo modo se denomina optimizador automático de ajustes (ATO). En este modo, se asigna al
a
r s ity RSID
optimizador mucho más tiempo para tener en cuenta más opciones y recopilar estadísticas. El ATO
ive IVE
puede generar un plan más adecuado y crear un perfil SQL que influirá en el optimizador para
n
le U UN
seleccionar el mejor plan cuando se emita una sentencia SQL en el futuro.
c
Ora

Prueba
En la fase de análisis, se utiliza el diccionario de datos para

buscar las propiedades y estadísticas de los objetos

especificados o implicados en una sentencia SQL. El
optimizador utiliza esta información para crear un plan de
ejecución. El optimizador se llama siempre para un análisis
ligero.
a. Verdadero
b. Falso A
E L
D
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Respuesta: b y
sit RSI D
e r E para un análisis pesado, porque no se encuentra alguna parte del
El optimizadorn seiv V
llama siempre
I
cursor nile U UN asociado en el área SQL. Un análisis ligero no suele llamar al
el plan de ejecución
c
Ora
optimizador, porque encuentra el cursor SQL en el área SQL.

Identificación de SQL Erróneo
• El SQL erróneo utiliza más recursos de lo necesario.

• El SQL erróneo tiene las siguientes características:

– Mucho tiempo de análisis
– Demasiadas E/S (lecturas y escrituras físicas)
– Demasiadas obtenciones en buffer
– Demasiado tiempo de CPU
– Demasiadas esperas
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Identificación de SQLsErróneo y
it RSI D
e r E es que se pueden escribir diferentes sentencias SQL que generen el
iv deIVSQL
• Una de las virtudes
n
l U UN
mismo resultado. Cualquier
ecorrecta. Sin sentencia SQL que genere el resultado correcto es una sentencia
c
Ora
SQL embargo, diferentes SQL pueden necesitar diferentes cantidades de recursos.
El SQL erróneo puede ser correcto, pero es ineficaz, ya que utiliza más recursos de lo necesario.
• Los síntomas del SQL erróneo pueden ser cualquiera de las características que se muestran en la
diapositiva. El informe de SQL principal mostrado en la siguiente diapositiva proporciona una
forma de buscar aquellas sentencias SQL que consumen más recursos en el sistema.
• El SQL erróneo puede deberse a un diseño erróneo, una codificación deficiente o a la selección
de un plan de ejecución ineficaz por parte del optimizador. Como DBA, apenas tiene control
sobre el diseño o la codificación, pero puede influir en el optimizador para generar un mejor
plan de ejecución.
• Conceptualmente, existe un plan de ejecución óptimo para cualquier juego de resultados de un
determinado juego de datos relacionales. El optimizador intenta encontrar este plan de ejecución
óptimo según las limitaciones de tiempo y los recursos. Se puede tardar mucho tiempo en
encontrar el plan óptimo. Por ejemplo, no desearía esperar 5 minutos a que el optimizador
genere un plan que reduzca el tiempo de ejecución en 5 segundos. El orden en el que el
optimizador evalúa los planes de ejecución de prueba, se verá influenciado por muchos factores,
incluido el modo en el que se escribe el SQL.

Informes de SQL Principal
SQL Ordered by CPU Time
SQL Ordered by Gets

L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI
Informes de SQL Principal D
e r
iv IVdeEla inversión en el terreno del ajuste es el ajuste SQL. Los informes de
• La mayor recuperación
n
l U
SQL principal sonN
U muy
e de recursos útiles para la identificación de las sentencias que consumen la mayor
c
Ora
cantidad del sistema. Los estudios demuestran que normalmente el 20% de las
sentencias SQL consumen el 80% de los recursos y el 10% de las sentencias consumen el 50%
de los recursos. Esto significa que con la identificación y el ajuste de las sentencias de SQL
principal, puede mejorar el rendimiento de todo el sistema.
• La búsqueda de las sentencias SQL con mayor consumo de recursos se simplifica gracias al uso
de los informes de SQL principal. Tanto los informes de AWR como los de Statspack incluyen
un juego de listas de SQL principal. Cada informe muestra las sentencias de SQL principal
almacenadas por uso de recursos en diferentes categorías. Las categorías son: Elapsed Time,
CPU Time, Gets, Reads, Executions, Parse Calls, Sharable Memory y Version Count. Los
informes individuales no incluyen el texto SQL completo, sino que se muestra un informe de
todo el texto SQL por SQL_ID a continuación de los informes individuales.
• No todas las sentencias SQL se incluyen en estos informes por defecto. El número de sentencias
incluidas se controla mediante el valor del parámetro topnsql para AWR y los valores de
nivel y umbral de Statspack. Para obtener más información sobre los parámetros de Statspack,
consulte el apéndice Uso de Statspack.

Supervisión de SQL
... A
E L
D
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Supervisión de SQL sit y SI D
e r R
En Oracle Database
U I VE 2, puede acceder a la función SQL Monitoring de Enterprise
niv 11gNVersión
Managerle
c U si hace clic en el separador Performance. Puede realizar su selección
Database Control
O r
entrealos valores de Real Time e Historical. Desplácese hasta el área Additional Monitoring Links y
haga clic en SQL Monitoring, como se muestra en la diapositiva.
Nota: el parámetro de inicialización COMPATIBLE se debe definir en 11.2.0.0 (o superior) para
utilizar esta función.

Ejecuciones SQL Supervisadas
Para cada ejecución de SQL de larga duración:

ID de sesión, donde Inicio (y

Estado: Error Tiempo Lecturas
se ejecuta el SQL finalización) de la
de Ejecución de CPU de disco
Finalizada
ejecución
LA
Duración de la Grado de paralelismo
D E
OS
ejecución (tiempo
Comando SQL en
real)
ejecución D
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI
Ejecuciones SQL Supervisadas D
e r E o símbolos de cada ejecución de SQL, se muestra una indicación
nivsobreNlos
Al mover el cursor
U I Vvalores
relevante.
c U muestra el comando SQL real en ejecución con el cursor en el enlace
leLa diapositiva
SQL
O r a
ID.
Al hacer clic en el enlace que muestra el ID de SQL, se accede a la página Monitored SQL Execution
Details, como se muestra en la siguiente diapositiva.

Lista de Supervisión de SQL
L A
D E
D OS
3 E SA
E GR nlyฺ
4D
E eo
I O N L us
D AC RITA
F
a n d A D
Lista de Supervisión s y
deitSQL SI D
e r E R
iv otro
Esta diapositivanmuestra I V ejemplo de las ejecuciones de SQL supervisadas:
1. En lal e U superior
sección UN izquierda, puede ver para cada SQL de larga duración, el estado de
c
Oraterminación (que puede ser: en ejecución, terminado o error), la duración de ejecución (tiempo
real), el ID de SQL y el ID de sesión en la que se ha ejecutado el SQL.
2. Aquí puede ver el tiempo de base de datos por clase de espera y las operaciones de lectura y
escritura de E/S.
3. Este detalle muestra el grado de paralelismo: el número de instancias implicadas en esta
ejecución paralela.
4. Y aquí se puede ver que la ejecución del comando SQL ha terminado.

Detalles de Ejecución de SQL Supervisada
En ejecución actualmente
Atributos de
ejecución básica Obtenciones en buffer
4,5 minutos, Poco de lectura/escritura
principalmente tiempo tiempo de Desglose de evento de espera
de CPU (verde) E/S (azul)
L A
D E
Datos de ASH en la
D OS
línea de tiempo
E SA
E GR nlyฺ
D E eo
La operación de unión actual
O N
ha producido 18.000 filasu s ahora
hasta
I L
D AC RITA
F
a n d A D
Detalles de Ejecuciónsde y SI D
it SQLRSupervisada
e r ESQL se muestran en tres páginas con separadores diferentes:
Los detalles den laiv
ejecución
I Vde
• Planle U UN en la parte inferior de la diapositiva
Statistics, mostrada
c
O• raParallel, que muestra la distribución del trabajo entre los servidores paralelos (no forma parte del
ejemplo de la diapositiva)
• Activity, que muestra los datos de ASH en una línea de tiempo
Al hacer clic en el enlace Session, se accede a la página Session Details.
Al hacer clic en el enlace SQL ID, se accede a la página SQL Details.

Informe de Supervisión de SQL
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Visualización del Informe y
sit deR SI D
Supervisión de SQL
v e r E
ni NIdeV SQL muestra la misma información que las diapositivas anteriores;
El informe de supervisión
U
pero estale
c U textual, en lugar de gráfica. Comienza con el texto SQL, seguido de
vez de forma
O r a
información global y, a continuación, los detalles de supervisión del plan SQL, que indica también la
operación actual con una flecha.
Cuando aparezcan los nuevos botones Save y Mail, podrá guardar el informe en formato HTML y
enviar por correo electrónico el informe activo, por ejemplo, a un experto de ajuste SQL, si la
organización tiene esta división de trabajo.

Prueba
Una sentencia SQL que utiliza más recursos de lo necesario se

considera SQL erróneo. ¿Cuáles de las siguientes son

características de SQL erróneo?
a. Exploraciones de tablas completas
b. Gran cantidad de E/S físicas
c. No utilizar índices
d. Tener un gran número de esperas
e. Tener un gran número de análisis E LA
S D
DO
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Respuesta: b, d y
sit RSI D
e r Eson las características de esta lista que apuntan a SQL erróneo.
U niyvde esperas
El exceso de E/S
N I V
l e
Las exploraciones
c deUtablas completas y el no utilizar índices podrían apuntar a un exceso de E/S,
rano necesariamente. Un gran número de análisis puede indicar un tamaño insuficiente del pool
pero
O
compartido, en lugar de SQL erróneo.

¿Qué es un Plan de Ejecución?
Un plan de ejecución es un juego de pasos que realiza el

optimizador al ejecutar una sentencia SQL y efectuar una

operación.
SORT
L A
D E
HJ
D OS
E SA
E GRHJ nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI
¿Qué es un Plan de Ejecución? D
e r
U nivuna N
Cuando se ejecuta VE el servidor ejecuta los pasos del plan creado por el optimizador.
sentencia,
I
c lerecupera
Cada paso U
físicamente filas de datos de la base de datos o las prepara de alguna forma para
Or a
la emisión de la sentencia por parte del usuario. La combinación de los pasos que se utilizan para
ejecutar una sentencia se denomina “plan de ejecución”.
Un plan de ejecución incluye un método de acceso para cada tabla a la que accede la sentencia y un
orden de las tablas (orden de unión). El optimizador también utiliza diferentes métodos para
combinar las filas de varias tablas (método de unión). Los pasos del plan de ejecución no se realizan
en el orden en el que están numerados.
El plan de ejecución permite consultar los métodos que puede seleccionar el optimizador. En
ocasiones, el plan de ejecución ilustra claramente por qué es ineficaz una sentencia; por ejemplo,
cuando se elige una exploración de tabla completa (FTS), que implica muchas E/S, en lugar de una
consulta de índice. En este caso, la pregunta es ¿por qué ha elegido el optimizador la FTS? La
lección Influencia en el Optimizador examina esta pregunta con más detalle.

Métodos para Ver los Planes de Ejecución
Para ver los planes de ejecución, utilice:

• Páginas SQL de Enterprise Manager

• Métodos DBMS_XPLAN para ver planes de:
– Repositorio de Carga de Trabajo Automática
– V$SQL_PLAN
– SQL Tuning Sets
– Plan table
• SQL Trace (evento 10046) con tkprof L A
D E
• SQL*Plus AUTOTRACE
D OS
• EXPLAIN PLAN
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y I
it RdeSEjecución
Métodos para Ver lossPlanes D
e r E
n iv permite
Enterprise Manager
I V examinar los planes de sentencias SQL en AWR, en la vista
V$SQL_PLAN
l U o en un
e planes U Njuego de ajustes SQL. Enterprise Manager utiliza DBMS_XPLAN para
r a
obtenercestos de ejecución. Puede acceder a estos planes a través de las páginas TOP SQL,
O
SQL Monitor o SQL Advisor, según el juego de planes SQL que desee ver.
El paquete DBMS_XPLAN contiene varios procedimientos para obtener y dar formato al plan de
ejecución desde diferentes orígenes, entre los que se incluyen: el repositorio de AWR,
V$SQL_PLAN, las líneas base de planes SQL, juegos de ajustes SQL y una tabla de plan.
• El repositorio de carga de trabajo automática (AWR) es un repositorio incorporado en Oracle
Database 11g. En intervalos regulares, Oracle Database realiza una instantánea de todas las
estadísticas fundamentales y la información de carga de trabajo y la almacena en AWR, incluida
una lista de sentencias SQL de muchos recursos. Los datos de AWR incluyen planes de
ejecución.
• La vista V$SQL_PLAN contiene información sobre las sentencias SQL ejecutadas y sus planes
de ejecución, que aún están en el pool compartido. También se denomina caché SQL.
• Los juegos de ajustes SQL contienen las sentencias SQL y sus planes de ejecución asociados.
• Una tabla de plan puede contener el plan de ejecución generado por el comando SQL EXPLAIN
PLAN.
La utilidad SQL Trace se utiliza para medir las estadísticas de temporización de una sentencia SQL.
Esta misma información de rastreo se obtiene con la definición del evento 10046. Ambas salidas de
rastreo se pueden formatear con la utilidad tkprof.

Métodos para Ver los Planes de Ejecución (continuación)
El comando AUTOTRACE disponible en SQL*Plus genera la salida de PLAN_TABLE y las
estadísticas sobre el rendimiento de una consulta. Este comando proporciona muchas de las mismas
estadísticas de SQL Trace, como lecturas de disco y de memoria.
El comando EXPLAIN PLAN le permite ver el plan de ejecución que utiliza el optimizador para
ejecutar una sentencia SQL sin ejecutar la sentencia. El plan de ejecución generado por el comando
EXPLAIN PLAN puede no ser el mismo que el generado por el optimizador de tiempo de
ejecución.
L A
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
cle U UN
Ora

Usos de Planes de Ejecución
• Determinación del plan de ejecución actual

• Identificación del efecto de los índices

• Determinación de las rutas de acceso
• Verificación del uso de índices
• Verificación del plan de ejecución que se puede utilizar
SORT SORT
L A
D E
HJ HJ D OS
E SA
G R yฺ
NL E E o nHJl
N D use
C IO AL
D A RIT
F
a n d A D
y
sit RSI
Usos de Planes de Ejecución D
e r
planes deE
U
• Determinar nelvplan
La visualización ide
I V ejecución se utiliza para:
Nde crear un índice
de ejecución actual
l e
• Identificar el U
c cursores que contengan una rutaendeunaacceso
efecto tabla
• r a
Buscar
O tabla completa o de rango de índices) determinada (por ejemplo, exploración de
• Identificar los índices que selecciona el optimizador

• Determinar si el optimizador que selecciona un plan de ejecución concreto (por ejemplo, unión
de bucles anidados) que espera el desarrollador
La comparación de costos y la medida de los tiempos de ejecución reales, así como el uso de
recursos de un SQL que ejecuta varios planes, son métodos que ayudan a decidir qué plan de
ejecución es más adecuado para dicho SQL, pero la comparación de planes de ejecución no es
suficiente para determinar el plan de costo más bajo.
Los planes de ejecución pueden mostrar cómo influyen en el optimizador elementos como: índices,
estadísticas sobre los objetos de base de datos, cambios en los valores de los parámetros de
inicialización y la migración de la aplicación o de la base de datos a una nueva versión. Pero estos
elementos tienen una naturaleza global. Pueden afectar a todo el sistema. SQL Access Advisor o
SQL Performance Analyzer son herramientas más adecuadas para analizar el impacto de dichos
cambios.
Por defecto, los planes de ejecución no se mantienen una vez que el SQL queda obsoleto en el pool
compartido. Si los planes utilizados anteriormente se mantienen en tablas definidas por el usuario, o
se cargan como planes de línea base, se podrá identificar la forma en la que los cambios realizados en
el rendimiento de una sentencia SQL se pueden correlacionar con los cambios en el plan de
ejecución para dicha sentencia.
Paquete DBMS_XPLAN: Visión General
• El paquete DBMS_XPLAN proporciona una forma fácil de

mostrar la salida desde:

– El comando EXPLAIN PLAN
– Repositorio de Carga de Trabajo Automática (AWR)
– Vistas fijas V$SQL_PLAN y V$SQL_PLAN_STATISTICS_ALL
• El paquete DBMS_XPLAN proporciona tres funciones de
tablas que se pueden utilizar para recuperar y mostrar el
plan de ejecución: L A
– DISPLAY D E
– DISPLAY_AWR D OS
– DISPLAY_CURSOR E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Paquete DBMS_XPLAN: t y
siVisión SI D
General
e r E R
n iv IV
El paquete DBMS_XPLAN proporciona una forma fácil de mostrar la salida del comando EXPLAIN
PLAN enle U U N
varios formatos predefinidos. También puede utilizar el paquete DBMS_XPLAN para
c
ra el plan de una sentencia almacenada en AWR. Además, proporciona una forma de mostrar el
mostrar
O
plan de ejecución SQL y las estadísticas de tiempo de ejecución de SQL para los cursores SQL en
caché en función de la información almacenada en las vistas fijas V$SQL_PLAN y
V$SQL_PLAN_STATISTICS_ALL.
El paquete DBMS_XPLAN proporciona tres funciones de tablas que se pueden utilizar para recuperar
y mostrar el plan de ejecución:
• DISPLAY formatea y muestra el contenido de una tabla del plan desde PLAN_TABLE.
• DISPLAY_AWR formatea y muestra el contenido del plan de ejecución de una sentencia SQL
almacenada en AWR.
• DISPLAY_CURSOR formatea y muestra el contenido del plan de ejecución de cualquier cursor
cargado desde la vista V$SQL_PLAN.

Paquete DBMS_XPLAN: Visión General (continuación)
Los métodos de este paquete contienen un parámetro FORMAT que le permite especificar el nivel de
detalle de los planes mostrados.
• BASIC: muestra la información mínima del plan (el ID de operación, el nombre de objeto y la
opción de operación).
• TYPICAL: Valor por defecto. Muestra la información más relevante del plan. La eliminación de
particiones, el paralelismo y los predicados sólo se muestran cuando están disponibles.

• ALL: Nivel máximo. Incluye la información mostrada con el nivel TYPICAL y agrega
información de proyección, así como sentencias SQL generadas para los servidores de ejecución
en paralelo (sólo si están en paralelo).
• SERIAL: similar a TYPICAL, excepto que la información paralela no se muestra, incluso si el
plan se ejecuta en paralelo.
Este paquete se ejecuta con los privilegios del usuario que realiza la llamada, no del propietario del
paquete (SYS). La función de la tabla DISPLAY_CURSOR necesita privilegios Select en las
siguientes vistas fijas: V$SQL_PLAN, V$SESSION y V$SQL_PLAN_STATISTICS_ALL. Con la
función DISPLAY_AWR se necesitan privilegios SELECT en DBA_HIST_SQL_PLAN, L A
DBA_HIST_SQLTEXT y V$DATABASE. Todos estos privilegios se otorgan de forma automática D E
S
DO
como parte de SELECT_CATALOG_ROLE. Sin embargo, no se recomienda el otorgamiento de este
A
ES
rol de forma indiscriminada, ya que puede provocar problemas de seguridad.
R
G nlyฺ
Tanto la función DISPLAY_CURSOR como DISPLAY_AWR aceptan SQL_ID como argumento
E
N DE use o
(como se muestra posteriormente en los ejemplos de esta lección). El valor de SQL_ID de una
sentencia se puede obtener consultando V$SQL o DBA_HIST_SQLTEXT.
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
c le U UN
Ora

Comando EXPLAIN PLAN
• Genera un plan de ejecución del optimizador

• Almacena el plan en la tabla PLAN

• No ejecuta la propia sentencia
SORT
L A
D E
OS
HJ
EXPLAIN PLAN
D
E SA
HJ
E GR nlyฺ
E deleplan
Tabla
D o
N s
C IO AL u
D A RIT
F
a n d A D
Comando EXPLAIN PLAN y
sit RSI D
e r
niv NPLAN
El comando EXPLAIN
U I VEse utiliza para generar el plan de ejecución que utiliza el optimizador
leutilizar
para ejecutar
c U SQL. No ejecuta la sentencia, sino que simplemente produce el plan que
una sentencia
O r a
se puede y lo inserta en una tabla. Si examina el plan, podrá ver cómo el servidor de Oracle
ejecuta la sentencia.
Para utilizar EXPLAIN PLAN, debe:
• En primer lugar, utilizar el comando EXPLAIN PLAN para explicar una sentencia SQL
• Recuperar los pasos del plan con los métodos del paquete DBMS_XPLAN
PLAN_TABLEse crea de forma automática como una tabla temporal global para contener la salida de
una sentencia EXPLAIN PLAN para todos los usuarios. PLAN_TABLE es la tabla de salida de
ejemplo por defecto en la que la sentencia EXPLAIN PLAN inserta las filas que describen los planes
de ejecución.
Nota: EXPLAIN PLAN puede generar un plan diferente del plan real utilizado por el optimizador,
por muchos motivos:
• El comando EXPLAIN PLAN no tiene acceso a las variables ligadas.
• La sesión de SQL*Plus puede tener un entorno diferente debido a los disparadores de conexión
o a los valores de los parámetros de la sesión.
V$SQLPLAN contendrá el plan real utilizado.

Comando EXPLAIN PLAN: Ejemplo
EXPLAIN PLAN
SET STATEMENT_ID
= 'text'
INTO your plan table
FOR statement
EXPLAIN PLAN
SET STATEMENT_ID = 'demo01' FOR
SELECT e.last_name, d.department_name A
FROM hr.employees e, hr.departments d E L
D
WHERE e.department_id = d.department_id;
D OS
Explained. SA
G RE yฺ
Nota: el comando EXPLAIN PLAN noEejecuta E onl
realmente la sentencia. N D use
C IO AL
D A RIT
F
a n d A D
Comando EXPLAIN PLAN: y
sit Ejemplo SI D
e r E R
n iv el plan
Este comando inserta I V de ejecución de la sentencia SQL en la tabla del plan y agrega la
e
etiqueta lde U
nombre U N
demo01 para futuras referencias. La etiqueta es opcional. También puede
c
ra la siguiente sintaxis:
utilizar
OEXPLAIN PLAN
FOR
SELECT e.last_name, d.department_name
FROM hr.employees e, hr.departments d
WHERE e.department_id =d.department_id;

Comando EXPLAIN PLAN: Salida
SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
Plan hash value: 1343509718
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU|
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 106 | 2862 | 6 (17|
| 1 | MERGE JOIN | | 106 | 2862 | 6 (17|
| 2 | TABLE ACCESS BY INDEX ROWID| DEPARTMENTS | 27 | 432 | 2 (0|
| 3 | INDEX FULL SCAN | DEPT_ID_PK | 27 | | 1 (0|
|* 4 |
| 5 |
SORT JOIN
TABLE ACCESS FULL
|
| EMPLOYEES
|
|
107 | 1177 |
107 | 1177 |
4 (25|
3 (0| L A
--------------------------------------------------------------------------------
D E
Predicate Information (identified by operation id):
D OS
---------------------------------------------------
S A
E
GR nlyฺ
4 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
filter("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
E
18 rows selected.
N DE use o
C IO AL
D A RIT
F
a n d A D
Comando EXPLAIN PLAN: y
sit Salida SI D
e r R
E DBMS_XPLAN se puede utilizar para formatear y mostrar la
U niv del
La función DISPLAY I V
paquete
última sentencia
c l UN en una tabla del plan.
e almacenada
La
O a
rdiapositiva muestra el resultado del uso del paquete DBMS_XPLAN como se muestra en la página
anterior para recuperar la información de la tabla PLANen este ejemplo.
También puede utilizar la sintaxis que se muestra a continuación para recuperarla de la tabla PLAN.
SELECT plan_table_output FROM
TABLE(dbms_xplan.display('plan_table','demo01','serial'));
La salida es la misma que la que se muestra en la diapositiva. En este ejemplo, puede sustituir el
nombre de otra tabla del plan en lugar de PLAN_TABLE y 'demo01' representa el ID de sentencia.
Puede ejecutar el script utlxpls.sql (ubicado en el directorio
ORACLE_HOME/rdbms/admin/) para mostrar EXPLAIN PLAN de la última sentencia
explicada. Este script utiliza la función de tabla DISPLAY desde el paquete DBMS_XPLAN.

Lectura de un Plan de Ejecución
0 SELECT STATEMENT
1 MERGE JOIN
TABLE ACCESS BY
L A
INDEX ROWID 2 4 SORT JOIN D E
of DEPARTMENTS
D OS
E SA
INDEX FULL SCAN E GR nTABLE
FULL l yฺ SCAN
DEPT_ID_PK 3
N D5 E useofoEMPLOYEES
C IO AL
D A RIT
F
a n d A D
Lectura de un Plan desEjecución y
it RSI D
e r
v ejecución, Ese puede crear un árbol de ejecución (o árbol de análisis), para
conocer mejor U nla iforma
A partir del plan de
I V
Ntodosque
en la se procesa una sentencia. Para crear el árbol, empiece por el paso 1.
l e
A continuación, U
cbajo el paso 1. Repita este procedimiento
busque los pasos con el principal del paso 1 y agréguelos como secundarios o
r
ramas
O a para todos los pasos, buscando los secundarios de
dicho paso hasta que se justifiquen todos los pasos. Para cada paso del plan de ejecución, Oracle
Database asigna un número que representa la columna de ID de PLAN_TABLE. Cada paso se
representa por un “nodo”. El resultado de la operación de cada nodo se transfiere al nodo principal,
que lo utiliza como entrada.
La secuencia de pasos se determina por las relaciones principal-secundario de los pasos. Cada paso
del plan de ejecución recupera filas de la base de datos o las acepta como entrada de uno o más pasos
distintos, también conocidos como “orígenes de fila”. El paso secundario se realiza al menos una vez
y da lugar al principal. Cuando un principal tiene varios secundarios, cada secundario se ejecuta de
forma secuencial en el orden de la posición de los pasos. Si los pasos secundarios inferiores se
organizan de izquierda a derecha, el plan se puede leer de izquierda a derecha y de abajo hacia arriba.
En el diagrama, los números corresponden a los valores de ID de la tabla PLAN (consulte la
diapositiva anterior). El optimizador recupera las filas de la tabla DEPARTMENTS con una
exploración de índice realizando una FULL INDEX SCAN en la columna de clave primaria. El
optimizador realiza una operación FULL TABLE SCAN y SORT en la tabla EMPLOYEES. Estos
dos juegos de resultados realizan la operación MERGED para obtener el resultado final de la consulta.
Nota: el paso 3 es una exploración completa del índice de clave primaria de la tabla
DEPARTMENTS, la operación recupera las entradas de índice y, a continuación, obtiene las filas de la
tabla en orden. Una exploración completa rápida de índice no devuelve las entradas de índice en
orden, por lo que será necesario realizar también una operación de ordenación.
Uso de la Vista V$SQL_PLAN
• V$SQL_PLAN proporciona una forma de examinar el

plan de ejecución para los cursores ejecutados

recientemente.
• La información de V$SQL_PLAN es muy similar a la
salida de una sentencia EXPLAIN PLAN:
– EXPLAIN PLAN muestra un plan teórico que se puede
utilizar en caso de que se vaya a ejecutar esta
sentencia.
– V$SQL_PLAN contiene el plan real utilizado. L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Uso de V$SQL_PLAN sit y SI D
e r R
E de examinar el plan de ejecución para los cursores ejecutados
n iv unaIV
Esta vista proporciona forma
U UN de esta vista es muy similar a la salida de PLAN_TABLE. Sin
e La información
recientemente.
l
c
ra EXPLAIN PLAN muestra un plan teórico que se puede utilizar en caso de que se vaya a
embargo,
O
ejecutar esta sentencia, mientras que V$SQL_PLAN contiene el plan real utilizado. El plan de
ejecución que obtiene la sentencia EXPLAIN PLAN puede ser distinto al plan de ejecución real
utilizado, debido a las consultas de variables ligadas, a la definición del parámetro cursor_sharing.
V$SQL_PLAN muestra el plan para un cursor específico. Cada sentencia SQL puede tener varios
cursores asociados, cada uno de los cuales está identificado por CHILD_NUMBER. Por ejemplo, la
misma sentencia ejecutada por diferentes usuarios tendrá distintos cursores asociados, si el objeto al
que se hace referencia está en otro esquema. Diferentes indicaciones o diferentes valores de variables
ligadas pueden provocar diferentes cursores. La tabla V$SQL_PLAN se puede utilizar para ver los
diferentes planes de los distintos cursores secundarios de la misma sentencia.
Nota: otra vista útil es V$SQL_PLAN_STATISTICS, que proporciona las estadísticas de ejecución
de cada operación del plan de ejecución para cada cursor almacenado en caché. Además, la vista
V$SQL_PLAN_STATISTICS_ALL combina información de V$SQL_PLAN con las estadísticas
de ejecución de V$SQL_PLAN_STATISTICS y V$SQL_WORKAREA.

Columnas de V$SQL_PLAN
HASH_VALUE Valor hash de la sentencia principal en la

caché de biblioteca
ADDRESS Dirección del manejador del principal de este cursor
CHILD_NUMBER Número del cursor secundario que utiliza este
plan de ejecución
POSITION Orden de procesamiento de las operaciones con el
mismo PARENT_ID
PARENT_ID ID del siguiente paso de ejecución que opera en la L A
salida del paso actual D E
ID Número asignado a cada paso del plan de ejecución D OS
E SA
E GR nlyฺ
E eo
Dlas
Nota: ésta es sólo una lista parcial
I O N
de
L us
columnas.
D AC RITA
F
a n d A D
Columnas de V$SQL_PLAN y
sit RSI D
e r
niv NdeIVlaEvista V$SQL_PLAN se muestran en las columnas de PLAN_TABLE.
Casi todas las columnas
U
Las columnas
c U el mismo nombre tienen el mismo significado en ambas vistas.
le que tienen
Las
O a
rcolumnas ADDRESS y HASH_VALUE se pueden utilizar para la unión mediante V$SQLAREA
para agregar la información específica del cursor.
Las columnas ADDRESS, HASH_VALUE y CHILD_NUMBER se pueden utilizar para la unión
mediante V$SQL para agregar la información específica del cursor secundario.

Consulta de V$SQL_PLAN
SELECT PLAN_TABLE_OUTPUT FROM
TABLE(DBMS_XPLAN.DISPLAY_CURSOR('cfz0cdukrfdnu'));
SQL_ID cfz0cdukrfdnu, child number 0

-------------------------------------
FROM hr.employees e, hr.departments d WHERE
e.department_id =d.department_id

--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU|
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 6 (100|
| 1 | MERGE JOIN | | 106 | 2862 | 6 (17|
| 2 | TABLE ACCESS BY INDEX ROWID| DEPARTMENTS | 27 | 432 | 2 (0|
L A
| 3 |
|* 4 |
INDEX FULL SCAN
SORT JOIN
| DEPT_ID_PK |
| |
27 | |
107 | 1177 |
1 (0|
4 (25| D E
| 5 | TABLE ACCESS FULL | EMPLOYEES | 107 | 1177 | 3 (0|
--------------------------------------------------------------------------------
D OS
--------------------------------------------------- E SA
4 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID") E GR nlyฺ
filter("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")E
N D use o
24 rows selected.
C IO AL
D A RIT
F
a n d A D
Consulta de V$SQL_PLAN y
sit RSI D
e r E
v IdeVV$SQL_PLAN
U niconsulta
Puede realizar la
N
con la función DBMS_XPLAN.DISPLAY_CURSOR()
leSQL_ID
para mostrar
c U última o actual ejecutada (como se muestra en el ejemplo). Puede transferir
la sentencia
O r a
el valor de para la sentencia como un parámetro y obtener el plan de ejecución para una
sentencia determinada. Para obtener el SQL_ID:
FROM hr.employees e, hr.departments d
WHERE e.department_id =d.department_id;
SELECT SQL_ID, SQL_TEXT FROM V$SQL

WHERE SQL_TEXT LIKE '%SELECT e.last_name,%' ;
13saxr0mmz1s3 select SQL_id, sql_text from v$SQL …

cfz0cdukrfdnu SELECT e.last_name, d.department_name …
El parámetro FORMAT controla el nivel de detalle del plan. Además de los valores estándar (BASIC,
TYPICAL, SERIAL y ALL), hay dos valores soportados adicionales para mostrar las estadísticas de
tiempo de ejecución para el cursor:
• RUNSTATS_LAST: muestra las estadísticas de tiempo de ejecución para la última ejecución del
cursor.
• RUNSTATS_TOT: muestra el total de las estadísticas de tiempo de ejecución agregadas para
todas las ejecuciones de una sentencia SQL determinada desde la primera vez que se analizó y
ejecutó la sentencia.

Vista V$SQL_PLAN_STATISTICS
• V$SQL_PLAN_STATISTICS proporciona las estadísticas de

ejecución real.
• V$SQL_PLAN_STATISTICS_ALL permite
comparaciones de las estimaciones del optimizador.
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Vista V$SQL_PLAN_STATISTICS y
sit RSI D
e r
U niv NIVE
La vista V$SQL_PLAN_STATISTICS proporciona las estadísticas de ejecución real para cada
operación
c leledel U el número de filas de salida y el tiempo transcurrido. Todas las estadísticas,
plan, como
O r a
excepto número de filas de salida, son acumulativas. Por ejemplo, las estadísticas de una operación
de unión incluyen también las estadísticas de las dos entradas. Las estadísticas de
V$SQL_PLAN_STATISTICS están disponibles para los cursores que se han compilado con el
parámetro de inicialización STATISTICS_LEVEL definido en ALL.
La vista V$SQL_PLAN_STATISTICS_ALL contiene estadísticas de uso de memoria para los
orígenes de fila que utilizan la memoria SQL (unión hash o de ordenación). Esta vista concatena la
información de V$SQL_PLAN con estadísticas de ejecución de V$SQL_PLAN_STATISTICS y
V$SQL_WORKAREA.

Consulta de AWR
SELECT PLAN_TABLE_OUTPUT FROM TABLE

(DBMS_XPLAN.DISPLAY_AWR('454rug2yva18w'));
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------
SQL_ID 454rug2yva18w
--------------------
select /* example */ * from hr.employees natural join hr.departments

LA
------------------------------------------------------------------------------ D|E
|Id | Operation | Name | Rows | Bytes |Cost(%CPU)| TimeS
O
------------------------------------------------------------------------------
| 0| SELECT STATEMENT | | | | S
6 (100)|AD |
6 E(17)| 00:00:01 |
| 1| HASH JOIN | | 11 | 968 |
220 |G 2
R (0)| yฺ 00:00:01
| 2| TABLE ACCESS FULL| DEPARTMENTS | 11 |
E l
3on(0)|
|
DE use
| 3| TABLE ACCESS FULL| EMPLOYEES | 107 | 7276 | 00:00:01 |
------------------------------------------------------------------------------
IO ALN
A RITC
D
F
a n d A D
Consulta de AWR y
sit RSI D
e r E
Puede utilizar la
n iv DBMS_XPLAN.DISPLAY_AWR()
función I V para mostrar todos los planes
l e
almacenados U en AWR.U NEn el ejemplo mostrado, se transfiere un SQL_ID como argumento.
c
O1.raEjecute la sentencia
A continuación, se indican los pasos para realizar este ejemplo:
SQL.
SQL> select /* example */ *
2> from hr.employees natural join hr.departments;
2. Consulte V$SQL_TEXT para obtener el valor de SQL_ID.
SQL> select sql_id, sql_text from v$SQL
2> where sql_text like '%example%';
SQL_ID SQL_TEXT
------------- -------------------------------------------
F8tc4anpz5cdb select sql_id, sql_text from v$SQL …
454rug2yva18w select /* example */ * from …
3. Mediante SQL_ID, verifique que esta sentencia se ha capturado en la vista de diccionario
DBA_HIST_SQLTEXT. Si la consulta no devuelve filas, indica que la sentencia aún no se ha
cargado en AWR.

Consulta de AWR (continuación) 
SQL> SELECT SQL_ID, SQL_TEXT FROM dba_hist_sqltext WHERE SQL_ID ='
454rug2yva18w';
no rows selected
Puede realizar una instantánea manual de AWR en lugar de esperar la siguiente instantánea (que se
produce cada hora). La sentencia SQL no se podrá capturar a menos que esté en el rango topnsql,
por lo que puede forzar que se capturen todas las sentencias SQL si cambia el rango topnsql con
el procedimiento MODIFY_SNAPSHOT_SETTING. A continuación, compruebe si se ha capturado
en DBA_HIST_SQLTEXT:
SQL> exec –
2> DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(-
3> topnsql => 'MAXIMUM');
PL/SQL procedure successfully completed.
SQL> exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

L A
PL/SQL procedure successfully completed. D E
D OS
SQL> exec – S A
E
3> topnsql => 'DEFAULT'); E GR nlyฺ
2> DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(-
N DE use o
PL/SQL procedure successfully completed.
C IO AL
D A RIT
SQL> SELECT SQL_ID, SQL_TEXT
U N ISTdba_hist_sqltext WHERE SQL_ID
FROM ='
454rug2yva18w';
d F D
SQL_ID n
a IDA
SQL_TEXT D
-------------- s i t y -------------------------------
S
v e r select E R
U ni NIV
454rug2yva18w /* example */ * from …
a c lela función U
4. Utilice DBMS_XPLAN.DISPLAY_AWR () para recuperar el plan de ejecución:
Or SQL>SELECT PLAN_TABLE_OUTPUT FROM TABLE
(DBMS_XPLAN.DISPLAY_AWR('454rug2yva18w’));
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------
SQL_ID 454rug2yva18w
--------------------
select /* example */ * from hr.employees natural join hr.departments
----------------------------------------------------------------------------------
|Id | Operation | Name | Rows | Bytes |Cost(%CPU)| Time |
----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 7 (100)| |
| 1 | HASH JOIN | | 11 | 968 | 7 (15)| 00:00:01 |
| 2 | TABLE ACCESS FULL| DEPARTMENTS | 11 | 220 | 3 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL| EMPLOYEES | 107 | 7276 | 3 (0)| 00:00:01 |
----------------------------------------------------------------------------------

SQL*Plus AUTOTRACE
OFF
SET AUTOTRACE ON
TRACE[ONLY]
EXPLAIN
STATISTICS L A
D E
D OS
SHOW AUTOTRACE E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
SQL*Plus AUTOTRACEsit y SI D
e r E R
n iv obtener
En SQL*Plus, puede I V de forma automática el plan de ejecución y algunas estadísticas
l e
adicionales U
sobre la U N
ejecución de un comando SQL con el valor AUTOTRACE. A diferencia del
c
ra EXPLAIN PLAN, la sentencia se ejecuta realmente. Sin embargo, puede optar por
comando
O
suprimir la ejecución de la sentencia especificando AUTOTRACE TRACEONLY EXPLAIN.
AUTOTRACE es una práctica herramienta de diagnóstico para el ajuste de la sentencia SQL. Debido a
que es puramente declarativa, resulta más fácil de utilizar que EXPLAIN PLAN.
Opciones de Comandos
OFF Desactiva sentencias SQL de autotrace.
ON Activa sentencias SQL de autotrace.
TRACEONLY Activa sentencias SQL de autotrace y suprime la salida de la sentencia.
EXPLAIN Muestra los planes de ejecución pero no muestra las estadísticas.
STATISTICS Muestra las estadísticas pero no muestra los planes de ejecución.
Nota: si se omiten las opciones de los comandos EXPLAIN y STATISTICS, los planes de
ejecución y las estadísticas se mostrarán por defecto.

Uso de SQL*Plus AUTOTRACE
• Para iniciar el rastreo de las sentencias con AUTOTRACE:

set autotrace on
• Para ocultar la salida de sentencias:

set autotrace traceonly
• Para mostrar sólo los planes de ejecución:

L A
set autotrace traceonly explain D E
D OS
• Controlar el diseño con los valores de columna ESA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Uso de SQL*Plus AUTOTRACE y
sit RSI D
e r
niv NIVE
Requisitos Previos
U
Para acceder
c U de STATISTICS, debe tener acceso a varias tablas dinámicas de
le aEllosDBA
datos
r a
rendimiento.
O puede otorgar acceso con el rol PLUSTRACE creado en el script
plustrce.sql. El DBA debe ejecutar el script como usuario SYS y, de este modo, ningún
usuario con el rol de DBA podrá otorgar el rol PLUSTRACE a los usuarios que deseen utilizar la
opción STATISTICS de AUTOTRACE.
Ejemplos
La diapositiva muestra ejemplos del comando AUTOTRACE.
Control del Diseño del Plan de Ejecución de AUTOTRACE
El plan de ejecución consta de cuatro columnas mostradas en el siguiente orden:
ID_PLUS_EXP Número de línea de cada paso
PARENT_ID_PLUS_EXP Número de línea del paso principal
PLAN_PLUS_EXP Paso del informe
OBJECT_NODE_PLUS_EXP Enlaces de base de datos o servidores de consultas en paralelo
utilizados
Puede cambiar el formato de estas columnas o suprimirlas, con el comando SQL*Plus COLUMN. Para
obtener más información, consulte Oracle SQL*Plus User’s Guide and Reference.(Guía del Usuario
y Referencia de Oracle SQL*Plus).

SQL*Plus AUTOTRACE: Estadísticas
set autotrace traceonly statistics
SELECT *
FROM products;
Statistics
-----------------------------------------------------
1 recursive calls
0 db block gets
9 consistent gets L A
3 physical reads
D E
0 redo size
15028 bytes sent via SQL*Net to client D OS
556 bytes received via SQL*Net from client
E SA
6 SQL*Net roundtrips to/from client
0 sorts (memory) E GR nlyฺ
0 sorts (disk)
72 rows processed N DE use o
C IO AL
D A RIT
F
a n d A D
SQL*Plus AUTOTRACE: y SI
sitEstadísticas D
e r E R
U niv varias
AUTOTRACE muestra
N I V estadísticas, aunque no todas son relevantes para tratarlas en este
momento.
c U más importantes son las siguientes:
leLas estadísticas
db a
Or block gets Número de E/S lógicas para obtenciones actuales
consistent gets Lecturas de bloques de la caché de buffers
physical reads Número de bloques leídos en el disco
redo size Cantidad de datos redo generados (para sentencias DML)
sorts (memory) Número de ordenaciones realizadas en memoria
sorts (disk) Número de ordenaciones realizadas con el almacenamiento temporal en
disco
Nota: DB block gets son lecturas de los bloques actuales en la caché de buffers. consistent gets son
lecturas de los bloques de la caché de buffers que tienen datos de deshacer. physical reads son
lecturas de bloques en el disco. db block gets, consistent gets y physical reads son las tres estadísticas
que se suelen controlar. Deben ser bajas si se comparan con el número de filas recuperadas. Las
ordenaciones se deben realizar en memoria en lugar de en el disco.

Utilidad SQL Trace
• Se activa normalmente a nivel de sesión.

• Recopila las estadísticas de sesión de las sentencias SQL

agrupadas por sesión.
• Genera una salida que TKPROF puede formatear.
Archivo
Proceso de servidor
de rastreo L A
D E
D OS
TKPROF E SA
Archivo
E GRde ninforme
l yฺ
Base de Datos
N DE use o
C IO AL
D A RIT
F
a n d A D
Utilidad SQL Trace sit y SI D
e r R
E tiene Diagnostics Pack, la utilidad SQL Trace y TKPROF permiten
U nivEdition
Si utiliza Standard I V
o no
recopilarle
c UNpara que los planes de ejecución SQL comparen el rendimiento. Una buena
las estadísticas
ra de comparar dos planes de ejecución es ejecutar las sentencias y comparar las estadísticas para
forma
O
ver cuál se ejecuta mejor. SQL Trace escribe la salida de las estadísticas de la sesión en un archivo y
el usuario utiliza TKPROF para formatearla. Puede utilizar estas herramientas junto con EXPLAIN
PLAN para obtener los mejores resultados.
La utilidad SQL Trace:
• Se puede activar para una sesión o para una instancia.
• Informa sobre el volumen y las estadísticas de tiempo para las fases de análisis, ejecución y
recuperación.
• Genera una salida que TKPROF puede formatear.
Cuando se activa la utilidad SQL Trace para una sesión, Oracle Database genera un archivo de
rastreo que contiene estadísticas de la sesión para sentencias SQL rastreadas para esa sesión. Cuando
se activa la utilidad SQL Trace para una instancia, Oracle Database crea archivos de rastreo para
todas las sesiones.
Nota: SQL Trace implica alguna sobrecarga, por lo que normalmente no resulta conveniente activar
SQL Trace a nivel de instancia.

Utilidad SQL Trace (continuación)
La utilidad SQL Trace proporciona información de rendimiento sobre sentencias SQL individuales.
SQL Trace proporciona lo siguiente, incluida la información de origen de fila:
• Recuentos de análisis, ejecución y recuperación
• Tiempos de CPU y transcurrido
• Lecturas físicas y lógicas
• Número de filas procesadas

• Faltas en la caché de biblioteca
• Nombre de usuario con el que se produce cada análisis
• Todas las operaciones de confirmación y rollback
• Operaciones de fila que muestran el plan de ejecución real de cada sentencia SQL
• Número de filas, de lecturas consistentes, de lecturas físicas, de escrituras físicas y tiempo
transcurrido para cada operación de una fila
Nota: se puede obtener un resumen de cada archivo de rastreo mediante la utilidad TKPROF.
L A
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
c le U UN
Ora

Uso de la Utilidad SQL Trace
1. Defina los parámetros de inicialización.

2. Active el rastreo.
3. Ejecute la aplicación.
4. Desactive el rastreo.
5. Cierre la sesión.
6. Formatee el archivo de rastreo.
7. Interprete la salida. A
Archivo E L
SQL Trace
de rastreo S D
A DO
S
EArchivo
R
G deninforme yฺ
TKPROF E l
N DE use o
Base de Datos
C IO AL
D A RIT
F
a n d A D
Uso de la Utilidad SQL t y
siTrace SI D
e r R
Eutilizar SQL Trace:
U nivpasos
Debe realizar estos V
para
I
1. Defina
c l UN de inicialización adecuados.
e los parámetros
O2.raActive SQL Trace.
3. Ejecute la aplicación (y desactive el rastreo cuando termine).
4. Desactive SQL Trace.
5. Cierre la sesión. (Al cerrar la sesión se desactiva también el rastreo a nivel de sesión.)
6. Formatee el archivo de rastreo producido por SQL Trace mediante tkprof.
7. Interprete la salida y ajuste las sentencias SQL cuando sea necesario.
La ejecución de SQL Trace aumenta la sobrecarga del sistema. Utilice SQL Trace sólo cuando sea
necesario y úselo a nivel de sesión en lugar de a nivel de instancia.
Nota: en este ejemplo se asume el uso de servidores dedicados. En un entorno de servidor
compartido, XA, o un pool de conexiones a nivel de aplicación, una única sesión se puede servir de
varios servidores. Todos los servidores implicados se deben rastrear y los archivos de rastreo se
combinan mediante la utilidad trcsess para enviarlos posteriormente a tkprof para formatearlos.
Para obtener más información sobre trcsess, consulte la lección Supervisión de Aplicaciones.

Parámetros de Inicialización
STATISTICS_LEVEL = {BASIC|TYPICAL|ALL}
TIMED_STATISTICS = {false|true}
MAX_DUMP_FILE_SIZE = {n|unlimited}
DIAGNOSTIC_DEST={directory_path|$ORACLE_BASE/diag}
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI
Parámetros de Inicialización D
e r
niv NIde
Existen varios parámetros
U VE inicialización relacionados con SQL Trace.
le
STATISTICS_LEVEL
c U
r a
Oparámetro
El de inicialización STATISTICS_LEVEL proporcionado por Oracle controla todas las
recopilaciones de estadísticas principales o los asesores de la base de datos. Este parámetro define el
nivel de recopilación de estadísticas de la base de datos. En función de la definición de
STATISTICS_LEVEL, se recopilan algunos asesores o estadísticas:
• BASIC: No se recopilan asesores ni estadísticas. El control y muchas funciones automáticas se
desactivan. Oracle no recomienda esta definición porque desactiva funciones importantes de
Oracle.
• TYPICAL: Éste es el valor por defecto y asegura la recopilación de las principales estadísticas
mientras proporciona el mejor rendimiento global de la base de datos. Esta definición debe ser
adecuada para la mayoría de los entornos. TYPICAL hace que se active
TIMED_STATISTICS.
• ALL: se incluyen todos los asesores o estadísticas recopilados con el valor TYPICAL, además
de estadísticas de tiempo del sistema operativo y estadísticas de ejecución del origen de fila.
Esta vista muestra el estado de las estadísticas o de los asesores que controla
STATISTICS_LEVEL.

Parámetros de Inicialización (continuación)
TIMED_STATISTICS
La utilidad SQL Trace proporciona gran cantidad de información sobre la ejecución de SQL dentro
de un proceso, que incluye de manera opcional información de temporización. Si desea obtener
información de temporización, debe definir este parámetro en TRUE. El parámetro STATISTICS
LEVEL define automáticamente este parámetro. Puede definir este parámetro independientemente de
STATISTICS_LEVEL mediante la definición del parámetro TIMED_STATISTICS en el archivo

de parámetros con:
SQL> ALTER SYSTEM SET TIMED_STATISTICS = TRUE
El parámetro también se puede definir de forma dinámica para una sesión concreta mediante el
siguiente comando:
SQL> ALTER SESSION SET timed_statistics=TRUE;
Las estadísticas de temporización tienen una resolución que se mide en microsegundos.
MAX_DUMP_FILE_SIZE
A
Cuando se activa la utilidad SQL Trace a nivel de instancia, todas las llamadas al servidor producen
L
E
una línea de texto en un archivo con el formato de archivo del sistema operativo. Este parámetro de
D
S
inicialización limita el tamaño máximo de este archivo (en bloques del sistema operativo). Es un
parámetro dinámico y de sesión. A DO
ES
Advertencia: el valor por defecto es UNLIMITED, por lo que los archivos de rastreo pueden crecer
R
hasta llenar el sistema de archivos. E G nlyฺ
DE use o
DIAGNOSTIC_DEST es el directorio raíz del Repositorio de Diagnóstico Automático. El valor por
N
IO AL
defecto de este directorio se deriva de la variable de entorno ORACLE_BASE; en UNIX es
C
A RIT
$ORACLE_BASE/diag. El archivo que se genera mientras la utilidad de rastreo está activada se
D
UN DIST
colocará en un subdirectorio de este repositorio en
F
nd AD
../rdbms/<db_name>/<instance_name>/trace.
a
Obtención de Información s ity sobre
S D de Parámetros
IValores
r ER actuales consultando la vista V$PARAMETER:
ve deIVparámetros
Puede visualizar
n ivalores
l e U SELECT
SQL> UN name, value
c
Ora
2 FROM v$parameter
3 WHERE name LIKE '%dest%';
O bien puede utilizar lo siguiente:
SQL> SHOW PARAMETER dest

Activación de SQL Trace
• Para la sesión actual:

SQL> EXEC dbms_monitor.session_trace_enable;
SQL> EXECUTE dbms_session.set_sql_trace(true);
• Para cualquier sesión:

SQL> EXECUTE dbms_monitor.session_trace_enable
2 (session_id, serial_id, waits, binds); L A
D E
• Para rastreo en toda la instancia:
D OS
S A
E
SQL> EXEC dbms_monitor.database_trace_enable();
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Activación de SQL Trace y
sit paraRuna D
SI Sesión
e r E
Puede utilizar los
n ivcomandos I V mostrados para activar SQL Trace para la sesión. Las llamadas al
l e U
procedimiento son U N
útiles si desea activar o desactivar SQL Trace en una unidad PL/SQL.
c
ra también puede activar SQL Trace para la sesión de otro usuario mediante un paquete
El DBA
O
proporcionado.
2> (session_id, serial_id);
En esta llamada al procedimiento, session_id y serial_id son los valores de las columnas
SID y SERIAL# de V$SESSION, una vista de diccionario de datos utilizada habitualmente por los
administradores de base de datos.
Para activar SQL Trace para una instancia completa, utilice el procedimiento
DATABASE_TRACE_ENABLE del paquete DBMS_MONITOR. El rastreo de ambos eventos de
espera y de los valores de enlace se puede activar en los métodos de DBMS_MONITOR como:
2> (session_id, serial_id,
3> waits => TRUE, binds => TRUE);
Advertencia: el rastreo en toda la instancia genera un gran número de archivos de rastreo y afecta al
rendimiento.
Nota: se debe otorgar EXECUTE en el paquete DBMS_MONITOR para poder utilizarlo.

Desactivación de SQL Trace
• Para la sesión actual:

SQL> EXEC dbms_monitor.session_trace_disable;
SQL> EXECUTE dbms_session.set_sql_trace(false);
• Para cualquier sesión:

SQL> EXECUTE dbms_monitor.session_trace_disable
2 (session_id, serial_id);
L A
• Para rastreo en toda la instancia: D E
SQL> EXEC dbms_monitor.database_trace_disable(); D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Desactivación de SQLsTrace y
it R para D
SI una Sesión
e r E SQL Trace mediante uno de los métodos anteriores, sustituyendo
Cuando terminenelivajuste, Idesactive
V
la palabral U N o disable por enable. Si activa SQL Trace para una única sesión,
eFALSE porUTRUE
c
Ora de esa sesión también se desactivará SQL Trace.
al salir

Formateo de los Archivos de Rastreo
OS> tkprof tracefile outputfile [options]
Ejemplos del comando TKPROF:
OS> tkprof
OS> tkprof ora_902.trc run1.txt
OS> tkprof ora_902.trc run2.txt sys=no
sort=execpu print=3 A
E L
D
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Formateo de los Archivos y SI
sit deRRastreo D
e r E
n ivTKPROF
Utilice el comando I V para formatear los archivos de rastreo en una salida legible. Ésta es la
le
sintaxis de U
TKPROF:U N
a c
r tkprof tracefile outputfile [options]
OOS>
tracefile Nombre del archivo de salida de rastreo (entrada para TKPROF)
outputfile Nombre del archivo donde se almacenarán los resultados formateados
Cuando se introduce el comando TKPROF sin ningún argumento, éste genera un mensaje de sintaxis
junto con una descripción de todas las opciones de TKPROF. Consulte la diapositiva siguiente para
obtener una lista completa. Ésta es la salida que se obtiene al introducir el comando TKPROF sin
ningún argumento:
Usage: tkprof tracefile outputfile [explain= ] [table= ]
[print= ] [insert= ] [sys= ] [sort= ]
Por defecto, al archivo .trc se le asigna un nombre con SPID. SPID se puede encontrar en
V$PROCESS. Una manera sencilla de buscar el archivo es la siguiente:
SQL> ALTER SESSION SET TRACEFILE_IDENTIFIER = 'MY_FILE';
A continuación, el archivo de rastreo de TKPROF incluirá la cadena 'MY_FILE'.

Opciones del Comando TKPROF
SORT = option
PRINT = n
EXPLAIN = username/password
INSERT = filename
SYS = NO
AGGREGATE = NO
RECORD = filename L A
D E
TABLE = schema.tablename
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Opciones del Comando s y
it RSI
TKPROF D
Las opciones queiv e r
se muestran Een negrita son las opciones utilizadas con mayor frecuencia:
U n I V
INSERT e Crea un
c l UN script SQL para cargar los resultados de TKPROF en una tabla de la base de
Ora
datos.
SORT Orden de las sentencias en el informe (consulte la página anterior para obtener una lista
de valores).
PRINT Produce sólo un informe de este número (ordenado) de sentencias.
(Esta opción resulta especialmente útil en combinación con la opción SORT.)
EXPLAIN Se conecta y ejecuta EXPLAIN PLAN en el esquema especificado.
SYS Desactiva la lista de sentencias SQL recursivas, emitida por el usuario SYS.
AGGREGATE Activa o desactiva el comportamiento (por defecto) de TKPROF, y agrega sentencias SQL
idénticas en un registro.
WAITS Especifica si se registran resúmenes para cualquier evento de espera encontrado en los
archivos de rastreo.
TABLE Especifica la tabla en la que se almacenan temporalmente los planes de ejecución antes de
escribirlos en el archivo de salida. (Este parámetro se ignora si no se especifica
EXPLAIN. Resulta útil si varios individuos utilizan TKPROF para ajustar el mismo
esquema simultáneamente, con el fin de evitar una interferencia destructiva.)
RECORD Crea un script SQL con todas las sentencias SQL no recursivas encontradas en el archivo
de rastreo. (Este script se puede utilizar para reproducir la sesión de ajuste
posteriormente.)

Opciones del Comando TKPROF (continuación)
Opciones de Ordenación
prscnt Número de veces que se llamó al análisis.
prscpu Análisis de tiempo de CPU.
prsela Análisis de tiempo transcurrido.
prsdsk Número de lecturas de disco durante el análisis.

prsqry Número de buffers para lectura consistente durante el análisis.
prscu Número de buffers para lectura actual durante el análisis.
prsmis Número de faltas en la caché de biblioteca durante el análisis.
execnt Número de ejecuciones llamadas.
execpu Tiempo de CPU invertido en la ejecución.
exeela Tiempo transcurrido en la ejecución.
exedsk Número de lecturas de disco durante la ejecución.
LA
exeqry Número de buffers para lectura consistente durante la ejecución. D E
S
execu
A DO
Número de buffers para lectura actual durante la ejecución.
exerow
R ES
Número de filas procesadas durante la ejecución.
exemis E G nlyฺ
Número de faltas de la caché de biblioteca durante la ejecución.
fchcnt
N DE use o
Número de veces que se llamó a la recuperación.
fchcpu C IO AL
Tiempo de CPU invertido en la recuperación.
fchela D A RIT
Tiempo transcurrido en la recuperación.
fchdsk F UN DIST
Número de lecturas de disco durante la recuperación.
a nd AD
fchqry
r s ity RSID
Número de buffers para lectura consistente durante la recuperación.
fchcu
n ive IVE
Número de buffers para lectura actual durante la recuperación.
fchrow
c le U UN
Número de filas recuperadas.
Ora
userid Identificador del usuario que analizó el cursor.

Salida del Comando TKPROF
• Texto de la sentencia SQL

• Estadísticas de rastreo (para llamadas recursivas y a

sentencias) divididas en tres pasos de procesamiento SQL:
PARSE Traduce la sentencia SQL en un plan de ejecución.
EXECUTE Ejecuta la sentencia.

(Este paso modifica los datos de las sentencias
INSERT, UPDATE y DELETE.) L A
D E
FETCH Recupera las filas devueltas por una consulta.
D OS
(Las recuperaciones sólo se realizan para sentencias
E SA
SELECT.)
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Salida del Comando TKPROF y
sit RSI D
e r Elas estadísticas de una sentencia SQL mediante el paso de
La salida de TKPROF
n iv muestraI V
procesamiento
l U UNcontiene estadísticas se identifica por el valor de la columna de llamada.
ecadadefilaSQL.
ra
El pasocde que
O
PARSE Este paso traduce la sentencia SQL en un plan de ejecución e incluye
comprobaciones de la autorización de seguridad correcta y de la existencia de
tablas, columnas y otros objetos a los que se haga referencia.
EXECUTE Este paso es la ejecución real de la sentencia por parte del servidor de Oracle.
Para las sentencias INSERT, UPDATE y DELETE, este paso modifica los
datos (incluidas las ordenaciones cuando sea necesario). Para las sentencias SELECT,
este paso identifica las filas seleccionadas.
FETCH Este paso recupera las filas devueltas por una consulta y las ordena cuando es necesario.
Las recuperaciones se realizan sólo para las sentencias SELECT.
Nota: el valor PARSE incluye los análisis pesados y ligeros. Un análisis pesado hace referencia al
desarrollo del plan de ejecución (incluida la optimización); posteriormente, se almacena en la caché
de biblioteca. Un análisis ligero significa que una sentencia SQL se envía a la base de datos para su
análisis, pero la base de datos la encuentra en la caché de biblioteca y sólo necesita verificar datos
como los derechos de acceso. Los análisis pesados pueden resultar costosos, en especial en cuanto a
la optimización. Un análisis ligero suele ser costoso en términos de actividad de la caché de
biblioteca.

Hay siete categorías de estadísticas de rastreo:

Count Número de veces que se ejecutó el procedimiento

CPU Número de segundos para procesamiento
Elapsed Número total de segundos para ejecución
Disk Número de lecturas físicas de los bloques
Query Número de lecturas lógicas de buffers para lecturas L A

D E
consistentes
OS
A D
Actual Número de lecturas lógicas de buffers en modo
R ES actual
Filas Número de filas procesadas mediante E G
la n l yฺ
recuperación
o la ejecución N DE use o
C IO AL
D A RIT
F
a n d A D
sit R SI D
(continuación)
e r
niv en N
La salida se explica
U IVE siguiente.
la página
La salida
a c lede ejemploUserá:
Or ID : 6assxhyzbq5jf
SQL
select max(cust_credit_limit)
from customers where cust_city ='Paris'
call count cpu elapsed disk query current rows
------- ------ ------ -------- -------- -------- -------- ----------
Parse 1 0.00 0.02 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.01 0.26 1455 1457 0 1
------- ------ ------ -------- -------- -------- -------- ----------
total 4 0.02 0.28 1455 1457 0 1

Salida del Comando TKPROF (continuación)
Junto a la columna CALL, TKPROF muestra las siguientes estadísticas para cada sentencia:
Count Número de veces que se analizó, ejecutó o recuperó una sentencia. (Compruebe esta
columna para valores superiores a 1 antes de interpretar las estadísticas de las otras
columnas. A menos que se utilice la opción AGGREGATE = NO, TKPROF agrega
ejecuciones de sentencias idénticas a una tabla de resumen.)
CPU Tiempo total de CPU en segundos de todas las llamadas a análisis, ejecución o
recuperación.
Elapsed Tiempo total de CPU en segundos de todas las llamadas a análisis, ejecución o
recuperación.
Disk Número total de bloques de datos leídos físicamente de los archivos de datos en disco
de todas las llamadas a análisis, ejecución o recuperación.
Query Número total de buffers recuperados en modo consistente de todas las llamadas
a análisis, ejecución o recuperación. (Los buffers se recuperan normalmente en modo
consistente para las consultas.) L A
D E
Actual Número total de buffers recuperados en modo actual. (Los buffers se S
DO
recuperan normalmente en modo actual para las sentencias DML. Sin embargo, los
A
ES
bloques de cabecera de segmento siempre se recuperan en modo actual.)
R
Filas E G nlyฺ
Número total de filas procesadas por la sentencia SQL. (Este total no incluye
DE use o
las filas procesadas por las subconsultas de la sentencia SQL. Para las sentencias
N
SELECT, el número de filas devueltas aparece en el paso de recuperación. Para las
C IO AL
A RIT
sentencias UPDATE, DELETE e INSERT, el número de filas procesadas
D
UN DIST
aparece en el paso de ejecución.)
F
Nota
DISK equivale a physical a ndreadsA D
desde v$sysstat o AUTOTRACE.
•
s i t y S I D
QUERY equivale ra consistent
R gets desde v$sysstat o AUTOTRACE.
ive aIdb
•
• CURRENTn equivale V Eblock gets desde v$sysstat o AUTOTRACE.
le U U N
a c
Or

La salida TKPROF también incluye lo siguiente:

• Sentencias SQL recursivas

• Faltas de caché de biblioteca
• Análisis del ID de usuario
• Plan de ejecución
• Indicación o modo del optimizador
• Operación de origen de fila
L A
...
Misses in library cache during parse: 1 D E
Optimizer mode: ALL_ROWS
D OS
Parsing user id: 85 (SH)
S A
E
Rows Row Source Operation
---- --------------------------------------------------- E GR nlyฺ
1 SORT AGGREGATE (cr=1457 pr=1455 pw=1455 E
77 TABLE ACCESS FULL CUSTOMERS (cr=1457 D
time=0 us)
pr=1455se
o
pw=1455 time=3338
... N
IO AL u
A RITC
D
F
a n d A D
sit RSI D
e r
v IVSQL E emitida por un usuario, el servidor de Oracle debe emitir
Para ejecutar una
U nisentencia
ocasionalmente
c l UN adicionales. Dichas sentencias se denominan sentencias SQL recursivas.
e sentencias
O a
Porrejemplo, si inserta una fila en una tabla que no cuenta con espacio suficiente para albergar dicha
fila, el servidor de Oracle realiza llamadas recursivas para asignar el espacio de forma dinámica. Las
llamadas recursivas también se generan cuando la información del diccionario de datos no está
disponible en la caché del diccionario de datos y se debe recuperar del disco.
Si las llamadas recursivas se producen cuando la utilidad SQL Trace está activada, TKPROF las
marca claramente como sentencias SQL recursivas en el archivo de salida. Puede suprimir la lista de
llamadas recursivas del archivo de salida definiendo el parámetro de línea de comandos SYS=NO.
Tenga en cuenta que las estadísticas de las sentencias SQL recursivas siempre se incluyen en la lista
de la sentencia SQL que provocó la llamada recursiva.
Faltas de Caché de Biblioteca
TKPROF también muestra el número de faltas de la caché de biblioteca que resulta de los pasos de
análisis y de ejecución de cada sentencia SQL. Estas estadísticas aparecen en líneas independientes a
continuación de las estadísticas tabulares.

Salida del Comando TKPROF (continuación)
Llamadas Recursivas
Análisis del Identificador de Usuario
Éste es el identificador del último usuario que analizó la sentencia.
Operación de Origen de Fila
La operación de origen de fila muestra los orígenes de datos para la ejecución de la sentencia SQL.
Esta sección proporciona l número de filas procesadas de cada operación ejecutada en las filas e
información adicional del origen de fila, como lecturas y escrituras físicas; cr = lecturas consistentes,
pw = escrituras físicas, pr = lecturas físicas, time = tiempo (en microsegundos), cost = costo
estimado, size = bytes estimados del origen de fila, card=cardinalidad (número de filas). Las
operaciones de origen de fila se incluye sólo si el cursor se ha cerrado durante el rastreo. Si la
operación de origen de fila no aparece en el archivo de rastreo, puede que desee ver EXPLAIN
PLAN.
Plan de Ejecución A
Si especifica el parámetro EXPLAIN en la línea de comandos de TKPROF, TKPROF utiliza el E L
D
OS
comando EXPLAIN PLAN para generar el plan de ejecución de cada sentencia SQL rastreada.
D
A
TKPROF también muestra el número de filas procesadas por cada paso del plan de ejecución.
S
Nota: tenga en cuenta que el plan de ejecución se genera en el momentoR E
en el que se ejecuta el
comando TKPROF y no en el que se generó el archivo de rastreo. EstoE G l yฺ si, por ejemplo,
podríaninfluir
DE use o
se ha creado o borrado un índice desde que se rastrearon las sentencias.
N
Indicación o Modo del Optimizador C IO AL
D
Señala la indicación del optimizador utilizada durante
IT de la sentencia. Si no hay
A laRejecución
F
indicación, muestra el modo del optimizador D IST
UN utilizado.
a nd AD
r s ity RSID
n ive IVE
l e U UN
c
Ora

Salida de TKPROF sin Índice: Ejemplo
...

------- ------ -------- ---------- ---------- -------- ---------- -------
Parse 1 0.00 0,00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0,03 0,03 1455 1459 0 1
------- ------ -------- ---------- ---------- -------- ---------- -------
total 4 0,04 0,04 1455 1459 0 1
Misses in library cache during parse: 1 L A

Parsing user id: 85 (SH) D E
D OS
SA
---- ---------------------------------------------------
E
GR nlyฺ
1 SORT AGGREGATE (cr=1459 pr=1455 pw=1455 time=0 us)
77 TABLE ACCESS FULL CUSTOMERS (cr=1459 pr=1455 pw=1455 time=170
E
DE use o
us cost=406 size=1260 card=90)
…
IO ALN
A RITC
D
F
a n d A D
Salida de TKPROF sin t y
siÍndice: SI D
Ejemplo
e r R
E que la agregación de resultados a través de varias ejecuciones
El ejemplo de la iv IVmuestra
ndiapositiva
(filas) sele
U UN de la tabla CUSTOMERS. Son necesarios 0,12 segundos del tiempo de
está recuperando
ra c
recuperación de CPU. La sentencia se ejecuta a través de una exploración completa de la tabla
O
CUSTOMERS, como se puede observar en la operación de origen de fila de la salida.
Se debe optimizar la sentencia.
Nota: si los valores de CPU o elapsed son 0, no se definirá timed_statistics.

Salida de TKPROF con Índice: Ejemplo
...

------- ------ ----- ---------- ---------- ---------- ---------- -------
Parse 1 0.00 0,00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0,00 0,00 77 77 0 1
------- ------ ----- ---------- ---------- ---------- ---------- -------
total 4 0,01 0,01 77 77 0 1
Misses in library cache during parse: 1

Parsing user id: 85 (SH) L A
D E
------- ---------------------------------------------------
D OS
1 SORT AGGREGATE (cr=77 pr=77 pw=77 time=0 us)
77 TABLE ACCESS BY INDEX ROWID CUSTOMERS (cr=77 pr=77 pw=77 E SA
77
time=555 us cost=85 size=1260 card=90)
INDEX RANGE SCAN CUST_CUST_CITY_IDX (cr=2 pr=2 pw=2 E GR nlyฺ
time=1 us cost=1 size=0 card=90)(object id 75264)
N DE use o
C IO AL
D A RIT
F
a n d A D
Salida de TKPROF con y
sitÍndice: S I D
Ejemplo
e r R
Een la diapositiva indican que el tiempo de CPU se redujo 0,01
Los resultados n ivse muestran
que I V
segundosle
U
cuando se U Nun índice en la columna CUST_CITY. Puede que se hayan logrado los
creó
c
ra porque la sentencia utiliza el índice para recuperar los datos. Además, puesto que este
resultados
O
ejemplo está volviendo a ejecutar la misma sentencia, la mayoría de los bloques de datos ya están en
memoria. Puede lograr mejoras importantes en cuanto a rendimiento creando índices de manera
razonable. Identifique áreas para una posible mejora con la utilidad SQL Trace.
Nota: no se deben crear índices a menos que sea necesario. Los índices ralentizan el procesamiento
de los comandos INSERT, UPDATE y DELETE porque las referencias a filas se deben agregar,
cambiar o eliminar. Los índices no utilizados se deben eliminar. Sin embargo, en lugar de procesar
todo el SQL de la aplicación a través de EXPLAIN PLAN, puede utilizar la supervisión de índices
para identificar y eliminar los índices que no se utilizan o utilizar SQL Access Advisor para
identificar los índices no utilizados.

Generación de un Rastreo de Optimizador
Definir un rastreo de optimizador del evento 10053.

SQL> ALTER SESSION SET EVENTS

2> '10053 trace name context forever, level 1';
Ejecutar la sentencia que interesa.

SQL> select *
2> from hr.employees natural join hr.departments LA
3> where department_id = 10; DE
D OS
Buscar y ver el archivo de rastreo. E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Generación de un Rastreo y SI
sit deROptimizadorD
e r E que genere un rastreo de las decisiones sobre costos que realice con
nival optimizador
Se pueden indicar
U I V
el comando.
c l UN esto se utiliza para proporcionar a los Servicios de Soporte Oracle
e En ocasiones,
Ora ALTERadicional
información sobre las acciones del optimizador.
SESSION SET EVENTS
'10053 trace name context forever, level 1';
La ubicación del rastreo del optimizador en la misma ubicación que los demás archivos de rastreo y
el nombre del archivo de rastreo se pueden modificar con el comando:
ALTER SESSION SET TRACEFILE_IDENTIFIER='opt';
El archivo de rastreo no necesita formato pero es bastante grande, asegúrese de aumentar el tamaño
permitido para el rastreo en la sesión con:
ALTER SESSION SET MAX_DUMPFILE_SIZE=UNLIMITED;
Pare el rastreo en la sesión saliendo de la sesión o del comando:
ALTER SESSION SET EVENTS
'10053 trace name context off';
El archivo de rastreo contiene una gran cantidad de información que no es fácil de leer. Para obtener
más información, consulte el documento 338137.1 de My Oracle Support sobre el caso práctico de
análisis de archivos de rastreo 10053.

Prueba
El optimizador crea un plan de ejecución que realiza la acción

solicitada por la sentencia SQL. El plan de ejecución muestra

la ruta de acceso y las estimaciones de costos asociados.
Identifique las herramientas que pueden mostrar el plan de
ejecución.
a. Asesor de Ajustes SQL
b. Comando EXPLAIN PLAN
c. Perfiles SQL L A
d. Procedimiento DBMS_XPLAN.DISPLAY D E
e. SQL Plus AUTOTRACE D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Respuesta: a, d y e sit y SI D
e r R
iv SQL,IVelEprocedimiento DBMS_XPLAN.DISPLAY y el comando SQL Plus
El Asesor de Ajustes
n
AUTOTRACE l U UNun plan de ejecución. Los perfiles SQL son objetos de la base de datos que
e mostrarán
c
ra el optimizador para generar un mejor plan de ejecución. El comando EXPLAIN PLAN
utiliza
O
genera un plan de ejecución y lo coloca en una tabla de plan, pero hay que utilizar SQL o
DBMS_XPLAN.DISPLAY para visualizar el plan.

Resumen

• Describir el procesamiento de sentencias SQL

• Describir el rol del optimizador
• Ver las estadísticas de sentencias SQL
• Identificar sentencias SQL con un bajo rendimiento
• Generar y ver un plan de explicación
• Generar un informe tkprof
LA
• Generar un rastreo de optimizador D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Visión General de la Práctica 9: Uso de las
Utilidades del Plan de Ejecución
• Uso de AUTOTRACE
• Uso de EXPLAIN PLAN
• Uso de AWR
• Recuperación del plan de ejecución con DBMS_XPLAN
• Uso de tkprof
• Generación de un rastreo de optimizador A
E L
S D
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Ora
c
n
r s
le U UN
ive IVE
a
F
ity RSID
nd AD
D
C
UN DIST
N
A RIT
IO AL
E
R
DE use o
ES
G nlyฺ
A DO
S D E LA
Influencia del Optimizador
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora
Objetivos
Al finalizar esta lección, debería estar capacitado para:

• Describir el comportamiento del optimizador

• Explicar cómo pueden afectar la estadísticas al optimizador
• Describir cómo afectan las estructuras de datos al
optimizador
• Ajustar los parámetros para influir en el optimizador
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Funciones del Optimizador de Consulta
Consulta analizada
(desde el analizador)
Transformador
de consulta Consulta
transformada
Estimador Diccionario
Estadísticas
Consulta y L A
estimaciones D E
Generador
D OS
SA
del plan
E
E GR nlyฺ
Plan de consulta
(al generador de origen de fila) N DE use o
C IO AL
D A RIT
F
a n d A D
Funciones del Optimizador y SI
sit deRConsulta D
e r
El optimizadorn iv IVE
(denominado también “optimizador de consulta”) realiza sus tareas durante la fase de
U N
U de SQL. La mayoría de estas tareas se realizan sólo durante un análisis
le procesamiento
análisis del
r a
pesado cporque la salida del optimizador, el plan de ejecución, se almacena con el cursor en el pool
O
compartido. Las operaciones del optimizador incluyen:
• Transformación de consultas
• Estimación
• Generación de planes
Esta ilustración muestra la introducción de una consulta en el transformador de consulta. A
continuación, la consulta transformada se envía al estimador. Las estadísticas se recuperan del
diccionario y la consulta y las estimaciones se envían al generador del plan. El generador del plan lo
devuelve al estimador para su comparación con otros planes o envía el plan de consulta al generador
de origen de fila.
El optimizador prueba varias rutas de acceso, órdenes de unión y métodos de unión para buscar el
mejor plan. El optimizador se puede ver influenciado mediante la estructura de sentencias SQL,
estadísticas, estructuras de datos (índices, tipos de tablas) y parámetros. Estas influencias determinan
el orden en el que se prueban las diferentes combinaciones. Puesto que el optimizador de tiempo de
ejecución se ejecuta durante un tiempo limitado, puede que no pruebe todas las combinaciones.

Funciones del Optimizador de Consulta (continuación)
Transformación de Consultas
La entrada para el transformador de consulta es una consulta analizada, representada por un juego de
bloques de consultas. Un bloque de consulta se puede definir como una consulta completa, una
subconsulta anidada o una vista no fusionada. Los bloques de consultas están anidados o
interrelacionados entre sí. La forma de la consulta determina el modo en el que los bloques de
consultas se interrelacionan entre sí. El objetivo principal del transformador de consulta es

determinar si resulta ventajoso el cambio de la forma de la consulta para que sea posible la
generación de un mejor plan de consulta.
Estimación
El estimador genera tres tipos de medidas:
• Selectividad
• Cardinalidad
• Costo
Estas medidas están relacionadas entre sí y una se deriva de otra. El objetivo final del estimador
L
consiste en calcular el costo global de un plan concreto. Si las estadísticas están disponibles, el
A
D E
estimador las utilizará para calcular las medidas. El optimizador calculará aproximadamente los
S
DO
costos de cada plan de ejecución candidato según las estadísticas disponibles para el mismo. En
A
ES
ausencia de estadísticas, es posible que el optimizador realice ejemplos dinámicos o vuelva a los
R
precisión del costo estimado para el plan. E G nlyฺ
valores por defecto codificados. La calidad de las estadísticas está directamente relacionada con la
Generación de Planes N DE use o

C IO AL
A RIT
La función principal del generador del plan es la de probar diferentes planes posibles para una
D
F UN DIST
consulta concreta y seleccionar el que tenga el costo más bajo. Hay muchos planes diferentes que son
posibles debido a las distintas combinaciones de diferentes rutas de acceso, métodos de unión y
a nd AD
órdenes de unión que se pueden utilizar para acceder a los datos y procesarlos de distintas formas y
s ity RSID
producir los mismos resultados.
r
ive IVE
El plan de una consulta se establece generando en primer lugar subplanes para cada subconsulta
n
le U UN
anidada y vista no fusionada. Cada subconsulta anidada o vista no fusionada se representa por un
c
Ora
bloque de consulta independiente. Los bloques de consultas se optimizan por separado en un orden
ascendente. Es decir, el bloque de consulta interior se optimiza primero y se genera un subplan para
el mismo. El bloque de consulta exterior, que representa toda la consulta, se optimiza el último.
El generador del plan explora varios planes para un bloque de consulta probando diferentes rutas de
acceso, métodos de unión y órdenes de unión. El número de planes posibles para un bloque de
consulta es proporcional al número de elementos de unión en la cláusula FROM. Este número
aumenta de forma factorial con el número de elementos de unión. El generador del plan utiliza un
corte interno para reducir el número de planes que prueba a la hora de buscar el que tiene el costo
más bajo. El corte se basa en el costo del mejor plan actual. Si el mejor costo actual es alto, el
generador del plan lo intentará más detenidamente (es decir, explorará más planes alternativos) para
buscar un plan mejor con un costo más bajo. Si el mejor costo actual es bajo, el generador del plan
terminará la búsqueda rápidamente, porque otra mejora del costo no será significativa. El corte
funciona bien si el generador del plan empieza por un orden de unión inicial que produzca un plan
con un costo cercano a óptimo.
Nota: la diferencia principal entre el optimizador de consulta y el optimizador automático de ajustes
es el tiempo permitido para la comprobación de planes alternativos. El número de planes que puede
comprobar el optimizador de consulta es limitado.

Selectividad
• La selectividad representa una fracción de filas de un

origen de filas.
– La selectividad afecta a las estimaciones del costo
de E/S.
– La selectividad afecta al costo de ordenación.
• La selectividad está en un rango de valor de 0,0 a 1,0.
• Cuando las estadísticas están disponibles, el estimador
las utiliza para estimar la selectividad.
L A
• Cuando no hay estadísticas disponibles, el estimador D E
utiliza los valores por defecto o ejemplos dinámicos. OS
• Con los histogramas de columnas que contienen S AD
datos
R E
E G
sesgados, los resultados constituyen estimacionesn l yฺ de
selectividad adecuadas. DE se o N Lu
I O
D AC RITA
F
a n d A D
Selectividad y
sit RSI D
e r E de filas de un origen de fila que representa una fracción de las filas
La selectividadn iv el Inúmero
calcula V
U UN de fila. El juego de filas puede ser una tabla base, una vista o el resultado
devueltasledesde un origen
c
ra unión o un operador GROUP BY. La selectividad depende del predicado, como last_name
de una
O
= 'Smith', o de una combinación de predicados, como last_name = 'Smith' AND salary >
2000. La selectividad de un predicado indica cuántas filas de un origen de fila pasarán las prueba de
predicado.
# rows satisfying a condition
Selectivity = -----------------------------
Total # of rows
Cuando hay estadísticas disponibles, el estimador las utiliza para estimar la selectividad. Por
ejemplo, para un predicado de igualdad (last_name = 'Smith'), la selectividad se define en el
recíproco del número de n valores distintos de last_name, porque la consulta selecciona filas que
contienen uno de n valores distintos. Si hay un histograma disponible en la columna last_name, el
estimador lo utiliza en lugar del número de valores distintos. Si no hay ninguna estadística
disponible, el optimizador utiliza ejemplos dinámicos o un valor interno por defecto, en función del
valor del parámetro de inicialización OPTIMIZER_DYNAMIC_SAMPLING. La suposición de un
valor por defecto puede dar lugar al uso de un plan menos óptimo.

Cardinalidad y Costo
• La cardinalidad representa el número de filas en un origen

de fila.
• El costo representa las unidades de trabajo o recursos que
se utilizan.
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Cardinalidad y Costo sit y SI D
e r R
E de filas en un origen de fila. Aquí, el origen de fila puede ser
Cardinalidad:n iv IelVnúmero
representa
una tablale U UNo el resultado de una unión o un operador GROUP BY. Si se realiza una
base, una vista
c
ra en una tabla, ésta será el origen de fila y la cardinalidad será el número de filas de la tabla.
selección
O
Nota: no todos los orígenes de fila posibles se tienen en cuenta aquí.
Costo: representa el número de unidades de trabajo (o recursos) que se utilizan. El optimizador de
consulta utiliza la E/S de disco, el uso de CPU y el uso de memoria como unidades de trabajo. Así, el
costo que utiliza el optimizador de consulta representa una estimación del número de E/S de disco y
la cantidad de CPU y de memoria utilizada en la realización de una operación. La operación puede
consistir en la exploración de una tabla, el acceso a filas desde una tabla mediante un índice, la unión
de dos tablas o la ordenación de un origen de fila. El costo de un plan de consulta es el número de
unidades de trabajo que se supone que se van a producir cuando se ejecuta la consulta y se produce el
resultado.
La ruta de acceso determina el número de unidades de trabajo necesarias para obtener los datos de
una tabla base. La ruta de acceso puede ser una exploración de tabla, una exploración completa
rápida de índice o una exploración de índice.
El costo de varios recursos se normaliza en una unidad correspondiente al costo de una lectura de
bloque individual. A continuación, se comparan los costos para diferentes planes de ejecución. Las
unidades de trabajo son estimaciones normalizadas, no medidas físicas, pero las unidades de trabajo
son proporcionales al tiempo.

Cambio del Comportamiento del Optimizador
El optimizador se verá influenciado por:

• Construcción de sentencias SQL

• Estructura de datos
• Estadísticas
• Opciones de gestión de planes SQL
• Parámetros de sesión
• Parámetros del sistema
L A
• Indicaciones D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Cambio del Comportamiento y D
sit RdelSIOptimizador
e r Eseleccione la sentencia SQL correcta y genere el mismo plan de
Lo ideal es queneliv V
optimizador
U
ejecucióneóptimo. ElU N I
optimizador comienza con la creación de la sentencia SQL como guía para
a c l
seleccionar rutas de acceso. Aunque una sentencia SQL pueda conseguir el mismo resultado
O r
independientemente de si se escribe como una intersección, una unión externa o una subconsulta
correlacionada, cada formulario de esta sentencia hará que las rutas de acceso se evalúen en un orden
diferente y que, posiblemente, generen un plan de explicación diferente.
La siguiente guía principal para el optimizador es la estructura de datos. El comportamiento del
optimizador es siempre un juego de decisiones basadas en el costo relativo. Algunas rutas de acceso
son más eficaces que otras. La ruta de acceso disponible depende mucho de la estructura de datos. La
adición o eliminación de índices, el cambio de una tabla organizada en pilas a una tabla organizada
por índices son ejemplos de cambios en la estructura de datos.
Las estadísticas juegan un papel muy importante en las selecciones del optimizador. Si las
estadísticas no reflejan el estado actual de los objetos de datos, el optimizador no puede tomar
decisiones precisas. Aunque en ocasiones la actualización de las estadísticas puede provocar que
algunas sentencias empeoren su rendimiento (regresión).
En este punto, las influencias necesitan muy poca intervención del DBA. Las sentencias tienen la
codificación correcta, la estructura de datos es relativamente fija y las estadísticas se basan en el
tamaño de los objetos y se pueden actualizar automáticamente según sea necesario. El resto de estas
influencias son formas de cambiar el comportamiento del optimizador y requieren diferentes niveles
de intervención del DBA. Se organizan en orden de prioridad.
.
Cambio del Comportamiento del Optimizador (continuación)
Las opciones de gestión de planes SQL se abordan en la lección Gestión del Rendimiento SQL.
Los parámetros del sistema, definidos normalmente en el archivo de parámetros de inicialización,
controlan varios de los factores utilizados en los cálculos de costos del optimizador. El peligro de
utilizar los parámetros del sistema para ajustar SQL es que mientras que al definir un parámetro
concreto se puede mejorar el rendimiento de un juego de sentencias SQL, también se puede afectar al
rendimiento global de la aplicación o la instancia. Los parámetros del sistema se aplican a toda la
instancia, incluido el SQL recursivo que la instancia realiza en su nombre. A menudo, los
parámetros del sistema se definen en diferentes valores en una sesión durante la prueba, para
comparar el rendimiento antes de que el parámetro se defina en el nivel de sistema.
Las indicaciones aplicadas a la sentencia SQL son sugerencias para el optimizador y afectan a las
decisiones de éste. Puesto que el cambio del código SQL normalmente no está disponible para el
usuario como DBA, tampoco suele estar disponible el cambio de construcción de sentencias o la
adición de indicaciones.
L A
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
cle U UN
Ora

Estadísticas del Optimizador
El optimizador depende de varias estadísticas para determinar

un plan de ejecución óptimo para una sentencia SQL.

• La mayoría de las estadísticas se recopilan
automáticamente y se controlan mediante las preferencias
de estadísticas.
– Estadísticas de objetos
– Estadísticas del diccionario
• Otras estadísticas sólo se recopilan manualmente. L A
– Estadísticas sobre objetos fijos D E
– Estadísticas del sistema operativo D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Estadísticas del Optimizador y
sit RSI D
e r
El optimizadorn iv deIVlasEestadísticas de objetos relacionadas con los objetos a los que hace
depende
referencia
l U N y sus subobjetos e índices. Las estadísticas del diccionario son
ela sentenciaUSQL
c
ra para la optimización de SQL recursivo. Ambos juegos de estadísticas se supervisan y
importantes
O
refrescan mediante la tarea de mantenimiento automático Optimizer Statistics Gathering.
Normalmente, las estadísticas del diccionario no cambian rápidamente. Estos dos juegos de
estadísticas se pueden refrescar también de forma manual.
Algunos proveedores de aplicaciones pueden proporcionar sus propias rutinas de recopilación de
estadísticas y prefieren que la recopilación automática de estadísticas esté desactivada.
Las estadísticas sobre objetos fijos y las estadísticas del sistema operativo se deben recopilar
manualmente. Las estadísticas sobre objetos fijos, que son las vistas de rendimiento dinámico, no
cambian mucho a menos que se produzcan cambios de carga de trabajo, de modo que éstos se puedan
recopilar durante un período de carga de trabajo típico. Un cambio de carga de trabajo se puede
producir al desplegar una nueva aplicación o al agregar varios usuarios nuevos. Las estadísticas de
objetos, del diccionario y de objetos fijos se pueden recopilar manualmente desde un trabajo
programado de la página Gather Optimizer Statistics de EM o con los procedimientos del paquete
DBMS_STATS.

Estadísticas del Optimizador (continuación)
Las estadísticas del sistema operativo se recopilan estableciendo horas de inicio y finalización
manualmente o para un período determinado. Estas estadísticas se pueden recopilar también con las
opciones WORKLOAD o NOWORKLOAD. Las estadísticas del sistema operativo se deben recopilar de
forma periódica mediante la opción WORKLOAD durante la ejecución de una carga de trabajo típica.
Utilice el procedimiento GATHER_SYSTEM_STATS del paquete DBMS_STATS. Las estadísticas de
NOWORKLOAD se recopilan por defecto al iniciar la instancia. Para obtener más información,
consulte Oracle Database PL/SQL Packages and Types Reference (Referencia de Paquetes y Tipos
PL/SQL de Oracle Database).
L A
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
c le U UN
Ora

Estadísticas Ampliadas
El optimizador necesita estadísticas adicionales en algunos

casos.
• Estadísticas de varias columnas para columnas
relacionadas (grupos de columnas)
– Recopilar estadísticas sobre un grupo de columnas
– Para predicados complejos
– Sólo para predicados de igualdad
• Estadísticas de expresión para índices basados en L A
funciones D E
S
– Recopilar estadísticas sobre una expresión A DO
– Para expresiones utilizadas en predicados RE
S
– Crea una columna virtual E G nlyฺ
E o D use
IO ALN
A RITC
D
F
a n d A D
Estadísticas Ampliadas y
sit RSI D
e r E la selectividad para las columnas relacionadas sin estadísticas sobre
El optimizadorn noivpuede calcular
V
U I
todas las e
c l UNcolumnas
columnas implicadas. Anteriormente, estas estadísticas sólo estaban disponibles cuando
había
O r aun índice de varias sobre las columnas o en casos limitados por la creación dinámica
de ejemplos (DYNAMIC_SAMPLING >= 4). En Oracle Database 11g, puede crear un grupo de
columnas para proporcionar estas estadísticas al optimizador. Sin embargo, los grupos de columnas
sólo funcionan con predicados de igualdad. Las estadísticas de grupo de columnas permiten
recopilar, almacenar y utilizar las siguientes estadísticas para capturar la dependencia funcional entre
dos o más columnas: el número de valores distintos, el número de valores nulos, los histogramas de
frecuencia y la densidad. Si se utiliza una función para transformar un valor de columna para
utilizarlo en un predicado, las estadísticas de la columna transformada pueden ser muy diferentes.
Puede crear estadísticas de expresión para la expresión. Estas estadísticas de expresión se pueden
crear con o sin un índice basado en funciones. Las estadísticas para funciones basadas en índices se
recopilan por defecto.
Ambos métodos de estadísticas ampliadas crean una columna virtual para la tabla y las estadísticas se
recopilan en dicha columna. La función DBMS_STATS.CREATE_EXTENDED_STATS se utiliza
para crear la columna virtual y el procedimiento GATHER_TABLE_STATS tiene la sintaxis
necesaria para recopilar las estadísticas en esta columna virtual. Para obtener más información sobre
los procedimientos utilizados para crear y mantener estadísticas ampliadas, consulte la sección
DBMS_STATS de Oracle Database PL/SQL Packages and Types Reference (Referencia de Paquetes
y Tipos PL/SQL de Oracle Database) y la guía Oracle Database Performance Tuning Guide (Guía de
Ajuste de Rendimiento de Oracle Database).
Parámetros del Optimizador
Los parámetros del optimizador se pueden definir en:

• El nivel de sistema
• El nivel de sesión
Puede visualizar los valores de parámetro del optimizador para:
• El sistema con V$SYS_OPTIMIZER_ENV
• Las sesiones con V$SESS_OPTIMIZER_ENV
• Un plan específico mediante V$SQL_OPTIMIZER_ENV unido
con V$SQL o V$SQLAREA E LA
S D
DO
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
Uy/oNsusD
Copyright © 2010, Oracle T los derechos reservados.
ISTodos
filiales.
F
a nd AD
Parámetros del Optimizador
r s ity RSID
El optimizadorn seiv
e VEpor el juego de parámetros del entorno. Unos parámetros afectan
ve afectado
U N I y otros le afectan indirectamente. Todos estos parámetros se pueden
e
directamente al U
optimizador
cenl el nivel de sistema (instancia) y algunos de ellos se pueden definir en el nivel de sesión.
r a
definir
O
Los valores de los parámetros del sistema actuales se pueden visualizar mediante
V$SYS_OPTIMIZER_ENV y los parámetros a nivel de sesión mediante
V$SESS_OPTIMIZER_ENV.
Los parámetros del optimizador que se utilizan para crear un plan SQL concreto se pueden visualizar
mediante V$SQL_OPTIMIZER_ENV unido con V$SQL en (HASH_VALUE, CHILD_ADDRESS)
o con V$SQLAREA en (HASH_VALUE, ADDRESS).

Control del Comportamiento del Optimizador con
Parámetros
El comportamiento del optimizador se puede controlar con
los siguientes parámetros de inicialización:

• CURSOR_SHARING
• DB_FILE_MULTIBLOCK_READ_COUNT (ajuste
automático)
• OPTIMIZER_INDEX_CACHING
• OPTIMIZER_INDEX_COST_ADJ
• PGA_AGGREGATE_TARGET L A
D E
• OPTIMIZER_MODE
D OS
• OPTIMIZER_FEATURES_ENABLE SA
G RE yฺ
E E onl
N D use
C IO AL
D A RIT
F
a n d A D
Control del Comportamiento y I D
sit RdelSOptimizador con Parámetros
v e r E
CURSOR_SHARING:
U ni esteN I V
parámetro convierte los valores literales de las sentencias SQL en
variablesle LaU
a c ligadas.
los rplanes
conversión de los valores mejora el uso compartido del cursor y puede afectar a
de ejecución de las sentencias SQL. El optimizador genera el plan de ejecución basándose
Ola presencia de las variables ligadas y no de los valores literales. Para obtener más información
en
sobre este tema, consulte la lección Ajuste del Pool Compartido.
DB_FILE_MULTIBLOCK_READ_COUNT (ajuste automático)
Este parámetro especifica el número de bloques que se leen en una única E/S durante una
exploración completa de la tabla o una exploración completa rápida de índice. El optimizador utiliza
el valor de DB_FILE_MULTIBLOCK_READ_COUNT especificado explícitamente para calcular el
costo de las exploraciones de tablas completas y de las exploraciones completas rápidas de índice.
Los valores superiores originan un menor costo estimado para exploraciones de tablas completas y
pueden dar lugar a que el optimizador seleccione una exploración completa de la tabla sobre una
exploración de índice. En Oracle Database 11g, este parámetro se ajusta automáticamente y se define
cuando se inicia la instancia si no se especifica explícitamente. El valor automático se utiliza para
determinar el tamaño de la solicitud de lectura para las exploraciones de tablas completas y las
exploraciones completas rápidas de índice. Cuando se define el valor automático, el optimizador
utiliza un valor de 8. Incluso si el valor por defecto es grande, el optimizador no utilizará planes con
exploraciones de tablas completas si no define explícitamente este parámetro.

Control del Comportamiento del Optimizador con Parámetros (continuación)
OPTIMIZER_INDEX_CACHING
Este parámetro controla el costo de una sonda de índice junto con un bucle anidado. El rango de
valores de 0 a 100 para OPTIMIZER_INDEX_CACHING indica el porcentaje de bloques de índice
en la caché de buffers, que modifica las suposiciones del optimizador sobre la caché de índice para
los bucles anidados y los iteradores de listas IN. De un valor de 100 se deduce que el 100% de los
bloques de índice pueden estar en la caché de buffers y que el optimizador ajusta el costo de una
sonda de índice o bucle anidado en consecuencia. Actúe con cautela a la hora de utilizar este
parámetro porque los planes de ejecución pueden cambiar a favor del uso de índices.
OPTIMIZER_INDEX_COST_ADJ
Este parámetro se puede utilizar para ajustar el costo de las sondas de índice. Su rango de valores
oscila entre 1 y 10000. El valor por defecto es 100, lo que significa que los índices se evalúan como
una ruta de acceso en función del modelo de costo normal. Un valor de 10 indica que el costo de una
ruta de acceso de índice es el 10% del costo normal. La definición de este parámetro influye en el
optimizador cuando se tiene en cuenta un índice como parte del plan de ejecución. A
PGA_AGGREGATE_TARGET E L
S D
A DO
Este parámetro controla de forma automática la cantidad de memoria asignada para las ordenaciones
y uniones hash cuando el parámetro WORKAREA_SIZE_POLICY se define en AUTO. La asignación
R ES
de mayores cantidades de memoria para las ordenaciones y uniones hash reducen el costo del
E G nlyฺ
optimizador de estas operaciones. Este parámetro, si se define en true, permite que el optimizador
DE use o
de consulta calcule el costo de una transformación estrella para las consultas estrella. La
N
IO AL
transformación estrella combina los índices de bitmap en las distintas columnas de la tabla de hechos.
C
OPTIMIZER_MODE D A RIT
F UN DIST
El parámetro OPTIMIZER_MODE define el enfoque que utiliza el optimizador para determinar cuál
a nd AD
es el mejor plan. Consulte las siguientes diapositivas para obtener más información.
s ity RSID
OPTIMIZER_FEATURES_ENABLE y Parámetros con Subrayado (_)
r
n ive IVE
El parámetro OPTIMIZER_FEATURES_ENABLE controla un juego de parámetros del optimizador,
le U UN
la mayoría de los cuales son parámetros con subrayado (_). Estos parámetros se pueden definir de
c
Ora
forma independiente, aunque no se recomienda. En general, estos parámetros con subrayado activan
o desactivan determinadas funciones del optimizador. Los Servicios de Soporte Oracle recomiendan
que los clientes no definan estos parámetros con subrayado de forma independiente, sino sólo a
través del parámetro OPTIMIZER_FEATURES_ENABLE.
Otros Parámetros de Inicialización
La vista V$SES_OPTIMIZER_ENV muestra todos los parámetros de sesión utilizados por el
optimizador de alguna forma. La mayoría de estos parámetros son parámetros ocultos. Muchos de
ellos están relacionados con la consulta paralela o las vistas materializadas. Existen parámetros
relacionados con la gestión de planes SQL que se tratarán en la lección Gestión del Rendimiento
SQL. Puede visualizar todos los parámetros de sesión con el siguiente comando:
SELECT * FROM V$SES_OPTIMIZER_ENV;

Activación de las Funciones del
Optimizador de Consulta
• El comportamiento del optimizador se puede definir en
versiones anteriores de la base de datos.

• El parámetro de inicialización
OPTIMIZER_FEATURES_ENABLE se puede definir en
valores de versiones diferentes de la base de datos
(como 8.1.7 o 10.0.0).
• Ejemplo:
OPTIMIZER_FEATURES_ENABLE='9.2.0'; L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Activación de las Funciones y
sit R I D
SOptimizador
del de Consulta
e r
U niv NIVE
El parámetro OPTIMIZER_FEATURES_ENABLE aglutina al optimizador de consulta. Este
parámetro
c lese de U para activar una serie de funciones relacionadas con el optimizador,
puede utilizar
O r a
dependiendo la versión. Acepta una lista de valores de cadena válidos que corresponden a los
números de versiones, como 8.0.4, 8.1.7 y 9.2.0.
El parámetro OPTIMIZER_FEATURES_ENABLE le permite actualizar el servidor de Oracle pero
mantiene el comportamiento anterior del optimizador de consulta después de la actualización. Por
ejemplo, al actualizar el servidor de Oracle de la versión 8.1.5 a la 8.1.6, el valor por defecto del
parámetro OPTIMIZER_FEATURES_ENABLE cambia de 8.1.5 a 8.1.6. Esta actualización da lugar
a la activación por parte del optimizador de consulta de las funciones de optimización basadas en
8.1.6 en lugar de 8.1.5. Por motivos de estabilidad del plan o compatibilidad con versiones anteriores,
puede que no desee que cambien los planes de consultas a raíz de las nuevas funciones del
optimizador en una nueva versión. En este caso, puede definir el parámetro
OPTIMIZER_FEATURES_ENABLE en una versión anterior.
Por ejemplo, el siguiente valor activa el uso de las funciones del optimizador en la generación de
planes de consultas en Oracle9i, Versión 2:
OPTIMIZER_FEATURES_ENABLE='9.2.0';

Uso de Indicaciones
Indicaciones
• Son directivas (sugerencias) para el optimizador

• Requieren cambios en el código
• Son útiles para probar rutas de acceso específicas
• Se deben mantener a través de actualizaciones
SELECT /*+ INDEX (tablename indexname) */ …

L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Uso de Indicaciones sit y SI D
e r R
E Las indicaciones pueden hacer que el optimizador seleccione un
iv el optimizador.
Son sugerenciasnpara
I V
plan que e U UNLaunindicación
él estima como plan de costo mayor. Para utilizar las indicaciones, debe tener permiso
parara cl el código.
cambiar sigue siempre el verbo de la sentencia SQL (normalmente la
O
palabra clave SELECT). La siguiente indicación indica al optimizador que sólo tenga en cuenta un
índice concreto:
SELECT /*+ INDEX (tablename indexname) */ …
Hay más de 50 indicaciones. Cada una puede tener uno o más parámetros. Cada una implica el
cambio, la comprobación y el mantenimiento del código. El DBA puede utilizar indicaciones para
forzar un cambio en una sentencia para probar un plan de ejecución. Pero no debe utilizar
indicaciones en el código de producción. Los cambios en el entorno, las estadísticas, la versión de la
base de datos y hardware pueden hacer que la indicación sea obsoleta o perjudicial. Por ejemplo, si
cambia el nombre del índice, en el ejemplo anterior, habría que cambiar el código, probarlo y
propagarlo.
Las indicaciones pueden ser útiles en un entorno de desarrollo y prueba para probar el rendimiento de
una determinada ruta de acceso, pero el uso de indicaciones implica un compromiso con el
mantenimiento de la codificación cuando se aplican al código de producción. Realice la prueba
utilizando indicaciones y, a continuación, utilice otras técnicas para gestionar los planes de ejecución
SQL, como el Asesor de Ajustes SQL y las líneas base de plan SQL.
Para obtener más información sobre las indicaciones, consulte la guía Oracle Database Performance
Tuning Guide (Guía de Ajuste del Rendimiento de Oracle Database 11g).

Influencia en el Enfoque del Optimizador
El enfoque del optimizador consiste en evaluar conforme a los

siguientes factores:
• Mejor rendimiento (por defecto)
• Respuesta más rápida
Se puede definir el parámetro OPTIMIZER_MODE para cambiar
el enfoque:
• ALL_ROWS (valor por defecto)
• FIRST_ROWS[_n] E LA
D
OPTIMIZER_MODE se puede definir en varios niveles
D OS
• Sistema: ALTER SYSTEM SET…
E SA
• Sesión: ALTER SESSION SET… E GR nlyฺ
E o
N D use */
• Sentencia (indicación): /*+ FIRST_ROWS_10
IO AL
A RITC
D
F
a n d A D
Influencia en el Enfoque y
sit del R SI D
Optimizador
e r E para que seleccione planes que produzcan las primeras n filas más
ivel optimizador
Se puede influirnen I V
rápidas ole U UNpara el juego completo de filas devuelto. Con el método ALL_ROWS por
el menor costo
c
ra el optimizador busca el plan de costo más bajo independientemente del tiempo de respuesta.
defecto,
O
Con el método de respuesta rápida, el optimizador explora distintos planes y calcula el costo para
producir las primeras n filas para cada plan. Elige el plan que produce las primeras n filas al costo
más bajo. Recuerde que con la optimización de respuesta rápida, puede que un plan que produce las
primeras n filas al costo más bajo no sea el óptimo para producir todo el resultado. Si la necesidad es
obtener todo el resultado de una consulta, no debe utilizar la optimización de respuesta rápida. En su
lugar, utilice la indicación o el valor de parámetro ALL_ROWS.
Los parámetros y las indicaciones tienen las mismas palabras clave: ALL_ROWS y FIRST_ROWS_n.
El valor de n puede ser 1, 10, 100 o 1000. El valor de FIRST_ROWS sigue estando disponible sólo
para asegurar la compatibilidad con versiones anteriores. Si el parámetro OPTIMIZER_MODE no se
define explícitamente, se le aplicará por defecto el valor ALL_ROWS.
A nivel de sesión, el enfoque del optimizador definido a nivel de instancia se puede anular con el
comando ALTER SESSION. Una indicación a nivel de sentencia anula el enfoque del optimizador.

Optimización de las Sentencias SQL
• Mejor rendimiento
– Tiempo necesario para terminar la solicitud

– Adecuado para:
— Procesamiento por lotes
— Aplicaciones de informe
• Respuesta rápida
– Tiempo para recuperar las primeras filas
– Adecuado para: L A
— Aplicaciones interactivas D E
— Aplicaciones GUI o basadas en web D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSSQL
Optimización de las Sentencias I D
e r
U niv N
Seleccione un objetivo para
I VelEoptimizador en función de las necesidades de la aplicación:
• Parale
c U ejecutadas por lotes (como las aplicaciones de Oracle Reports), optimice
las aplicaciones
a
Or porque el usuario que iniciaElla rendimiento
para un mejor rendimiento. suele ser más importante en aplicaciones por lotes
aplicación sólo está interesado en el tiempo necesario para
terminarla. El tiempo de respuesta es menos importante porque el usuario no examina los
resultados de las sentencias individuales mientras la aplicación se está ejecutando.
• Para las aplicaciones interactivas (como aplicaciones Oracle Forms o consultas de SQL*Plus),
optimice para un tiempo de respuesta mejor. El tiempo de respuesta suele ser importante en
aplicaciones interactivas porque el usuario interactivo está en espera de ver la primera fila o las
primeras filas a las que accede la sentencia. Puede definir el número de filas que se deben
recuperar primero con el modo del optimizador de FIRST_ROWS_n, donde n especifica el
número de filas y se puede personalizar para las distintas páginas de la aplicación.
Nota: el modo FIRST_ROWS_n se basa únicamente en los costos y es sensible al valor de n. Con
valores pequeños de n, el optimizador tiende a generar planes que consisten en uniones de bucles
anidados con consultas de índice. Con valores grandes de n, el optimizador tiende a generar planes
que consisten en uniones hash y exploraciones de tablas completas.

Prueba
El optimizador calcula siempre el costo de una exploración de

tabla completa a partir de las estadísticas de la tabla y, a

continuación, prueba otras rutas de acceso para encontrar un
plan de costo más bajo. Uno sobre el total de valores distintos
de una columna (1/valores distintos) se denomina:
a. Cardinalidad
b. Costo
c. Filtro de predicado LA
d. Selectividad D E
O S
e. Estadísticas ampliadas A D
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Respuesta: d y
sit RSI D
e r
U niv NIVE
c le U
Or a

Rutas de Acceso
• Exploración de tabla completa

• Exploración de ID de fila
• Exploración de índice
• Exploración de tabla de ejemplo
• Exploración de cluster
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Rutas de Acceso y
sit RSI D
e r E por las que los datos se recuperan de la base de datos. Cualquier fila
niv sonNlasIVvías
Las rutas de acceso
U
localizar y U
se puedele recuperar con uno de los métodos mencionados en la diapositiva. Las rutas de
r a
acceso c
son las vías por las que los datos se recuperan de la base de datos.
O
El método de acceso debe corresponder a las estructuras de datos que se utilicen en la base de datos.
Las tablas y los índices son los más comunes, pero los clusters y las tablas organizadas por índices
(IOT) se utilizan en muchos casos. Incluso los índices tienen diferentes estructuras, árbol B*, bitmap
y dominio. (La estructura de índice de dominio y los métodos de acceso los define el usuario y están
fuera del alcance de este curso.)
En general, las rutas de acceso de índice se deben utilizar para sentencias que recuperan un pequeño
subjuego de filas de tabla, mientras que las exploraciones completas son más eficaces cuando se
accede a gran parte de la tabla. Las aplicaciones de procesamiento de transacciones en línea (OLTP),
que constan de sentencias SQL de corta ejecución con alta selectividad, se suelen caracterizar por el
uso de rutas de acceso de índice. Por otro lado, los sistemas de toma de decisiones (DSS) tienden a
utilizar exploraciones completas de los objetos relevantes. Las estructuras de IOT y clusters se
utilizan en casos concretos.
La exploración de tabla de ejemplo devuelve un ejemplo aleatorio de las filas o bloques de la tabla.
Este método se utiliza para la creación de ejemplos de datos en DSS y las aplicaciones de minería de
datos.
Nota: esta clase incluye un subjuego de las operaciones de ruta de acceso más utilizadas.
Selección de una Ruta de Acceso
El optimizador selecciona una ruta de acceso en función de los

siguientes factores:
• Rutas de acceso disponibles para la sentencia
• Costo estimado de ejecución de la sentencia, con cada ruta
de acceso o combinación de rutas
• Presencia de indicaciones en la sentencia SQL
• Presencia de esquemas SQL (obsoleto)
• Presencia de perfil SQL E LA
D
• Presencia de planes de línea base SQL OS
S AD
G RE yฺ
E E onl
N D use
C IO AL
D A RIT
F
a n d A D
Selección de una Ruta y
t Acceso
side SI D
e r R
E el optimizador determina primero las rutas que están disponibles
examinandoU
iv ruta de
Para seleccionar una
lasncondiciones
I V acceso,
l e U N la cláusula WHERE de la sentencia y su cláusula FROM. A
de
r a c
continuación, el optimizador genera un juego de posibles planes de ejecución con rutas de acceso
O
disponibles y estima el costo de cada plan, con las estadísticas para el índice, las columnas y las
tablas que puedan acceder a la sentencia. Por último, el optimizador selecciona el plan de ejecución
con el costo estimado más bajo.
Al seleccionar una ruta de acceso, el optimizador se verá influenciado por lo siguiente:
• Indicaciones del optimizador: la selección del optimizador entre las rutas de acceso
disponibles se puede sustituir por indicaciones. (El uso de indicaciones implica el cambio de
código.)
• Esquemas SQL: son indicaciones almacenadas independientemente de la sentencia. Los
esquemas son una función obsoleta,
• Estadísticas: por ejemplo, si una tabla no se ha analizado desde que se creó y las estadísticas de
la tabla muestran que es pequeña, el optimizador utilizará una exploración de tabla completa.
Las columnas LAST_ANALYZED y BLOCKS de la tabla ALL_TABLES reflejan las estadísticas
que ha utilizado el optimizador.
• Perfiles SQL: son estadísticas adicionales generadas por el analizador de ajustes SQL y que
influirán en el optimizador para producir un plan mejor.
• Planes de línea base SQL: si el plan que produce el optimizador no coincide con un plan de la
línea base de plan, se utilizará el plan de la línea base con el menor costo. Para obtener más
información, consulte la lección Gestión del Rendimiento SQL.
Nota: los parámetros de sesión NLS_SORT y NLS_COMP influirán en la ruta de acceso.

Exploraciones de Tablas Completas
• Falta de índice • Llamadas de E/S multibloque

• Gran cantidad de datos • Todas las filas por debajo de

• Tabla pequeña la marca de agua superior
select * from emp where ename = 'KING';

--------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
--------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 22 | 2 |
|* 1 | TABLE ACCESS FULL | EMP | 1 | 22 | 2 |
--------------------------------------------------------------------
L A
--------------------------------------------------- D E
1 - filter("EMP"."ENAME"='KING‘)
D OS
E SA Límite
E GR nlyฺ superior
B B B B ...DEB Be oB B B
I O N L us
D AC RITA
F
a n d A D
Exploraciones de Tablas y
sit CompletasSI D
e r R
E las filas de una tabla y filtra las que no cumplen los criterios de
niv NleeIVtodas
Este tipo de exploración
U
leUnatiene
selección.
c U de tabla completa es uno de los primeros métodos de acceso que el
exploración
O r a
optimizador en cuenta. Suele ser uno de los métodos más caros; sin embargo, una exploración
de tabla completa puede ser el método de acceso más eficaz, especialmente cuando se debe acceder
una gran parte de la tabla o cuando se pueden utilizar servidores en paralelo.
Las exploraciones de tabla completa se utilizarán cuando una tabla no tiene un índice en la columna
del predicado, las estadísticas indican que se debe acceder a una gran parte de la tabla o la tabla es
pequeña. Durante una exploración de tabla completa, se exploran todos los bloques formateados de la
tabla que están por debajo de la marca de agua superior, incluso si los bloques están vacíos. La marca
de agua superior indica la cantidad de espacio formateado para recibir datos. Se examinan todas las
filas para determinar si cumplen la cláusula WHERE de la sentencia y se descartan las filas que no son
necesarias.
Cuando la base de datos Oracle realiza una exploración de tabla completa, los bloques se leen de
forma secuencial. Debido a que los bloques son adyacentes, se podrán utilizar las llamadas de E/S
superiores a un único bloque para acelerar el proceso. Con las lecturas multibloque, se puede realizar
una exploración de tabla completa de forma más eficaz.

Exploraciones de Tablas Completas (continuación)
Las exploraciones de tablas completas tienen un costo menor que las exploraciones de rango de
índice al acceder a una gran parte de los bloques de una tabla, ya que las exploraciones de tablas
completas pueden utilizar llamadas de E/S mayores y realizar menos llamadas de E/S grandes tiene
un costo menor que realizar muchas llamadas pequeñas.
Nota: una llamada de E/S multibloque es más cara que una llamada de E/S de un solo bloque, pero
una llamada de E/S multibloque para 8 bloques, por ejemplo, es menos cara que 8 llamadas de un
único bloque.
Ejemplo: una exploración de tabla completa de una tabla que se puede leer con una llamada de E/S
es menos cara que una consulta de índice para recuperar sólo una fila. El índice debe realizar una E/S
para leer la cabecera del índice, al menos una más para leer el bloque de hoja y una tercera para leer
el bloque de la tabla.
El optimizador utiliza una exploración de tabla completa en cada uno de los siguientes casos:
• Falta de índice: si la consulta no puede utilizar ningún índice existente, utilizará una
exploración de tabla completa. Por ejemplo, si hay una función utilizada en la columna indexada A
E L
de la consulta, el optimizador no podrá utilizar el índice y en su lugar, utilizará una exploración
de tabla completa. S D
DO
• Gran cantidad de datos: Si el optimizador cree que la consulta tendrá acceso a la mayoría de
A
ES
los bloques de la tabla, utilizará una exploración de tabla completa, incluso aunque los índices
R
puedan estar disponibles.
E G nlyฺ
N DE use o
• Tabla pequeña: si una tabla contiene menos bloques que el valor de
DB_FILE_MULTIBLOCK_READ_COUNT por debajo de la marca de agua superior, una
C IO AL
exploración de tabla completa puede ser menos costosa porque se podrá leer en una sola llamada
de E/S. D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
c le U UN
Ora

Exploraciones de Identificador de Fila
El identificador de fila especifica el archivo y bloque de

datos que contienen la fila, así como la ubicación de ésta

en dicho bloque.
explain plan for
select * from emp where rowid='AAAJ5QAAFAAABsvAAC';
-----------------------------------------------------------
| Id | Operation | Name | Rows |Cost |
-----------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 1 |
L A
| 1 | TABLE ACCESS BY USER ROWID| EMP | 1 | 1 |
D E
OS
-----------------------------------------------------------
D
Bloque 6959 – Fila 2 E SA
E GR nlyฺ
B B B
N DEB use o B
C IO AL
D A RIT
F
a n d A D
y
sit RSdeI Fila
Exploraciones de Identificador D
e r E la ubicación exacta de la fila en la base de datos. El ID de fila
iv fila especifica
El ID de fila denuna I V
proporciona
l U UN
e el archivo de datos, el bloque de datos y la ubicación de la fila en ese bloque. La
r a c
localización de una fila mediante la especificación de su ID de fila es el método más rápido para
O
recuperar una única fila.
Para acceder a una tabla por ID de fila, Oracle Database obtiene primero los ID de las filas
seleccionadas, bien de la cláusula WHERE de la sentencia o a través de una exploración de índice de
uno o más índices de la tabla. A continuación, Oracle Database busca cada fila seleccionada en la
tabla basándose en su ID de fila. Éste suele ser el siguiente paso después de recuperar el ID de fila de
un índice.
Si el índice contiene todas las columnas necesarias para la sentencia, no se realizará el acceso a la
tabla por ID de fila. El acceso a la tabla será necesario para todas las columnas de la sentencia que no
estén presentes en el índice.
Nota: en ocasiones, debido a la migración de filas, la fila no se encuentra en la ubicación
especificada por el ID de fila del índice. Cuando no hay suficiente espacio en un bloque para
introducir una actualización de la fila, ésta se mueve a otro bloque y se coloca un puntero en el
bloque original. Sin embargo, el ID de fila del índice, sólo seguirá teniendo la dirección del bloque
original. Para obtener más información sobre la migración de filas, consulte la lección titulada
“Ajuste del Uso de Espacio de Segmentos”.

Operaciones de Índice
Tipos de exploraciones de índice:
• Exploración de índice único
• Exploración de rango de índices

B*Tree Index
• Exploración de rango de índices
IX_EMP
descendente
• Exploración de salto de índice
• Exploración completa
• Exploración completa rápida de
índice L A
• Unión de índices D E
• Operaciones de bitmap D OS
E SA
Table EMP B = block
E GR nlyฺ
D E eo
B B B
I O N
B
L usB B
A RITC A
D
F
a n d A D
Operaciones de Índice y
sit RSI D
e r E
U niv NdeIV
Para todas las opciones exploración de índice, se utilizan los valores de columna necesarios para
SQLUbusque en el índice. Se devuelve el ID de fila y se utiliza para acceder a la
lesenecesario.
que la sentencia
r a
tabla, c
si Si la sentencia SQL se puede satisfacer sólo con los valores de columna del
O
índice, no se accede al acceso a la tabla. Si la sentencia accede a otras columnas además de las
columnas indexadas, la base de datos Oracle podrá buscar las filas en la tabla mediante un acceso por
identificador de fila o una exploración de cluster. La operación de unión de índices evita el acceso a
la tabla mediante la unión de varios índices en el ID de fila para cumplir la lista de selección. La
operación de bitmap incluye las operaciones BITMAP INDEX SINGLE VALUE, BITMAP AND y
OR, y BITMAP CONVERSION TO ROWID.

Operaciones de Índice de Árbol B*
Exploración de índice único
Operation | Object | Rows
INDEX UNIQUE SCAN | PK_EMP | 1

Exploración de rango de índices (ascendente o descendente)
INDEX RANGE SCAN | EMP_DEPT_NO | 10
Exploración de salto de índice
INDEX SKIP SCAN | EMP_DEPT_SAL| 2
Exploración completa
INDEX FULL SCAN | EMP_LAST_SAL| 54
Exploración completa rápida de índice L A
D E
INDEX FAST FULL SCAN | EMP_LAST_SAL| 54
D OS
Unión de índices
E SA
HASH JOIN |
E GR| nlyฺ
INDEX RANGE SCAN | EMP_MGR
D E e|o 10
INDEX FAST FULL SCAN N L us | 10
| EMP_DEPT_NO
I O
D AC RITA
F
a n d A D
Operaciones de Índice y
t ÁrbolSB*I
side D
e r ERoperación de índice de árbol B* y el nombre de operación del plan
En la diapositiva
n isev muestra
I V cada
de ejecución
l e Ucorrespondiente.
UN o Cada operación de índice muestra también el nombre del índice y el
ra
númeroc de filas recuperadas estimadas.
O
Exploración única sólo está disponible para los predicados de igualdad en una columna con una
restricción de clave única o primaria.
Exploración de rango de índices es normalmente una exploración ascendente, pero si se utiliza la
indicación INDEX_DESC en la sentencia o existe una cláusula ORDER BY DESC, la exploración se
puede convertir en descendente.
Exploración de omisión de índice permite dividir lógicamente un índice compuesto en subíndices
más pequeños. En la exploración de omisión, la columna inicial del índice compuesto no se
especifica en la consulta. Es decir, se omite.
Exploración completa de índice lee todos los bloques de un índice en el orden del índice con
lecturas de bloque individuales. Nota: las entradas del índice están ordenadas en los bloques, pero el
orden de los bloques en el segmento no suele ser secuencial.
Exploración de índice completa rápida lee todos los bloques de un índice mediante E/S
multibloque y desecha los bloques innecesarios. Se puede utilizar cuando el índice contiene todas las
columnas que necesita el plan.
Unión de índices es una unión hash en el ID de fila de las entradas del índice. Todas las columnas
necesarias deben estar en los índices.

Índices de Bitmap
Valores de clave
BE 1 0 0 0 0 0 0 0 0 0 0 0
DE 0 1 0 0 0 0 0 0 0 0 0 0
Bitmap para
FR 0 0 1 1 1 1 0 0 0 0 0 0 el valor de clave FR
IL 0 0 0 0 0 0 1 0 1 0 0 0
NL 0 0 0 0 0 0 0 1 0 0 0 0
UK 0 0 0 0 0 0 0 0 0 1 1 1
Se define el bit para el registro ocho L A

Valores de clave D E
porque la fila tiene el valor NL
en la columna COUNTRY. D OS
E SA
M 1 1 1 0 1 1 0 1 1 1 1 1 EGR lyฺ
F 0 0 0 1 0 0 1 0 0 0 0 0DE se on para
Bitmap
I O N L u el valor de clave F
D AC RITA
F
a n d A D
Índices de Bitmap sit y SI D
e r R
E una entrada que contiene el valor de clave y el ID de fila de cada
Un índice de árbol
U nivB* almacena
I V
e de bitmap
fila. Un índice
c l UNempieza con la raíz y los bloques rama del árbol B*, pero en lugar de una
ra para cada fila, se crea un bitmap para cada valor de clave. Para cada ID de fila se define un
entrada
O
bit si la fila contiene un valor de clave. Se utiliza una función de asignación para transformar la
posición de bit en un ID de fila real. En un árbol B*, una entrada de índice apunta a una única fila.
Con los índices de bitmap, una única entrada de índice utiliza un bitmap para apuntar a varias filas
simultáneamente.
Los índices de bitmap son adecuados para datos muy repetitivos (datos con pocos valores distintos en
relación con el número total de filas de la tabla) que son en su mayoría de sólo lectura. Estos índices
nunca se deben tener en cuenta en una base de datos OLTP debido a los problemas relacionados con
la simultaneidad.
Un índice de bitmap tiene una estructura muy diferente; no se almacena ningún ID de fila. Cada valor
de clave diferente tiene su propio bitmap. Cada cabecera de bitmap almacena los ID de fila de inicio
y finalización. Según estos valores, el servidor utiliza un algoritmo interno para asignar los bitmaps
en los ID de fila.
Cada posición del bitmap se asigna a una posible fila de la tabla. El contenido de esa posición en el
bitmap para un valor concreto indica si la fila tiene ese valor en las columnas del bitmap. El valor
almacenado es 1 si los valores de la fila coinciden con la condición del bitmap; de lo contrario,
será 0.

Acceso a Índices de Bitmap
create bitmap index CUST_COUNTRY on CUST(country_iso)
SELECT CUST_LAST_NAME
FROM CUST
WHERE country_iso = 'FR';
-------------------------------------------------------------------------
| Id | Operation | Name | Rows |Cost |
-------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2921 | 368 |
| 1 | TABLE ACCESS BY INDEX ROWID | CUST | 2921 | 368 |
L A
| 2 | BITMAP CONVERSION TO ROWIDS| | | |
D E
|* 3 | BITMAP INDEX SINGLE VALUE | CUST_COUNTRY | | |
D OS
SA
-------------------------------------------------------------------------
Predicate Information (identified by operation id): E
---------------------------------------------------
E GR nlyฺ
DE use o
3 – access(COUNTRY_ISO<‘FR’)
IO ALN
A RITC
D
F
a n d A D
Acceso a Índices de Bitmap y
sit RSI D
e r
niv elNbitmap
Esta consulta explora
U I VE para el país FR para obtener las posiciones que contienen un 1. Para
c U
leuna consulta
estas posiciones se devuelven sus correspondientes filas para consulta. En algunos casos (por
Or a
ejemplo, que contabilice el número filas con COUNTRY_ISO = 'FR'), la consulta
puede utilizar simplemente el propio bitmap y realizar un recuento del número de valores 1 (sin
necesidad de las filas reales).
Cuando el optimizador utiliza un bitmap, debe incluir siempre un paso BITMAP CONVERSION TO
ROWIDS para poder acceder a la fila de la tabla.

Combinación de Bitmaps
SELECT * SELECT *
FROM CUST FROM CUST
WHERE country_iso in('FR','DE'); WHERE country = 'FR'
AND gender = 'M';
FR 0 0 1 1 1 1 0 0 0 0 0 0 FR 0 0 1 1 1 1 0 0 0 0 0 0
O Y
DE 0 1 0 0 0 0 0 0 0 0 0 0 M 1 1 1 0 1 1 0 1 0 1 1 1
0 1 1 1 1 1 0 0 0 0 0 0 0 1 0 1 1 0 0 0 0 0 A
E L
|D
OS
1 | TABLE ACCESS BY INDEX ROWID | 1 | TABLE ACCESS BY INDEX ROWID
2 | BITMAP CONVERSION TO ROWIDS | 2 | BITMAP CONVERSION TO ROWIDS |
D
3 | BITMAP INDEX SINGLE VALUE | 3 | BITMAP AND
E SA
|
GR nlyฺ
----------------------------------- 4 | BITMAP INDEX SINGLE VALUE |
5 | BITMAP INDEX SINGLE VALUE |
4 - access(("COUNTRY"='DE' OR
E
DE use o
"COUNTRY"='FR')) -----------------------------------
4 - access("GENDER"='M')
IO ALN
5 - access("COUNTRY"='FR')
A RITC
D
F
a n d A D
Combinación de Bitmaps y
sit RSI D
e r
niv NIfast
Gracias a las operaciones
U VEbit-and, bit-minus y bit-or, los índices de bitmap son eficaces:
• Cuando UIN (lista de valores)
cle sese combinan
utiliza
• ra
Cuando predicados con AND/OR
OLos índices de bitmap se pueden utilizar eficazmente cuando una consulta combina varios valores
posibles para una columna o cuando se utilizan dos columnas indexadas por separado.
En algunos casos, una cláusula WHERE puede hacer referencia a varias columnas indexadas por
separado.
Si tanto la columna COUNTRY como GENDER tienen índices de bitmap, con una operación bit-and
en los dos bitmaps encontraría rápidamente las filas que está buscando. Cuanto más complejas sean
las cláusulas WHERE, más ventajas obtendrá de los índices de bitmap.

Operaciones de Bitmap
BITMAP CONVERSION
• Puede ser TO o FROM ROWIDS

BITMAP INDEX
• Consulta de un único valor
• Exploración de rango
• Exploración completa
• Exploración completa no rápida
L A
BITMAP MERGE D E
BITMAP AND / OR D OS
BITMAP MINUS E SA
BITMAP KEY ITERATION E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Operaciones de Bitmap y
sit RSI D
e r
iv IVE FROM ROWID, el optimizador convierte de forma improvisada un
Con BITMAP nCONVERSION
U Nbitmap (cuando el costo es inferior al de otros métodos) para poder utilizar
árbol B* enUun
índice dele
c
raeficaces operaciones de comparación de bitmaps. Una vez que se realiza la comparación de
estas
O
bitmaps, el bitmap resultante se vuelve a convertir en ID de fila (BITMAP CONVERSION TO
ROWIDS) para realizar la consulta de datos.
Con la operación BITMAP MINUS, el servidor toma el segundo bitmap y lo niega, cambiando los
unos por ceros y los ceros por unos. A continuación, la operación bitmap minus se podrá realizar
como BITMAP AND con este bitmap negado.
Las operaciones BITMAP MINUS, AND y OR son operaciones binarias que utilizan dos orígenes de
fila de bitmap como entrada. Las operaciones de bitmap KEY ITERATION y MERGE son
operaciones n-arias. MERGE combina un juego de bitmaps. KEY ITERATION toma cada fila de un
origen de fila de tabla y busca el bitmap correspondiente en un índice de bitmap. Esta operación va
seguida de la operación BITMAP MERGE que fusiona el juego de bitmaps en un solo bitmap.
Puesto que los bitmaps se almacenan en una estructura de árbol B*, los métodos de acceso básicos
SINGLE VALUE, RANGE SCAN y FULL SCAN funcionan con índices de bitmap. SKIP SCAN y
FAST FULL SCAN no funcionan con índices de bitmap.

Operaciones de Unión
• La unión es una operación binaria que une sólo dos

orígenes de fila.
• Para cada unión, el optimizador determina lo siguiente (en
secuencia):
1. Orden de unión de las tablas
2. Mejor método de unión que se va a aplicar a cada unión
3. Ruta de acceso para cada origen de fila
• El orden de unión se ve afectado por las siguientes reglas A
incorporadas: E L
S D
– Un predicado de una sola fila fuerza al origen de la fila
D Oque
a
se coloque primero en el orden de unión. E SA
– Para uniones externas, la tabla con la tabla
E GdeRunión
n l yฺ externa
DE
debe ir después de la otra tabla en el orden edeounión para el
N s
procesamiento de la unión. IO Lu
D AC RITA
F
a n d A D
Operaciones de Unión y
sit RSI D
e r E que une sólo dos orígenes de fila. Una unión de varias filas
U nivoperación
Una unión es una I Vbinaria
Ntablas y la unión posterior del origen de fila resultante a otra tabla u origen
la unión deU
consta dele dos
c
ra hasta que se realicen todas las uniones.
de fila
O
Para cada sentencia de unión, el optimizador determina lo siguiente (en secuencia):
1. El orden de unión de las tablas
2. La mejor operación de unión que se va a aplicar a cada unión
3. La ruta de acceso para cada origen de fila
El número de tablas implicadas determina el número de órdenes de unión que se evaluarán, el
número de órdenes de unión crece de forma factorial con el número de tablas. (Número de
tablas)!=Número de órdenes de unión. Algunas órdenes de unión no se pueden tener en cuenta,
debido a las reglas de orden de unión incorporadas en el optimizador:
• Un predicado de una sola fila fuerza al origen de la fila a que se coloque primero en el orden de
unión.
• Para uniones externas, la tabla con la tabla de unión externa debe ir después de la otra tabla en el
orden de unión para el procesamiento de la unión.
Se comparan los costos de varios métodos de unión para cada orden de unión. Algunos métodos no
se pueden utilizar con algunas uniones debido a las limitaciones del método. Por ejemplo, una unión
hash no se puede utilizar para una unión no igualitaria.

Métodos de Unión
• Una operación de unión combina la salida de dos orígenes

de fila y devuelve un origen de fila resultante.

• Los métodos de unión incluyen lo siguiente:
– Unión de bucles anidados
– Unión de fusión/ordenación
– Unión hash
• Los métodos de unión tienen variaciones para lo siguiente:
– Unión externa L A
– Unión externa completa D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Métodos de Unión sit y SI D
e r R
E la salida de dos orígenes de fila (como tablas o vistas) y devuelve
Una operación n deiv V
unión combina
I
U UN (juego de datos). El servidor de Oracle soporta distintos métodos de unión
un origenlede fila resultante
c
Oralos siguientes:
como
Unión de bucles anidados: resulta útil cuando se unen pequeños subjuegos de datos y cuando la
condición de unión es una forma eficaz de acceder a la segunda tabla.
Unión hash: se utiliza para unir grandes juegos de datos. El optimizador utiliza la más pequeña de
dos tablas o el más pequeño de los orígenes de datos para crear una tabla hash en la clave de unión de
la memoria. A continuación, explora la tabla más grande, sondeando la tabla hash para buscar las
filas unidas. Este método se utiliza mejor cuando la tabla más pequeña se ajusta a la memoria
disponible. De este modo, el costo se limita a una única transferencia de lectura sobre los datos para
las dos tablas.
Unión de fusión/ordenación: se puede utilizar para unir filas de dos orígenes independientes. Las
uniones hash suelen funcionar mejor que las de fusión/ordenación. Por otro lado, las uniones de
fusión/ordenación pueden funcionar mejor que las uniones hash si se cumplen las dos condiciones
siguientes:
• Los orígenes de fila ya se han ordenado.
• No es necesario que se realice una operación de ordenación.
Estos métodos se tratan en las siguientes diapositivas.

Unión de Bucles Anidados
• Una de las dos tablas se define como tabla externa (o tabla

principal).
• La otra se denomina tabla interna.
• Para cada fila de la tabla externa, se recuperan todas las
filas que coinciden de la tabla interna.
Para cada fila de la tabla externa L A

D E
Para cada fila de la tabla interna D OS
E SA
Comprobación de una
E GR nlyฺ
DE use o
coincidencia
N
C IO AL
D A RIT
F
a n d A D
Unión de Bucles Anidados y
sit RSI D
e r
NESTED LOOPS n iv IVE
U
e ACCESS
TABLE
l UN (…)
ACCESS (…) OF our_outer_table
ra cTABLE OF our_inner_table
O
Debido a que se suelen utilizar con accesos indexados a tablas, los bucles anidados son comunes con
un plan de ejecución similar al siguiente:
NESTED LOOPS
TABLE ACCESS (BY row ID) OF our_outer_table
INDEX (... SCAN) OF outer_table_index (…..)
TABLE ACCESS (BY row ID) OF our_inner_table
INDEX (RANGE SCAN) OF inner_table_index (NON-UNIQUE)
A la tabla externa (principal) se suele acceder con una exploración de tabla completa. Si se determina
que una tabla de la unión devuelva una única fila, la regla de orden de unión la forzará a ser la tabla
principal. Si el predicado de unión es una unión no igualitaria, se podrá acceder a la tabla interna con
una exploración de tabla completa, una vez por cada fila de la tabla principal, dando lugar a
exploraciones completas de tablas repetidas.
La unión de bucles anidados se puede utilizar siempre para unir dos tablas. Por lo tanto, el
optimizador utilizará la unión de bucles anidados cuando no se puedan utilizar las uniones
fusión/ordenación, hash o cluster. Estas técnicas de unión se tratan más adelante en esta lección.

Unión de Bucles Anidados (continuación)
Para cada fila de la tabla externa (principal), se recuperan todas las filas de la tabla interna que
cumplen el predicado de unión. Los predicados no de unión de la tabla interna se tienen en cuenta
después de esta recuperación inicial, a menos que se utilice un índice compuesto (combinando los
predicados de unión y no de unión).
Oracle Database utiliza un optimizador interno denominado recuperación previa del bloque de datos.
La consulta de tabla utiliza la recuperación previa del bloque de datos. Cuando se selecciona una ruta
de acceso de índice y el índice no puede satisfacer por sí mismo la consulta, se deben recuperar
también las filas de datos que indica el ID de fila. Las entradas del índice se recuperan y ordenan por
ID de fila y, posteriormente, se utilizan para recuperar filas de la tabla. Este comportamiento es
automático y no se puede ver influenciado por las indicaciones. En uniones con recuperación previa
del bloque de datos, puede consultar el plan de explicación, como el siguiente:
NESTED LOOPS (Cost=…)
NESTED LOOPS (Cost=…)
TABLE ACCESS (FULL) OF(…)
INDEX (RANGE SCAN) OF (…)
TABLE ACCESS (BY INDEX row ID) OF (…) L A
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
c le U UN
Ora

Unión Hash
Una unión hash se ejecuta del siguiente modo:

• Las dos tablas se dividen en tantas particiones como

sean necesarias con una exploración de tabla completa.
• Para cada par de particiones, se crea una tabla hash en
la memoria de la partición más pequeña.
• La otra partición se utiliza para sondear la tabla hash.
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
Uy/oNsusD
Copyright © 2010, Oracle T los derechos reservados.
ISTodos
filiales.
F
a nd AD
Unión Hash
r s ity RSID
Las uniones hash n ve se realizan
isólo I V E para uniones igualitarias. Para ejecutar una unión hash, el servidor
de Oraclel U N pasos:
erealiza losUsiguientes
c
O1.rade
Realiza una exploración de tabla completa de una de las tablas que se deben unir (la exploración
la tabla más pequeña en primer lugar genera un costo menor)
2. Crea una tabla hash a partir de las filas procedentes de la primera tabla (origen de fila), sobre la
clave de unión.
3. Realiza una exploración de tabla completa de la otra tabla.
4. Sondea la tabla hash con cada fila procedente de la segunda tabla (origen de fila).
Plan de Ejecución Básica
HASH JOIN
TABLE ACCESS (..) OF table_A
TABLE ACCESS (..) OF table_B
Consideraciones de Rendimiento
Como norma general, las uniones hash superan las uniones de fusión/ordenación. En algunos casos,
una unión de fusión/ordenación puede superar una unión de bucles anidados. Es incluso más
probable que esto lo haga una unión hash.

Uniones de Fusión/Ordenación
Una unión de fusión/ordenación se ejecuta del siguiente modo:

1. Las filas de cada origen de fila se ordenan en las columnas

del predicado de unión.
2. A continuación, los dos orígenes de fila ordenados se
fusionan y se devuelven como origen de fila resultante.
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI
Uniones de Fusión/Ordenación D
e r E los dos orígenes de fila se ordenan por los valores de las columnas
nivde ordenación,
En las operaciones
U I V
utilizadas
c l UN de unión. Si ya se ha ordenado un origen de fila en una operación anterior,
een el predicado
O ra
la operación de fusión/ordenación omite la ordenación en dicho origen de fila. La ordenación puede
hacer que esta técnica de unión resulte costosa, especialmente si la ordenación no se puede realizar
en la memoria.
La operación de fusión combina los dos orígenes de fila ordenados para recuperar los pares de filas
que contienen los valores que coinciden para las columnas utilizadas en el predicado de unión.
Plan de Ejecución Básica
MERGE (JOIN)
SORT (JOIN)
TABLE ACCESS (…) OF table_A
SORT (JOIN)
TABLE ACCESS (…) OF table_B
Los accesos a tablas (table_A y table_B) se pueden basar en exploraciones de índices si no hay
ningún predicado no de unión que pueda utilizar un índice. Sin embargo, esta operación de unión
aparece con frecuencia con exploraciones de tablas completas en ambas tablas.
La secuencia (cuya tabla se ordena primero) no tiene importancia; no hay ningún concepto de tabla
externa o principal. Recuerde que la ordenación puede dar lugar a la creación de segmentos
temporales en el disco (proporcionando más E/S que las mismas exploraciones de tablas).

Uniones de Fusión/Ordenación (continuación)
Las uniones de fusión/ordenación tienden a funcionar mejor que una unión indexada de bucles
anidados si el número de filas que cumple la condición de unión representa una parte mayor del
número total de filas en las dos tablas.
Nota: el punto de equilibrio de una unión de fusión/ordenación y una unión indexada de bucles
anidados depende del rendimiento de la ordenación de la base de datos. Se puede influir en el
rendimiento de la ordenación definiendo los tablespaces temporales que son del tipo TEMPORARY.
Para obtener más información, consulte la lección Ajuste de PGA y Espacio Temporal.
L A
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F UN DIST
a nd AD
r s ity RSID
n ive IVE
c le U UN
Ora

Rendimiento de la Unión
Cada método de unión funciona mejor en determinadas

situaciones.
• Unión anidada
– Tablas pequeñas
– Índices de columnas de unión
• Uniones hash
– Tablas grandes
– Una tabla grande y pequeña L A
– Se selecciona una gran parte de la tabla para la unión D E
O S
• Fusión/ordenación D
E SA
– Unión no igualitaria
E GR nlyฺ
– Los orígenes de fila ya se han ordenado
N DE use o
C IO AL
D A RIT
F
a n d A D
Rendimiento de la Unión y
sit RSI D
e r
El optimizadorn iv IVelEmétodo con el menor costo estimado. Cada método se ejecuta mejor
seleccionará
U UN Hay algunos casos en los que será necesario un determinado método.
e situaciones.
en determinadas
l
Unara c
unión de bucles anidados puede unir dos orígenes de fila cualquiera. La unión de
O
fusión/ordenación puede unir condiciones no igualitarias. En general, la unión hash es la más rápida
si al menos uno de los orígenes de fila se puede mantener completamente en memoria, pero la unión
hash sólo puede realizar uniones igualitarias.
Los bucles anidados funcionan mejor en tablas pequeñas con índices de las condiciones de unión. Si
uno de los orígenes de fila es un origen de una fila, al igual que una consulta de igualdad en un valor
de clave primaria, la unión se convierte en una consulta simple. El optimizador intenta siempre
colocar el origen de fila más pequeño en primer lugar, convirtiéndolo en la tabla principal.
Para las uniones hash, si las tablas son demasiado grandes para la memoria disponible, se particionan
los orígenes de fila y la unión se realiza partición a partición. Esta operación puede utilizar mucha
memoria del área de ordenación y E/S en el tablespace temporal. Este método puede seguir siendo el
más eficaz, sobre todo cuando se utilizan servidores de consulta en paralelo.
La unión de fusión/ordenación puede realizar uniones no igualitarias. El optimizador puede elegir
este método cuando se puede acceder a los datos ordenados; de lo contrario, las ordenaciones
necesarias pueden hacer que este método sea más costoso.

Selección de los Planes de Ejecución para
Uniones por Parte del Optimizador de Consulta
El optimizador de consulta determina:
• Orígenes de fila
• Tipo de unión
• Método de unión
• Costo de los planes de ejecución
• Otros costos como:
– E/S
L A
– Tiempo de CPU E
D
• Indicaciones especificadas
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Selección de los Planes y D
SI para Uniones por Parte del Optimizador de
sit de Ejecución
e r R
Consulta
U niv NIVE
U tiene en cuenta lo siguiente a la hora de seleccionar un plan de ejecución:
le de consulta
El optimizador
Elcoptimizador determina primero si la unión de dos o más tablas da lugar definitivamente a un
• ra
O origen de fila que contenga al menos una fila. El optimizador reconoce estas situaciones basadas
en las restricciones UNIQUE y PRIMARY KEY de las tablas. Si se da esta situación, el
optimizador colocará estas tablas en primer lugar en el orden de unión. A continuación,
optimizará la unión del juego restante de tablas.
• Para sentencias de unión con condiciones de unión externa, la tabla con el operador de unión
externa debe ir después de la otra tabla de la condición en el orden de unión. El optimizador no
tiene en cuenta los órdenes de unión que violan esta regla. Asimismo, cuando una subconsulta se
ha convertido en una antiunión o semiunión, las tablas de la subconsulta deberán ir después de
las tablas del bloque de consulta externo al que están conectadas o con el que están
correlacionadas. Sin embargo, las antiuniones y semiuniones hash pueden sustituir esta
condición de ordenación en determinadas circunstancias.
Nota: las antiuniones hash se utilizan para calcular rápidamente las uniones de subconsulta NOT
EXISTS.

Selección de los Planes de Ejecución para Uniones por Parte del Optimizador de
Consulta (continuación)
• El optimizador genera un juego de planes de ejecución según los posibles órdenes de unión, los
métodos de unión y las rutas de acceso disponibles. A continuación, estima el costo de cada plan
y selecciona el que lo tenga más bajo. El optimizador estima los costos de los siguientes modos:
- El costo de una operación de bucle anidado se basa en el costo de lectura de cada fila
seleccionada de la tabla externa y de las filas coincidentes de la tabla interna en la memoria.

El optimizador estima estos costos con las estadísticas del diccionario de datos.
- El costo de una unión de fusión/ordenación se basa, sobre todo, en el costo de la lectura de
todos los orígenes en la memoria y su ordenación.
- El costo de una unión hash se basa, sobre todo, en el costo de la creación de una tabla hash
en uno de los lados de entrada a la unión y del uso de las filas del otro lado de la unión para
sondearla.
• El optimizador también tiene en cuenta otros factores a la hora de determinar el costo de cada
operación. Por ejemplo: Es probable que un área de ordenación más pequeña aumente el costo
de una unión de fusión/ordenación porque la ordenación necesita más tiempo de CPU y E/S en L A
este tipo de área. Es probable que la E/S multibloque reduzca el costo de una unión de D E
S
fusión/ordenación en relación con una unión de bucles anidados. Si se puede leer un gran
A DO
número de bloques secuenciales desde el disco en una única E/S, será menos probable que un
ES
índice de la tabla interna para la unión de bucles anidados mejore el rendimiento en una
R
E G nlyฺ
exploración de tabla completa. El tamaño del mutibloque se ajusta automáticamente y se
determina al inicio de la instancia.
N DE use o
• Con el optimizador de consulta, la elección del optimizador de los órdenes de unión se puede
C IO AL
A RIT
sustituir por la indicación ORDERED. Si la indicación ORDERED especifica un orden de unión
D
F UN DIST
que viole la regla para una unión externa, el optimizador ignorará la indicación y elegirá el
orden. Asimismo, se puede sustituir la elección del optimizador del método de unión por
indicaciones. a nd AD
r s ity RSID
n ive IVE
c le U UN
Ora

Operaciones de Ordenación
• SORT UNIQUE
• SORT AGGREGATE
• SORT GROUP BY
• SORT JOIN
• SORT ORDER BY
L A
D E
D OS
E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Operaciones de Ordenación y
sit RSI D
e r Ese producen cuando los usuarios especifican una operación que
ivordenación
Las operacionesnde I V
U UNEntre las operaciones más utilizadas se incluyen las siguientes:
e ordenación.
necesita luna
c
O•raSORT UNIQUE se produce si un usuario especifica una cláusula DISTINCT o si una operación
necesita valores únicos para el siguiente paso. Se eliminan los valores duplicados.
• SORT AGGREGATE no implica realmente una ordenación. Se utiliza cuando se calculan los
agregados en todo el juego de filas.
• SORT GROUP BY se utiliza cuando los agregados se calculan para distintos grupos de datos.
Para esta operación, se realiza una unión hash para agregar los grupos.
• SORT JOIN se produce durante una unión de fusión/ordenación si es necesario que la clave de
unión ordene las filas.
• SORT ORDER BY es necesaria cuando la sentencia especifica un ORDER BY que no se puede
satisfacer por ninguno de los índices.

Ajuste de Rendimiento de Ordenación
• Debido a que la ordenación de juegos grandes puede

resultar costosa, debe ajustar los parámetros de

ordenación.
• Tener en cuenta que DISTINCT, GROUP BY y la
mayoría de los operadores de definición provocan
ordenaciones implícitas.
• Minimizar la ordenación mediante una de las siguientes
acciones: A
– Intentar evitar DISTINCT y GROUP BY. E L
D
– Utilizar UNION ALL en lugar de UNION. D OS
– Activar el acceso a los índices para evitar la ordenación. E SA
E GR nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
Ajuste de Rendimiento y SI
t Ordenación
side D
e r R
E del lenguaje SQL, como DISTINCT, GROUP BY, UNION,
Anteriormente,n iv componentes
varios I V
MINUS ele U
INTERSECT, UNprovocaban ordenaciones implícitas. Algunos de estos componentes aún
c
ra ordenaciones. Como DBA, puede tener en cuenta estas condiciones, pero difícilmente
provocan
O
podrá cambiar el código.
Nota: el estándar SQL no garantiza que la salida se produzca en ningún orden a menos que se haya
especificado una cláusula ORDER BY. En Oracle Database 11g, algunas operaciones GROUP BY y
de agregación no producen ninguna ordenación.
Algunas ordenaciones se pueden evitar creando índices. Los índices concatenados, con los atributos
DESC o ASC adecuados, pueden ayudar especialmente a evitar las ordenaciones. Tenga en cuenta,
sin embargo, que pierde la ventaja de E/S multibloque porque, para evitar una ordenación, el índice
se debe explorar de forma secuencial. Una exploración completa rápida de índice (con E/S
multibloque) no garantiza que las filas se devuelvan en el orden correcto.
Para obtener más información sobre el ajuste de los parámetros del área de ordenación, consulte la
lección Ajuste de PGA y Espacio Temporal.

Prueba
Puede considerar un origen de fila utilizado por el optimizador
como una tabla en memoria. Un origen de fila puede ser una
proyección de una tabla con columnas limitadas por la lista de

selección y filas limitadas por la cláusula where o los
resultados de las operaciones de unión y ordenación. Algunos
de estos orígenes de fila se pueden transferir fila a fila hasta la
siguiente operación, pero los demás se deben completar (todas
las filas recuperadas) antes de pasar a la siguiente operación.
El costo de estas operaciones intermedias se ve afectado por
lo siguiente:
E LA
a. Tamaño del área de trabajo SQL (área de ordenación) S D
D O
b. Número de columnas en el origen de fila A
R ES
c. Selectividad de las columnas indexadasEG
n l yฺ
d. Número de índices en la tabla DE se o N Lu
I O
D AC RITA
F
a n d A D
Respuesta: a y
sit RSI D
e r Eque se complete la operación anterior antes de continuar; por ejemplo,
niv necesitan
Algunas operaciones
U I V
una unión
c l een la uniónUdeNordenación/fusión. La ordenación se debe completar antes de realizar la
ra En estos casos, debe haber espacio de memoria disponible para realizar la ordenación. Este
unión.
O
espacio de memoria se denomina área de trabajo SQL. Si esta área es demasiado pequeña para
contener la ordenación completa, la ordenación se desglosa en diferentes partes y se envía al disco en
un tablespace temporal. Resulta mucho más costoso desglosar la ordenación en diferentes partes y
escribir cada una de estas partes en el disco que realizar la ordenación completamente en memoria.

Resumen

• Describir el comportamiento del optimizador

• Explicar cómo pueden afectar la estadísticas al optimizador
• Describir cómo afectan las estructuras de datos al
optimizador
• Ajustar los parámetros para influir en el optimizador
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Influencia en el Optimizador
• Gestión de estadísticas
– Captura de estadísticas ampliadas
– Observación del cambio en el plan de explicación cuando se
producen cambios en las estadísticas
LA
D E
S
A DO
R ES
E G nlyฺ
N DE use o
C IO AL
D A RIT
F
a n d A D
y
sit RSI D
e r
U niv NIVE
c le U
Ora

Ora
c
n
r s
le U UN
ive IVE
a
F
ity RSID
nd AD
D
C
UN DIST
N
A RIT
IO AL
E
R
DE use o
ES
G nlyฺ
A DO
S D E LA

Afinamiento 23

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Afinamiento 23

Caricato da

Copyright:

Formati disponibili

Unauthorized reproduction or distribution prohibitedฺ Copyright 2012, Oracle and/or its affiliatesฺ

James Spiller Renuncia

Este documento contiene información propiedad de Oracle Corporation y se

Uso de las Funciones de los Paquetes 2-37

5 Eventos de Tiempo Principales 4-6

6 Uso de Líneas Base

Historial de Sesiones Activas: Visión General 7-20

Visión General de la Práctica 8: Uso de Servicios 8-29

9 Identificación de Sentencias SQL con Problemas

Parámetros de Inicialización 9-46

Unión de Bucles Anidados 10-33

13 Gestión del Rendimiento SQL

14 Uso de la Reproducción de Base de Datos

15 Ajuste del Pool Compartido

Caché de Resultados de Consultas SQL: Consideraciones 15-51

16 Ajuste de la Caché de Buffers

Uso de la Caché Flash Inteligente de BD 16-43

18 Gestión Automática de Memoria

Estadísticas de E/S y Enterprise Manager 19-14

20 Resumen de Ajuste del Rendimiento

Consideraciones de Fragmentación Interna 20-15

y PL/SQL o que tenga experiencia equivalente.

11g Release 2 (11.2) E10822-02

1. Convenciones Tipográficas para Palabras en Texto Normal

l e U UN enfatizadas; No guarde los cambios en la base de datos.

Orac marcadores de Introduzca hostname, donde

Comillas Títulos de lecciones Este tema se trata en la Lección 3,

2. Convenciones Tipográficas para Palabras en Ejemplos de Código

funciones FROM employees;

Al finalizar este curso, debería estar capacitado para lo

Oracle Database 11g: Ajuste de Rendimiento 1-2

– Supervisión mediante las herramientas disponibles

Oracle Database 11g: Ajuste de Rendimiento 1-3

Día Lección Tema

1 2 Diagnósticos de Ajuste Básicos

1 3 Uso del Repositorio de Carga de Trabajo Automática

1 5 Uso de Métricas y Alertas

2 6 Uso de Líneas Base

Oracle Database 11g: Ajuste de Rendimiento 1-4

3 12 Uso de SQL Performance Analyzer

4 13 Gestión del Rendimiento SQL

4 14 Uso de la Reproducción de Base de Datos

4 15 Ajuste del Pool Compartido

5 16 Ajuste de la Caché de Buffers

5 17 Ajuste de PGA y Espacio Temporal LA

Oracle Database 11g: Ajuste de Rendimiento 1-5

Oracle Database 11g: Ajuste de Rendimiento 1-6

Entre las personas implicadas en el ajuste están los:

• Administradores de base de datos

Oracle Database 11g: Ajuste de Rendimiento 1-7

Áreas de ajuste de rendimiento:

Oracle Database 11g: Ajuste de Rendimiento 1-8

Oracle Database 11g: Ajuste de Rendimiento 1-9

Oracle Database 11g: Ajuste de Rendimiento 1-10

• Identificar el ámbito del problema (sistema operativo, base

Oracle Database 11g: Ajuste de Rendimiento 1-11

automatizar el proceso de identificación de cuellos de botella.

Oracle Database 11g: Ajuste de Rendimiento 1-12

Los objetivos de ajuste efectivos son:

Oracle Database 11g: Ajuste de Rendimiento 1-13

Oracle Database 11g: Ajuste de Rendimiento 1-14

Las sesiones de ajuste tienen el mismo procedimiento:

1. Definir el problema y exponer el objetivo.