- El Database Buffer Cache.
- El Log Buffer.
- El Shared Pool.
Puede, opcionalmente, también contener.
- Un Large Pool.
- Un Java Pool.
- Un Streams Pool.
Sesiones de usuario también necesitan
memoria del lado de servidor. Esta es no compartida y es conocida como el
Program Global Area, o PGA. Cada sesión tendrá su propia PGA privada.
EXAMEN
¿Qué estructuras SGA son requeridas y
cuales son opcionales? El Database Buffer Cache, Log Buffer y Shared Pool son
requeridas; El Large Pool, Java Pool, y Streams Pool son opcionales.
Administrar el tamaño de estas estructuras
puede ser en gran parte automáticamente, o el DBA puede controlar el tamaño de
las mismas. Es generalmente buena práctica utilizar la administración
automática.
EL DATABASE BUFFER CACHE.
El Database Buffer Cache es el área de
trabajo para ejecución de SQL. Cuando la actualización de datos, sesiones de
usuarios no actualizan directamente los datos en el disco. Los bloques de datos
que contienen los datos de interés son primeramente copiados en el Database
Buffer Cache. Cambios (tales como inserción de nuevos registros y borrado o
modificación de registros existentes) son aplicados a estas copias de los
bloques de datos en el Database Buffer Cache. Los bloques permanecerán en el
Cache por algún tiempo después, hasta que el buffer que ocupan es necesario
para caching otro bloque.
Cuando consultas datos, los datos también
van vía Cache. La sesión resuelve que los bloques contienen las filas de
interés y los copia al Database Buffer Cache; los registros relevantes entonces
se transfieren al PGA de la sesión para futuros procesamientos. Y otra vez, los
bloques permanecerán en el Database Buffer Cache por algún tiempo después.
Tome nota del término Block. Los DataFiles
son formateados en bloques de tamaño fijo. Filas de las Tablas, y otros objetos
de datos tales como Index Keys, son almacenados en estos bloques. El Database
Buffer Cache es formateado en buffers de memoria cada tamaño para mantener un
bloque. A diferencia de los bloques, las filas son longitud variable; la
longitud de una fila dependerá sobre el número de columnas definidas para la
tabla, si las columnas tienen nada en ellos, y si es así, qué. Dependiendo del
tamaño de los bloques (que es elegido por el DBA) y el tamaño de los registros
(que depende de la tabla y su uso), puede haber varias filas por bloques o
posiblemente una fila puede estar en varios bloques, la estructura de los Bloques
de Datos será descrita en la sección de “DataFiles”.
Idealmente, todos los bloques contienen
datos que son accesados frecuentemente estarán en el Database Buffer Cache, por
lo tanto minimiza la necesidad de Disco. Como un uso típico del Database Buffer
Cache, considere un usuario final recuperando un registro de empleado y su
actualización, con estas declaraciones:
select last_name, salary, job_id from
employees where employee_id=100;
update employees set salary=salary * 1.1
where employee_id=100;
commit;
El proceso usuario solicitará el empleado
por el numero de empleado y construyo la instrucción SELECT. El SELECT
recuperará algunos detalles para ser enviados al Proceso de usuario, donde
serán formateados para desplegarlo. Para ejecutar esta instrucción, el proceso
servidor de las sesiones leerá el Bloque da Datos que contiene las filas
relevantes de un DataFiles en un Buffer. El proceso de usuario entonces
iniciará una pantalla de dialogo para solicitar algún cambio que serán hechos y
verificados, a continuación la instrucción UPDATE y la instrucción COMMIT serán
construidas y enviadas a el Proceso Servidor para su ejecución. Previsto que un
periodo excesivo de tiempo no ha transcurrido, El Bloque con el registro
todavía estará disponible en el Cache cuando la instrucción es ejecutada. En
este ejemplo, La Tasa de aciertos del Buffer Cache será de 50 porciento (%):
Dos accesos de un Bloque en el Cache, pero solo una lectura del bloque al
disco. El Database Buffer Cache bien afinado puede resultar en un cache con un
porcentaje de aciertos de más del 90 por ciento.
Un Buffer almacenando un Block cuya imagen
en el Cache no es lo mismo como la imagen sobre el disco a menudo es referido
como un Buffer sucio. Un Buffer será limpio cuando un bloque primero se copia
en él; en este punto; la Imagen del Bloque en el Buffer es lo mismo como la
imagen del bloque sobre el disco. El buffer llegara a ser sucio cuando el block
en el es actualizado. Eventualmente, los Buffers sucios se deben escribir de
nuevo a los DataFiles, momento en el que el Buffer será limpio otra vez,
incluso después de ser escrito en el Disco, el bloque permanece en memoria; es
posible que el Buffer no será sobrescrito con otro bloque por algún tiempo.
Observe que no existe una correlación
entre la frecuencia de actualizaciones a un Buffer(o el número de COMMITS) y
cuando consigue escribir de nuevo en los DataFiles. El escribir a los DataFiles
es hecho por el Proceso Background Database Writer (Database Writer Background
Process).
El tamaño del Database Buffer Cache es
crítico para el rendimiento. El cache debe ser del tamaño adecuado para
almacenar todos los bloques accedidos frecuentemente (ya sea limpio o sucio)
pero no tan grande que cachea bloques que son realmente necesarios. Un cache de
tamaño inferior resultará en una excesiva actividad de disco, como los bloques
de acceso frecuente son continuamente leídos de disco, utilizados, sobrescritos
por otros bloques, y entonces leídos desde disco otra vez. Un cache de gran
tamaño no es tan malo (siempre y cuando no es tan grande que el sistema
operativo está teniendo que intercambiar las páginas de la memoria virtual
dentro y fuera de memoria verdadera) pero puede causar problemas, por ejemplo,
el Inicio de una instancia es más lento si se trata de un Database Buffer Cache
masivo.
EXAMEN.
El tamaño del Database Buffer Cache puede
ser ajustado dinámicamente, y puede ser administrado automáticamente.
EN EL TRABAJO.
La determinación del tamaño óptimo del
Database Buffer Cache es una aplicación específica y un asunto ajuste de
rendimiento. Es imposible dar otra cosa que una vaga directrices sin hacer
observaciones, pero es probable que sea cierto que la mayoría de las bases de
datos funcionará bien con una caché de tamaño en cientos de megabytes hasta
unos pocos gigabytes. Muy pocas aplicaciones rendirán bien con un cache pequeño
que estos, y no muchos necesitarán un cache de centenares de gigabytes.
El Database Buffer Cache es asignado en el
momento de inicio de la instancia. Antes de la versión 9i de la base de datos
no era posible cambiar el tamaño del Database Buffer Cache sin reiniciar la
instancia de Base de Datos, pero desde 9i en adelante esta puede ser ajustada
en cualquier momento.
Este cambio de tamaño puede ser manual, o
(desde la versión 10g en adelante) automático en función de la carga de
trabajo, si el mecanismo automático ha sido habilitado.
EL LOG BUFFER.
El Log Buffer es una pequeña área, a corto
plazo de parada para los change vectors antes de que se escriban en el Redo Log
en Disco. Un change Vector es una modificación aplicada a algo; Ejecutando
instrucciones DML genera change vectors aplicados a los a datos. El Redo Log es
la garantía de la Base de Datos que los datos nunca se perderán: cada vez que
un Bloque de Datos es cambiado, los change vectors aplicados al Block son
escritos al Redo Log, desde donde pueden ser extraídos y aplicados a los
respaldos de los DataFiles si fuera necesario para restaurar un DataFile.
Redo no escribe directamente a los
Archivos Redo Log por Procesos de Servidor de la sesión. Si lo fuera, Las
sesiones tendrían que esperar operaciones de entrada-salida del disco a
completarse siempre que se ejecute una instrucción DML. En lugar, las sesiones
escriben el Redo al Log Buffer, en memoria. Esto es mucho más rápido que
escribir en el disco. El Log Buffer se escribe a los archivos de Redo Log. Una
escritura del Log Buffer a disco puede por lo tanto ser un proceso en lote de muchos
change vectors de muchas transacciones. Sin embargo, los change vectors en el
Log Buffer son escritos a disco en tiempo casi real-y cuando una sesión emite
una sentencia COMMIT, el Log Buffer (Que pueden contener vectores cambio de
muchas sesiones, intercalados entre sí) escribe realmente lo que hace en tiempo
real. Las escrituras son hechas por el Proceso Background Log Writer, el LGWR.
El Log Buffer es pequeño (en comparación
con otras Estructuras de Memoria) porque es un área de almacenamiento a muy
corto plazo. Los Change Vectors se insertan en él y fluyen a disco en casi
tiempo real.
No hay necesidad para que sea más que unos
pocos megabytes a lo mucho, y de hecho haciendo esto mucho más grande que el
valor por default puede ser seriamente malo para el rendimiento. El Valor por
default es determinado por el Servidor Oracle y es basado en el número de CPUS
en el nodo de Servidor.
No es posible crear un Log Buffer más
pequeño que el valor por default. Si usted intenta, esto será establecido al
tamaño por default de todos modos. Es posible crear un Log Buffer más grande
que el Valor por default, pero esto no es una buena idea. El problema es que
cuando una sentencia COMMIT es emitida, parte del procesamiento del commit
implica escribir el contenido del Log Buffer a los archivos Redo Log en Disco.
Esta escritura se produce en tiempo real, y mientras esta en progreso, la
sesión que emita el COMMIT se colgará. Procesamiento Commit es una parte
crítica de la Arquitectura Oracle. La garantía que una transacción committed
nunca será perdida está basada en esto: El mensaje de commit completado no se
devuelve a la sesión hasta que los Block de Datos en el Cache se han cambiado
(que significa que la transacción ha sido completada) y los change vectors han
sido escritos al Redo Log en Disco (y por lo tanto la transacción podría ser
recuperada si es necesario). Un Log Buffer grande significa que potencialmente
hay mas para escribir cuando es emitida una sentencia COMMIT, y por lo tanto
esto puede tomar más tiempo antes de que el mensaje commit complete pueda ser
enviado, y la sesión pueda reanudar el trabajo.
EN EL TRABAJO.
Aumentar el tamaño al Log Buffer arriba
del valor por default puede ser necesario para algunas aplicaciones, pero como
una regla inicie ajustando el Log Buffer en default.
El Log Buffer se asigna durante el inicio
de la Instancia, y este nunca puede ser cambiado de tamaño subsecuentemente sin
reiniciar la instancia. Este es un buffer circular. Como procesos de servidor
escriben Change Vectors a este, la dirección actual de escritura se mueve
alrededor(As server processes write change vectors to it, the current write
address moves around. - Como servidor de los procesos de escribir vectores
modificación de la misma, la escritura actual dirección se mueve alrededor.).
El proceso Log Writer escribe los Vectors en lotes, y como lo hace, el espacio
que ocuparon llega a estar disponible y se pueden sobre escribir más change
vectors. Es posible que en momento de máxima actividad, change vectors se generaran
más rápido que el proceso Log Writter pueda escribirlos. Si esto sucede, toda
la actividad DML cesará (por unos pocos milisegundos), mientras que el Log
Writer limpie el buffer. El proceso de limpiar el Log Buffer a disco es uno de
los últimos cuellos de botella en la Arquitectura de Oracle. No puede hacerse
más rápida las DML que el LGWR pueda vaciar los change vectors a los archivos
Online Redo Log.
EN EL TRABAJO.
Si la generación de Redo es el factor
limitante en el rendimiento de una Base de Datos. La única opción es ir a RAC.
En una Base de Datos RAC, cada su instancia tiene su propio Log Buffer, y su
propio LGWR. Esta es la única manera para Paralelizar la escritura de Datos
Redo a Disco.
EXAMEN.
El tamaño del Log Buffer es estático,
fijado en el inicio de la instancia. Este no puede ser administrado
automáticamente.
EL SHARED POOL.
El Shared Pool es la más compleja de las
estructuras de SGA. Está dividida en decenas de subestructura, todos los cuales
son administrados por el Servidor Oracle. Esta discusión de la arquitectura
mencionará solamente cuatro de los componentes del Shared Pool, y estos
solamente brevemente.
- Library Cache.
- Data Dictionary Cache.
- PL/SQL Area.
- SQL query y PL/SQL function result
cache.
Algunas otras estructuras serán descritas
en capítulos posteriores. Todas las estructuras dentro del Shared Pool son
administradas automáticamente. El tamaño será acorde al patrón de actividad
contra la instancia, dentro del tamaño total de la Shared Pool. La Shared Pool
en si mismo puede cambiar de tamaño de forma dinámica, o en respuesta a las
instrucciones del DBA o por haber gestionado automáticamente.
EXAMEN.
El tamaño del Shared Pool es dinámico y
puede ser gestionado automáticamente.
LIBRARY CACHE.
El Library Cache es un Área de Memoria
para almacenar el código recientemente ejecutado, en su forma analizada.
Analizar es la conversión de código escrito por programadores en algo
ejecutable, y es un proceso que Oracle hace en demanda. Almacenar código
analizado en el Shared Pool para poderlo reutilizar sin reanalizar, el
rendimiento puede mejorar mucho. Analizar código SQL toma tiempo. Considere una
simple instrucción SQL.
select * from employees where
last_name='KING';.
Antes que esta instrucción pueda ser
ejecutada, El Servidor Oracle tiene que resolver que significa, y como
ejecutarlo. Para comenzar, que es employees? Es una tabla, un sinónimo, o una
vista? Incluso existe? Entonces el “*” - ¿Cuáles son las columna que conforman
la tabla employees (si esta es una tabla)? El usuario tiene permisos para ver
la tabla? Las respuestas a estas preguntas y muchas otras tienen que ser
encontradas en el Diccionario de Datos.
EN EL TRABAJO.
El algoritmo utilizado para buscar
instrucciones SQL en el Library Cache está basado sobre los valores ASCII de
los caracteres que componen la instrucción. La menor diferencia (incluso algo
tan trivial como SELECT en lugar de select) significa que la declaración no
coincide, sino que se va a analizar de nuevo.
Resolviendo lo que significa la
declaración realmente, el servidor tiene que decidir la mejor manera de
ejecutarlo. Hay un índice sobre la columna last_name? Si es así, serie más
rápido usar el índice para localizar la fila, o para explorar toda la tabla.
Más consultas contra el diccionario de datos… es muy posible que una simple
consulta de una línea contra una tabla de usuario genere decenas de consultas
contra el diccionario de datos, y para el análisis de una instrucción tome
muchas veces más largo que el tiempo de ejecución. El propósito del Library
Cache del Shared Pool es almacenar declaraciones en su forma analizada, lista
para su ejecución. La primera vez que la instrucción es emitida, esta será
analizada antes de su ejecución. La segunda vez, esta puede ser ejecutada
inmediatamente. En una aplicación bien diseñada, es posible que las
declaraciones se puedan analizar de una vez ejecutada millones de veces. Esto
ahorra una gran cantidad de tiempo
DATA DICTIONARY CACHE.
El Data Dictionary Cache es algunas veces
se refiriere a el Row Cache. Sea cual sea el término que usted prefiera,
almacena las definiciones de objetos recientemente utilizados: descripciones de
tablas, índices, usuarios, y otras definiciones de metadatos. Manteniendo tales
definiciones en la memoria SGA, donde son inmediatamente accesibles a todas las
sesiones, en lugar que cada sesión tenga que leer varias veces el diccionario
de datos desde el disco, mejora el rendimiento del análisis.
El Data Dictionary Cache almacena
definiciones de objetos de modo que cuando las instrucciones tienen que ser
analizadas, pueden ser analizadas rápidamente – sin tener que consultar el
diccionario de datos. Considere que ocurre si estas sentencias son emitidas
consecutivamente:
select sum(salary) from employees;.
select * from employees where
last_name='KING';.
Ambas declaraciones deben ser analizadas
porque son declaraciones diferentes-pero analizar la primera instrucción SELECT
habrá cargado la definición de la tabla Employees y de sus columnas en el Data
Dictionary Cache, para analizar la segunda instrucción será más rápido de lo
que debiera haber sido, porque no será necesario acceder al Diccionario de
Datos.
EN EL TRABAJO.
La afinación de Shared Pool es por lo
general orientados hacia asegurar que El Library Cache es del tamaño correcto.
Esto es porque los Algoritmos de Oracle para asignar memoria en la SGA utilizan
algoritmos diseñados a favor del Dictionary Cache, Así que si Library Cache es
correcto, entonces el Dictionary Cache ya será correcto.
PL/SQL AREA.
Los objetos almacenados de PL/SQL son
Procedimientos, Funciones, paquetes de procedimientos y funciones, definiciones
de tipos de objetos, y Triggers. Todos estos son almacenados en el Diccionario
de Datos, como el código fuente y también en su forma compilada. Cuando un
objeto PL/SQL almacenado es invocado por una sesión, este debe ser leído del
Diccionario de Datos, para prevenir repetir la lectura, los objetos son
entonces guardados (Cached) en el PL/SQL Area de la Shared Pool.
La primera vez que un objeto PL/SQL es
utilizado, este debe ser leído desde las tablas del Diccionario de Datos en
disco, pero las invocaciones subsecuentes serán mucho más rápido, porque el
objeto estará disponible en el PL/SQL Area de la Shared Pool.
EN EL TRABAJO.
PL/SQL pueden ser emitidos desde procesos
de usuario, en lugar de ser almacenados en el Diccionario de Datos. Estos son
llamados PL/SQL anónimos. PL/SQL anónimos no pueden ser guardados (Cached) y
ser reutilizados, pero debe compilarlo dinámicamente. Por lo tanto, siempre se
comportará peor que almacenado PL/SQL. Desarrolladores deberían se alentados a
convertir todos los PL/SQL anónimos a PL/SQL Almacenados.
SQL QUERY Y PL/SQL FUNCTION RESULT CACHE.
El Result Cache es una nueva
característica en la versión 11g. En muchas aplicaciones, la misma consulta es
ejecutada muchas veces, ya sea por la misma sesión o muchas sesiones
diferentes. Creando un Result Cache permite al Servidor Oracle almacenar los
resultados de tales querys en memoria. La siguiente vez que la consulta es
emitida, en lugar de ejecutar la consulta el servidor puede recuperar los
resultados guardados en el cache (Cached). El mecanismo de Result Cache es los
suficientemente inteligente para rastrear si las tablas contra la que la
consulta fue ejecutada han sido actualizadas. Si esto ha sucedido, el resultado
de la consulta serán invalidados y la siguiente vez la consulta emitida, esta
será ejecutada nuevamente. Por lo tanto, no hay peligro de alguna vez recibir
un Result Cache fuera de fecha.
El PL/SQL Result Cache utiliza un
mecanismo similar, cuando una función PL/SQL es ejecutada. Este valor retornado
puede ser almacenado preparado para la siguiente vez que la función es
ejecutada. Si los parámetros pasados a la función, o las tablas que la función
consulta, son diferentes, la función será recalculada, pero por lo contrario,
El valor almacenado será el retornado.
Por default, el SQL Query y el PL/SQL
Function Result Cache esta deshabilitado, pero si habilita este
programáticamente, usted puede obtener mejoras drásticas en el rendimiento. El
cache esta dentro del Shared Pool: a diferencia de as otras áreas de memoria
descritas previamente, esto permite hacer al DBA algún control; él puede
especificar el tamaño máximo.
TAMAÑO DEL SHARED POOL.
El tamaño del Shared Pool es crítico para
el rendimiento. Este debe ser suficientemente grande para almacenar (cache)
todo el código ejecutado frecuentemente y definiciones de objetos
frecuentemente necesarias (en el Library Cache y el Data Dictionary Cache) pero
no tan grande que almacene instrucciones que solo sean ejecutadas solamente una
vez. Un tamaño menor del Shared Pool deteriora el rendimiento porque las
sesiones de servidor tienen que tomar repetidas ocasiones el espacio para
analizar sus instrucciones, que luego son sobrescritas por otras instrucciones
y por lo tanto tiene que ser analizadas nuevamente cuando son re ejecutadas. Un
Shared Pool de gran tamaño puede impactar negativamente sobre el rendimiento ya
que necesita demasiado tiempo para buscar. Si el Shared Pool es menor que el
tamaño optimo, el rendimiento se degradará. Pero hay un tamaño mínimo debajo
del cual las declaraciones fallarán.
La memoria en el Shared Pool es asignada
acorde al Algoritmo LRU(Lo menos Recientemente Utilizado – Least Recently
Used). Cuando el Servidor Oracle necesita espacio en el Shared Pool, este
sobrescribirá los objetos que no han sido utilizados por largo tiempo. Si el
objeto es mas tarde necesario nuevamente. Este tiene que ser recargado –
posiblemente sobrescribiendo otro objeto.
El Shared Pool es asignado en el momento
de inicio de la instancia. Anteriores versiones a 9i de la Base de Datos no era
posible cambiar el tamaño del Shared Pool sin reiniciar la Instancia de Base de
Datos. Pero desde la 9i en adelante puede ser cambiada de tamaño arriba o abajo
en cualquier momento. Este cambio de tamaño puede ser manual(desde la versión
10g en adelante) o automático en función de la carga de trabajo, si el
mecanismo ha sido habilitado.
EXAMEN.
El Tamaño del Shared Pool es dinámico y
puede ser administrado automáticamente.
EN EL TRABAJO.
Determinar el tamaño óptimo es un asunto
de ajuste de rendimiento, pero es probablemente seguro decir que la mayoría de
Bases de Datos necesitarán un Shared Pool de varios cientos de megabytes.
Algunas aplicaciones necesitarán una o más que un gigabytes, y muy pocos se
desempeñaran adecuadamente con menos que un ciento de megabytes.
EL LARGE POOL.
El Large Pool es un área opcional, será
utilizado automáticamente por varios procesos que de otra manera tomarían del
Shared Pool. Uno de los usos principales del Large Pool es por Procesos Shared
Server (Servidor compartido), que se describe en el capítulo 6 en la discusión
del Shared Server (Servidor Compartido) Servidores de ejecución Paralela
también utilizan el Large Pool, si hay uno. En la ausencia de un Large Pool,
estos procesos usaran memoria en la Shared Pool. Esto puede causan mala
contención para el Shared Pool. Si Shared Server (Servidor Compartido) o
Servidores paralelos se están utilizando, un Large Pool debería siempre ser
creado. Algunos procesos I/O pueden también hacer uso del Large Pool, tales
como el Procesos utilizado por el Recovery Manager cuando está realizando un
respaldo a un dispositivo de cinta.
El tamaño del Large Pool no es asunto de
rendimiento. Si un proceso necesita memoria del Large Pool, fallará con un
error si esa memoria no está disponible. Asignando más memoria que sea necesaria
no hará las instrucciones más rápidas, además, si existe una Large Pool, esta
será utilizado: no es posible para una declaración iniciar usando la Large
Pool, y luego volver a la Shared Pool si la Large Pool es demasiado pequeña.
Desde 9i release 2 en adelante es posible
crear y cambiar el tamaño al Large Pool después de iniciar la instancia, con
versiones anteriores, tenía que ser definido en el inicio y era de tamaño fijo.
Desde la versión 10g en adelante, la creación y el tamaño del Large Pool puede
ser completamente automático.
EXAMEN.
El Tamaño del Large Pool es dinámico y
puede ser gestionado automáticamente.
JAVA POOL.
El Java Pool solo es requerido si su
aplicación va a ejecutar Store-Procedures Java en la Base de Datos: es
utilizado por el espacio Heap para instanciar los objetos Java. Sin embargo,
una serie de opciones Oracle son escritas e Java, lo que la Java Pool es
considerada standard en la actualidad. Tenga en cuenta que código Java no es
almacenado (cache) en el Java Pool. Es almacenado en el Shared Pool, en la
misma manera que el código PL/SQL está depositado.
El tamaño óptimo de la Java Pool depende
de la Aplicación Java, y cuantas sesiones están ejecutándose. Cada sesión
requiere espacio en el Heap para sus objetos. Si el Java Pool es de tamaño
inferior, el rendimiento puede degradarse debido a la necesidad de reclamar
continuamente el espacio. En una aplicación EJB(Enterprise JavaBean), un objeto
tal como un bean de sesión sin estado puede ser instanciado y utilizado, y
entonces permanecerá en la memoria en caso de que se vuelva a usar: Como un
objeto puede ser reutilizado inmediatamente. Pero si el Servidor Oracle ha
tenido que destruir el Bean para espacio para otro, entonces tendrá que ser
reinstanciado la próxima vez que sea necesario. Si el Java Pool es crónicamente
inferior de tamaño, entonces las aplicaciones pueden fallar.
Desde 10g en adelante es posible crear y
cambiar de tamaño el Large Pool después de iniciar la instancia; esta creación
y tamaño del Large Pool pueden ser completamente automáticos. Con versiones
anteriores, tenía que ser definido en el inicio y era de tamaño fijo.
EXAMEN.
El tamaño de Java Pool es dinámico y puede
ser gestionado automáticamente.
EL STREAM POOL.
El Streams Pool es utilizado por el Oracle
Streams. Esta es una herramienta avanzado que esta mas allá del alcance del
Examen OCP o este libro. El mecanismo utilizado por Streams es extraer Change
Vectors desde el Redo Log de desde este reconstruir las declaraciones que
fueron ejecutadas-o declaraciones que tendrían el mismo efecto. Estas
declaraciones son ejecutadas en la Base de Datos Remota. Los procesos que
extraen Changes Vectors desde el Redo Log y los procesos que aplican los
Changes Vectors necesitan memoria: Esta memoria es el Streams Pool. Desde la
base de datos 10g es posible crear y cambiar de tamaño el Streams Pool después
de iniciar la Instancia; esta creación y tamaño pueden ser completamente
automáticos. Con versiones anteriores se había que definir en el inicio y era
de tamaño fijo.
EXAMEN.
El tamaño del Streams Pool es dinámico y
puede ser gestionado automáticamente.
EJERCICIO 2-2.
Investigar las Estructuras de Memoria de
la Instancia.
En este ejercicio, usted ejecutara
consultas para determinar eñ tamaño actual de varias estructuras de memoria que
constituyen la instancia.
1.Conéctese a la Base de Datos con el
usuario SYSTEM.
2.Muestre tamaños máximos y mínimos de los
componentes de la SGA que pueden ser cambiados de tamaño dinámicamente.
select
COMPONENT,CURRENT_SIZE,MIN_SIZE,MAX_SIZE from v$sga_dynamic_components;
La ilustración muestra el resultado sobre
una Base de Datos de ejemplo.
El ejemplo muestra una Instancia sin
Streams, por lo tanto un Streams Pool de tamaño cero. Ni la Large Pool ni la
Java Pool ha cambiado desde el inicio desde la instancia. Pero ha habido
cambios hechos a el tamaño del Shared Pool y el Database Buffer Cache. Solo el
Dafault Pool del Database Buffer Cache ha sido configurado, esto es usual,
excepto en bases de datos muy ajustadas.
3.Determinar la cantidad de memoria,
actual y asignada a la Program Global Area.
select name,value from v$pgastat where
name in ('maximum PGA allocated','total PGA allocated');
Excelente aritculo introductorio a las estrucutras de memoria de una instancia oracle
ResponderEliminarde donde viene los streams poll
ResponderEliminar