1 - Diagnóstico general de la base de datos

Transcripción

1 1 - Diagnóstico 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í también, conocer los procesos derivados de las consultas SQL y cómo interactúa 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 características, por lo que suele llegar a ser dificultoso entender por dónde comenzar a focalizar los esfuerzos del ajuste ó?tuning?. Como solución a estos conceptos, a lo largo de este curso se expondrán y aplicarán metodologías de ajustes que ya están probadas para poder llegar sin problemas a cumplir con los objetivos deseados.

2 1.1 Visión general de Oracle 9i Performance Tuning En la figura se presenta una clasificación de los contenidos tratados en esta subunidad, teniendo en cuenta, la relación de los mismos con el Material del Estudiante (kit). Esta clasificación sugiere diferentes momentos de lectura, estudio y revisión, entre los contenidos de este currículo y el Material del Estudiante (Kit). Según esta clasificación los contenidos pueden ser de: Lectura Previa: Se sugiere la lectura de estos contenidos antes de abordar los subtemas, temas o unidades asociados al Material del Estudiante (Kit). Lectura Complementaria: Se sugiere la lectura de estos contenidos como complemento a los subtemas, temas o unidades asociados al Material del Estudiante (Kit). Lectura Adicional: Se sugiere la lectura posterior de estos contenidos, como material adicional a los tratados en el Material del Estudiante (Kit). Prácticas : Actividades de laboratorios e interactivas incluidas como práctica adicional al Material del Estudiante (Kit).

3 1.1 Visión general de Oracle 9i Performance Tuning Objetivos En el presente subcapítulo aspiramos a que usted logre definir los roles asociados al proceso de ajuste, que pueda describir las dependencias entre los ajustes de las distintas fases de desarrollo, que sea capaz de identificar los problemas comunes de ajuste, y que pueda realizar actividades de ajuste. También nos interesa que usted llegue a comprender cómo alcanzar un equilibrio entre rendimiento y seguridad.

4 1.1 Visión general de Oracle 9i Performance Tuning Cuestionario de Iniciación Coloque el cursor sobre los botones numerados que aparecen a la izquierda para visualizar las preguntas de iniciación. Si desea, puede desplegar su respuesta.

5 1.1 Visión general de Oracle 9i Performance Tuning Conceptos de Tuning Los ajustes que pueden resultar de un posible problema de performance ó de algún monitoreo preventivo pueden tener varios ámbitos, como ser el ámbito del diseño y desarrollo de software; el ámbito del diseño 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 diseño que cumpla satisfactoriamente con los requerimientos del negocio (y si los requerimientos a su vez son los realmente necesarios), los problemas de ajuste disminuirán significativamente. La Figura muestra un esquema de la relación entre un buen diseño de software y su relación con los posibles puntos a ajustar. Desde el punto de vista de la base de datos, no solamente habría que mirarla como un software de gestión 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 también se debe tener en cuenta la utilización de los discos rígidos y en función de esto poder determinar los tiempos de recuperación, terminando de asentar el concepto de Tiempo Medio para la Recuperación (MTTR - Mean Time To Recover)

6 1.1 Visión general de Oracle 9i Performance Tuning Objetivos de Tuning Independientemente de la forma de realizar el ajuste a la aplicación, 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 definición de bancos de prueba, seguimientos históricos de los datos ó estadísticas a medir en el proceso de ajuste. Uno de los pasos iniciales al momento de reproducir un aspecto que requiere ajuste, es la utilización de un Banco de Pruebas. De su utilización posiblemente se saque una idea de cómo 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 muestra una enumeración de estos aspectos. Idealmente, todas estas áreas deberían ser monitoreadas simultáneamente por un período de tiempo, mientras el sistema se encuentra en un estado de procesamiento normal. Los resultados medidos de estas áreas se suelen concentrar en estadísticas y velocidades de respuesta. Las estadísticas se suelen obtener de la ejecución 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 estadísticas se suelen medir en porcentajes ó tiempos de espera.

