Teoría

PARTE II
DIMENSIONADO DE LA BASE DE DATOS

3. Configuracin de la Base de Datos y Acceso al Disco
4. Conjunto Compartido (Shared Pool)
5. Dimensionado del Buffer Cache (Data Base Buffer Cache)

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

Profesor Adjunto: Ing. Hctor Pedro Liberatori Pg. 24
Profesor Adjunto: Ing. Ariel Alejandro Vega

II DIMENSIONADO DE LA BASE DE DATOS

Los problemas con la baja performance de algunas tareas en las aplicaciones son debidas frecuentemente por
consultas SQL mal estructuradas por un diseo deficiente de la base de datos. Por esta causa, Oracle provee una
serie de herramientas que ayudan al DBA a identificar y solucionar este tipo de problemas.
Otro frente de problemas con respecto a la falta de rendimiento puede ser la forma en que los datos son buscados
actualizados en su medio fsico. Este evento de leer escribir (I/O) en los medios fsicos pueden llegar a ser la
causa de una mala respuesta por parte del motor de base de datos. Para este tipo de problemas tambin se proveen
ciertas herramientas y consultas que son utilizadas para el proceso de ajuste en la etapa de acceso a disco.
En este captulo se vern las actividades que se pueden llegar a programar para determinar el tipo de problema y
cmo comenzar a solucionarlo.



UNIDAD 3
CONFIGURACION DE LA BASE DE DATOS Y ACCESO AL DISCO
3.1. OBJETIVOS
En esta unidad el alumno deber conocer las ventajas de la arquitectura de archivos de Oracle y el particionado de
los datos.
Adems se considera fundamental que llegue a saber diagnosticar los problemas de los tablespaces; y saber de qu
manera controlar y ajustar, tanto a los puntos de control, como a los archivos Redo Log.
Por ltimo, deber describir el funcionamiento de dichos puntos de control.

3.2. CUESTIONARIO DE INICIACION

3.3. PROCESOS Y ARCHIVOS
Los procesos en segundo plano son los encargados de relacionar los bloques de datos que se encuentran en la
memoria de la instancia de la base de datos (SGA) con el medio fsico. Como se puede ver en la tabla de la Figura
3.1, no todos los procesos efectan escrituras en el medio como trabajo por defecto, pero s todos realizan lecturas
en su mayor parte de trabajo.



El proceso de escritura de la base de datos (DBWn) es el responsable de escribir el buffer desde el cache de base de
datos a los archivos de datos que se encuentran en el medio fsico. Como se ha visto en captulos anteriores, el
proceso DBWn realiza esta escritura cuando ocurre un proceso Checkpoint y cuando el proceso de servidor
(Server Process) se encuentra buscando buffers libres en el cache de base de datos. Este ejemplo es mencionado,
ya que ajustar el proceso de lectura/escritura (I/O) del proceso DBWn es una actividad muy importante cuando se
habla de ajustes de rendimiento.

3.4. LINEAMIENTOS DE PERFOMANCE
Cada segmento de la base de datos es almacenado dentro de una estructura lgica de almacenamiento llamado
Tablespace. Como es sabido, cada base de datos contiene al menos un Tablespace (SYSTEM) el cual es usado por
Oracle Server para almacenar las tablas e ndices del Diccionario de Datos. Claramente una base de datos bien
diseada contendr ms de un tablespace para los diferentes objetos de la aplicacin.
Sin importar la cantidad de tablespaces definidos en la base de datos, cada uno de ellos realizarn lecturas y
escrituras en los Archivos de Datos, y es por esto que la cantidad y ubicacin de estos archivos son un punto de
ajuste muy importante para tener en cuenta. En particular, el DBA debera mantener baja la contencin de datos,
distribuyendo los archivos de datos en varios tablespaces, ubicndolos en sistemas de discos diferentes.
Al hablar ms puntualmente del acceso a disco de los Archivos de Datos, se pueden aplicar varias tcnicas para
mejorar el rendimiento de cada acceso al medio fsico (I/O). La Figura 3.2 muestra las reas donde se suele ajustar
para maximizar la lectura/escritura.

Figura 3.1
Figura 3.2



3.5. ALMACENAMIENTO DE DATOS
Teniendo en cuenta las observaciones sobre las tcnicas requeridas para el mejoramiento del acceso al medio
fsico, entraremos en detalle para tener una idea ms acabada sobre estos aspectos:
Para el caso de las Aplicaciones NoOracle, hay que tener en cuenta el no ubicar archivos que no tengan que ver con
Oracle Server en las mismas unidades de disco unidades lgicas (Figura 3.3). Esto podra ser causante de una
posible contencin de los recursos y adems estos accesos a disco de archivos NoOracle no sern tenidos en
cuenta en la recoleccin de estadsticas de ajuste, con lo que la informacin que se pudiere recolectar con
estadsticas de acceso a disco de Oracle ser errnea.
Otra tcnica a tener en cuenta es la creacin de Tablespaces Gestionados Localmente (LMT Locally Manager
Tablespaces, Figura 3.4). Este tipo de almacenamiento utiliza un mapa de bits almacenado en la cabecera de cada
archivo de datos en lugar de utilizar una lista de bloques libres en el diccionario de datos. Esto permite a los
tablespaces asignar desasignar espacio mucho ms rpido (sin tener que acceder al diccionario de datos en el
tablespace SYSTEM).
Para el balanceo de los Archivos de Datos (Figura 3.5), la manera ms simple de solucionar esto es ubicando los
segmentos apropiados de la aplicacin en Tablespaces diferentes y asegurarse principalmente de no utilizar el
tablespace SYSTEM como tablespace temporal por defecto. Un acceso a disco excesivo a los archivos de datos del
tablespace SYSTEM podra ser el indicador de que este tablespace se est utilizando para otra cosa que no es el
almacenamiento del diccionario de datos

Figura 3.3
Figura 3.4



3.6. ESTADISTICAS DE ACCESO A DATOS
La medicin de la performance del acceso a disco de los Archivos de Datos en la base de datos puede realizarse
utilizando las vistas dinmicas de rendimiento V$FILESTAT y V$DATAFILE, la salida de la herramienta STATSPACK
la utilidad grfica Performance Manager de OEM (la utilidad STATSPACK se analizar en captulos posteriores).
Estas vistas del diccionario de datos pueden usarse para monitorear la performance de la actividad de lectura y
escritura sobre los Archivos de Datos. La tablas de la Figuras 3.6 y 3.7 muestraN una descripcin de estas vistas.
El componente Performance Manager del Pack de Diagnsticos de Oracle Enterprise Manager (OEM) incluye varias
representaciones de la performance en la actividad de acceso al medio (I/O) basada en tiempos, para cada archivo
de datos. La Figura 3.8 muestra una pantalla de esta utilidad que refleja cmo se representa esta actividad en la
cual se puede ver que los archivos de datos SYSTEM01.DBF y USERS01.DBF pasan mucho tiempo realizando
operaciones de lectura/escritura, al menos en el perodo analizado en dicha utilidad

Figura 3.5
Figura 3.6



3.7. LECTURA COMPLETA DE UNA TABLA
Una vez balanceados los requerimientos de lectura/escritura a travs del balanceo de los archivos de datos,
dividiendo los distintos objetos (tablas, ndices, secuencias, vistas, etc) en distintos tablespaces, el DBA puede
continuar la optimizacin del acceso a disco (la lectura/escritura de estos objetos) para que sean lo ms rpidas
posibles. Esta tarea puede realizarse de tres maneras: Ubicando los archivos de datos en unidades de disco
separadas, dividiendo los tablespaces o ajustando el parmetro DB_FILE_MULTIBLOCK_READ_COUNT del archivo
de inicio init.ora.
La idea de la separacin de los archivos de datos en distintos dispositivos se corresponde a una tcnica en donde
los archivos de datos se almacenarn en diversas ubicaciones, incrementando la performance de lectura/escritura,
ya que ocurrir que mltiples cabezales de disco se utilizarn a la vez al momento de realizarse una operacin de
I/O. La manera ms fcil de dividir estos archivos de datos en diferentes dispositivos es almacenarlos en Arrays de
discos en un dispositivo de tipo RAID. Un dispositivo RAID (Redundant Array of Independent Disks) consiste en
un conjunto fsico de discos que pueden gestionarse y ser accedidos como si fuesen un solo disco varias unidades
lgicas. De esta manera, al ubicar un Archivo de Datos en un sistema RAID, implcitamente causa que el archivo se
divida entre los discos que conformen este sistema. Cabe destacar que esta tcnica no requiere de ningn esfuerzo
por parte del DBA.
Figura 3.7
Figura 3.8



