Teoría

UNIVERSIDAD NACIONAL
DE JUJUY

FACULTAD DE INGENIERIA

HERRAMIENTAS INFORMATICAS AVANZADAS
INTRODUCCION A LA BASE DE DATOS ORACLE
Parte 1 - Diagnstico General de la Base de Datos

Profesor Adjunto: Ing. Hctor Pedro Liberatori
Profesor Adjunto: Ing. Ariel Alejandro Vega
Ayudante de 1: APU Rebeca Flores
AO 2012

PARTE I

DIAGNOSTICO GENERAL DE LA BASE DE DATOS

1. Visin general de un DBMS - Perfomance Tuning (Ajuste)
2. Herramientas de Diagnstico y Tuning

UNIVERSIDAD NACIONAL DE JUJUY
ANALISTA PROGRAMADOR UNIVERSITARIO
Ctedra: BASE DE DATOS II

Profesor Adjunto: Ing. Hctor Pedro Liberatori Pg. 3

I - DIAGNOSTICO GENERAL DE LA BASE DE DATOS

Conocer el rendimiento de las bases de datos Oracle por el lado de su funcionamiento y su manera de resolver los
conflictos, nos puede llevar a obtener respuestas a ciertas preguntas comunes, como ser: Por qu el sistema est
lento? , por qu esta consulta tarda tanto?.
Para tener la habilidad de contestar esta pregunta firmemente (y con un basamento concreto) es necesario
adquirir ciertos conocimientos sobre la arquitectura de Oracle Server, como as tambin, conocer los procesos
derivados de las consultas SQL y cmo interacta el sistema operativo con el Hardware.
Consecuentemente, ajustar tunear una base de datos puede llegar a ser una tarea intimidante, ya que
efectivamente Oracle 9i es altamente ajustable configurable y muy rico en caractersticas, por lo que suele llegar
a ser dificultoso entender por dnde comenzar a focalizar los esfuerzos del ajuste tuning. Como solucin a estos
conceptos, a lo largo de este curso se expondrn y aplicarn metodologas de ajustes que ya estn probadas para
poder llegar sin problemas a cumplir con los objetivos deseados.



UNIDAD 1
VISION GENERAL DE UN DBMS - PERFOMANCE TUNING (AJUSTE)
1.1. OBJETIVOS
En la presente unidad el alumno deber lograr definir los roles asociados al proceso de ajuste, describir las
dependencias entre los ajustes de las distintas fases de desarrollo, identificar los problemas comunes de ajuste, y
realizar actividades de ajuste. Tambin deber comprender cmo alcanzar un equilibrio entre rendimiento y
seguridad.

1.2. CUESTIONARIO DE INICIACION

1.3. CONCEPTOS DE TUNING
Los ajustes que pueden resultar de un posible problema de performance de algn monitoreo preventivo pueden
tener varios mbitos, como ser el mbito del diseo y desarrollo de software; el mbito del diseo de la base de
datos y el mbito del monitoreo tanto de las aplicaciones como de la base de datos.
Para el caso del mbito de las aplicaciones, por lo general, suele ser ste el punto de partida ante la necesidad de
realizar ajustes de performance, ya que si se cuenta con un diseo que cumpla satisfactoriamente con los
requerimientos del negocio (y si los requerimientos a su vez son los realmente necesarios), los problemas de ajuste
disminuirn significativamente. La Figura 1.1 muestra un esquema de la relacin entre un buen diseo de
software y su relacin con los posibles puntos a ajustar.
Desde el punto de vista de la base de datos, no solamente habra que mirarla como un software de gestin de datos,
sino como un todo en conjunto a la plataforma donde se encuentra soportada, es decir, el sistema operativo y el
hardware. Es por esto que tambin se debe tener en cuenta la utilizacin de los discos rgidos y en funcin de esto



poder determinar los tiempos de recuperacin, terminando de asentar el concepto de Tiempo Medio para la
Recuperacin (MTTR Mean Time To Recover).

