3 Dimensionado Avanzado Hasta ahora hemos visto cómo

3 Dimensionado Avanzado
Hasta ahora hemos visto cómo configurar y ajustar las estructuras de memoria de Buffer Cache y del
Conjunto Compartido. Estos dos componentes de la SGA junto al Redo Log Buffer que se tratará en este
capítulo son utilizados por cada aplicación Oracle.
En este capítulo en particular nos focalizaremos (a demás del Redo Log Buffer) en la parametrización,
monitoreo y ajuste de dos áreas de la SGA que posiblemente se usen ó no, dependiendo del ambiente y el
destino de negocio de cada implementación de Oracle en Particular:
* Componentes arquitectónicos del Conjunto Extendido
* Conjunto Java
Debido a que algunos ambientes Oracle no hacen uso de estos componentes, veremos los conceptos
esenciales relacionados a cada una de estas áreas antes de introducirnos en las técnicas requeridas para
monitorear y mejorar su rendimiento.
3.1
Dimensionado Dinámico de la Instancia
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
Dimensionado Dinámico de la Instancia
3.1.1
Objetivos
En el presente subcapítulo buscamos que usted pueda implementar la asignación dinámica de SGA y que
sepa cómo ajustar dinámicamente, tanto a la Buffer Cache como al Conjunto Compartido.
3.1
Dimensionado Dinámico de la Instancia
3.1.2
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.
3.1
Dimensionado Dinámico de la Instancia
3.1.3
Características de la SGA
Los componentes de la instancia – La SGA y los procesos en segundo plano – adquieren espacio en la
memoria del servidor inmediatamente después del inicio de la base de datos; mientras que los procesos en
segundo plano requeridos, siempre ocuparán la misma cantidad de memoria para sus operaciones, y cuatro
parámetros de inicio determinarán los requerimientos de tamaño de la SGA. Estos cuatro parámetros son
expuestos en la tabla de la Figura .
A pesar que estos parámetros son definidos en el archivo de parámetros de inicio, la mayoría de estos
parámetros de SGA pueden ser modificados dinámicamente, es decir, que el DBA puede modificar su tamaño
mientras la instancia está corriendo. En versiones previas de Oracle, el DBA necesitaba detener la instancia,
cambiar los valores y volver a iniciar para que tomen efecto y esto causaba problemas al momento de tener
que hacer mantenimiento ó ajuste de rendimiento.
En Oracle 9i el tamaño total de la SGA se determina por un solo parámetro de inicio: SGA_MAX_SIZE. Dentro
del valor máximo definido en este parámetro, se pueden variar los tamaños del Conjunto Compartido y del
Buffer Cache en forma dinámica, utilizando el comando ALTER SYSTEM. Si el valor del parámetro
SGA_MAX_SIZE es menor que la suma de sus componentes, al inicio de la instancia, Oracle ignorará este
parámetro y utilizará en su lugar la suma de los componentes.
3.1
Dimensionado Dinámico de la Instancia
3.1.4
Los Gránulos
Para poder ser capaz de gestionar los tamaños de las estructuras de memoria en forma dinámica, Oracle
9i creó una nueva unidad de almacenamiento para la SGA, llamada gránulo. De esta manera, la memoria
definida para la SGA es dividida en pequeñas unidades llamadas gránulos.
Un gránulo es una pieza de espacio contiguo de memoria virtual ubicada en la SGA. El tamaño de cada
gránulo varía de acuerdo al tamaño total de la SGA, definido en el archivo de parámetros. La tabla de la
Figura muestra los posibles valores de los gránulos de la SGA.
Cuando la instancia se inicia, los gránulos son creados en la SGA. Cada componente de la SGA adquiere
el espacio definido en el archivo de parámetros utilizando los gránulos disponibles.
Si los componentes de la SGA no utilizan la totalidad de los gránulos disponibles, los sobrantes permanecerán
en la SGA disponibles para su uso cuando alguno de los componentes de la SGA varíe su tamaño en forma
dinámica. Al hacer esto, se reacomodarán estos gránulos. De lo contrario, se retornará un error ORA-02097
ú ORA-04033. Ocasionalmente el DBA deberá reducir el tamaño de alguno de los componentes de la SGA
para poder incrementar ó detener la instancia para agrandar directamente el tamaño del parámetro
SGA_MAX_SIZE.
Cabe destacar que la capacidad de dividir la SGA en gránulos le da la flexibilidad a Oracle de poder manejar
tablespaces con distinto tamaño de bloque.
3.1
Dimensionado Dinámico de la Instancia
3.1.5
Gestión de los Gránulos
Durante el inicio de la instancia es cuando se obtiene el valor del parámetro SGA_MAX_SIZE y lo divide en
gránulos. El tamaño mínimo que puede tomar la SGA se rige por: un gránulo para los Buffers Redo, un gránulo
para el Buffer Cache y un gránulo para el Conjunto Compartido.
Como comentamos anteriormente, el tamaño del Buffer Cache y del Conjunto Compartido puede cambiar en
forma dinámica con el comando ALTER SYSTEM.
El ensayo de la Figura muestra la ejecución de la consulta que modifica el tamaño del Buffer Cache de 48MB
a 100MB.
Cambiar el tamaño del Buffer Cache con el comando ALTER SYSTEM causará que el archivo SPFILE asociado
a la instancia se actualice. Este cambio queda efectivo al próximo inicio de la instancia.
Cabe destacar que para poder realizar estas modificaciones dinámicas, se deben tener en mente tres reglas:
* El tamaño especificado debe ser múltiplo del tamaño del gránulo.
* El tamaño total del Buffer Cache, Conjunto Compartido y Redo Log Buffer no puede exceder el tamaño
especificado en el parámetro SGA_MAX_SIZE.
* El conjunto de Buffers por defecto, designado por el parámetro DB_CACHE_SIZE no puede ser puesto en
cero.
3.1
Dimensionado Dinámico de la Instancia
3.1.6
Lectura Adicional: Administracion del Gránulo
El tamaño del buffer cache puede ser redefinido en forma manual, esto es, deteniendo la instancia, modificando
los parámetros y por último volviendo a iniciar dicha instancia. Esta técnica es necesaria cuando se necesita
incrementar el tamaño del parámetro SGA_MAX_SIZE.
Hay que tener en cuenta que al hacer esto, se modificarán todas las estadísticas recolectadas al momento,
y hasta que la instancia no llegue a un punto “caliente” de procesamiento, los indicadores de acceso al Buffer
Cache serán artificialmente bajos, hasta tanto no se produzcan accesos suficientes a los Archivos de Datos.
En general, es práctica de ajuste aceptable el mantener el tamaño del Buffer Cache – ya sea en forma manual
ó dinámica – en un tamaño mayor al necesario. De todas formas, además de simplificar esta tarea en una
ejecución de “prueba y error”, se puede utilizar la característica antes descrita del Asistente del Buffer Cache
ó Buffer Cache Advisory. Esta herramienta permite monitorear los cambios que podrían impactar en el
rendimiento del Buffer Cache si se lo define a un valor mayor ó menor que el tamaño actual.
3.1
Dimensionado Dinámico de la Instancia
3.1.7
EI: SGA
Determinar si las siguientes afirmaciones son correctas
3.1. Dimensionado Dinámico de la Instancia
3.1.8. TP: Cálculos iniciales para estimar el tamaño de la SGA
TP: Cálculos iniciales para estimar el tamaño de la SGA.
Duración Estimada: 30 min.
3.1
Dimensionado Dinámico de la Instancia
3.1.9
Síntesis
Oracle utiliza la SGA para almacenar ó cachear datos de la aplicación en memoria. La meta de esta actividad
es mejorar el rendimiento de la base de datos, al permitir que las sentencias SQL y PL/SQL, que la aplicación
utiliza más frecuentemente, estén disponibles en su estructura de memoria correspondiente.
El tamaño máximo que se puede gestionar la SGA se define por el parámetro SGA_MAX_SIZE que – al
iniciar la instancia – se subdivide en gránulos con un tamaño que va a depender del tamaño del bloque del
sistema operativo. De esta manera le da la flexibilidad a la base de datos para que se puedan modificar en
forma dinámica los tamaños de sus componentes.
Hay que tener en cuenta que un ajuste incorrecto puede llevar a un pobre rendimiento de la base de datos.
3.1
Dimensionado Dinámico de la Instancia
3.1.10 EInt: Dimensionado Dinámico de la Instancia
A continuación le proponemos un ejercicio que pondrá a prueba sus conocimientos acerca de la totalidad de
este subcapítulo.
3.2
Dimensionado de Otras Estructuras de Memoria
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.2
Dimensionado de Otras Estructuras de Memoria
3.2.1
Objetivos
En este subcapítulo aspiramos a que usted conozca y pueda definir el tamaño de Buffer Redo Log.
También nos interesa que sepa controlar el Conjunto Java (Java Pool) y, finalmente, que pueda definir la
cantidad de memoria que puede utilizar una sesión Java.
3.2
Dimensionado de Otras Estructuras de Memoria
3.2.2
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.
3.2
Dimensionado de Otras Estructuras de Memoria
3.2.3
El Buffer de Logs Rehacer (Redo log Buffer)
El mecanismo de Oracle para Rehacer ú Oracle Redo Log, registra los cambios hechos a los datos por
una aplicación de usuario para que de esta forma aquellas transacciones confirmadas puedan ser devueltas
ó rehechas en caso que ocurra algún tipo de fallo en la instancia. Como se ha mencionado en ocasiones
anteriores, este mecanismo de rehacer consiste en los siguientes componentes:
*Buffer de Redo Logs
*Proceso en segundo plano de escritura de Logs (LGWR)
*Archivos Redo Log (online)
*Archivos Redo Log Archivados
En este capítulo nos centraremos en la estructura de memoria de Redo.
El Redo Log Buffer es una porción de la SGA que almacena información requerida de las transacciones
para rehacer una aplicación de usuario en caso de fallos de la instancia. Estas transacciones pueden ser
del tipo DML (Inserts, Updates, Deletes) ó sentencias DDL (Create, Alter, Drop, etc.)
La información de Redo es copiada al Buffer de Redo por cada Proceso de Servidor de cada usuario.
3.2
Dimensionado de Otras Estructuras de Memoria
3.2.4
Gestión del Redo Log Buffer
Algunos mecanismos opcionales de Redo, como el archivado de los Archivos Redo Log y las bases de datos
Stand By pueden impactar negativamente en el rendimiento de la base de datos, ya que para llevar a cabo
estas tareas se requiere un acceso de Lectura/Escritura adicional; de todas maneras, cualquier motivo que
decline la performance debe ser cuidadosamente analizado, ya que dichas utilidades se definen en consecuencia
de un plan de contingencia ó de recuperación ante desastres.
Por lo general, el proceso en segundo plano de escritura del log (Log Writer – LGWR) suele hacer un buen
trabajo manteniendo siempre disponible los contenidos del Buffer Redo Log para ser reutilizados, esto es,
“limpiando” ó copiando el contenido del buffer a los Archivos Redo Log en el disco.
Hay casos en que este proceso no funciona como debería, terminando en una baja de rendimiento debido
a esperas que se producen en memoria, hasta que LGWR libere el espacio. Para ello veremos cómo
implementar técnicas de monitoreo y ajuste de estos componentes.
La Figura muestra una imagen conceptual del funcionamiento del mecanismo de Redo Log Buffer.
3.2
3.2.5
Dimensionado de Otras Estructuras de Memoria
Lineamientos para el Dimensionado del Redo Log Buffer
A diferencia del Buffer de Datos y del conjunto compartido, el Buffer de Redo Log no se maneja por un mecanismo LRU.
En lugar del efecto de “cinta transportadora” que produce una lista LRU, los Buffers Redo se manejan por un mecanismo
que se asemeja a un embudo, donde la información de las transacciones de los usuarios ingresa arriba del embudo para
ser luego descargada por el proceso de escritura LGWR. Para mantener el volumen de las entradas que van ingresando
al embudo, el proceso LGWR tiene la responsabilidad de leer el contenido del embudo para escribir al archivo en las
siguientes circunstancias:
*Cuando una aplicación ejecuta un comando COMMIT
*Cada tres segundos
* Cuando el Redo Log Buffer se llena a tres cuartos de su capacidad
*Cuando el volumen de entradas de Redo en el Buffer alcanza 1MB
*Cuando ocurre un evento CheckPoint
El tamaño del Buffer de Redo se determina por el parámetro de inicio LOG_BUFFER.
Una forma de poder medir el rendimiento del Buffer Redo Log es en términos de la cantidad y tamaño de las esperas
que los Procesos de Servidor experimentan cuando tratan de almacenar las entradas con información de sus transacciones
en el Buffer. Estas esperas se pueden visualizar con las vistas V$SYSSTAT y V$SESSION_WAIT. Cabe destacar que
estas mismas estadísticas pueden encontrarse en una salida de la herramienta STATSPACK.
Las estadísticas que recolectan estas vistas, relevantes para el ajuste del Buffer de Redo, tienen que ver con las entradas
relacionadas a “redo buffer allocation retries”, “redo entries” y “redo log space”.
Redo Entries son estadísticas que reportan la cantidad de entradas que se han ubicado en el Redo Log Buffer por el
Proceso de Servidor desde que se inició la instancia.
Redo Buffer Allocation Retries almacena estadísticas de la cantidad de veces que el Proceso de Servidor tuvo que
esperar y reintentar guardar las entradas de Redo debido a que el proceso LGWR no ha terminado de escribir las
entradas del buffer en los Archivos Redo Log.
Utilizando estas dos estadísticas, es posible calcular el indicador de reintentos utilizando la consulta que se ensaya en
la Figura . Idealmente se desearía que el Proceso de Servidor nunca tenga que esperar para acceder el Buffer de Redo.
Si los valores de este indicador aumentan, es posible que el Buffer Redo Log necesite ajuste. La recomendación de
Oracle es que este indicador debería ser menor al 1%.
Redo Log Space Request contiene estadísticas que miden cuán frecuente debe esperar el proceso LGWR un evento
de cambio de log (Log Switch), como se muestra en la Figura .
3.2
Dimensionado de Otras Estructuras de Memoria
3.2.6
Operaciones Redo
A diferencia de la vista dinámica V$SYSSTAT, la cual muestra estadísticas para toda la instancia, la vista V$SESSION_WAIT
puede mostrar cuánto tiempo y para qué eventos una sesión en particular ha tenido que esperar. La estadística “Log
Buffer Space” indica cuánto tiempo una sesión de usuario tuvo que esperara para almacenar una entrada en el Buffer
Redo Log, debido a que el proceso LGWR no ha terminado aún de escribir el contenido del Buffer en el disco. (los
Archivos Redo Log). La Figura muestra una consulta a esta vista para monitorear la actividad por usuario conectado.
Para entender un poco mejor el significado de esta consulta, en la Figura se presenta una tabla con los posibles estados
de espera.
AJUSTE:
El objetivo de ajustar el Buffer Redo Log es el de asegurarse que los Procesos de Servidor de los usuarios puedan
acceder y almacenar entradas de Redo en el Buffer sin tener que experimentar esperas.
La forma más fácil de mejorar el rendimiento del Buffer Redo es aumentando su tamaño en memoria. Un valor mayor
de esta estructura disminuirá sensiblemente las esperas de los Procesos de Servidor.
Este tamaño se define con el parámetro de inicio LOG_BUFFER. EL valor por defecto es 512KB ó 128KB multiplicado
por la cantidad de procesadores del servidor, el valor mayor de estos es quien quedará. Cabe destacar que si por algún
motivo se define un valor demasiado pequeño, al iniciar la instancia, Oracle Server sobrescribirá este valor por el valor
por defecto.
Otra manera de ajustar este Buffer es reduciendo las demandas de escrituras de entradas innecesarias. Esta técnica
se implementa por dos métodos:
Utilizando la opción UNRECOVERABLE. Esta opción es utilizada cuando se crea una tabla utilizando el comando
CREATE TABLE AS SELECT SQL, como se muestra en la Figura . Las tablas creadas de esta forma no generarán
ningún tipo de información Redo por los inserts de este comando. De todas maneras, cualquier operación DML
subsecuente a este comando sí generará entradas Redo.
Al igual que la opción UNRECOVERABLE, la opción NOLOGGING permite especificar qué tablas deberían omitir la
generación de entradas Redo cuando ciertos tipos de operaciones DML se ejecutan sobre ellas. El ejemplo de la Figura
muestra la creación de una tabla con esta característica. También es posible utilizar esta opción utilizando el comando
ALTER TABLE emp NOLOGGING. A diferencia de la opción UNRECOVERABLE, NOLOGGING tiene un efecto
permanente sobre la tabla, con lo que si se desea que comience a generar entradas de Redo, se debería modificar
su estructura con el comando ALTER TABLE emp LOGGING.
3.2
Dimensionado de Otras Estructuras de Memoria
3.2.7
Utilización de Java
En los últimos años, los desarrolladores de aplicaciones se han volcado a Java como plataforma de software.
La popularidad de Java sale del hecho que las aplicaciones resultantes son multiplataforma y pueden ser
distribuidas muy fácilmente gracias a la tecnología web.
El ambiente Java consiste en código de aplicación independiente al sistema operativo, el cual cuenta con
una Máquina Virtual de Java ó JVM utilizado para actuar como intérprete y ejecutar el código. Oracle 9i incluye
una extensa variedad de aplicaciones e interfaces para facilitar la interactuación de las aplicaciones basadas
en Java con la base de datos. Es por esto que Oracle tiene la capacidad de dedicar una porción de su memoria
(en la SGA) para ubicar al código Java y a las variables de aplicación específicas de una sesión, residiendo
durante el período que el programa se ejecute. Esta estructura es denominada Conjunto Java ó Java Pool.
AJUSTE:
Existen varios parámetros que se pueden utilizar para configurar el ambiente Java en Oracle. El parámetro
principal es JAVA_POOL_SIZE, que se utiliza para definir la cantidad de memoria de la SGA que se dedicará
a esta estructura. Otros parámetros relacionados se describen en la tabla de la Figura . Oracle recomienda
ajustar el parámetro JAVA_POOL_SIZE a un tamaño de 50MB ó más, para grandes aplicaciones Java.
Una vez parametrizadas las estructuras de memoria para aplicaciones Java, el DBA debería monitorear el
rendimiento para poder determinar si requiere algún ajuste adicional. Par esto se puede consultar la vista
V$SGASTAT filtrando por el campo POOL, como se ensaya en la Figura . El valor “free memory”, mostrado
en la figura, puede ser usado para ayudar a ajustar el tamaño del conjunto Java. Si esta vista muestra un
valor alto para “free memory” en comparación con “memory in use”, probablemente es porque se ha asignado
poco espacio al conjunto de Java.
3.2
Dimensionado de Otras Estructuras de Memoria
3.2.8
Lectura Adicional: Ajustando el Buffer Redo Log
Imagine que ha “heredado” en un nuevo trabajo una base de datos Oracle existente, que se utiliza para
soportar uno de los sistemas de la compañía. Una vez que se han examinado los indicadores de rendimiento
del Conjunto Compartido y del Buffer de Datos, se da cuenta que podría mejorar el rendimiento agrandando
el tamaño de estas estructuras, pero no hay suficiente memoria en el servidor para poder implementar esta
solución. Por otro lado surge también del análisis que el indicador de rendimiento del Buffer Redo Log es muy
bajo: 0.0000012.
Una de las soluciones podría ser hacer una solicitud a la empresa y comprar una cantidad mayor de memoria
al servidor y simplemente ajustar estas estructuras de memoria.
Si no se puede realizar la primera opción, puede contar con los resultados obtenidos del Buffer Redo y la
chance puede ser que el tamaño de memoria designado para esta estructura de memoria sea inadecuado
y esté acaparando un espacio que no le corresponde, malgastando memoria para este caso.
Con lo que se pone a verificar la configuración de la SGA. De este análisis surge que el tamaño designado
para el Buffer Redo Log es de 10MB y sabe que cualquier valor arriba de 1MB será inutilizado, ya que el
proceso LGWR se ha configurado para escribir en disco cuando el Buffer llega a un tercio de su capacidad
ó alcanza un tamaño de 1MB.
Entonces, al reducir la capacidad de esta estructura a 1MB ó menos, puede ahora asignar aproximadamente
los 9MB sobrantes para el Conjunto Compartido ó el Buffer de Datos. De esta manera ha mejorado el
rendimiento general de la base de datos sin necesidad de incrementar el tamaño general de la SGA ni teniendo
que agregar actualizaciones de Hardware innecesarias.
3.2
Dimensionado de Otras Estructuras de Memoria
3.2.9
Buffer Redo Log
Al agrandar el tamaño de los buffers, hace que el acceso a disco sea menor ya que los cambios de Log son
menos frecuentes
3.2
Dimensionado de Otras Estructuras de Memoria
3.2.10 TP: StatsPack
Laboratorio 3.2.10
TP: Utilización de la herramienta STATSPACK.
Duración Estimada: 40 min.
3.2
Dimensionado de Otras Estructuras de Memoria
3.2.11 Síntesis
En este subcapítulo hemos visto la importancia del rol que cumple el mecanismo de Redo de Oracle, en
función de las necesidades de recuperación ante fallos. La información de Redo ó rehacer es ubicada
inicialmente en el Redo Log Buffer por cada Proceso de Servidor del Usuario, donde permanece hasta que
el proceso en segundo plano LGWR escriba su contenido a los Archivos Redo Log Online (ubicados físicamente
en el disco).
Cuando uno de los Archivos Redo Log se llena con estas entradas, el proceso LGWR realizará un cambio
de Log (Log Switch) al próximo archivo disponible.
Para hacer monitoreo, se pueden utilizar varias vistas dinámicas de rendimiento: V$SYSSTAT, V$SESSION_WAIT
y V$SYSTEM_EVENT.
Adicionalmente se puede utilizar la herramienta STATSPACK para colectar las estadísticas necesarias y
centralizarlas en un archivo de salida.
Las técnicas que se pueden utilizar para mejorar el rendimiento de esta estructura de memoria es agrandar
el tamaño de la misma ó evitar entradas de Redo innecesarias, usando las opciones UNRECOVERABLE ó
NOLOGGING.
Otra estructura analizada es el Conjunto de Java ó Java Pool, donde se comentó la importancia de esta
plataforma de desarrollo y cómo interactúa necesariamente con la base de datos, Esta estructura se la define
por el parámetro JAVA_POOL_SIZE y utilizará una porción de la SGA para almacenar código y variables
propias de la aplicación Java.
3.2
Dimensionado de Otras Estructuras de Memoria
3.2.12 EInt: Dimensionado de Otras Estructuras de Memoria
A continuación le proponemos un ejercicio que pondrá a prueba sus conocimientos acerca de la totalidad
de este subcapítulo.
3.3
Parametrizando Oracle Server en Ambiente Compartido
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.3
Parametrizando Oracle Server en Ambiente Compartido
3.3.1
Objetivos
En el presente subcapítulo nos interesa que usted pueda identificar los problemas asociados al servidor
compartido (Shared Server), que sepa configurar su entorno, además de diagnosticar y resolver las cuestiones
que tengan que ver con su rendimiento.
Por último queremos que usted conozca cómo optimizar el rendimiento en un ambiente de Servidor Compartido.
3.3
3.3.2
Parametrizando Oracle Server en Ambiente Compartido
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.
3.3
Parametrizando Oracle Server en Ambiente Compartido
3.3.3
Principales Características
Cada aplicación de usuario tiene dos procesos asociados a su conexión con la base de datos: Un Proceso de Usuario,
el cual se ejecuta en el lado del cliente ó en el servidor de aplicaciones y un Proceso de Servidor, que se ejecuta sobre
la base de datos, precisamente dentro de la instancia de Oracle.
La configuración por defecto de Oracle 9i, se implementa con el mecanismo de Servidor Dedicado, donde cada Proceso
de Servidor del usuario se dedica únicamente (como su nombre lo indica) a resolver las solicitudes de la sesión de ese
usuario.
Cabe destacar que cuando se trata de un Oracle Server instalado en un sistema operativo UNIX (como suele tratarse
en grandes empresas), cada uno de estos Procesos de Servidor se ejecutará en el sistema operativo como un proceso
individual del SO, con lo que si hay 50 usuarios conectados, habrán 50 procesos corriendo en el sistema operativo.
Existe también una segunda posible configuración de Oracle Server, llamada Servidor Compartido ó Shared Server,
donde varios Procesos de Servidor Compartidos se crean en la máquina de Oracle Server. Estos procesos pueden ser
utilizados para resolver consultas SQL de cualquier usuario que esté conectado a la base de datos.
Como se ha comentado en cursos anteriores, la arquitectura del Servidor Compartido está formada por varios componentes:
Procesos de Usuario. Cada aplicación de usuario que inicie una conexión con el servidor, creará un proceso de este
tipo.
Procesos de conexión Oracle Net. Es un proceso que escucha conexiones entrantes de los clientes. Cuando esto ocurre,
este proceso lo asigna a un distribuidor.
Procesos Distribuidores (Dispatchers). Son procesos en segundo plano que corren en el Sistema Operativo y aceptan
las solicitudes entrantes de los Procesos de Usuario. Para una instancia puede haber hasta cinco procesos distribuidores
simultáneamente.
Colas de Solicitudes. Es una ubicación donde el distribuidor deja las solicitudes del usuario. Existe sólo una cola de
solicitudes y se almacena en la SGA.
Colas de Respuestas. Es la ubicación donde los Procesos de Servidor Compartidos ponen los resultados de las actividades
solicitadas. Los procesos distribuidores toman estas respuestas y se las envían al Procesos de Usuario que realizó la
solicitud. Hay una cola de Respuestas para cada distribuidor que se almacena en la SGA.
Procesos de Servidor Compartido. Son procesos en segundo plano que corren en el Sistema Operativo, interactuando
con la SGA en representación de los Procesos de Usuario. Estos procesos realizan las mismas actividades que un
Proceso de Servidor dedicado, con la diferencia que utiliza los tiempos ociosos de un usuario para atender solicitudes
de otros. De esta manera se maximizan las cantidades de conexiones concurrentes a la base de datos.
La Figura muestra una imagen representativa de la arquitectura del Servidor Compartido.
3.3
Parametrizando Oracle Server en Ambiente Compartido
3.3.4
Monitoreo de los Distribuidores (Dispatchers)
Una vez que se ha decidido a utilizar un ambiente distribuido, como parte de las tareas de DBA está la de
monitorear y ajustar esta característica para obtener un incremento en el rendimiento. Al igual que para el
Conjunto Compartido y el Buffer Cache, se pueden utilizar una serie de vistas dinámicas de rendimiento para
llevar a cabo esta tarea. La tabla de la Figura muestra las principales vistas que cumplen este cometido. Cada
una de estas vistas puede ser utilizada para monitorear los dos componentes dinámicos de la arquitectura
de servidor compartido: El Servidor Compartido y los Procesos Distribuidores (Dispatchers).
El rendimiento de los procesos de los distribuidores puede medirse en función de las esperas que experimientan,
definiendo un indicador de espera llamado “Busy Ratio”. Este indicador puede calcularse utilizando la vista
dinámica de rendimiento V$DISPATCHER, como se ve en la Figura , donde se puede ver que los procesos
distribuidores para el protocolo TCP/IP han estado activos, atendiendo solicitudes un 33,23% del tiempo en
que estuvieron corriendo. Oracle recomienda agregar más distribuidores si este indicador excede el 50%.
Otro indicador del rendimiento del Servidor Compartido es la cantidad de tiempo que un Proceso de Usuario
estuvo esperando que el distribuidor le acepte una solicitud. Para esto se pueden utilizar las vistas V$QUEUE
y V$DISPATCHER, como se ve en la Figura , donde se observa que un Proceso de Usuario ha tenido una
espera de 0,0093 centésimas de segundo por una respuesta de un distribuidor.
3.3
3.3.5
Parametrizando Oracle Server en Ambiente Compartido
Monitoreo de los Servidores Compartidos
Al igual que para los distribuidores, una forma de monitorear el rendimiento de los procesos de Servidor Compartido
es monitorear en qué medida los procesos se encuentran resolviendo solicitudes de los usuarios, esto es, el “Busy
Ratio” y se lo puede calcular utilizando la vista V$SHARED_SERVER, como se ensaya en la Figura , donde se puede
ver que al menos hubo un proceso de Servidor Compartido ocupando un 16.85% de su tiempo.
Si durante un momento de procesamiento existen pocos procesos de servidor, las solicitudes pueden llegar a experimentar
esperas mientras tratan de procesarlas. Estas esperas pueden monitorearse con la vista V$QUEUE, como se muestra
en la Figura donde se puede ver que un Proceso de Usuario esperó un promedio de 0,0003 centésimas de segundo
para ser atendido por un Proceso de Servidor Compartido.
3.3
Parametrizando Oracle Server en Ambiente Compartido
3.3.6
Monitoreo de los Procesos
Las esperas mostradas en las vistas V$QUEUE y V$DISPATCHER son indicadores de contención de los
distribuidores. Otra evidencia adicional de esta contención para los distribuidores se puede determinar (siempre
hablando de un ambiente distribuido) utilizando la vista dinámica de rendimiento V$DISPATCHER_RATE. La
tabla de la Figura muestra las columnas útiles para el monitoreo de la contención. La Figura muestra un
ensayo de esta vista donde se compara el indicador de servicio actual contra el máximo de solicitudes. De
esta vista surge que grandes variaciones entre los indicadores de servicio actuales y los máximos, pueden
demostrar que posiblemente se requiera mejorar el rendimiento del Servidor Compartido.
La vista dinámica de rendimiento V$SHARED_SERVER_MONITOR da una perspectiva acumulada sobre la
actividad del Servidor Compartido. Las columnas más destacadas de esta vista se detallan en la Figura junto
a un ejemplo de consulta a esta vista, donde se sabe que al inicio de la instancia se definió la cantidad de
Servidores Compartidos en 3 y se puede ver que hay dos Procesos de Servidor Compartido adicionales
iniciados por la instancia. También se observa que uno de los Servidores iniciados se ha detenido automáticamente
cuando la demanda de los recursos disminuyó.
3.3
Parametrizando Oracle Server en Ambiente Compartido
3.3.7
Uso de Memoria en el Ambiente Compartido
Como se ha visto en capítulos anteriores, incrementar el tamaño del Conjunto Compartido, definiendo
un área reservada, y almacenar paquetes PL/SQL en memoria, son métodos efectivos para mejorar el
rendimiento de la base de datos en ambientes dedicados. Pero cuando se trata de un ambiente distribuido,
el espacio reservado para el Conjunto Compartido puede ser utilizado por otros objetos que no son SQL
ni PL/SQL, como por ejemplo, la información de conexiones de usuarios a Servidores Compartidos (UGA
– User Global Area) se almacenará también en el Conjunto Compartido, como así también otras
características relacionadas al Backup y Recuperación.
Cuando este tipo de características opcionales de Oracle son utilizadas, el rendimiento del Conjunto
Compartido puede ser afectado negativamente cuando su esfuerzo se ve redireccionado por otros
propósitos.
Para resolver este inconveniente, Oracle provee la habilidad de crear un área especial en la SGA, llamada
Conjunto Extendido ó Large Pool, la cual puede ser utilizada para procesar solicitudes de almacenamiento
de opciones particulares, como el Backup ó el área compartida del usuario en ambientes distribuidos
(UGA).
3.3
3.3.8
Parametrizando Oracle Server en Ambiente Compartido
Detección de Problemas y Soluciones
Los problemas de rendimiento en una arquitectura de Servidor Compartido suelen estar relacionados con las siguientes
áreas:
* Componentes de la SGA que no se han ajustado adecuadamente para el ambiente compartido.
* Poca cantidad de Servidores Compartidos corriendo para atender las solicitudes.
* Poca cantidad de Distribuidores corriendo para atender las solicitudes de los usuarios.
Para todos los casos, la solución de ajuste termina siendo una parametrización para agrandar algunos de los tamaños
de estos componentes.
Debido a que los Servidores Compartidos operan por sentencia y no por transacción, la sesión del usuario y la información
del cursor son ubicadas en la SGA, particularmente en la UGA. Por defecto, la UGA se almacenará a su vez en la
estructura de memoria del Conjunto Compartido, con lo que mínimamente (si se decide mantener esta configuración)
se debería incrementar el tamaño del Conjunto Compartido. Otra solución podría ser mover información de UGA desde
el Conjunto Compartido al Conjunto Extendido (Large Pool).
AJUSTE:
Cuando los Servidores Compartidos que se están ejecutando no pueden atender alguna solicitud entrante porque se
encuentran ocupados, el proceso en segundo plano PMON iniciará dinámicamente un proceso de Servidor Compartido
adicional, teniendo como límite de cantidad el valor definido en el parámetro MAX_SHARED_SERVERS.
Esta tarea puede realizarse en forma manual con la intervención del DBA, teniendo en cuenta que puede hacerse en
forma dinámica ó estática.
Para agregar Servidores Compartidos adicionales en forma dinámica, se puede utilizar el comando ALTER SYSTEM:
ALTER SYSTEM SET shared_servers = 10;
De esta manera, incrementará la cantidad de servidores compartidos a 10 tomando efectividad para las próximas
conexiones que se establezcan.
La forma de hacer esta tarea en forma manual, es deteniendo la instancia y modificando el parámetro del archivo de
parámetros SHARED_SERVERS y luego volviendo a iniciar la instancia.
Con respecto a los Distribuidores (Dispatchers), estos procesos no pueden ser iniciados dinámicamente por el proceso
PMON. Si las consultas vistas en temas anteriores a las vistas dinámicas de rendimiento revelan contención en los
distribuidores, el DBA puede agregar una mayor cantidad de distribuidores dinámicamente ó manualmente, pero no en
forma automática.
Para ello el DBA, si desea modificar este valor dinámicamente, debe ejecutar el comando:
ALTER SYSTEM SET dispatchers = ‘tcp, 6’;
Como se puede ver, se debe especificar el protocolo de red además de la cantidad de distribuidores.
3.3
Parametrizando Oracle Server en Ambiente Compartido
3.3.9
Obteniendo Información del Diccionario de Datos
Como se ha visto a lo largo del capítulo, se pueden utilizar varias vistas dinámicas de rendimiento para obtener
información (en su mayoría estadística) sobre el entorno compartido de Oracle.
En este ítem se expondrá a modo de referencia un resumen con las vistas utilizadas.
3.3
Parametrizando Oracle Server en Ambiente Compartido
3.3.10 Lectura Adicional: Tipos de Usuarios del Ambiente Compartido
Es posible pensar en la diferencia entre el ambiente dedicado y el ambiente compartido de Oracle Server haciendo una
analogía con la diferencia entre tener un auto propio ó movilizarse con una compañía de radio taxis.
Si se traslada utilizando su propio auto, puede ir a donde guste y cuando guste sin tener que esperar para acceder a
algún auto. De todas maneras, cuando no está utilizando su propio auto (cuando duerme por ejemplo) este auto se
convierte en un recurso caro que no se está utilizando. Consecuentemente, si se moviliza con la compañía de taxis,
posiblemente tenga alguna pequeña demora cuando quiera acceder a un auto, pero terminará yendo al lugar que quiere
cuando quiere, como si tuviese su propio auto, con la diferencia que cuando usted no está utilizando ese auto, otros
clientes pueden hacer uso del servicio, haciendo un buen uso del recurso (reduciendo los tiempos ociosos del auto).
Lo mismo ocurre con el ambiente dedicado y el distribuido. El Servidor Dedicado provee una comunicación eficiente
entre el Proceso de Usuario y el Proceso Servidor, ya que este último se dedica a atender en forma exclusiva a ese
Proceso de Usuario. De esta manera, al igual que el auto propio, los Servidores Dedicados tienen la desventaja del
consumo de memoria y recursos de CPU en el equipo del Oracle Server cuando el usuario está conectado pero sin
hacer nada. Esto trae problemas de escalabilidad cuando la cantidad de usuarios que requieren conectarse para trabajar
aumenta considerablemente y los recursos no se usan adecuadamente.
El caso del ambiente compartido resuelve este problema al tener un mejor aprovechamiento de los tiempos ociosos de
los Servidores Compartidos y utilizando de esta manera los recursos de memoria y CPU para otras tareas de otros
usuarios que sí requieren procesar en ese momento pero, como ocurre de la misma manera que con la compañía de
taxis, los Servidores Compartidos pueden impactar negativamente en el rendimiento de la base de datos si los Servidores
Compartidos no se encuentran disponibles cuando un Proceso de Usuario requiere de sus servicios.
Desde el punto de vista técnico, existen diferencias al utilizar la arquitectura de Servidores Compartidos dependiendo
del sistema operativo que se esté utilizando.
Como se ha comentado en este capítulo, los procesos que se van iniciando para cada Servidor Compartido se comporta
como un proceso independiente (cada uno con un nombre propio y número de proceso) en un ambiente UNIX. En un
sistema operativo Windows TODOS los procesos que se inicien por Servidores Compartidos se asociarán a un solo
ejecutable, llamado ORACLE.EXE. De esta manera se puede ver que esta característica no provee la misma escalabilidad
entre distintos sistemas operativos.
3.3
Parametrizando Oracle Server en Ambiente Compartido
3.3.11 EI: El Ambiente Compartido
Identificar los componentes de la arquitectura de Servidores Compartidos
3.3
Parametrizando Oracle Server en Ambiente Compartido
3.3.12 TP: Monitoreo del Ambiente Compartido
Laboratorio 3.3.12
TP: Monitoreo del Ambiente Compartido.
Duración Estimada: 45 min.
3.3
Parametrizando Oracle Server en Ambiente Compartido
3.3.13 Síntesis
Como se viene viendo a lo largo del curso, Oracle 9i incluye varias características de operación que, si son
utilizadas, pueden llegar a afectar el rendimiento general de la base de datos. La opción de Servidor
Compartido está designada para permitir la utilización de conexiones de usuario adicionales de una aplicación
a un sistema existente, sin tener que agregar recursos de CPU ó memoria para soportar dichos usuarios.
La configuración del Servidor Compartido se implementa con la utilización de Distribuidores ó Dispatchers,
que son quienes se encargan de recibir las solicitudes provenientes de los Procesos de Usuarios y distribuirlos
sobre los Servidores Compartidos disponibles, en lugar de utilizar Servidores Dedicados para cada conexión.
Los Servidores Compartidos y los distribuidores pueden ser monitoreados utilizando vistas dinámicas de
rendimiento para determinar si estos procesos son suficientes para soportar la carga de los usuarios. Es
posible iniciar procesos de Servidor Compartido ó distribuidores adicionales con la intervención del DBA
para alivianar la carga si se produjera un cuello de botella en esta instancia.
Con respecto a la memoria (SGA) puede utilizarse el Conjunto Extendido para almacenar la información
de la UGA de los usuarios conectados y de esta manera disminuir la carga de trabajo y espacio designado
para el Conjunto Compartido quien es el encargado de almacenar la UGA por defecto.
3.3
Parametrizando Oracle Server en Ambiente Compartido
3.3.14 EInt: Parametrizando Oracle Server en Ambiente Compartido
A continuación le proponemos un ejercicio que pondrá a prueba sus conocimientos acerca de la totalidad de
este subcapítulo.

Download Report