El parmetro DB_FILE_MULTIBLOCK_READ_COUNT del archivo init.ora determina la cantidad mxima de bloques
de la base de datos que pueden ser ledos en una operacin de lectura por un Proceso de Servidor, cuando realiza
una actividad de lectura completa de una tabla Full Table Scan. El valor por defecto de este parmetro es 8
bloques y el valor mximo depender del sistema operativo que se est utilizando. Si se ajusta este parmetro en
un valor mayor a 8 se beneficiar la performance cuando se realice una lectura completa de una tabla, ya que al
incrementarse este parmetro por cada lectura del proceso se recoger una mayor cantidad de bloques, acortando
la cantidad de veces que debera acceder al disco. Cuando se est ajustando este parmetro, se puede consultar la
vista V$SYSTAT para determinar con qu frecuencia una aplicacin realiza lecturas completas de tablas, como se
muestra en la Figura 3.9. Si se observan altos valores en los resultados de esta vista, esto es un indicador de que la
aplicacin frecuentemente realiza lecturas completas de tablas y un incremento del parmetro la beneficiara.
Otra vista til para monitorear las lecturas completas de tablas es la vista V$SESSION_LONGOPS, esta vista muestra
la actividad asociada con las operaciones de larga duracin como podra causar una lectura completa. La Tabla de
la Figura 3.10 muestra la descripcin de esta vista.
Cabe destacar que una operacin de lectura completa de tabla aparecer en esta vista siempre que el proceso haya
escaneado ms de 10.000 bloques de Oracle.

Figura 3.9
Figura 3.10



3.8. CHECKPOINTS
El proceso en segundo plano Log Writer (LGWR) escribe los contenidos de la estructura de memoria Redo Log
Buffer (ubicada en la SGA) cuando ocurre un evento CheckPoint en la base de datos.
Un evento CheckPoint representa un momento en el tiempo en donde la base de datos se encuentra en un estado
consistente. Los CheckPoints son sumamente importantes ya que, en caso de falla de la instancia, permite que
solamente las transacciones que ocurrieron luego del ltimo CheckPoint requieran ser recuperadas en el momento
de recuperacin de la instancia (realizada automticamente por el proceso SMON al inicio de la instancia).
Existen dos tipos de CheckPoints, incrementales y completos. Cuando ocurre un CheckPoint incremental, se
realizan las siguientes acciones:
El proceso en segundo plano CKPT actualiza el encabezado del (de los) archivo(s) de control (ya sean copias
multiplicadas no) inmediatamente.
El proceso en segundo plano CKPT vuelve a actualizar el encabezado del(de los) archivo(s) de control junto a
los encabezados de los Archivos de Datos en cada cambio (switch) de Grupo de Redo Log.
La Figura 3.11 muestra la secuencia del CheckPoint Incremental.
Cuando ocurre un evento CheckPoint completo, tienen lugar las siguientes acciones:
Todo el contenido del Redo Log Buffer en memoria es escrito a los archivos Redo Log Online por el proceso en
segundo plano LGWR.
Todo el buffer de la estructura de memoria Database Buffer Cache que contenga transacciones confirmadas
(commit) son escritas a disco por el proceso en segundo plano DBWn.
Los encabezados de los archivos de control y de datos son actualizados por el proceso en segundo plano CKPT
para indicar que ha ocurrido un evento CheckPoint.
La Figura 3.12 muestra la secuencia del CheckPoint Completo.
Estos eventos CheckPoint ocurren en la base de datos cuando:
La instancia se detiene (shutdown) utilizando cualquier mtodo excepto ABORT.
Cuando ocurre un cambio (switch) de los grupos de Redo Log.
Cuando el DBA ejecuta manualmente un evento CheckPoint con el comando ALTER SYSTEM CHECKPOINT.
Cuando un Tablespace es puesto en modo backup (backup en caliente) usando el comando ALTER
TABLESPACE nombre_tbs BEGIN BACKUP cuando es puesto OFFLINE. Este CheckPoint es diferente al
CheckPoint completo, ya que solamente los buffers sucios pertenecientes a ese tablespace son escritos.
Cuando el valor especificado en el parmetro FAST_START_MTTR_TARGET es excedido

Figura 3.11



3.9. TIEMPOS DE RESPUESTA
Ocasionalmente los eventos CheckPoint son iniciados, pero no se llegan a completar satisfactoriamente debido a
que una solicitud de un segundo CheckPoint ocurre muy seguida a la del primero. Es posible detectar los
CheckPoints que se han iniciado pero no han finalizado, consultando la vista dinmica de rendimiento
V$SYSTEM_EVENT, la cual contiene estadsticas de los cambios de LOG (switches), reportando de esta manera la
cantidad de esperas (waits) que ocurrieron desde que se inici la instancia. La tabla de la Figura 3.13 describe el
contenido de las principales columnas de esta vista.
La Figura 3.14 muestra una consulta de ejemplo a esta vista donde se puede observar las esperas relacionadas a
las actividades de CheckPoint en la base de datos. Los dos eventos que muestra son indicadores del rendimiento de
este proceso: CheckPoints finalizados y cambios de Log (CheckPoints incompletos).
El registro CheckPoint Completed muestra cuntas veces un proceso CheckPoint tuvo que esperar para finalizar
sus actividades. Si los valores de este registro son altos, indica que este proceso requiere ajuste.
El registro Log File Switch muestra lo mismo que el anterior pero para los archivos Redo Log Online, o sea, cuntas
veces esper para realizar el cambio de log (switch). Cuando esto ocurre, el proceso CheckPoint que se est
ejecutando es abandonado y comienza un nuevo proceso CheckPoint. Este proceso genera excesivo acceso a disco y
no trae ningn beneficio para el rendimiento.
El componente Performance Manager del OEM puede ser utilizado adicionalmente para monitorear el rendimiento
de la actividad del proceso CheckPoint.
AJUSTE:
Una manera de reducir la cantidad de eventos CheckPoint en la base de datos es agrandar el tamao de los
miembros de los grupos Redo Log Online, ya que un evento muy frecuente es el cambio de Log. Este mtodo tiene
sus limitaciones ya que no pueden ser agrandados a un tamao ms grande que el que tienen, quedando como
opcin agregar nuevos grupos de Redo Log con sus miembros ahora s ms grandes, e ir eliminando los antiguos a
medida que quedan inutilizados, como se muestra en la Figura 3.15.
Otra forma de ajustar la frecuencia de los eventos de este proceso es a travs de parmetros de inicio (init.ora), que
permiten al DBA ajustar las acciones de estos eventos. El parmetro en cuestin es FAST_START_MTTR_TARGET, el
cual es utilizado para especificar el tiempo medio (en segundos) para recuperar en caso de fallo de la instancia. Los
posibles valores van de cero a 3.600 segundos. Al ajustar este parmetro Oracle realizar CheckPoints adicionales
para asegurarse de tener la frecuencia necesaria. Cabe destacar que este parmetro puede modificarse
dinmicamente (si se utiliza un spfile) con el comando ALTER SYSTEM SET.
Figura 3.12



Figura 3.13
Figura 3.14
Figura 3.14



3.10. ARCHIVOS REDO LOG
Toda la informacin de Redo es eventualmente escrita a los archivos Redo Log Online, por el proceso LGWR. Es
sabido tambin que la prdida de un log puede resultar en la prdida de transacciones confirmadas, con lo que
estos archivos deberan ser multiplicados para que cada grupo de Redo tenga varios miembros.
La medicin del rendimiento de los archivos Redo Log Online de la base de datos es difcil, ya que Oracle no provee
muchas vistas del diccionario que muestren directamente la actividad de lectura/escritura. Para ello, se usa la vista
V$SYSTEM_EVENT para su monitoreo, como muestra la Figura 3.15, donde se ven dos eventos, log file switch
completion y log file parallel write. El primero indica la cantidad de tiempo que el proceso LGWR esper para
completar un cambio de log, y el segundo muestra cunto tiempo le tom al proceso LGWR escribir entradas de
Redo desde el buffer al archivo.
AJUSTE:
Una de las formas de asegurarse que los archivos Redo Log no causen problemas de rendimiento de
lectura/escritura es separando sus archivos de otros tipos de archivo Oracle, como ser los archivos de datos
control. Esto es debido a que la actividad de lectura/escritura es tpicamente secuencial y para el resto de los
archivos el acceso es aleatorio. Al separarlos, se mejorar la eficiencia de los dispositivos.
Una vez que estos archivos estn separados, se puede mejorar an ms si estos archivos son ubicados en
dispositivos lo ms rpidos posibles, como ser una estructura RAID.
ARCHIVADO:
El proceso de archivado (archiving) se refiere a la copia de los archivos Redo Log Online al momento del cambio de
log a una ubicacin secundaria para que luego puedan ser utilizados en algn escenario de recuperacin. Este
mecanismo es muy importante en el entorno del backup, pero tambin hay que tener ciertos cuidados cuando se
habla de Performance, ya que aplicar esta metodologa puede producir aumentos significativos en los tiempos de
escritura. Para esto se debe monitorear y ajustar este proceso correctamente.
La ubicacin de los archivos de Redo se especifica en el parmetro de inicio LOG_ARCHIVE_DEST
LOG_ARCHIVE_DEST_n, donde n son los destinos alternativos de almacenamiento. Hay que tener en cuenta que si
los destinos de archivado se llenan, el procesamiento de la base de datos se detiene lanzando un error de archivado
a la pantalla y al archivo de alertas hasta que se libere espacio en la ubicacin. Opcionalmente se puede definir una
ubicacin alternativa con el comando:
SQL> ALTER SYSTEM ARCHIVE LOG ALL TO
2. /u04/oradata/prod
De esta manera, se asigna un nuevo espacio para continuar el archivado, se libera la instancia nuevamente para
que siga procesando y se escribe esta informacin en el archivo de alertas