1.4. OBJETIVOS DEL TUNING
Independientemente de la forma de realizar el ajuste a la aplicacin, base de datos y/o hardware, es importante
poder definir los objetivos que se desean alcanzar de este proceso y la manera en que se van a medir.
Estos procesos incluyen la definicin de bancos de prueba, seguimientos histricos de los datos estadsticas a
medir en el proceso de ajuste.
Uno de los pasos iniciales al momento de reproducir un aspecto que requiere ajuste, es la utilizacin de un Banco
de Pruebas. De su utilizacin posiblemente se saque una idea de cmo se ver el sistema una vez ajustado antes de
realizar el esfuerzo por completo. Para poder realizar esta tarea adecuadamente, es necesario contar con varios
aspectos trabajados en conjunto, que tengan que ver con el ajuste. La Figura 1.2 muestra una enumeracin de
estos aspectos. Idealmente, todas estas reas deberan ser monitoreadas simultneamente por un perodo de
tiempo, mientras el sistema se encuentra en un estado de procesamiento normal. Los resultados medidos de estas
reas se suelen concentrar en estadsticas y velocidades de respuesta.
Las estadsticas se suelen obtener de la ejecucin de scripts de Oracle sobre la base de datos, utilizando
herramientas de terceras partes, dependiendo del mbito que se desea medir. Los resultados de las estadsticas se
suelen medir en porcentajes tiempos de espera.

Figura 1.1
Figura 1.2



1.5. HACIENDO TUNING
Al tratar de comenzar a examinar todo un entorno para dar inicio al monitoreo que devendr en un ajuste de
rendimiento, es tarea corriente comenzar por ver los errores comunes que se suelen cometer en el mbito de la
mejora del rendimiento. La Figura 1.3 enumera los errores comnmente realizados.
Para el caso de las aplicaciones SQL, se suele dar el caso en que justamente una consulta a la base de datos es la
causante de la prdida de performance. Esto se debe a una posible mala resolucin de diseo al momento de
definir la forma de consultar a la base de datos. En los captulos siguientes se ver ms en detalle cmo detectar y
solucionar este tipo de problemas.
Los planes de ejecucin no solamente surgen de una sentencia SQL ineficiente, sino que una sentencia
correctamente definida tambin podra llevar a una mala eleccin de un plan de ejecucin (el plan de ejecucin se
ver en los prximos captulos), ya que su principal basamento es la estadstica.
Es sabido que la SGA se utiliza principalmente para el cach de datos y sentencias SQL, entre otras cosas. El
objetivo de estas estructuras de memoria es el de mejorar el rendimiento, permitiendo a las aplicaciones encontrar
consultas ya resueltas en memoria, pero una mala definicin de estas estructuras podra llevar a un muy mal
desempeo de las respuestas del Oracle Server.

1.6. TUNING EN LA ETAPA DE DESARROLLO
Tradicionalmente Oracle recomendaba una resolucin de la metodologa de ajuste de rendimiento basado en un
modelo descendente (topdown) que se focalizaba principalmente en el diseo del SQL embebido en la aplicacin
antes de analizar las caractersticas propias del ajuste, relacionadas al manejo de las estructuras de memoria y a
los accesos fsicos a discos rgidos. Es cierto que esta metodologa es til en ciertos escenarios, pero en la
actualidad Oracle recomienda una serie de Principios del Ajuste de Rendimiento que se ajustan mejor al general de
los casos. De todas maneras, estas dos metodologas formas de resolver el problema del ajuste de rendimiento no
deben ser mutuamente excluyentes. Estas metodologas existen para ayudar al DBA a reconocer dnde focalizar
los esfuerzos del ajuste, que seguramente variarn en funcin del contexto.
En definitiva, siempre se debe tener en cuenta que para lograr un buen resultado en el ajuste de un sistema, no slo
hace falta el conocimiento del DBA, sino que tambin se requiere de un trabajo en conjunto de los diseadores,
desarrolladores y administradores de sistemas red.
La metodologa de ajuste seleccionada deber depender del tipo de sistema que se est ajustando. Por lo general, el
acercamiento tradicional (descendente) es el correcto para mbitos de desarrollo sobre bases de datos y el nuevo
(basado en principios) suele ser ms apropiado para ajustar sistemas en produccin.
Cuando hablamos de sistemas en etapa de desarrollo la metodologa descendente enfatiza la revisin de las
caractersticas ms probables de ajuste en una primera etapa, dejando las reas que tengan menor impacto en la
performance para un segundo anlisis. La Tabla de la Figura 1.4 muestra el orden que se plantea en esta
metodologa.
De esta manera, las reas examinadas inicialmente se encuentran relacionadas con la aplicacin directamente
hasta descender a cuestiones base. La experiencia cuenta que el 90% de los ajustes se hacen en las primeras
etapas.
Figura 1.3