7 1.1 Visión general de Oracle 9i Performance Tuning 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 enumera los errores comúnmente 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 pérdida de performance. Esto se debe a una posible mala resolución de diseño al momento de definir la forma de consultar a la base de datos. En los capítulos siguientes se verá más en detalle cómo detectar y solucionar este tipo de problemas. Los planes de ejecución no solamente surgen de una sentencia SQL ineficiente, sino que una sentencia correctamente definida también podría llevar a una mala elección de un plan de ejecución (el plan de ejecución se verá en los próximos capítulos), ya que su principal basamento es la estadística. 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 definición de estas estructuras podría llevar a un muy mal desempeño de las respuestas del Oracle Server.

8 1.1 Visión general de Oracle 9i Performance Tuning Tuning en la etapa de Desarrollo Tradicionalmente Oracle recomendaba una resolución de la metodología de ajuste de rendimiento basado en un modelo descendente (top-down) que se focalizaba principalmente en el diseño del SQL embebido en la aplicación antes de analizar las características propias del ajuste, relacionadas al manejo de las estructuras de memoria y a los accesos físicos a discos rígidos. Es cierto que esta metodología 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 metodologías ó formas de resolver el problema del ajuste de rendimiento no deben ser mutuamente excluyentes. Estas metodologías existen para ayudar al DBA a reconocer dónde focalizar los esfuerzos del ajuste, que seguramente variarán en función del contexto. En definitiva, siempre se debe tener en cuenta que para lograr un buen resultado en el ajuste de un sistema, no sólo hace falta el conocimiento del DBA, sino que también se requiere de un trabajo en conjunto de los diseñadores, desarrolladores y administradores de sistemas ó red. La metodología 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 más apropiado para ajustar sistemas en producción. Cuando hablamos de sistemas en etapa de desarrollo la metodología descendente enfatiza la revisión de las características más probables de ajuste en una primera etapa, dejando las áreas que tengan menor impacto en la performance para un segundo análisis. La Tabla de la Figura muestra el orden que se plantea en esta metodología. De esta manera, las áreas examinadas inicialmente se encuentran relacionadas con la aplicación directamente hasta descender a cuestiones base. La experiencia cuenta que el 90% de los ajustes se hacen en las primeras etapas.

9 1.1 Visión general de Oracle 9i Performance Tuning Tuning en la etapa de Producción De manera contraria al ajuste en el proceso de desarrollo de la aplicación, el ajuste por medio de Principios del Ajuste de Rendimiento que Oracle recomienda se focaliza mayormente en técnicas para identificar y resolver ciertos aspectos ajustables. En capítulos posteriores se tratarán estos temas. La tabla que se ve en la Figura muestra los aspectos principales de esta metodología. Cabe destacar que algunas de las áreas mencionadas en la tabla se solapan con la metodología tradicional. La principal diferencia que esta metodología presenta es que tiene en cuenta que los cambios en un sistema en producción son muy difíciles y costosos. A medida que una aplicación se vuelve más prevaleciente, esta metodología se vuelve más importante por su forma de aplicación, ya que tiene en cuenta los factores de mayor importancia a ajustar sumado a un perfil más formal. A lo largo de este curso se verán en detalle los aspectos correspondientes a la aplicación de esta metodología.

10 1.1 Visión general de Oracle 9i Performance Tuning Comparaciones De la utilización de una metodología tradicional (top-down) ó 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 genérica los aspectos que se deberían tener en cuenta: -Características comunes que se suelen ajustar. -Verificar los errores de los logs de alerta. -Chequear que los valores de los parámetros de inicialización 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 más 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.

11

12 1.1 Visión general de Oracle 9i Performance Tuning Lectura Adicional: Revisión de la Arquitectura Oracle Uno de los factores de éxito de DBA es comprender profundamente la arquitectura de Oracle y sus mecanismos, como así también 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 genérico de esta arquitectura antes de comenzar en profundidad. La arquitectura de Oracle Server puede dividirse en dos categorías principales, que son la Instancia, como conjunto lógico y la Base de Datos para la parte física. 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 mínimamente 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 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 muestra cuatro parámetros con sus valores por defecto, que gobiernan principalmente el comportamiento de la SGA. Cabe recordar que si bien estos parámetros se definen a nivel inicial, la mayoría de ellos pueden ser modificados dinámicamente una vez iniciada la instancia. Para Oracle 9i, el tamaño general de la SGA se define por un solo parámetro: SGA_MAX_SIZE; de esta manera, los tamaños de buffer de DB Cache y Shared Pool pueden modificarse dinámicamente hasta llegar a este máximo. Por otro lado, la Base de Datos de Oracle Server se compone de los archivos físicos, 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.