Figura 3.15



3.11. HERRAMIENTAS DE DIAGNOSTICO
El proceso en segundo plano LGWR puede implcitamente iniciar procesos de archivado adicionales siempre que la
cantidad actual sea inadecuada para cumplir con las necesidades de la instancia. De todas maneras, el DBA puede
experimentar definiendo explcitamente los procesos de archivados adicionales si se sabe de antemano que el
cuello de botella de rendimiento se encuentra en este proceso.
AJUSTE:
Para realizar esto, se ajusta el parmetro LOG_ARCHIVE_MAX_PROCESSES en el archivo de parmetros init.ora. La
cantidad de procesos de archivado a iniciar va a depender de la cantidad de ubicaciones definidas y de la velocidad
de escritura de las mismas.
El valor por defecto es uno y los posibles valores que puede tomar este parmetro va de 1 a 10, al igual que la
cantidad mxima de ubicaciones posibles de archivado. Esta cantidad de procesos ajustados en este parmetro
comenzar a operar al inicio de la instancia.
Para su monitoreo se puede contar con la vista dinmica de rendimiento V$ARCHIVE_PROCESSES, que mostrar la
cantidad y nivel de actividad de los mltiples procesos de archivado, como se ve en la Figura 3.16. La Figura 3.17
muestra un ejemplo de su utilizacin, donde se puede observar que se han iniciado cuatro procesos, de los cuales
dos (el cero y el uno) se encuentran en estado BUSY, o sea, copiando los contenidos de los archivos Redo Log
Online con la secuencia 100231 y 100232.

Figura 3.16



3.12. FUNCIONAMIENTO DEL CACHE DE DATOS (DATABASE BUFFER CACHE)
Entendiendo el funcionamiento del Cach de datos Database Buffer Cache.
El Cach de datos es una porcin de la SGA que almacena copias de los bloques de datos de los segmentos de una
aplicacin de usuario que se haya utilizado recientemente. Cada Buffer en el cach corresponde, en tamao, a un
bloque de la base de datos. Estos bloques pueden pertenecer a segmentos de tipo que aparecen en la Figura 3.18.
La utilizacin de cada uno de estos buffers en el cach se gestiona con la combinacin de los siguientes
mecanismos:
Una lista LRU
Procesos de Servidor
Proceso de Escritura DBWR
La lista del ltimo usado LRU (Last Recent Used) que utiliza esta estructura de memoria al igual que la
estructura Conjunto Compartido (Shared Pool) es un algoritmo en donde revisa las solicitudes subsecuentes de
nuevos buffers basndose en el tiempo que se han accedido por ltima vez. De esta manera, Oracle puede
mantener en memoria los bloques usados ms recientemente. As se tiene una lectura mucho ms rpida ya que la
lectura de memoria es mucho ms veloz que la de disco. La Figura 3.19 muestra un esquema de la utilizacin de
esta lista, donde inicialmente cuando hay una solicitud del Proceso de Servidor, se copian los bloques (A, B, C) del
disco a memoria al principio de la lista (Most Recent Used). Estos bloques permanecern en la lista y a medida que
ingresen nuevos bloques por otras solicitudes, se irn moviendo hacia el sector LRU (Last Recent Used). Si un
bloque A es accedido nuevamente durante su permanencia en la lista, el bloque nuevamente ser movido al inicio
de la lista.
Cuando un Proceso de Servidor no encuentra la informacin que necesita en la memoria, debe leerla desde el disco,
con lo que debe contar con buffers libres para su nueva ubicacin. Cuando se realiza esta operacin, el proceso de
servidor utiliza la lista LRU y una nueva lista, llamada Lista Sucia (Dirty List), de la siguiente manera:
Mientras se busca por bloques libres en la lista LRU, el proceso de servidor mueve cualquier bloque sucio que
encuentre en la lista LRU a la lista sucia.
La lista sucia crece a medida que se le mueven los bloques de la lista LRU. Cuando esta lista alcanza un tamao
definido, el proceso DBWn escribir los bloques de esta lista a disco.
El proceso DBWn puede tambin escribir bloques sucios al disco aunque la lista sucia no est completa. Esto
ocurre cuando un proceso de servidor ha examinado demasiados buffers sin encontrar un lugar libre. En este
caso, el proceso DBWn escribir los buffers sucios directamente de la lista LRU al disco.
Figura 3.17



La escritura de bloques sucios al disco no solamente se debe al proceso de servidor, hay otros eventos que causan
este proceso. La tabla de la Figura 3 muestra una lista completa de los factures que causan que el proceso DBWn
realice la escritura

Figura 3.18
Figura 3.19



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

3.14. EJERCICIO INTEGRADOR: LA BASE DE DATOS Y EL ACCESO AL DISCO



3.15. SINTESIS
En esta unidad se ha analizado la importancia de la distribucin de los distintos archivos de la base de datos y su
impacto en el procesamiento de las lecturas/escrituras (I/O).
Se ha verificado las distintas maneras de diagnosticar y medir los tiempos de respuesta de los procesos en segundo
plano a travs de las vistas dinmicas de rendimiento y de las herramientas grficas de Oracle Enterprise Manger.
Tambin se profundizo sobre el funcionamiento del proceso CheckPoint,y el proceso Database Writer, para
entender mejor los aspectos de ajuste y el porqu se realizan.



UNIDAD 4
CONJUNTO COMPARTIDO (SHARED POOL)
4.1. OBJETIVOS
En esta unidad las metas son: poder determinar el tamao de los objetos de la base de datos, poder describir la
UGA rea Global del Usuario; saber ajustar el espacio del conjunto compartido (Shared Pool); y adems conocer a
las mtricas del cach de la biblioteca, los problemas comunes al ajustar el conjunto compartido, y tambin al
Conjunto Grande (Large Pool).




4.3. ESTRUCTURAS DE MEMORIA
El conjunto compartido Shared Pool es la porcin de la SGA que almacena las consultas SQL y los bloques PL/SQL
que se han ejecutado recientemente por los usuarios. Esta estructura de memoria se gestiona por una lista LRU
(Last Recent Used).
Principio de funcionamiento:
Cuando una aplicacin ejecuta un comando SQL PL/SQL sobre la instancia, se realizarn una serie de operaciones
antes que se ejecute efectivamente. Primero, Oracle har conversiones necesarias para pasar la sentencia a
caracteres ASCII. Luego el proceso de servidor realiza un algoritmo de HASH sobre el string ASCII y el hash
resultante chequea si ese hash se encuentra en memoria (en el conjunto compartido). Si existe, el proceso de
usuario utilizar la versin que tenga en memoria para ejecutar la sentencia.
Ahora, si el valor de hash que tiene no se encuentra en esta estructura de memoria, el proceso de servidor
comenzar a hacer el parsing de la sentencia y luego la ejecutar. Esta tarea de parseo agrega un tiempo de
procesamiento para la respuesta, ya que debe verificar la sintaxis, existencias de objetos, estedsticas de acceso,
preparar la consulta y tener permisos para acceder; con lo que este paso es caro para el rendimiento de la base de
datos.
Esta tarea de parseo puede minimizarse si se ajusta correctamente tanto la aplicacin como la base de datos. Para
esto, se debe conocer cmo est formada esta estructura de memoria.
El conjunto compartido est formado por tres componentes: El Cach de Biblioteca Library Cache, el Cach de
Diccionario de Datos Data Dictionary Cache y el rea Global de Usuario User Global Area.
El Cach de Biblioteca es la ubicacin de memoria donde Oracle almacena las sentencias SQL PL/SQL usadas.
Cuando se habla de PL/SQL se habla de procedures, funciones, paquetes, triggers clases de Java. Esta estructura
contiene:
El texto de la sentencia.
El valor Hash de la sentencia.
Estadsticas asociadas a la sentencia.
El Plan de Ejecucin.

Figura 4.1