1.7. TUNING EN LA ETAPA DE PRODUCCION
De manera contraria al ajuste en el proceso de desarrollo de la aplicacin, el ajuste por medio de Principios del
Ajuste de Rendimiento que Oracle recomienda se focaliza mayormente en tcnicas para identificar y resolver
ciertos aspectos ajustables. En captulos posteriores se tratarn estos temas. La tabla que se ve en la Figura 1.5
muestra los aspectos principales de esta metodologa.
Cabe destacar que algunas de las reas mencionadas en la tabla se solapan con la metodologa tradicional. La
principal diferencia que esta metodologa presenta es que tiene en cuenta que los cambios en un sistema en
produccin son muy difciles y costosos.
A medida que una aplicacin se vuelve ms prevaleciente, esta metodologa se vuelve ms importante por su forma
de aplicacin, ya que tiene en cuenta los factores de mayor importancia a ajustar sumado a un perfil ms formal.
A lo largo de este curso se vern en detalle los aspectos correspondientes a la aplicacin de esta metodologa.

1.8. COMPARACIONES
De la utilizacin de una metodologa tradicional (topdown) basada en principios de ajuste, puede surgir la
necesidad de tener que ajustar el servidor de base de datos; para esto se plantean en forma genrica los aspectos
que se deberan tener en cuenta:
Caractersticas comunes que se suelen ajustar.
Verificar los errores de los logs de alerta.
Chequear que los valores de los parmetros de inicializacin de la instancia sean los correctos.
Verificar el uso de la memoria, velocidades de escritura a disco e intercambio de memoria.
Figura 1.4
Figura 1.5



Ajustes del tiempo de respuesta.
Verificar el estado de los procesos relacionados con el servidor. Estos suelen estar en estado Inactivo,
Ejecutando Bloqueado.
Determinar los componentes que ms recursos consumen.
Equilibrio entre Rendimiento y Seguridad. Factores que afectan al rendimiento:
Uso de varios archivos de control.
Varios miembros de los grupos Redo Log.
Puntos de Control (CheckPoints) muy frecuentes.
Copias de backup a disco.
Archivado (ARCHIVELOG) de la base de datos.
Cantidad de usuarios concurrentes y sus transacciones.

1.9. REVISION DE LA ARQUITECTURA ORACLE
Uno de los factores de xito de DBA es comprender profundamente la arquitectura de Oracle y sus mecanismos,
como as tambin las relaciones entre las estructuras de memoria, procesos en segundo plano y actividades de I/O.
Para ello se plantea en este tem un repaso genrico de esta arquitectura antes de comenzar en profundidad.
La arquitectura de Oracle Server puede dividirse en dos categoras principales, que son la Instancia, como conjunto
lgico y la Base de Datos para la parte fsica.
Cuando hablamos de la Instancia de Oracle Server, hablamos de la estructura de memoria principal del servidor,
llamada SGA, y sus procesos en segundo plano. La SGA se compone mnimamente de cuatro estructuras de
memoria, como ser el Buffer Cache, Data Base Cache, el Conjunto Compartido Shared Pool, el Redo Log Buffer y
el conjunto de Java Java Pool. De la misma manera, los procesos en segundo plano principales son el System
Monitor (SMON), Process Monitor (PMON), Database Writer (DBWn), Log Writer (LGWR) y el proceso Checkpoint
(CKPT). La Figura 1.7 muestra las responsabilidades de cada uno de estos mecanismos.
Estas estructuras y procesos ocupan espacio en la memoria del Oracle Server al momento de iniciar la instancia. La
tabla de la Figura 1.8 muestra cuatro parmetros con sus valores por defecto, que gobiernan principalmente el
comportamiento de la SGA. Cabe recordar que si bien estos parmetros se definen a nivel inicial, la mayora de
ellos pueden ser modificados dinmicamente una vez iniciada la instancia.
Para Oracle 9i, el tamao general de la SGA se define por un solo parmetro: SGA_MAX_SIZE; de esta manera, los
tamaos de buffer de DB Cache y Shared Pool pueden modificarse dinmicamente hasta llegar a este mximo.
Figura 1.6



Por otro lado, la Base de Datos de Oracle Server se compone de los archivos fsicos, como ser los de control, datos y
Redo Log. Adicionalmente se pueden asociar otros archivos, como ser el init.ora, Alert.log los archivos Redo Log
Archivados.

Figura 1.7
Figura 1.8



