Vous êtes sur la page 1sur 72

HERRAMIENTAS INFORMATICAS AVANZADAS

AJUSTE DEL RENDIMIENTO DE BASES DE DATOS ORACLE

I - DIAGNOSTICO GENERAL DE LA BASE DE DATOS II - DIMENSIONADO DE LA BASE DE DATOS III - DIMENSIONADO AVANZADO IV - AJUSTE DEL RENDIMIENTO (TUNING) V - PARAMETRIZACION AVANZADA VI - SISTEMA OPERATIVO Y CONCURRENCIA

PARTE I DIAGNOSTICO GENERAL DE LA BASE DE DATOS


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

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)


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.

CUESTIONARIO DE INICIACION

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.1

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.

1.2

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.3

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.

1.4

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.5

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.

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.6

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. 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.

1.7

1.8

EJERCICIO DE REPASO: CONCEPTOS DE TUNING


Responder por Verdadero / Falso en funcin de la afirmacin.

EJERCICIO INTEGRADOR: VISION GENERAL DE ORACLE 9i PEFOMANCE TUNING

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


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

CUESTIONARIO DE INICIACION

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.

2.1

2.2

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 delsistema 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.

2.3

2.4

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.5

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

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.6

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. 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.7

2.7

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.

2.8

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

2.9

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 parmetroSTATISTICS_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

2.10

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.11

EJERCICIO DE REPASO: METODOLOGIA DE ORACLE EXPERT


Identificar los pasos necesarios para satisfacer la metodologa que aplica Oracle Expert.

EJERCICIO INTEGRADOR: HERRAMIENTAS DE DIAGNOSTICO Y TUNING

Vous aimerez peut-être aussi