4.4. PROTECCION DE DATOS (LATCHES)
Los bloqueos en estas estructuras de memoria son utilizados para proteger el acceso inadecuado. De esta manera,
Oracle se asegura que un proceso no acceda concurrentemente a la misma porcin de estructura. Si un proceso
necesita una estructura que se est utilizando, el proceso experimentar una espera. Este comportamiento de
esperar vara dependiendo del tipo de bloqueo que se est utilizando:
Si el bloqueo se define como Dispuesto a Esperar, el proceso que solicita el acceso deber esperar un perodo de
tiempo e intentar acceder nuevamente debiendo esperar posiblemente si el bloqueo contina.
Si el bloqueo se especifica como Bloqueo Inmediato, el proceso que solicita acceso contina procesando, a pesar de
esperar que quede disponible ese acceso.
Si se detectan esperas frecuentes a esta estructura de memoria, esto indica que el Conjunto Compartido debera ser
controlado para un posible ajuste de rendimiento.
AJUSTE:
De ser necesario, para ajustar el conjunto compartido, se debera tener en cuenta:
Ajustar las consultas SQL: Identificar las sentencias similares que se podran compartir si se las escribe con una
notacin en comn y utilizando variables ligadas. Para esto se puede utilizar la vista V$SQLAREA donde tengan un
nmero bajo de ejecuciones.
Mantener en memoria sentencias ms utilizadas: stas deben estar el mayor tiempo posible en memoria. Si se
asigna ms espacio a esta estructura, este problema se reducir.
Evitar reanalizar: Si hay una sentencia almacenada en memoria y algn objeto que hace referencia sufre
modificaciones, la sentencia se tornar invlida debiendo analizarla nuevamente.
Reserva de espacio: Asegurarse la disponibilidad de espacio para grandes requisitos de memoria reservando
porciones de esta estructura.
Uso de PL/SQL: Oracle recomienda utilizar pequeas funciones empaquetadas de PL/SQL, en vez de grandes
bloques annimos.
Ambiente Compartido: para este ambiente conviene utilizar la estructura de memoria del conjunto grande (Large
Pool) para administrar las conexiones.

Figura 4.2



4.5. TERMINOLOGIA
El principal indicador de rendimiento del Conjunto Compartido (Shared Pool), es la media de la cantidad de
accesos Cache Hit Ratio que tenga esta estructura de memoria. Un alto valor de esta cantidad quiere decir que
hay muchos usuarios que estn ejecutando sentencias SQL boques PL/SQL que ya estn almacenados
cacheados en memoria. Estas cantidades de acceso pueden medirse tanto para el cach de biblioteca como para
el cach de diccionario de datos.
Oracle recomienda ajustar el cache de biblioteca para mejorar su rendimiento (sus hits), ya que un valor de esta
memoria por debajo de su valor ptimo tiene un gran impacto en el rendimiento de la base de datos.
Para tener informacin relacionada con los hits, se puede consultar la vista V$LIBRARYCACHE.
La Figura 4.4 muestra un ejemplo de la ejecucin de esta vista.
La columna GETHITRATIO hace referencia al trmino get para referirse a un tipo de bloqueo, llamado Bloqueo de
Parseo. Cada vez que ocurre un parseo, el valor del campo GETS es incrementado por 1. La columna GETHIT
almacena la cantidad de veces que las sentencias encontraron una copia en memoria (Cacheada), al momento de
parsearse, y cuando esto ocurre, no es necesario ejecutar un parking, el Proceso de Servidor simplemente ejecuta
la copia que tiene en memoria. De estas dos ltimas columnas se calcula la columna GetHitRatio. Para el ejemplo de
la Figura 1, este valor est sobre el 79% de eficacia, con lo que es una marca no muy buena, teniendo en cuenta que
para un ambiente OLTP Oracle recomienda una media sobre el 90%, pudindose mejorar.
AL igual que la columna GETS, PINS tambin est relacionada a los bloqueos. Mientras que GETS se asocia al
momento del parseo, PINS se asocia a los bloqueos que ocurren en tiempo de ejecucin, cuando se accede en forma
concurrente al mismo objeto en memoria. Cada vez que una sentencia se ejecuta, el valor de PINS se incrementa en
uno. La columna PINSHITRATIO indica cun frecuente se asocia la misma sentencia en tiempo de ejecucin. Para el
caso de la Figura 1, un valor del 90% es aceptable para un ambiente OLTP.
La columna RELOADS muestra la cantidad de veces que una sentencia debe ser vuelta a parsear porque el Cach
expir esta sentencia la invalid. Esta tarea se resuelve en forma automtica.
Las invalidaciones se almacenan en la columna INVALIDATIONS. stas ocurren cuando una sentencia es marcada
como invlida, debido a alguna modificacin de algn objeto que haga referencia, por ejemplo, al recompilar una
vista, todas las sentencias que estn cacheadas se marcan como invlidas debindose volver a parsear.
Figura 4.3



4.6. LIBRARY CACHE
Ahora que se sabe sobre los componentes del conjunto compartido y de qu manera medir su rendimiento, se
pueden comentar algunos mtodos para mejorar el rendimiento de esta estructura de memoria. El objetivo de
estos mtodos es incrementar el rendimiento del conjunto compartido mejorando las mtricas de las estructuras
del cach de biblioteca y de diccionario de datos.
AJUSTE:
La manera ms sencilla de mejorar el rendimiento de los cachs de biblioteca y de diccionario de datos es
aumentar el tamao del conjunto compartido en s, ya que Oracle Server gestiona dinmicamente los tamaos
relativos de las estructuras de biblioteca y de diccionario de datos, sobre el tamao total del conjunto compartido.
El tamao del conjunto compartido est determinado por el parmetro SHARED_POOL_SIZE. Este parmetro se
especifica en Bytes y por defecto se define en 64 MB para sistemas operativos de 64 bits y en 16 MB para sistemas
operativos de 32 bits. La Figura 4.5 muestra cmo se puede consultar la vista V$SGASTAT para conocer su tamao
(en este caso el valor por defecto).
El tamao del conjunto compartido puede ser ajustado en forma manual dinmica.
La Figura 4.6 muestra el comando para hacer este ajuste en forma dinmica, donde se modifica su valor a 200 MB,
teniendo en cuenta que el nuevo valor, sumado a los tamaos del buffer de datos y de Redo Log no puede exceder
el tamao del valor SGA_MAX_SIZE.

Figura 4.4
Figura 4.5



4.7. DIMENSIONADO DE LA LIBRARY CACHE
Continuando con el ajuste del conjunto compartido, adicionalmente al parmetro SHARED_POOL_SIZE, hay otros
parmetros de inicio que afectan directamente el rendimiento del conjunto compartido. Estos son:
OPEN_CURSORS: cada sesin individual tiene asignada un rea privada para el SQL para usarla con el manejo de
cursores. Este parmetro limita qu cantidad de estos cursores pueden ser usados por sesin. El valor por defecto
es 50. Esta cantidad suele ser poca para la mayora de las aplicaciones. Al aumentar este parmetro, no solamente
habilitar al usuario a abrir ms cursores, sino que tambin reducir el reparseo de las sentencias SQL, mejorando
de esta manera el Hit Ratio.
CURSOR_SPACE_FOR_TIME: cuando este parmetro se ajusta a TRUE, las reas compartidas de SQL son
resguardadas. Esto previene que el mecanismo LRU (Last Recent Used) elimine alguna sentencia SQL de memoria
hasta que todos los cursores que le hagan referencia se cierren. Esto reduce el tiempo de ejecucin de las consultas.
El valor por defecto es FALSE. Si se tiene suficiente memoria en el servidor como para almacenar todas las
sentencias que son utilizadas frecuentemente por la aplicacin, debera considerar la utilizacin de este parmetro.
Cabe destacar que Oracle Recomienda NO utilizar este parmetro si la aplicacin utiliza Oracle Forms como
plataforma de desarrollo.
SESSION_CACHED_CURSORS: cuando la misma consulta es ejecutada muchas veces por el mismo usuario, este
parmetro puede ser utilizado para definir qu cantidad de cursores asociados a esa consulta deberan ser
almacenados en memoria. El valor por defecto es 0. La recomendacin de Oracle es que si se utiliza Oracle Forms
se debera ajustar este parmetro a TRUE para mejorar el rendimiento de la memoria, ya que las sentencias SQL
contenidas en los formularios (que son ejecutadas frecuentemente a medida que los usuarios navegan por los
formularios) se almacenarn en memoria minimizando el reparseo.
CURSOR_SHARING: este parmetro permite al DBA cambiar el comportamiento por defecto al momento de
parsear y almacenar en memoria (cachear) sentencias SQL. La tabla de la Figura 4.7 muestra una descripcin de
los valores que se le puede asignar.

Figura 4.6
Figura 4.7