1.10. EJERCICIO DE REPASO: CONCEPTOS DE TUNING
Responder por Verdadero / Falso en funcin de la afirmacin.

1.11. EJERCICIO INTEGRADOR: VISION GENERAL DE ORACLE 9i PEFOMANCE TUNING



1.12. SINTESIS
Adoptar una metodologa probada de ajuste de rendimiento es la clave para Oracle al momento de ganar
performance. Desde que se ha tomado conciencia de la necesidad de analizar el sistema completo, los diseadores
de aplicaciones, desarrolladores, administradores y DBAs son los que deben participar de este proceso de ajuste.
Las recomendaciones de Oracle en cuanto a las metodologas, incluyen una aproximacin para el momento del
desarrollo y testing de las aplicaciones y una para el momento que estas aplicaciones se pasan a un entorno
productivo.
Teniendo en consideracin todos los aspectos que envuelven este proceso, el ajuste debe tomar un lugar de
realizacin desde una perspectiva metodolgica, para asegurarse que se realicen bancos de prueba y se
establezcan objetivos medibles para tener xito en esta tarea.



UNIDAD 2
HERRAMIENTAS DE DIAGNOSTICO Y TUNING
2.1. OBJETIVOS
En la presente unidad el alumno deber identificar los componentes intervinientes en el ajuste de rendimiento, los
archivos de rastreo de los procesos en segundo plano, las vistas dinmicas de rendimiento para el ajuste.
Tambin deber desarrollar habilidades para recopilar estadsticas con OEM (Oracle Enterprise Manager), y saber
describir las principales herramientas disponibles para el ajuste.
Por ltimo es muy importante conocer el paquete StatsPack

2.2. CUESTIONARIO DE INICIACION



2.3. EL ARCHIVO ALERT.LOG
El archivo de alertas (ALERT.LOG) registra mensajes con informacin y mensajes con errores de todos los eventos
que ocurren en el servidor de base de datos durante su operacin. Cabe destacar que estos registros se almacenan
en forma cronolgica desde el ms antiguo al ms reciente. Este archivo se encuentra ubicado en el parmetro
BACKGROUND_DUMP_DEST del archivo de inicializacin init.ora. Es importante tener en cuenta que si se utiliza
OFA (Optimal Fexible Architecture) el nombre del archivo puede variar en funcin del sistema operativo que se
est utilizando, ya que para la tecnologa UNIX, la convencin del archivo ser alert_SID.log, y para Windows se
utilizar el formato SIDalrt.log (para ambos casos SID representa el nombre de la instancia Oracle a la que el
archivo pertenece).
La Figura 2.1 contiene una muestra del contenido que se genera en un archivo de alertas al iniciar una instancia.
El archivo de alertas es constantemente actualizado por Oracle Server mientras que la base de datos se encuentre
en operacin, por lo que si no se le realiza mantenimiento alguno su crecimiento podra llegar a generar un archivo
inmanejable y dificultoso para trabajar.
Algunas tareas comunes de mantenimiento del archivo de alertas es renombrar, recortar eliminar. Una vez
realizado esto, Oracle crea un archivo de alertas nuevo.
La Figura 2.2 contiene una enumeracin del contenido de este tipo de archivos.

Figura 2.1