13 1.1 Visión general de Oracle 9i Performance Tuning EI: Conceptos de Tuning Responder Verdadero/Falso en función de la afirmación

14 1.1 Visión general de Oracle 9i Performance Tuning Síntesis Adoptar una metodología 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 diseñadores de aplicaciones, desarrolladores, administradores y DBA s son los que deben participar de este proceso de ajuste. Las recomendaciones de Oracle en cuanto a las metodologías, incluyen una aproximación 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 consideración todos los aspectos que envuelven este proceso, el ajuste debe tomar un lugar de realización desde una perspectiva metodológica, para asegurarse que se realicen bancos de prueba y se establezcan objetivos medibles para tener éxito en esta tarea.

15 1.1 Visión general de Oracle 9i Performance Tuning EInt: Visión general de Oracle 9i Performance Tuning A continuación le proponemos un ejercicio que pondrá a prueba sus conocimientos acerca de la totalidad de este subcapítulo.

16 1.2 Herramientas de Diagnóstico y Tuning En la figura se presenta una clasificación de los contenidos tratados en esta subunidad, teniendo en cuenta, la relación de los mismos con el Material del Estudiante (kit). Esta clasificación sugiere diferentes momentos de lectura, estudio y revisión, entre los contenidos de este currículo y el Material del Estudiante (Kit). Según esta clasificación los contenidos pueden ser de: * Lectura Previa: Se sugiere la lectura de estos contenidos antes de abordar los subtemas, temas o unidades asociados al Material del Estudiante (Kit). * Lectura Complementaria: Se sugiere la lectura de estos contenidos como complemento a los subtemas, temas o unidades asociados al Material del Estudiante (Kit). * Lectura Adicional: Se sugiere la lectura posterior de estos contenidos, como material adicional a los tratados en el Material del Estudiante (Kit). * Prácticas : Actividades de laboratorios e interactivas incluidas como práctica adicional al Material del Estudiante (Kit).

17 1.2 Herramientas de Diagnóstico y Tuning Objetivos En el presente subcapítulo nos interesa que usted pueda identificar tanto a los componentes intervinientes en el ajuste de rendimiento, como a los archivos de rastreo de los procesos en segundo plano, o como a las vistas dinámicas de rendimiento para el ajuste. También pretendemos que usted sepa recopilar estadísticas con OEM, y que sepa describir las principales herramientas disponibles para el ajuste. Por último consideramos importante que conozca el paquete StatsPack.

18

19 1.2 Herramientas de Diagnóstico y Tuning Cuestionario de Iniciación Coloque el cursor sobre los botones numerados que aparecen a la izquierda para visualizar las preguntas de iniciación. Si desea, puede desplegar su respuesta.

20

21

22 1.2 Herramientas de Diagnóstico y Tuning El archivo ALERT.LOG El archivo de alertas (ALERT.LOG) registra mensajes con información y mensajes con errores de todos los eventos que ocurren en el servidor de base de datos durante su operación. Cabe destacar que estos registros se almacenan en forma cronológica desde el más antiguo al más reciente. Este archivo se encuentra ubicado en el parámetro BACKGROUND_DUMP_DEST del archivo de inicialización init.ora. Es importante tener en cuenta que si se utiliza OFA (Optimal Fexible Architecture) el nombre del archivo puede variar en función del sistema operativo que se esté utilizando, ya que para la tecnología UNIX, la convención 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 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 operación, por lo que si no se le realiza mantenimiento alguno su crecimiento podría 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 contiene una enumeración del contenido de este tipo de archivos.