4.8. NIVELES DE ESTADISTICA
Existen una serie de vistas asociadas al rendimiento del conjunto compartido, las cuales son utilizadas parar
monitorear el uso del cach de biblioteca y pueden llegar a predecir su frecuencia de cambio en la memoria. En
Oracle 9i se han creado dos nuevas vistas V$SHARED_POOL_ADVICE y V$LIBRARY_CACHE_MEMORY para
proporcionar informacin necesaria para determinar efectivamente cunta memoria est usando la estructura de
cach de biblioteca mostrando en forma separada la cantidad que hay actualmente cacheada y en la lista LRU.
Otro valor importante que muestra es una estadstica de cunto tiempo se podra ganar perder al cambiar el
valor del conjunto compartido. Todas estas estadasticas almacenadas se pierden si se reinicia la instancia si se
ajusta el parmetro STATISTICS_LEVEL a BASIC.
La Figura 4.8 muestra un ensayo de la vista v$shared_pool_advice donde se puede ver que muestra informacin
sobre el tiempo estimado ahorrado [en segundos] durante el anlisis al utilizar diferentes tamaos del conjunto
compartido. Estos tamaos van del 50% al 200% del tamao actual de esta estructura y no se pueden redefinir.
Como se puede ver, la columna de ahorro de tiempo tiene el mismo valor, indicando que modificar el tamao del
conjunto compartido no variar en rendimiento del tiempo de anlisis. Pero si aumentase, mostrara que
efectivamente convendra hacer este ajuste

4.9. EL PLAN DE EJECUCION
Los Planes de Ejecucin resultantes del parking son almacenados en el conjunto compartido. Estos registros
pueden ser consultados utilizando la vista dinmica de rendimieto V$SQL_PLAN. Esta vista contiene la mayora de
las columnas que la tabla EXPLAIN_PLAN, ms otras columnas utilizadas para el monitoreo de la sentencia
almacenada a la que pertenece. Estas vistas pueden unirse junto a otras vistas para tener una actividad completa
de las sentencias SQL en la base de datos. El ejemplo de la Figura 4.9 muestra el usuario, la consulta SQL y el plan
de ejecucin para una consulta almacenada en el conjunto compartido por el usuario HR.
Figura 4.8



4.10. ASIGNACION DE MEMORIA
Continuando con las consultas del tema anterior, si se est buscando informacin ms general sobre los tipos de
sentencias SQL que los usuarios estn ejecutando al momento de monitorear la actividad en el conjunto
compartido, se puede utilizar la vista dinmica de rendimiento V$SESSION y V$DB_OBJECT_CACHE.
La vista V$SESSION contiene informacin general sobre cada uno de los procesos que estn conectados
actualmente a la instancia. Esta vista tiene una columna llamada COMMAND, que puede ser utilizada para
identificar qu tipo de sentencia se est ejecutando en esa sesin. Existen aproximadamente 90 posibles valores
para esta columna, los cuales representan un tipo distinto de sentencia SQL. La tabla de la Figura 4.10 muestra los
valores ms utilizados en esta vista. La Figura 4.11 muestra un ejemplo de la ejecucin de esta vista donde se la
consulta para saber qu usuarios estn realizando actualizaciones en este momento.
La vista dinmica de rendimiento V$DB_OBJECT_CACHE puede utilizarse para determinar qu tipo de objeto de la
base de datos est siendo referenciado por las sentencias SQL. Al seleccionar las columnas TYPE y EXECUTIONS de
esta vista, se puede tener una lista de la frecuencia con la que las aplicaciones han referenciado cada uno de los
objetos, como se ve en la Figura 4.12, donde se ve que el alto valor de ejecuciones del objeto CURSOR junto al
pequeo valor del objeto PACKAGE indica que la aplicacin se maneja mayormente por sentencias SQL y no por
procedimientos almacenados en la base de datos. Esta informacin es til ya que convirtiendo algunas de estas
sentencias SQL en paquetes PL/SQL en funciones puede mejorar notablemente el rendimiento del conjunto
compartido.

Figura 4.9
Figura 4.10



4.11. EL CONJUNTO COMPARTIDO (SHARED POOL)
Si una aplicacin realiza largas llamadas a paquetes PL/SQL Triggers, otras sentencias SQL que se encuentren
almacenadas en el cach, posiblemente se muevan fuera de la memoria, debido al comportamiento de la lista LRU.
Esto tiene por efecto reducir la capacidad de esta estructura para estas sentencias.
Para evitar este problema, Oracle brinda al DBA la habilidad de designar una porcin del cach de librera para ser
utilizado exclusivamente por paquetes PL/SQL grandes. Esta rea de memoria es llamada rea de Conjunto
Compartido Reservado.
AJUSTE:
El parmetro SHARED_POOL_RESERVED_SIZE puede ser utilizado para definir la cantidad de espacio en memoria
para uso exclusivo de estos objetos y los triggers. El valor de este parmetro se especifica en bytes y, como regla,
no puede sobrepasar el 50% del valor especificado en el parmetro SHARED_POOL_SIZE. Por defecto,
SHARED_POOL_RESERVED_SIZE se ajusta automticamente a un 5% del valor del tamao del conjunto
compartido, y la recomendacin de Oracle es ajustar este valor a un 10%.
Figura 4.11
Figura 4.12



Otra forma de determinar el tamao ptimo de memoria reservada es monitoreando la vista
V$DB_OBJECT_CACHE, donde se puede ver los tamaos de los paquetes PL/SQL que actualmente se encuentran
almacenados en memoria, como se ve en la Figura 4.13.
La vista dinmica de rendimiento V$SAHRED_POOL_RESERVED puede usarse para monitorear el uso de esta rea
de memoria y poder determinar si est correctamente ajustada. Los siguientes son indicadores de sobreasignacin
de memoria:
Las estadsticas en la columna REQUES_MISSES est constantemente en cero con el valor STATIC.
La columna FREE_SPACE tiene un valor sobre el 50% del total de memoria asignado a esta rea reservada.

4.12. DIMENSIONADO DEL CACHE DE DICCIONARIO DE DATOS
Al igual que el cach de librera, la medicin de la efectividad del Cach de Diccionario de Datos se expresa en
trminos de medias (Hit Ratio). Estas mtricas muestran la frecuencia con que la aplicacin encuentra informacin
del diccionario de datos almacenada en memoria, a pesar de haberla tenido que leer inicialmente del disco.
Esta informacin es contenida en una vista dinmica de rendimiento llamada V$ROWCACHE. La salida de la
herramienta STATSPACK tambin tiene estadsticas relacionadas con el cach de diccionario de datos.
Dos columnas de esta vista pueden usarse para calcular esta mtrica. Estas columnas son GETS y GETMISSES, como
se ve en la Figura 4.14 donde el resultado que arroja indica que la aplicacin est encontrado informacin en el
diccionario de datos almacenado en memoria casi un 97% de las veces que la requiere. Oracle recomienda ajustar
el Conjunto Compartido si esta mtrica se encuentra por debajo del 85%.
Observando la salida de la utilidad STATSPACK en la seccin encabezada Dictionary Cache Stats for DB, como
muestra la Figura 4.15, se puede ver que la performance de esta estructura de memoria tambin es expresada en
trminos de mtricas por prdidas (miss ratios). Por ejemplo, el valor de Pct Miss para cada uno de los
componentes del cach de diccionario de datos van de 0 a 3.6%. Esto significa que la mtrica de esta estructura se
encuentra entre el 96.4 y el 100% durante el perodo monitoreado.

Figura 4.13
Figura 4.14



4.13. ADMINISTRACION DE LA MEMORIA DE USUARIO
El rea Global del Usuario (UGA) se encuentra presente solamente si Oracle Server se encuentra configurado en
modo compartido. En esta arquitectura, el rea global de usuario es utilizada para almacenar en memoria
informacin sobre la sesin del usuario.
Esta informacin debe estar en una ubicacin compartida ya que la arquitectura compartida de Oracle Server
requiere varios procesos de servidor que a su vez gestionan varias sesiones de usuario compartiendo las
sentencias SQL y bloques PL/SQL.
Desde el momento en que un proceso de servidor compartido inici una transaccin, la informacin sobre esta
conexin debe guardarse en esta rea compartida.
En un ambiente dedicado, esta informacin es mantenida directamente por el rea Global de Procesos (PGA).

Figura 4.15
Figura 4.16



4.14. MANTENIMIENTO EN MEMORIA
Las aplicaciones que utilizan un uso muy grande de paquetes PL/SQL, triggers secuencias de Oracle pueden
mejorar sus mtricas de rendimiento del conjunto compartido almacenando permanentemente estos objetos (de
uso frecuente) en memoria hasta que la instancia se detenga. Esta tcnica es llamada Mantenimiento en Memoria
Pinning y se realiza a travs de un paquete PL/SQL provisto por Oracle, llamado DBMS_SHARED_POOL. Este tipo
de paquetes se almacenan en un espacio de almacenamiento reservado por el parmetro
SHARED_POOL_RESERVED_SIZE.
El paquete DBMS_SHARED_POOL no se crea por defecto al ejecutar el script catproc.sql al momento de crearse la
base de datos. Para ello, se debe ejecutar otro script llamado dbmspool.sql, ubicado en el directorio rdbms/admin.
de Oracle, con privilegios de SYSDBA.
Este paquete contiene dos procedimientos, KEEP y UNKEEP, los cuales son utilizados para mantener PIN y para
liberar UNPIN un paquete, trigger secuencia en memoria. La Figura 4.17 muestra un ejemplo en el que se
demuestra cmo almacenar un paquete PL/SQL llamado APPROVE_PO en memoria.
Una vez almacenado este objeto en memoria, nos interesara poder conocer verificar si esto ha sucedido
realmente saber qu objetos hay almacenados al momento. Para ello, utilizaremos la vista V$DB_OBJECT_CACHE,
como se ve en la Figura 4.18.
Continuando con la explicacin de esta tcnica de almacenamiento, hasta ahora sabemos cmo hacerlo y cmo
verificar su uso. Lo que nos queda por ver es saber qu se debe almacenar en este tipo de memoria.
Para determinar cules objetos deberan ser almacenados, se requiere un conocimiento de la aplicacin y sus
componentes. Una forma de tener informacin y poder saber la frecuencia de uso de los objetos, es por medio de la
auditora de Oracle.