2.4. EL ARCHIVO TRACE
La ubicacin de los archivos de rastreo de los Procesos en Segundo Plano se define por el parmetro
BACKGROUND_DUMP_DEST, al igual que el archivo de alertas.
Oracle 9i permite contar con estos archivos para obtener informacin detallada de rastreo para los eventos de
estos procesos. Por defecto, la mayora de los eventos del servidor no generarn un archivo de rastreo, pero hay
ciertos eventos que obligadamente lo harn, como ser errores detectados por cualquiera de estos procesos.
Para el caso de los archivos de rastreo de los Procesos de Usuario, estos incorporan el identificador de proceso del
sistema operativo en el nombre del archivo.
El DBA puede basarse en la vistas de rendimiento V$PROCESS y V$SESSION para identificar qu usuario ha
generado un archivo de rastreo en particular. La Figura 1 demuestra la utilizacin de estas vistas en donde se
puede ver que el archivo de rastreo llamado ora_prod_42992.trc pertenece a la sesin de MATT.
Hay eventos que automticamente generarn archivos de rastreo, como ser errores de proceso, pero si se desea
registrar toda la actividad de los usuarios, el DBA deber definir en el archivo de inicio que se desea hacer esta
accin. Este registro de actividades puede realizarse utilizando los siguientes mtodos:
Rastreo a nivel de instancia: Este evento se lo define utilizando el parmetro SQL_TRACE en TRUE. De esta
manera, todos los procesos que se estn ejecutando en la instancia crearn su propio archivo de rastreo; es por
esto que esta utilidad debe utilizarse con especial cuidado, ya que puede producir un incremento de espacio y
procesamiento adicional sobre el sistema. El valor por defecto es FALSE.
Rastreo a nivel de sesin ( de usuario): Los usuarios pueden iniciar detener su propio rastreo con el
siguiente comando: ALTER SESSION SET SQL_TRACE = [TRUE | FALSE]. Esta accin no puede ser ejecutada
siempre, ya que un usuario que slo puede ejecutar una aplicacin no tendra esta capacidad. Para esto, Oracle
provee un paquete PL/SQL llamado DBMS_SYSTEM que contiene un procedimiento llamado
SET_SQL_TRACE_IN_SESSION y permite activar el rastreo de otro usuario al proporcionar como parmetro el
identificador de sistema (SID System Identifier) y el nmero de serie (serial#) del usuario, valores que surgen
de la vista V$SESSION. La Figura 2.4 muestra cmo se activa la sesin del usuario JOE, utilizando la vista de la
Figura 2.3.
Figura 2.2



Figura 2.3
Figura 2.4



2.5. HERRAMIENTAS DISPONIBLES
A lo largo de este curso se trabajar con una serie de herramientas, disponibles en Oracle Server, cuyo uso
depender del mbito en donde se desee ajustar. Dentro del dominio de herramientas que se pueden utilizar para
el ajuste, se encuentran:
OEM: Oracle Enterprise Manager dispone de una variedad de herramientas grficas (GUI). Estas herramientas
en la consola OEM ayudan al DBA a monitorear, de una forma grfica, las bases de datos.
Paquetes de diagnstico y ajuste: Oracle cuenta con un set de herramientas para complementar el proceso de
ajuste a realizar por el DBA, donde se pueden utilizar componentes para identificar, diagnosticar y reparar
problemas en la base de datos.
STATSPACK: Esta herramienta utiliza una combinacin de scripts, provistos por Oracle, y de paquetes PL/SQL
para producir una evaluacin de la performance general de la base de datos, para luego utilizar estos datos
estadsticos en las decisiones de ajuste.
Vistas del Diccionario de datos: existen dos formas de contar con la informacin de la base de datos,
utilizando vistas dinmicas de rendimiento (Vistas "V$") y las vistas del diccionario de datos.
UTLBSTAT.sql y UTLESTAT.sql: el propsito de estos scripts es capturar y sumarizar en un reporte virtual
toda la actividad de rendimiento de la base de datos durante un perodo de tiempo definido

2.6. OEM (ORACLE ENTERPRISE MANAGER)
La consola de Oracle Enterprise Manager integra los componentes de Administracin de Bases de Datos, Ajustes y
Diagnstico, en un ambiente centralizado y grfico desde donde se puede administrar todas las bases de datos.
Estas son algunas de sus caractersticas:
Paquete de Diagnsticos de Oracle:
Monitor de Bloqueos
Administrador de Performance
Visin general de rendimiento
Sesiones
SQL
Visor de rastreos de Oracle
Figura 2.5



Paquete de Oracle Tuning:
Oracle Expert
Analizador de SQL
Mapa de Tablespaces
Oracle Expert es una herramienta grfica que se utiliza para analizar los datos en funcin del rendimiento, de
acuerdo a las especificaciones del DBA. Una vez que los datos son analizados, Oracle utiliza una interface embebida
para formular una serie de recomendaciones. Estas recomendaciones pueden ser presentadas en un reporte
sumariado con scripts de SQL y hasta la generacin automtica de un nuevo archivo de parmetros init.ora. La
tabla de la Figura 2.6 muestra la metodologa que presenta Oracle Expert, donde cada uno de estos pasos es
representado en una pantalla en la interface de Oracle Expert.

2.7. STATSPACK
Antes de comenzar a utilizar el paquete STATSPACK para monitorear el rendimiento de la base de datos, se debe
crear un esquema llamado PERFSTAT que contendr todos los objetos necesarios para que la herramienta
STATSPACK almacene su informacin. Para esto, se debe ejecutar (conectado con el usuario SYS) el script llamado
spcreate.sql. Cabe destacar que la clave por defecto del usuario PERFSTAT es PERFSTAT. Por razones de seguridad,
esta clave debera ser cambiada. Durante la ejecucin de este script, se le preguntar por el nombre del tablespace
por defecto que utilizar. Para los datos se crear automticamente un nuevo tablespace de 250MB.
Una vez que los componentes de STATSPACK se han configurado correctamente, se los puede utilizar para
monitorear el rendimiento de la base de datos. Este proceso se lo puede realizar de dos maneras diferentes:
manualmente, ejecutando el comando STATSPACK.SNAP en forma automtica, con SPAUTO.SQL donde se
agendan los procesos.
Una vez ejecutado el procedimiento SNAP, una foto de los valores actuales relacionados a estadsticas de
rendimiento son capturados y almacenados en las tablas residentes en el esquema PERFSTAT. Estas estadsticas
sern comparadas contra la prxima captura que se realice con el proceso SNAP. Estas estadsticas que se van
colectando no son eliminadas de la base de datos. El mismo funcionamiento ocurre para la captura de contenidos
en forma automtica, la diferencia consiste en que se la puede programar a intervalos regulares de tiempo. Este
script (SPAUTO.SQL) utiliza el paquete DBMS_JOBS para programar las tareas de recoleccin de informacin
estadstica.
Figura 2.6



Al contener toda la informacin estadstica necesaria para tomar las decisiones de ajuste necesarias, es posible
mostrar un reporte que contenga las recomendaciones de ajuste utilizando el script SPREPORT.SQL. Durante la
ejecucin de este script se le preguntarn los datos desde qu foto a qu se desea analizar. La Figura 2.7 muestra
un ejemplo de la utilizacin de este script.

2.8. VISTAS DEL DICCIONARIO DE DATOS
Existen aproximadamente 170 vistas del diccionario de datos del DBA en Oracle 9i. Estas vistas se forman sobre
tablas llamadas Tablas Base (quienes forman el diccionario de datos). Al igual que las vistas dinmicas de
rendimiento, estas tablas base se encuentran muy poco documentadas y tienen un nombre poco significativo, con
lo que el DBA debe recurrir a las vistas del diccionario (vistas de las tablas base) para poder tener informacin
concreta.
La tabla de la Figura 2.8 muestra un detalle de las vistas ms utilizadas.
Figura 2.7



2.9. PRINCIPALES VISTAS DE RENDIMIENTO
Al hablar de vistas de rendimiento del diccionario de datos para el ajuste, podramos llegar a contar
aproximadamente 225 vistas dinmicas de rendimiento en Oracle 9i. Estas vistas se basan en tablas dinmicas que
en su conjunto se las llama las tablas X$. Estas tablas virtuales existen solamente en memoria y seguramente no
estarn documentadas; de ms est decir que sus nombres se encuentra codificados, por ejemplo, X$KSMSP
X$KWQSI. Para poder lidiar con este tipo de tablas es que se utilizan las vistas dinmicas (V$).
La tabla de la Figura 2.9 muestra una lista que enumera las vistas dinmicas de rendimiento que son utilizadas con
mayor frecuencia.
En general, las consultas a la base de datos, principalmente a la vista V$SYSSTAT, mostrarn estadsticas para la
instancia desde que sta fue iniciada. Al unir esta vista con otras vistas relevantes se puede tener una imagen
general del rendimiento de la base de datos.
De la misma manera, al consultar la vista V$SESSTAT, se tendr informacin sobre estadsticas de una sesin en
particular

Figura 2.8
Figura 2.9



2.10. HERRAMIENTAS DESARROLLADAS POR EL DBA
Probablemente las utilidades provistas por Oracle Server cumplan con los requisitos necesarios para monitorear el
comportamiento de la base de datos. Pero es posible que se le presenten escenarios de negocio donde se le
presenta la necesidad de tener que realizar ciertas consultas operaciones que no pueden satisfacer
completamente estas herramientas. De esta manera, el DBA tiene la posibilidad de poder realizar sus propias
herramientas de monitoreo ajustes de rendimiento para sus bases de datos.
Por lo general, estos programas propios suelen contener:
Comprobaciones de espacio libre de los archivos de datos para comprobar su espacio.
Monitoreo de los segmentos de datos.
Definicin particular de la estructura de la base de datos.
Utilizacin de eventos y automatizacin de tareas programadas.
Utilizacin de paquetes suministrados por Oracle.
Hay que tener en cuenta el uso de ciertos parmetros al momento de la recopilacin de estadsticas:
El parmetro STATISTICS_LEVEL determina el nivel de recopilacin, teniendo los valores que se puede consultar
con la vista V$STATISTICS_LEVEL:
BASIC: No se recopilan datos estadsticos.
TYPICAL: Es el valor por defecto. Se recopilan estadsticas a nivel de segmento.
ALL: Se recopilan todo tipo de estadsticas, incluyendo las de Sistema Operativo.
Consultar la vista V$STATISTICS_LEVEL para determinar a qu parmetros afecta el parmetro
STATISTICS_LEVEL.
El parmetro TIMED_STATISTICS se utiliza para recopilar no, estadsticas de tiempo. Los valores que pueden
tomar entonces es TRUE FALSE.
El parmetro DB_CACHE_ADVICE puede tomar los valores:
OFF: No se recopilan estadsticas y no ocupa memoria.
READY: Se le asigna memoria pero no recopila estadsticas.
ON: Se recopilan estadsticas y se asigna memoria al proceso

Figura 2.10



2.11. ARCHIVOS DE RASTREO DE USUARIOS
Adicionalmente, para administrar correctamente los archivos de rastreo que se pudieron haber generado, ya sea
para el usuario, como para los procesos en segundo plano, hay que tener muy en cuenta el crecimiento de los
mismos. Por ejemplo, cuando se rastrean los eventos de la sesin de un usuario, cada accin que el usuario realiza
contra la instancia es incluida en el archivo de rastreo.
Si el rastreo ( tracking) es dejado corriendo durante un perodo de tiempo prolongado, los archivos de rastreo
podran crecer demasiado y hasta podran causar que se llene un disco (especificado por el parmetro
USER_DUMP_DEST) en el archivo de parmetros init.ora.
Para poder gobernar esto, se puede utilizar el parmetro MAX_DUMP_FILE_SIZE que le permite al DBA limitar el
tamao mximo que un archivo de rastreo puede crecer. El valor de este parmetro puede expresarse tanto en
bloques del sistema operativo como en bytes. La tabla que muestra la Figura 2.11 presenta la variedad de formas
en que este parmetro puede ser definido.
Como se ha mencionado anteriormente, al igual que el archivo de alertas, de procesos en segundo plano, de
eventos y de rastreo de usuarios, los archivos resultantes deben ser renombrados, recortados eliminados
ocasionalmente para mejorar la capacidad de utilizacin de los mismos cuando se los necesiten

2.12. EJERCICIO DE REPASO: METODOLOGIA DE ORACLE EXPERT
Identificar los pasos necesarios para satisfacer la metodologa que aplica Oracle Expert.

Figura 2.11



2.13. EJERCICIO INTEGRADOR: HERRAMIENTAS DE DIAGNOSTICO Y TUNING

2.14. SINTESIS
Tener informacin correcta, precisa y completa es una tarea crtica antes, durante y despus del proceso de ajuste
de rendimiento. Esta informacin puede obtenerse de varios medios y ubicaciones. El archivo de alertas contiene
variada informacin sobre la instancia que se est ejecutando, mientras que los archivos de rastreo de los procesos
de usuario y de los procesos en segundo plano pueden utilizarse para conocer qu es lo que est pasando
directamente en la base de datos. Las vistas dinmicas de rendimiento (V$) y las vistas del diccionario de datos
(DBA) permiten al administrador obtener informacin importante sobre estadsticas de la base de datos en
funcionamiento.
Adems, Oracle ofrece dos utilidades: STATSPACK y las herramientas UTLBSTAT.SQL y UTLESTAT.SQL, con las que
se pueden capturar estadsticas durante un determinado perodo de tiempo para luego analizarse utilizando los
reportes de salida de estas utilidades.
La consola visual OEM (Oracle Enterprise Manager) provee informacin de ajuste a travs de sus monitores de
eventos, utilizando un Agente Inteligente (Intelligent Agent). Mucha informacin til de rendimiento brinda el OEM
combinando una serie de paquetes para este cometido, como ser los paquetes de diagnstico y ajuste y Oracle
Expert.

Teoría

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Teoría

Diunggah oleh

Hak Cipta:

Format Tersedia

UNIVERSIDAD NACIONAL

Anda mungkin juga menyukai