23 1.2 Herramientas de Diagnóstico y Tuning Archivos Trace La ubicación de los archivos de rastreo de los Procesos en Segundo Plano se define por el parámetro BACKGROUND_DUMP_DEST, al igual que el archivo de alertas. Oracle 9i permite contar con estos archivos para obtener información detallada de rastreo para los eventos de estos procesos. Por defecto, la mayoría de los eventos del servidor no generarán un archivo de rastreo, pero hay ciertos eventos que obligadamente lo harán, 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 demuestra la utilización de estas vistas en donde se puede ver que el archivo de rastreo llamado ora_prod_42992.trc pertenece a la sesión de MATT. Hay eventos que automáticamente generarán 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 acción. Este registro de actividades puede realizarse utilizando los siguientes métodos: Rastreo a nivel de instancia: Este evento se lo define utilizando el parámetro SQL_TRACE en TRUE. De esta manera, todos los procesos que se estén ejecutando en la instancia crearán 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 sesión (ó de usuario): Los usuarios pueden iniciar ó detener su propio rastreo con el siguiente comando: ALTER SESSION SET SQL_TRACE = [TRUE FALSE]. Esta acción no puede ser ejecutada siempre, ya que un usuario que sólo puede ejecutar una aplicación no tendría 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 parámetro el identificador de sistema (SID System Identifier) y el número de serie (serial#) del usuario, valores que surgen de la vista V$SESSION. La Figura muestra cómo se activa la sesión del usuario JOE, utilizando la vista de la figura 1.

24 1.2 Herramientas de Diagnóstico y Tuning 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 gráficas (GUI). Estas herramientas en la consola OEM ayudan al DBA a monitorear, de una forma gráfica, las bases de datos. Paquetes de diagnóstico 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 combinación de scripts, provistos por Oracle, y de paquetes PL/SQL para producir una evaluación de la performance general de la base de datos, para luego utilizar estos datos estadísticos en las decisiones de ajuste. Vistas del Diccionario de datos: Existen dos formas de contar con la información de la base de datos, utilizando vistas dinámicas de rendimiento (Vistas "V$") y las vistas del diccionario de datos. UTLBSTAT.sql y UTLESTAT.sql: El propósito de estos scripts es capturar y sumarizar en un reporte virtual toda la actividad de rendimiento de la base de datos durante un período de tiempo definido.

25 1.2 Herramientas de Diagnóstico y Tuning OEM La consola de Oracle Enterprise Manager integra los componentes de Administración de Bases de Datos, Ajustes y Diagnóstico, en un ambiente centralizado y gráfico desde donde se puede administrar todas las bases de datos. Estas son algunas de sus características: Paquete de Diagnósticos de Oracle: -Monitor de Bloqueos -Administrador de Performance -Visión 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 gráfica que se utiliza para analizar los datos en función 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 generación automática de un nuevo archivo de parámetros init.ora. La tabla de la Figura muestra la metodología que presenta Oracle Expert, donde cada uno de estos pasos es representado en una pantalla en la interface de Oracle Expert.

26

27 1.2 Herramientas de Diagnóstico y Tuning 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 información. 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 debería ser cambiada. Durante la ejecución de este script, se le preguntará por el nombre del tablespace por defecto que utilizará. Para los datos se creará automáticamente 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 automática, con SPAUTO.SQL donde se agendan los procesos. Una vez ejecutado el procedimiento SNAP, una foto de los valores actuales relacionados a estadísticas de rendimiento son capturados y almacenados en las tablas residentes en el esquema PERFSTAT. Estas estadísticas serán comparadas contra la próxima captura que se realice con el proceso SNAP. Estas estadísticas que se van colectando no son eliminadas de la base de datos. El mismo funcionamiento ocurre para la captura de contenidos en forma automática, 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 recolección de información estadística. Al contener toda la información estadística 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 ejecución de este script se le preguntarán los datos desde qué foto a qué foto se quiere analizar. La Figura muestra un ejemplo de la utilización de este script.

28 1.2 Herramientas de Diagnóstico y Tuning 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 dinámicas 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 información concreta. La tabla de la Figura muestra un detalle de las vistas más utilizadas.

29 1.2 Herramientas de Diagnóstico y Tuning Principales Vistas de Rendimiento Al hablar de vistas de rendimiento del diccionario de datos para el ajuste, podríamos llegar a contar aproximadamente 225 vistas dinámicas de rendimiento en Oracle 9i. Estas vistas se basan en tablas dinámicas que en su conjunto se las llama las tablas X$. Estas tablas virtuales existen solamente en memoria y seguramente no estarán documentadas; de más 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 dinámicas (V$). La tabla de la Figura muestra una lista que enumera las vistas dinámicas de rendimiento que son utilizadas con mayor frecuencia. En general, las consultas a la base de datos, principalmente a la vista V$SYSSTAT, mostrarán estadísticas 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á información sobre estadísticas de una sesión en particular.

30 1.2 Herramientas de Diagnóstico y Tuning 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. Monitoreo de los segmentos de datos. Definición particular de la estructura de la base de datos. Utilización de eventos y automatización de tareas programadas. Hay que tener en cuenta el uso de ciertos parámetros al momento de la recopilación de estadísticas: El parámetro STATISTICS_LEVEL determina el nivel de recopilación, teniendo los valores que se puede consultar con la vista V$STATISTICS_LEVEL: BASIC: No se recopilan datos estadísticos. TYPICAL: Es el valor por defecto. Se recopilan estadísticas a nivel de segmento. ALL: Se recopilan todo tipo de estadísticas, incluyendo las de Sistema Operativo. El parámetro TIMED_STATISTICS se utiliza para recopilar ó no, estadísticas de tiempo. Los valores que pueden tomar entonces es TRUE ó FALSE. El parámetro DB_CACHE_ADVICE puede tomar los valores: OFF: No se recopilan estadísticas y no ocupa memoria. READY: Se le asigna memoria pero no recopila estadísticas. ON: Se recopilan estadísticas y se asigna memoria al proceso.

31 1.2 Herramientas de Diagnóstico y Tuning Lectura Adicional: 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 sesión de un usuario, cada acción que el usuario realiza contra la instancia es incluida en el archivo de rastreo. Si el rastreo (ó tracking) es dejado corriendo durante un período de tiempo prolongado, los archivos de rastreo podrían crecer demasiado y hasta podrían causar que se llene un disco (especificado por el parámetro USER_DUMP_DEST) en el archivo de parámetros init.ora. Para poder gobernar esto, se puede utilizar el parámetro MAX_DUMP_FILE_SIZE que le permite al DBA limitar el tamaño máximo que un archivo de rastreo puede crecer. El valor de este parámetro puede expresarse tanto en bloques del sistema operativo como en bytes. La tabla que muestra la Figura presenta la variedad de formas en que este parámetro 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 utilización de los mismos cuando se los necesiten.

32 1.2 Herramientas de Diagnóstico y Tuning EI: MetodologÃa de Oracle Expert Identificar los pasos necesarios para satisfacer la metodologãa que aplica Oracle Expert

33 1.2 Herramientas de Diagnóstico y Tuning TP: Uso de la herramienta Oracle Expert Laboratorio TP: Uso de la herramienta Oracle Expert. Duración Estimada: 30 min.

34 1.2 Herramientas de Diagnóstico y Tuning Síntesis Tener información correcta, precisa y completa es una tarea crítica antes, durante y después del proceso de ajuste de rendimiento. Esta información puede obtenerse de varios medios y ubicaciones. El archivo de alertas contiene variada información 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 dinámicas de rendimiento (V$) y las vistas del diccionario de datos (DBA) permiten al administrador obtener información importante sobre estadísticas de la base de datos en funcionamiento. Además, Oracle ofrece dos utilidades: STATSPACK y las herramientas UTLBSTAT.SQL y UTLESTAT.SQL, con las que se pueden capturar estadísticas durante un determinado período de tiempo para luego analizarse utilizando los reportes de salida de estas utilidades. La consola visual OEM (Oracle Enterprise Manager) provee información de ajuste a través de sus monitores de eventos, utilizando un Agente Inteligente (Intelligent Agent). Mucha información útil de rendimiento brinda el OEM combinando una serie de paquetes para este cometido, como ser los paquetes de diagnóstico y ajuste y Oracle Expert.

35 1.2 Herramientas de Diagnóstico y Tuning EInt: Herramientas de Diagnóstico y Tuning A continuación le proponemos un ejercicio que pondrá a prueba sus conocimientos acerca de la totalidad de este subcapítulo.