Figura 4.17
Figura 4.18



4.15. EJERCICIO INTEGRADOR: CONJUNTO COMPARTIDO
Identificar los componentes del .Conjunto Compartido (Shared Pool).

4.16. SINTESIS
El conjunto compartido juega un importante papel en el procesamiento de las sentencias SQL ejecutadas en la
instancia por la aplicacin. Acta como cach para estas definiciones, evitando que cuando se intenta ejecutar una
nueva sentencia que es idntica se tenga que volver a parsear.
El conjunto compartido almacena su informacin en dos reas: El cach de biblioteca y el cach del diccionario de
datos. El cach de biblioteca es utilizado para almacenar las sentencias SQL y los bloques PL/SQL como
procedimientos, funciones triggers. El cach del diccionario de datos almacena informacin, en la base de datos,
sobre los objetos que han sido utilizados por las sentencias SQL almacenadas en memoria.
El rendimiento del conjunto compartido se mide en trminos de los promedios mtricas de acceso, llamados hit
ratios para ambas estructuras de memoria. Estas mtricas se pueden obtener consultando las vistas dinmicas de
rendimiento V$LIBRARYCACHE y V$ROWCACHE, respectivamente. Adicionalmente se puede contar con la salida
de la utilidad STATSPACK.
La performance del conjunto compartido puede mejorarse incrementando el tamao de esta estructura, definiendo
un rea reservada para grandes objetos, ajustando las consultas que acceden a la base de datos y definiendo
correctamente la parametrizacin de los cursores al inicio de la instancia.



UNIDAD 5
DIMENSIONADO DEL BUFFER CACHE (DATA BASE BUFFER CACHE)
5.1. OBJETIVOS
Esta unidad tiene por objetivo que el alumno logre conocer tanto al asesor de tamao del cach, como el uso de la
estructura de memoria cach buffers.
Tambin es de inters que el alumno aprenda a crear y gestionar el cach buffers, as como tambin controlar su
uso.
Por ltimo el alumno deber poder identificar y resolver problemas de rendimiento.


5.3. VISION GENERAL
El cach de buffers Database Buffer Cache simplemente Buffer Cache es una porcin de la SGA que almacena
(cachea) copias de los bloques de datos de los segmentos de la aplicacin de los usuarios que han sido accedidos
recientemente. Cada buffer en el Buffer Cache corresponde en tamao, y contiene los datos de un bloque de la base
de datos.
Los bloques almacenados en el Buffer Cache pueden llegar a pertenecer a distintos tipos de segmento:
Tablas
ndices
Clusters
Grandes Segmentos (LOB)
Segmentos de Rollback
Segmentos Temporales



La utilizacin de estos bloques va a ser gestionada por la combinacin de una serie de mecanismos, como ser una
lista LRU (explicada en captulos anteriores ), un Proceso de Servidor y un proceso de escritura en segundo plano
(DBWn).
Al concepto de LRU se podra agregar que las copias de los bloques que son almacenados en buffers libres
contienen la misma informacin que los bloques que estn almacenados en el disco. Aquellos bloques en donde la
copia de memoria no concuerda con la copia en disco, son llamados buffers sucios Dirty Buffers, y por lo tanto, no
pueden ser sobrescritos por nuevos bloques recin ledos del disco hasta que su contenido no sea primero escrito a
disco.

Figura 5.1
Figura 5.2



5.4. EL BUFFER CACHE
Por lo general, suele ser una buena prctica de ajuste mantener el tamao del Buffer Cache, ya sea en forma
dinmica manual, a travs de su parmetro de inicio DB_CACHE_SIZE.
Ms all de esta tcnica, es posible utilizar una nueva caracterstica de Oracle 9i que es el Asesor del Buffer Cache.
Este asesor realiza un seguimiento de los cambios que ocurren en le rendimiento del cach y estima aquellos
movimientos que podran superar el tamao actual del buffer. Para poder utilizar este asesor, previamente
requiere cierta configuracin.
AJUSTE:
Si se requiere que el asesor comience a tomar muestras estadsticas de valores, se debe ajustar el parmetro
DB_CACHE_ADVICE en ON. Esto causa que Oracle 9i asigne memoria para el Asesor del Buffer Cache y comience a
operar con el rendimiento del Buffer Cache. El resto de los posibles valores de este parmetro pueden ser:
OFF, que detiene el Asesor del Buffer Cache liberando el espacio en memoria y recursos de CPU.
READY, donde se preasigna memoria para el Asesor, pero no inicia su proceso, con lo que tampoco ocupar
recursos de CPU. Esta opcin suele ser utilizada para asegurarse que en el futuro si se habilita el Asesor del
Buffer Cache no tendr problemas de asignacin de memoria.
Las estadsticas que realiza el Asesor del Buffer Cache se almacenan en la vista dinmica de rendimiento
V$DB_CACHE_ADVICE. Las columnas de esta vista se pueden observar en la Figura 5.3.
Luego de un perodo normal de procesamiento de la base de datos, el DBA puede examinar esta vista para conocer
los datos estadsticos que resolvi. La Figura 5.4 muestra un ensayo utilizando esta vista, donde se puede observar
que los lmites de salida de los registros estn para un tamao de bloque de 8KB.
Para este ejemplo, se asume que la instancia que gener esta salida tuvo un Buffer Cache de 30MB. Este valor
aparece en el tercer registro de la columna SIZE_FOR_ESTIMATE. La columna ESTD_PHYSICAL_READS indica que
durante el tiempo de recoleccin de informacin del asesor, se estiman 6028 lecturas fsicas con este tamao de
Buffer Cache. Si el tamao del Buffer Cache se redujera a 20 MB, se deberan esperar 6614 lecturas fsicas segn
esta consulta.
De esta manera, el Asesor del Buffer Cache le da al DBA una estimacin con un cuadro comparativo de cuntas
lecturas fsicas se pueden esperar al incrementar reducir el tamao del Buffer Cache.

Figura 5.3



5.5. ADMINISTRACION DEL BUFFER CACHE
El objetivo de mejorar el rendimiento del Buffer Cache es reducir la demanda del acceso de las consultas al disco.
Para esto es que los bloques se ubican en memoria. Es por ello que si no se ajusta el Buffer Cache a un tamao
adecuado, Oracle Server posiblemente muestre resultados pobres de rendimiento de las consultas.
Como hemos mencionado, los mecanismos de comprobacin del uso del Buffer Cache son:
Comprobacin de los eventos de espera usando las vistas V$SYSTEM_EVENT, V$SESSIONS_EVENT y
V$SESSION_WAIT.
Utilizar el Asesor del Buffer Cache a travs de la vista V$DB_CACHE_ADVICE.
AJUSTE:
El ajuste de esta estructura de memoria pude hacerse utilizando varias tcnicas, que tienen por objetivo minimizar
los eventos de espera. A modo de resumen, para mejorar el uso del Buffer Cache, el DBA puede:
Revisar que las sentencias SQL que se ejecutan estn ajustadas correctamente para minimizar la cantidad de
bloques a acceder.
Tener en cuenta la utilizacin de ndices.
Utilizar el Asesor del Buffer Cache para determinar si se debe modificar el tamao del Buffer.
Utilizar varios conjuntos de buffers para separar los bloques accedidos por caracterstica de acceso.
Configurar las tablas ms utilizadas para almacenarlas en memoria.
Figura 5.4



5.6. INDICADORES DE PERFOMANCE
La vista dinmica de rendimiento V$SYSTAT contiene estadsticas de rendimiento generales para toda la base de
datos, desde que se ha iniciado la instancia. La descripcin de esta vista se puede observar en la tabla de la
Figura 5.6.
Existen ms de 200 diferentes estadsticas que colecta la vista V$SYSSTAT. De todas formas slo cuatro de ellas
estn relacionadas con el ajuste del Buffer Cache.
Phisical Reads: esta estadstica indica la cantidad de bloques de datos (tablas, ndices y segmentos de roll back)
ledos desde el disco al buffer cache, desde que se ha iniciado la instancia.
Phisical Reads Direct (LOB): esta estadstica indica la cantidad de lecturas que sobrepasaron el Buffer Cache,
debido a que son de un tipo de datos muy grande.
Session Logical Reads: esta estadstica muestra la cantidad de veces que se ha solicitado por un bloque que ya
exista en memoria, utilizando de esta manera, el buffer almacenado en cach.
La Figura 5.7 muestra un ensayo de esta vista donde se utilizan estas estadsticas para calcular la media de lectura
del Buffer Cache, donde se puede observar que esta consulta indica que hay un 93.7% de las veces que las
aplicaciones de usuario encuentran sus solicitudes en el Buffer Cache.
La recomendacin de Oracle es que en un ambiente OLTP la media de acceso al Buffer Cache debe estar por encima
del 90%.

Figura 5.5
Figura 5.6



5.7. LA IMPORTANCIA DE LAS METRICAS (HIT RATIO)
Como vimos en el tema anterior, las mtricas estadsticas son muy tiles al momento de tener que medir el
rendimiento del Buffer Cache. De todas maneras, existen tambin mediciones que no son mtricas del Buffer
Cache, para medir su rendimiento. Estos indicadores estn relacionados a procesos que buscan buffers libres en el
Buffer Cache, definindose bajo el nombre de:
Free Buffer Inspected: es la cantidad de buffers inspeccionados por el Proceso de Servidor antes de encontrar un
buffer libre. Un indicador relacionado es Dirty Buffer Inspected, el cual representa la cantidad total de buffers
sucios que un Proceso de Servidor encontr mientras trataba de buscar un buffer libre.
Free Buffer Waits: es la cantidad de veces que el Proceso de Servidor ha tenido que esperar para inspeccionar por
buffers libres. Estas esperas ocurren cuando el Proceso de Servidor tuvo que esperar a que el proceso de escritura
de datos (DBWn) escriba los buffers sucios al disco.
Buffer Busy Waits: indica la cantidad de veces a que el Proceso de Servidor ha tenido que esperar a que un buffer
libre se vuelva disponible. Estas esperas ocurren cuando un buffer solicitado por un Proceso de Servidor se
encuentra en memoria, pero est en uso por otro proceso. Tambin se puede dar para los segmentos de rollback
para los buffers de ndices.
Las vistas dinmicas de rendimiento V$SYSTEM_EVENT y V$SYSSTAT contienen estos indicadores descritos, como
se ensaya en la Figura 5.8.

Figura 5.7
Figura 5.8



5.8. DIMENSIONADO DEL BUFFER CACHE
Por defecto, todos los segmentos de la base de datos se almacenan cachean en el Buffer Cache por defecto; esto
da lugar a que algunas tablas que se acceden con una frecuencia muy baja y que son de inters para muy pocas
aplicaciones, puedan causar que las tablas que s son frecuentes se caigan de la lista LRU del Buffer Cache.
Para evitar esto, Oracle provee la capacidad de dividir el Buffer Cache hasta tres veces, dando como resultado
varios Conjuntos de Buffers Cache Buffers Pools. De esta manera, el DBA determina explcitamente qu segmento
se cachea y en qu conjunto de buffers de cach.
Antes de proceder a la creacin de estos Conjuntos de Buffers Cache Buffers Pools, el DBA debe determinar qu
tipo de conjunto de buffers necesita utilizar. Cada Conjunto de Buffers es utilizado para almacenar segmentos
basndose en su frecuencia de uso:
KEEP POOL: utilizado para almacenar segmentos que rara vez le interese que baje de memoria. El tamao de este
buffer se designa a travs de un parmetro de inicio llamado DB_KEEP_CACHE_SIZE. El valor por defecto es 0 bytes,
lo que significa que al iniciar la instancia este Conjunto de Buffers de Cach no se puede utilizar.
RECYCLE POOL: a diferencia del Keep Pool, este buffer se utiliza para almacenar segmentos que no le interesan
que permanezcan en memoria. El tamao de este conjunto se define por el parmetro de inicio
DB_RECYCLE_CACHE_SIZE y, al igual que el conjunto KEEP, es opcional, teniendo un valor por defecto de 0 bytes.
DEFAULT POOL: es utilizado para almacenar segmentos que no se han asignado a ninguno de los conjuntos
anteriores. Este es el Buffer Cache en s y su tamao se debe definir obligatoriamente para que la instancia pueda
iniciar con el parmetro DB_CACHE_SIZE. El valor por defecto es 48 MB.
Una vez que los conjuntos de Buffer Cache se han creado, el DBA puede asignar los segmentos para que se
almacenen en el cach que corresponda. Para ello, debe alterar la estructura de los objetos definiendo el parmetro
BUFFER_POOL para indicar en qu conjunto se debe almacenar en memoria, como se ve en la Figura 5.10.

Figura 5.9



5.9. LINEAMIENTOS PARA EL DIMENSIONADO
El paquete PL/SQL DMBS_STATS ofrece varias opciones adicionales, para el anlisis de rendimiento, que no se
encuentran en el paquete DBMS_UTILITY. Algunas de estas opciones incluyen la habilidad de:
Almacenar viejas estadsticas antes de que se calculen nuevas. Esto es muy til ya que permite restaurar viejos
valores para realizar comparaciones.
Poder tomar muestras ms pequeas al momento de realizar estimaciones.
Calcular estadsticas de tablas mucho ms rpido pudiendo realizar el anlisis en paralelo.
Tomar estadsticas automticamente, en tablas altamente voltiles, pudiendo pasar por alto el almacenamiento
en tablas estticas.
De esta manera, al utilizar este paquete se puede conocer el tamao de los objetos en la base de datos y se puede
estimar cmo se debera ajustar el conjunto de buffers KEPP, al sumar los tamaos de todos los objetos que se
designaron a este conjunto.
Podemos ver un ejemplo de su utilizacin en la Figura 5.11 donde se pretende ajustar el conjunto KEEP en funcin
del tamao de la tabla DEPARTMENTS del esquema HR, dando como resultado 24 bloques.
Adicionalmente se pueden utilizar dos vistas ms, V$CACHE y DBA_USERS para tener informacin sobre los
segmentos que posiblemente sean buenos candidatos para ser almacenados en el conjunto KEEP en el conjunto
RECYCLE. La tabla de la Figura 5.12 muestra una descripcin de estas vistas.
Hay que tener en cuenta que para poder utilizar la vista V$CACHE, se debe correr previamente su script de
creacin, llamado CATPARR.SQL, incluido en la instalacin del Oracle Server.
La Figura 5.13 muestra un ensayo con estas vistas donde se pueden ver los objetos que actualmente se encuentran
en el Buffer Cache, incluyendo los bloques que se estn almacenando y el tipo de segmento al que pertenecen.
Al analizar la salida de esta consulta, se puede ver que las tablas EMPLOYEE y REGION y el ndice EMPLOYEE_PK se
encuentran actualmente en el Buffer Cache, los cuales son buenos candidatos para el conjunto KEEP. Con un
monitoreo frecuente de esta vista, se puede aproximar (por descarte) qu objetos debern designarse al conjunto
RECYCLE.
Figura 5.10



Figura 5.11
Figura 5.12
Figura 5.13



5.10. GESTION DE LAS METRICAS DE RENDIMIENTO
La vista dinmica de rendimiento V$BUFFER_POOL_STATISTICS contiene varias columnas que muestran
informacin til para calcular los indicadores de cada uno de los conjuntos de Buffer Cache. Las columnas ms
utilizadas de esta vista son:
NAME: Nombre del conjunto de Buffers.
DB_BLOCK_GETS, se refiere a la cantidad de solicitudes, por segmento, que se brindaron desde memoria.
CONSISTENT_GETS, es la cantidad de solicitudes que se brindaron desde los bloques de rollback.
PHYSICAL_READS, indica la cantidad de solicitudes que se brindaron desde el disco, de esta manera, se puede
utilizar esta vista para calcular las medias para cada conjunto de buffers, utilizando la consulta que se muestra en
la Figura 5.14.
Como se puede ver en el ejemplo, si se han definido los conjuntos correctamente, el indicador para el conjunto
KEEP debera ser muy alto y el indicador para el conjunto RECYCLE, por el contrario, debera tener un valor
pequeo. Un valor normal para el conjunto DEFAULT debera rondar entre el 70 y el 80%.

5.11. TRABAJANDO CON TABLAS EN MEMORIA
No importa cuntos conjuntos de buffers se decida utilizar, cada uno de ellos se manejar por una lista LRU.
Normalmente los bloques accedidos por las aplicaciones de los usuarios se ubican en esta lista. Cabe recordar que
las tablas que son escaneadas completas Full Table Scan (FTS) almacenan sus bloques despus del ltimo bloque
usado en la lista LRU, con lo que son prximas a dejar de existir en este cach.
Este comportamiento presenta un verdadero dilema para el ajuste de rendimiento. Si el optimizador se da cuenta
que esta tabla es accedida frecuentemente, pero no siempre se encuentra en la lista LRU ocasiona un alto impacto
en el acceso a disco.
Una forma de solucionar este problema (particularmente con tablas pequeas) es la utilizacin de tablas
almacenadas en memoria Cached Tables para evitar este acceso a disco. Para esto, estos buffers se almacenan al
principio de la lista LRU como si no fuesen FTS. El efecto de realizar esta tarea es tener ms tiempo la tabla en
memoria. Almacenar una tabla en memoria puede resolverse de tres maneras: al momento de crear la tabla,
alterando la definicin de la tabla utilizando un HINT en la consulta.
Las Figuras 5.15, 5.16 y 5.17 muestran ejemplos de estas implementaciones.
Figura 5.14



5.12. FREE LIST
Como se ha hablado en captulos anteriores, los segmentos de Oracle utilizan bloques para almacenar datos. De
esta manera, cada segmento mantiene una lista llamada Lista Libre Free List que contiene informacin de
aquellos bloques en los segmentos que estn disponibles para recibir nuevos datos. Los bloques que cumplen con
esta condicin son aquellos que no han alcanzado el tamao definido por el parmetro PCTFREE.
Si la aplicacin tiene muchos usuarios concurrentes realizando operaciones de Insert, el Proceso de Servidor puede
llegar a experimentar esperas cuando trata de acceder a la Lista de Bloques Libres. Estas esperas son llamadas
Contencin de la Lista Libre Free Lists Contention.
Este tipo de contencin puede ser detectado consultando las vistas dinmicas de rendimiento V$WAITSTAT,
V$SYSTEM_EVENT y V$SESSION_WAIT y la vista del diccionario de datos DBA_SEGMENTS.
La vista V$SYSTEM_EVENT muestra estadsticas sobre los eventos de espera que han ocurrido en la base de datos
desde que ha iniciado la instancia. Si se detectan ocurrencias de espera en el Buffer, indica que puede llegar a
existir una contencin de la Lista Libre. La consulta que se ensaya en la Figura 5.18, se utiliza para determinar si
ocurren esperas en el buffer Buffer Busy Waits.
La vista V$WAITSTAT contiene estadsticas sobre la contencin para cada bloque del segmento. La tabla de la
Figura 5.19 muestra los contenidos de esta vista.
Figura 5.15
Figura 5.16
Figura 5.17





La vista V$SESSION_WAIT contiene estadsticas relacionadas a las esperas experimentadas por cada una de las
sesiones en forma individual, y adems puede ser unida con la vista del diccionario de datos V$DBA_SEGMENTS
que contiene informacin sobre cada uno de los segmentos de la base de datos para determinar qu segmentos
estn experimentando una Contencin de la Lista Libre. La consulta que se ensaya en la Figura 5.20 muestra la
unin de estas dos vistas, donde se puede observar que la tabla EMPLOYEE que slo tiene una lista libre es una de
las causantes de contencin en la base de datos.

5.13. AMBIENTE DISTRIBUIDO
Para mejorar el rendimiento del proceso en segundo plano DBWn, se pueden utilizar dos parmetros de inicio:
DBWR_IO_SLAVES y DB_WRITER_PROCESSES. Cada uno de estos parmetros tiene su cometido en el
mejoramiento del rendimiento de la transicin de los bloques de datos entre el medio fsico y la memoria (Buffer
Cache).
Figura 5.18
Figura 5.19
Figura 5.20



El parmetro DBWR_IO_SLAVES especifica la cantidad de procesos esclavos del DBWn que se iniciarn junto con el
inicio de la instancia. El valor por defecto es 0 y el valor mximo de este parmetro va a depender del sistema
operativo. Cada proceso esclavo tendr un nombre designado para ejecutarse en el sistema operativo. Para el caso
de UNIX, la convencin utilizada para los procesos esclavos de una instancia llamada PROD, es:
Primer proceso esclavo de DBW0: ora_i101_PROD
Segundo proceso esclavo de DBW0: ora_i102_PROD
Proceso n esclavo de DBW0: ora_in_PROD
Los procesos esclavos son similares a los procesos DBWn en s, con la diferencia que solamente pueden realizar
operaciones de escritura, no pueden realizar lecturas para llevar bloques del disco a la memoria. El propsito de
estos esclavos es simular un acceso a disco asincrnico en un sistema operativo que slo soporte el acceso a disco
sincrnico. De esta manera se aliviana la tarea de DBW0 en el proceso de lectura.
Mientras que los esclavos de DBWn pueden ayudar al rendimiento de entrada/salida, no son capaces de realizar
todas las tareas del proceso DBWn (como administrar las listas LRU en el Buffer Cache). Si este proceso necesita
asistencia para realizar estas tareas, es posible iniciar procesos adicionales DBWn utilizando el parmetro
DB_WRITER_PROCESSES. El valor por defecto es 1 y, al igual que para los esclavos, el valor mximo depender de
la capacidad del sistema operativo no pudiendo superar los 10 procesos. La forma de llamarse estos procesos ser
entonces: DBW0, DBW1, DBW2 DBW9.
Mltiples procesos DBWn, generalmente tiene buen rendimiento de escritura/lectura, por ejemplo, teniendo cinco
procesos DBWn sin procesos esclavos ofrecern un mejor rendimiento que teniendo un solo proceso DBWn con
cuatro esclavos. El balanceo entre la cantidad de procesos DBWn y procesos esclavos, depender del tipo de espera
que se desea ajustar del cuello de botella que se est presentando en el sistema.

5.14. RENDIMIENTO DEL BUFFER CACHE
Un indicador de acceso al Buffer Cache del 100% no siempre significa que sea el mejor rendimiento.
Es posible que los usuarios de una base de datos se estn quejando por el pobre rendimiento de la base de datos,
con lo que el DBA realiza su anlisis consultando la vista V$SYSSTAT y encuentra un resultado del 99,97%.
Aparentemente este indicador es el correcto, con lo que el DBA decide revisar otros aspectos de la base de datos
que puedan afectar el rendimiento.
En esta situacin, se debera realizar una inspeccin ms detallada del contenido del Buffer Cache. En particular se
debera determinar qu cantidad de buffers de ndices se almacenan en memoria. Esto se podra lograr utilizando
las vistas V$CACHE y DBA_USERS. De esta manera, se podra dar cuenta, entonces, de que una columna de una gran
tabla est utilizando este ndice en memoria. Adicionalmente se da cuenta que esta columna en memoria tiene una
muy baja cardinalidad de datos, por ejemplo cuatro posibles valores ocupando un 90% del Buffer con estos
bloques.
Estos bloques de ndice son muy utilizados por la aplicacin y es por esto que siempre estarn llevando bloques a
memoria dando una falsa impresin que el Buffer Cache est funcionando correctamente segn su indicador de
acceso.
Para poder solucionar este problema, el DBA se debera asegurar que las estadsticas actuales se encuentran
almacenadas en el diccionario de datos para que el optimizador pueda determinar si le conviene utilizar el ndice
una lectura completa de la tabla (Full Table Scan).
Otra forma de ajustar esto es designar los bloques de este segmento para que sean almacenados en el conjunto
RECYCLE en lugar del Buffer Cache.
Figura 5.21



Como se ha dicho al inicio de este tema, un indicador de acceso al Buffer Cach del 100% no siempre significa que
sea el mejor rendimiento.

5.15. FUNCIONAMIENTO DEL BUFFER CACHE

5.16. EJERCICIO INTEGRADOR: BUFFER CACHE
El ejercicio siguiente permitir comprobar los conocimientos adquiridos con respecto al Buffer Cache.
Figura 5.21



5.17. SINTESIS
El rol del Buffer Cache es el de almacenar los segmentos ms frecuentemente utilizados para que la aplicacin que
lo utiliza minimice la cantidad de lecturas al medio fsico, al acceder a los datos. El tamao del Buffer Cache se
determina por los parmetros SGA_MAX_SIZE, DB_CACHE_SIZE, DB_KEEP_CACHE_SIZE y
DB_RECYCLE_CACHE_SIZE. Cada uno de estos buffers almacena los datos de cada bloque del segmento. La
actividad del Buffer Cache se gestiona por medio de listas LRU, listas sucias, procesos de servidor y procesos de
escritura (DBWn).
El rendimiento del Buffer Cache se mide por indicadores que comparan la cantidad de lecturas realizadas en
memoria con la cantidad de lecturas que se han tenido que realizar en disco. Un indicador del 90% mejor, es el
esperado para un ambiente OLTP. Este indicador puede ser calculado con la vista V$SYSSTAT la salida del
paquete STATSPACK.
Otros indicadores de rendimiento del Buffer Cache son las esperas del acceso a los bloques libres, llamados Free
Buffer Inspected, Buffers Busy Waits y Free Buffers Wait.
Las opciones de mejoramiento de estos indicadores incluyen agrandar el tamao del Buffer Cache, utilizar
mltiples conjuntos de buffers, almacenar tablas en memoria, mejorar el rendimiento del proceso de
lectura/escritura y utilizar ndices para minimizar el acceso completo a una tabla (Full Table Scan).

Teoría

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Teoría

Uploaded by

Copyright:

Available Formats

PARTE II

DIMENSIONADO DE LA BASE DE DATOS

You might also like