Oracle 12 2017 Parte2

Mdulo 1
Arquitectura de Oracle 12c
Oracle Database 12c: Administrator Certified Associate

Tabla de contenidos
Concepto de Instancia Oracle

Concepto de Instancia Oracle ................................................................................. 1-1
Estructuras de memoria ......................................................................................... 1-2
System Global Area (SGA) .................................................................................. 1-3
Program Global Area (PGA).............................................................................. 1-12
User Global Area (UGA) ................................................................................... 1-15
reas de cdigo software ................................................................................ 1-15
Administracin de la memoria ......................................................................... 1-16
Estructuras de procesos........................................................................................ 1-22
Procesos de usuario ......................................................................................... 1-23
Procesos Oracle ................................................................................................ 1-24
Procesos servidores..................................................................................... 1-24
Procesos background .................................................................................. 1-26
1

Concepto de Instancia Oracle 1-1

Un servidor Oracle es un sistema gestor de base de datos que proporciona un acercamiento
abierto, comprensivo, integrado a la gestin de la informacin. La arquitectura de un
servidor Oracle se divide en dos partes fundamentales: la instancia y la base de datos
propiamente dicha.
Cuando una base de datos arranca sobre un servidor de base de datos, Oracle reserva un
rea de memoria denominada SGA (System Global Area) y arranca uno o varios procesos
Oracle de respaldo (background). Se puede definir por tanto una instancia Oracle como el
conjunto formado por las estructuras de memoria principal y por los procesos Oracle. Este
mecanismo gestiona los datos de la base de datos asociada y da servicio a los usuarios.
Es posible configurar un servidor Oracle de una de las siguientes formas, mutuamente

excluyentes:
Instancia nica: existe una relacin uno a uno entre la base de datos y la instancia.
Oracle RAC (Real Application Clusters): relacin uno a varios entre la base de datos y
la instancia.
Independientemente de si la configuracin es con una instancia o con varias, una instancia

de base de datos est asociada con una nica base de datos en un momento dado. No es
posible montar dos bases de datos simultneamente sobre la misma instancia, aunque una
base de datos puede estar asociada a una o varias instancias simultneamente (Oracle RAC).
1-2 Concepto de Instancia Oracle
Estructuras de memoria
Oracle utiliza la memoria para almacenar la siguiente informacin:
Cdigo de programa.
Informacin sobre las sesiones conectadas aunque no estn activas.
Informacin necesaria durante la ejecucin de un programa.
Informacin compartida entre los procesos Oracle, por ejemplo la informacin sobre
bloqueos.
Datos cargados en memoria como los bloques de datos y las entradas de redo log.
Las estructuras de memoria bsicas asociadas con Oracle son las siguientes:
System Global Area (SGA): est formada por un conjunto de estructuras de memoria
que contienen datos e informacin de control de la instancia. La SGA es compartida
por todos los procesos servidores y por los procesos de respaldo (backgroud).
Program Global Area (PGA): es un rea de memoria no compartida que contiene
datos e informacin de control exclusivamente de un proceso Oracle. La PGA se crea
cuando el proceso Oracle arranca. Existe una PGA por cada proceso servidor y por
cada proceso de respaldo (background).
User Global Area (UGA): esta memoria est asociada a cada sesin del usuario.
reas de cdigo software: son porciones de memoria utilizadas para almacenar
cdigo que se est ejecutando o que puede ejecutarse. El cdigo de Oracle se
almacena en un rea de software que generalmente se encuentra en una ubicacin
diferente de aquella en la que se encuentran los programas de usuario.
System Global Area (SGA)

La SGA (System Global Area) es un grupo de estructuras de memoria compartida que
contienen datos e informacin de control para una instancia de base de datos Oracle. Si hay
mltiples usuarios conectados de forma concurrente a la misma instancia, los datos de la
SGA de la instancia sern compartidos entre todos los usuarios. Debido a esto, suele ser
denominada tambin Shared Global Area.
Durante el arranque de la instancia, Oracle reserva automticamente memoria para la SGA y
durante la parada de la instancia, el sistema operativo reclama la memoria y Oracle la libera.
Cada instancia de base de datos tiene su propia SGA.
La SGA es una estructura de lectura/escritura que permite que los procesos de los usuarios
conectados a la base de datos puedan leer informacin de ella y que varios procesos puedan
escribir en la SGA durante la ejecucin de Oracle.
Las estructuras de datos contenidas en la SGA son las siguientes:
Database Buffer Cache
Redo Log Buffer
Shared Pool Area
Java Pool
Large Pool
Streams Pool
Una parte de la SGA contiene informacin general sobre el estado de la base de datos y de la
instancia, tal como los procesos background que han de utilizarse. Este parte se denomina
Fixed SGA. En esta rea no hay datos de usuario almacenados. Adicionalmente, la SGA
mantiene informacin relativa a la comunicacin entre procesos tal como informacin sobre
bloqueos.
Si el sistema utiliza arquitectura de procesos servidores compartidos (Shared Servers), las

colas de peticiones y respuestas, as como parte de la informacin de la PGA, estar dentro
de la SGA.
Nocin de Grnulo
La SGA est compuesta de toda una serie de componentes, espacios de memoria para
satisfacer peticiones concretas de reserva de memoria. Todos los componentes de la SGA
reservan y liberan espacio de memoria en unas unidades denominadas grnulos. Oracle
contabiliza el uso de memoria de cada componente en grnulos.
Un grnulo es una cantidad de memoria que puede ser asignada a una estructura de la SGA.
El tamao de grnulo est determinado por el tamao total de la SGA:
4 Mb si el tamao total de la SGA es inferior o igual a 1Gb.
8 Mb (plataforma Microsoft Windows) o 16 Mb (otras plataformas) si el tamao de la
SGA es superior a 1Gb.
La asignacin de memoria a las estructuras de la SGA se efecta en nmero entero de
grnulos (con un redondeo automtico al grnulo superior si el valor de un parmetro no es
mltiplo del tamao del grnulo. En cualquier caso, hay bastantes diferencias entre distintas
plataformas.
La vista V$SGAINFO permite conocer el tamao de grnulo que est siendo utilizado
actualmente. El tamao de cada componente y la fecha y tipo de operacin de
redimensionamiento realizada puede ser consultada en el diccionario mediante la vista
V$SGA_DYNAMIC_COMPONENTS. La base de datos mantiene un buffer circular con las
ltimas 400 operaciones de redimensionamiento de la SGA. Se puede visualizar este buffer a
travs de la vista dinmica V$SGA_RESIZE_OPS.
Oracle puede establecer lmites sobre cuanta memoria va a utilizar la base de datos para la
SGA. Esto permite que la instancia arranque con un mnimo de memoria y usar ms hasta
alcanzar el valor del parmetro SGA_MAX_SIZE. Si la suma total de los valores de reserva de
memoria de todos los parmetros afectados en tiempo de arranque de la instancia, es
superior al valor de SGA_MAX_SIZE, ste ltimo ser ignorado.
Database Buffer Cache

El buffer cache de datos es la parte de la SGA que almacena copias de los bloques de datos
ledos desde los ficheros (datafiles). Todos los procesos de usuario conectados de forma
concurrente a la instancia, comparten el acceso a esta estructura.
Oracle distingue entre 3 tipos de bloques:
Libres o free blocks. Son los bloques de la Database Buffer Cache que an no han sido
utilizados para albergar datos ledos de los datafiles.
Pegados o pinned blocks. Son los bloques que estn siendo usados en ese preciso
instante.
Sucios o dirty blocks. Son los bloques que estn en la buffer cache y que han sido
modificados o borrados por algn usuario pero que todava no se han almacenado en
el disco.
Tanto el Database Buffer Cache como la Shared Sql Area estn segmentadas de forma lgica
en mltiples partes con la finalidad de reducir la contencin en los entornos
multiprocesador.
Los buffers dentro de la cach estn organizados en dos listas:
Write List: almacena los bloques modificados (dirty blocks) que an no han sido
sincronizados a disco.
LRU (Least Recently Used) List: registra todos los bloques de datos clasificndolos en
calientes/hot buffer (accedidos recientemente) y fros/cold buffers (no utilizados
recientemente). Se utiliza este algoritmo para garantizar que el acceso a los bloques
es eficiente.
Conceptualmente, existe una sola lista LRU pero, por razones de concurrencia, la
instancia de base de datos utiliza varias.
Cuando un proceso Oracle necesita recuperar un dato lo busca en el Database Buffer Cache.
Si el proceso encuentra el dato en la cach (cache hit) este puede ser ledo directamente
desde la memoria y si no lo encuentra (cache miss), el bloque de datos que contiene la
informacin ha de ser copiado desde el disco a un buffer libre en la cach antes de ser
recuperado.
Antes de colocar un bloque de datos en la cache, el proceso Oracle ha de buscar un bloque
libre en la lista LRU. Si durante la bsqueda encuentra un dirty block en esta lista, lo mueve a
la Write List y contina buscando. Cuando el proceso encuentra un bloque libre, lee los datos
desde el disco colocndolos en el buffer y registra el bloque en la lista LRU, en concreto en la
zona MRU (Most Recently Used).
Si un proceso Oracle no encuentra un bloque libre, enva una seal al proceso background
DBW0 para que escriba los bloques modificados (dirty) a disco.
Tamao del Database Buffer Cache

Oracle soporta mltiples tamaos de bloque en la base de datos. El tamao de bloque
estndar se especifica a travs del parmetro DB_BLOCK_SIZE. Los valores admitidos van de
2k a 32k. El tablespace SYSTEM utiliza como tamao de bloque el estndar.
El tamao de la zona de memoria del Database Buffer Cache que gestiona bloques de
tamao estndar viene dado por el parmetro DB_CACHE_SIZE.
La implementacin de otras zonas dentro de este cach de datos para procesar tamaos de
bloque no estndar se realiza configurando los parmetros:
DB_2K_CACHE_SIZE
DB_4K_CACHE_SIZE
DB_8K_CACHE_SIZE
DB_16K_CACHE_SIZE
DB_32K_CACHE_SIZE
El tamao de la Database Buffer Cache es crtico para las prestaciones de la base de datos.
Debe ser de suficientemente grande como para albergar todos los bloques de datos
utilizados frecuentemente.
Una cach pequea supone una actividad de disco excesiva porque se llena rpidamente y el
proceso DBWn se ve forzado a guardar los dirty blocks en los ficheros de datos.
Mltiples Buffer Pools

Se puede configurar el Database Buffer Cache en distintos pools independientes, de forma
que mantengan o liberen los datos ms rpidamente que el funcionamiento habitual de la
cach. De esta forma, objetos concretos de un esquema pueden ser asignados al espacio
apropiado para controlar el tiempo de vida de sus bloques en la cache.
Los distintos espacios (pools) en memoria son:
DEFAULT Buffer Pool: Contiene los bloques de datos de los objetos de esquema que
no han sido asignados de forma especfica a ningn otro pool, as como aquellos
asignados directamente a este espacio. Es el nico pool que est disponible por
defecto y adems es obligatorio.
KEEP Buffer Pool: Est pensado para almacenar los bloques a los que se accede con
mayor frecuencia. El objetivo de este pool es retener los objetos de un esquema en
memoria y evitar contencin en E/S.
RECYCLE Buffer Pool: Est pensado para los bloques que apenas se usan y su objetivo
es evitar el consumo innecesario de espacio en la cach. Elimina los bloques de
memoria en el momento en que no son necesarios y se reclama espacio disponible.
Los parmetros de inicializacin necesarios para
configurar los buffer pool KEEP y RECYCLE son:
DB_KEEP_CACHE_SIZE
DB_RECYCLE_CACHE_SIZE
El parmetro DB_CACHE_SIZE especifica el tamao de

la cach para el Default Buffer Pool.
El uso de mltiples pools est limitado a que sus
bloques deben tener el tamao del bloque estndar
de la base de datos (parmetro de inicializacin
DB_BLOCK_SIZE).
Redo Log Buffer

Es un buffer circular que almacena informacin sobre los cambios realizados en la base de
datos. La informacin se almacena en las llamadas Entradas de Redo (Redo Entries). Estas
entradas contienen la informacin necesaria para reconstruir o rehacer aquellos cambios
realizados en la base de datos a travs de sentencias DML (INSERT, UPDATE o DELETE) y DDL
(CREATE, ALTER o DROP). Las entradas de este buffer permiten garantizar el recovery de la
base de datos.
Las Entradas de Redo son copiadas por los procesos servidores de Oracle desde el espacio de
memoria del usuario al Redo Log Buffer en la SGA. Estas entradas usan de forma continua y
secuencialmente el espacio del buffer.
El proceso background LGWR escribe las entradas de este buffer en disco en el fichero (o
grupo de ficheros) de Redo Log Online activo.
El parmetro de inicializacin LOG_BUFFER determina el tamao (en bytes) del Redo Log
Buffer. En general, valores altos reducen la contencin de E/S al fichero de Redo Log,
especialmente si las transacciones son largas o numerosas.
Shared Pool Area

Esta zona de memoria cachea distintos tipos de informacin. Contiene los siguientes
componentes: Library Cache, Dictionary Cache, Result Cache, buffers para mensajes de
ejecucin en paralelo y estructuras de control.
El tamao total de esta estructura de memoria est determinado por el parmetro de
inicializacin SHARED_POOL_SIZE. El valor por defecto de este parmetro es 8MB en
plataformas de 32 bits y 64MB en plataformas de 64 bits.
Library Cache
Es una zona de memoria compartida que incluye: reas compartidas de SQL (Shared SQL
Area), reas privadas de SQL (Private SQL Area) en el caso de configuracin de procesos
servidores compartidos, reas compartidas de PL/SQL (Shared PL/SQL Area) que almacenan
procedimientos y paquetes PL/SQL, y estructuras de control tales como latches. Administra
los datos mediante algoritmo LRU.
Cada sentencia SQL se ejecuta utilizando las reas SQL tanto compartida como privada. De
esta forma, cuando dos usuarios ejecutan la misma sentencia SQL, Oracle usa la misma zona
compartida para los dos usuarios. Sin embargo, cada usuario ha de tener una copia separada
de la sentencia en su rea privada SQL.
Cuando se ejecuta una sentencia SQL, Oracle intenta reutilizar el cdigo ejecutado con
anterioridad. Si existe la sentencia analizada (parseada) y almacenada en la Library Cache y
puede compartirse, Oracle reutiliza el cdigo.
La Library Cache dispone de zonas
Shared SQL Area: Un rea compartida SQL que contiene el anlisis (parse) y el plan de
ejecucin de cada sentencia SQL. De esta forma puede compartirse entre varios
usuarios accediendo al mismo cdigo. Oracle reserva memoria de la Shared Pool
cuando una nueva sentencia SQL es analizada para poder almacenarla en esta rea. El
tamao de esta rea depender de la complejidad de la sentencia.
Shared PL/SQL Area: El cdigo PL/SQL (procedimientos, funciones, paquetes y
triggers) son tratados al igual que las sentencias SQL. Oracle reserva un rea
compartida para analizar y compilar este cdigo. Adicionalmente se reserva un rea
privada para mantener valores especficos para la sesin que est ejecutando un
programa, incluyendo variables locales, globales y de paquete (instanciacin de
paquete) y buffers para ejecutar SQL. Si ms de usuario ejecuta la misma unidad de
programa lo har desde un rea compartida aunque mantenga su copia privada en su
rea privada SQL.
Todas las unidades de programa son almacenadas en el diccionario de datos, tanto el

cdigo como la compilacin). Cuando se invoca un objeto PL/SQL, se lee del
diccionario y se carga en esta zona de memoria, de forma que si otra sesin lo
necesita ya est en cach. Esto no ocurre con los bloques annimos.
Data Dictionary Cache

El diccionario de datos es una coleccin de tablas y vistas de la base de datos conteniendo
informacin de referencia sobre la base de datos, sus estructuras y sus usuarios.
Los accesos al diccionario de datos son frecuentes cada vez que se analiza (parse) una
sentencia SQL. De hecho, se accede tan a menudo que hay dos localizaciones especficas en
memoria designadas para almacenar datos del diccionario. Un rea se denomina Data
Dictionary Cache, tambin conocida como Row Cache ya que almacena los datos como filas
en lugar de usar buffers (que almacenan bloques completos de datos).
La otra zona de memoria en la que se almacenan datos del diccionario es en la propia
Library Cache. Todos los procesos Oracle comparten ambas caches para acceder a la
informacin del diccionario de datos.
Result Cache
En Oracle11g se introdujo una caracterstica bastante innovadora denominada Result Cache,
la cual permite crear una porcin de memoria destinada a guardar aquellos datos que son
ms o menos estticos dentro de Oracle.
Esto permite consultar el valor final de un dato sin necesidad de acceder varias veces a disco,
ni pasar nuevamente por clculos o por grandes planes de ejecucin para resolver una
sentencia SQL.
Por ejemplo al lanzar una consulta mediante la sentencia SELECT COUNT(*) sobre una tabla
muy grande, se demorara varios minutos. Pues bien, al realizar esta consulta de nuevo,
como el resultado est almacenado en memoria se encuentra listo para ser reutilizado. Por
tanto la segunda consulta es rapidsima.
Se puede configurar de forma automtica (FORCE) o manual (MANUAL) mediante el
parmetro de inicializacin RESULT_CACHE_MODE.
A diferencia de los que ocurre con los otros pools, la cach de resultados (Result Cache)
mantiene los resultados y no los bloques de datos. Existen varias posibilidades de utilizacin
Query Result Cache y PL/SQL Function Result Cache.
Reserved Pool
El pool reservado (Reserved Pool) es una zona de memoria en Shared Pool Area que Oracle
puede utilizar para asignar grandes bloques contiguos de memoria.
La asignacin de memoria desde la Shared Pool Area se efecta en trozos o chunks. Esta
fragmentacin permite que objetos de gran tamao (ms de 5 Kb) se carguen en la cach sin
necesidad de solicitar una nica zona de memoria contigua. De esta manera, la base de
datos reduce la posibilidad de quedarse sin memoria contigua debido a la fragmentacin.
Es poco frecuente que Java, PL/SQL o cursores SQL puedan realizar asignaciones fuera de la
Shared Pool Area que sean mayores de 5 Kb. Para permitir que estas asignaciones se realicen
de manera ms eficiente, Oracle reserva una pequea cantidad de la Shared Pool para esta
funcionalidad.
Mediante el parmetro de inicializacin SHARED_POOL_RESERVED_SIZE se puede
configurar el tamao de este pool.
Large Pool
Opcionalmente se puede configurar dentro de la SGA un rea de memoria denominada
Large Pool. Esta zona soporta asignaciones de espacios de memoria adicionales para:
Memoria de sesin (UGA) para procesos servidores compartidos y Oracle XA
interface (utilizado cuando las transacciones interactan con ms de una base de
datos).
Buffers de mensajes utilizados en la ejecucin en paralelo de las sentencias.
E/S de procesos servidores.
Buffer para las operaciones de backup y restore de RMAN.
El uso de esta rea de memoria evita la contencin en la Shared Pool.
Este espacio es diferente del resto del espacio utilizado en la Shared Pool Area porque no
utiliza el algoritmo LRU. Los espacios de memoria se reservan y no se liberan hasta que no se
hayan terminado de utilizar. Tan pronto como se liberan hay otro proceso que las puede
utilizar.
El parmetro de inicializacin LARGE_POOL_SIZE (en bytes) permite dimensionar el espacio
de memoria dedicado a esta zona.
Java Pool
Es una zona de memoria utilizada por las sesiones especficas de cdigo Java y solo se
necesita si hay aplicaciones que ejecuten funciones Java (clases) almacenadas en la base de
datos. Acta de forma diferente dependiendo del modo en que est configurado el servidor
(dedicado o compartido).
Las estadsticas que recolecta el Java Pool Advisor proporcionan informacin sobre el uso de
memoria de la Library Cache por parte de Java y permite establecer cmo podran afectar a
la tasa de anlisis (parse) los cambios en el tamao del Pool de Java. Este asesor se activa
automticamente cuando se establece el parmetro STATISTICS_LEVEL a TYPICAL o ALL.
El parmetro de inicializacin JAVA_POOL_SIZE (en bytes) permite dimensionar el espacio
de memoria dedicado a este pool.
Streams Pool
Esta memoria es usada exclusivamente por los flujos (streams) de Oracle. Almacena colas de
mensajes y proporciona memoria a Oracle Streams para capturar y aplicar procesos. A
menos que se configure especficamente, el tamao de esta memoria est configurado a 0.
El tamao de la Streams Pool crece dinmicamente como sea necesario cuando los flujos de
Oracle son usados.
El tamao del Streams Pool est controlado por el parmetro STREAMS_POOL_SIZE.
Program Global Area (PGA)

El rea global de programa PGA (Program Global Area) es una regin de memoria que
contiene datos e informacin de control para un proceso servidor que se comparte con otros
procesos o hilos del sistema. Es un rea de memoria privada generada cuando el proceso
servidor arranca. El acceso es exclusivo para el proceso servidor y la informacin contenida
en ella es leda y escrita por el cdigo Oracle.
El total de memoria PGA reservada para todos los procesos servidores de una base de datos
Oracle suele ser denominada PGA agregada (Aggregated PGA) o PGA de la instancia
(Instance PGA).
El contenido de la PGA es variable dependiendo de si la instancia est funcionando con

procesos servidores compartidos o no. En una configuracin de servidor compartido, una
parte de la PGA est almacenada en la SGA, por defecto en Shared Pool o en Large Pool si se
encuentra definida. Pero de forma general, sus reas pueden clasificarse en:
rea SQL privada

El rea SQL Privada (Private SQL Area) contiene informacin acerca de las sentencias SQL
analizadas (parseadas). Cada sesin que ejecuta una sentencia SQL tiene su rea SQL privada
para guardar las variables asociadas, el estado de la ejecucin de la sentencia y la
informacin especfica de la sesin. Cada usuario que lanza la misma sentencia tiene su
propia rea SQL privada usando una nica rea SQL compartida. Por lo tanto muchas reas
SQL privadas pueden estar asociadas con la misma rea SQL compartida.
Un cursor es un manejador de un rea de SQL privado especfico. Como se muestra en la
siguiente figura, se puede pensar en un cursor como puntero en el proceso de usuario y
como un estado en el proceso servidor. Debido a que los cursores estn estrechamente
relacionados con las reas de SQL privadas, los trminos se utilizan a veces indistintamente.
El rea de SQL privado de un cursor est dividido, a su vez, en dos reas con diferentes
tiempos de vida:
rea persistente (Persistent Area) conteniendo, por ejemplo, informacin de las bind
variables. Solo se libera cuando se cierra el cursor.
rea de ejecucin (Run-time Area), que contiene informacin de estado sobre la
ejecucin de la sentencia y que se libera cuando la ejecucin ha terminado.
Oracle crea el rea Run-time como primer paso en la peticin de una ejecucin. Para las
sentencias INSERT, UPDATE y DELETE, Oracle libera el rea Run-time una vez que la
sentencia ha finalizado. Para las consultas, Oracle libera el rea Run-time una vez han sido
devueltas todas las filas o la consulta ha sido cancelada.
La distribucin de las reas privadas depende del tipo de conexin establecida en una sesin.
Si la sesin se conecta a travs de un proceso servidor dedicado, el rea SQL privada se
localizar en la PGA del proceso servidor. Sin embargo, si la sesin se conecta a travs de un
proceso servidor compartido, parte de su rea SQL privada se almacenar en la SGA.
Memoria de sesin
Memoria reservada por una sesin para almacenar sus variables (informacin de conexin) y
otra informacin relativa a la sesin. En caso de usar procesos servidores compartidos, la
memoria de sesin no ser privada.
reas de trabajo SQL

Las reas de trabajo SQL son zonas de memoria dentro de la PGA empleadas para
operaciones complejas que hacen uso intensivo de la memoria como las siguientes:
Operadores Sort (order by, group by, rollup ...).
Hash-Join.
Bitmap Merge.
Create Bitmap.
Si no hay memoria suficiente para realizar estas operaciones, sern almacenadas en disco en
los archivos tempfile del tablespace temporal con el coste correspondiente.
Se pueden gestionar las reas de trabajo SQL de forma global automticamente a travs del
parmetro PGA_AGGREGATE_TARGET. Si se establece, Oracle intenta asegurar que el total
de memoria PGA reservada en la base de datos para los procesos servidores nunca exceda
de este valor.
Tambin se pueden controlar individualmente de forma manual cada una de las reas de
trabajo SQL mediante los parmetros SORT_AREA_SIZE, HASH_AREA_SIZE,
BITMAP_MERGE_AREA_SIZE y CREATE_BITMAP_AREA_SIZE.
Al establecer el parmetro PGA_AGGREGATE_TARGET se ignoran los valores que puedan
tener los parmetros *_AREA_SIZE.
Para poder establecer la gestin automtica de PGA, el parmetro WORKAREA_SIZE_POLICY
debe tener el valor AUTO. Para deshabilitar la gestin automtica de PGA se le establecer el
valor MANUAL y Oracle tendr en cuenta los parmetros *_AREA_SIZE.
Existe un conjunto de vistas del diccionario de datos que proporcionan estadsticas sobre el
uso de la PGA. Muchas de estas estadsticas se habilitan cuando el parmetro
PGA_AGGREGATE_TARGET se configura. Estas vistas son:
V$SYSSTAT
V$SESSTAT
V$PGASTAT
V$SQL_WORKAREA
V$SQL_WORKAREA_ACTIVE
Las siguientes columnas de la vista del diccionario V$PROCESS muestran informacin de la
memoria PGA reservada y usada por un proceso Oracle: PGA_USED_MEM,
PGA_ALLOCATED_MEM y PGA_MAX_MEM.
User Global Area (UGA)

El rea global de usuario (UGA) es una zona de memoria de sesin, es decir, su objetivo es
almacenar variables relacionadas con la sesin de base de datos. Bsicamente se almacenar
el estado de la sesin.
La UGA debe estar disponible para la sesin de base de datos durante la vida de la sesin.
Por este motivo, no puede almacenarse en la PGA en una configuracin de servidor
compartido porque la PGA es especfica para cada proceso. En estos casos la UGA se guarda
en la SGA.
reas de cdigo software

Son zonas de memoria utilizadas para almacenar cdigo que est siendo utilizado o va a
utilizarse. El cdigo Oracle se almacena en un rea software que est en una localizacin
diferente de la que usan los programas de usuario.
Las reas software suelen ser estticas en tamao y slo varan en las diferentes versiones
de cdigo. El tamao requerido para estas reas es diferente en base al sistema operativo.
Administracin de la memoria
La gestin de La memoria implica el mantenimiento de los tamaos ptimos de las
estructuras de memoria de Oracle en funcin de los requisitos de la base de datos en cada
momento. Oracle gestiona la memoria basndose en los parmetros de inicializacin. Se
puede establecer el tamao de la memoria para los siguientes componentes:
Fixed SGA Area y otras zonas internas necesarias para la instancia Oracle.
Database Buffer Cache.
Buffer de Redo Log.
Shared Pool Area.
Java Pool.
Large Pool.
Streams Pool.
Buffers Cache Keep y Recycle.
Buffers Cache para los tamaos de bloque no estndar.
Gestin manual de la memoria compartida

En las anteriores versiones de Oracle (hasta Oracle9i), el administrador de la base de datos
tena que especificar manualmente los valores para los diferentes componentes de la SGA
(MSMM-Manual Shared Memory Management) usando para ello los parmetros de
inicializacin correspondientes tales como DB_CACHE_SIZE, SHARED_POOL_SIZE,
JAVA_POOL_SIZE, LARGE_POOL_SIZE y STREAMS_POOL_SIZE.
El valor por defecto de LOG_BUFFER es, probablemente, correcto. Un valor mayor podra
tener un impacto negativo en el rendimiento, y si se establece un valor menor, se ignorar.
Gestin automtica de la memoria compartida

En la versin 10g de Oracle se incluye una nueva caracterstica que permite la gestin
automtica de la memoria compartida ASMM (Automatic Shared Memory Management)
simplificando la gestin de las diferentes reas de la SGA.
Parmetro SGA_TARGET
Usando el parmetro de inicializacin SGA_TARGET se puede especificar la cantidad total de
memoria SGA disponible para la instancia. De esta forma, Oracle distribuir este espacio a
travs de sus componentes asegurndose de un uso efectivo de la misma.
Al establecer la gestin automtica de memoria, los tamaos de los diferentes componentes
de la SGA son flexibles y pueden adaptarse a las necesidades en base a la carga de trabajo de
cada momento. Oracle distribuye automticamente la memoria disponible a travs de los
componentes segn stos lo requieran (bajo demanda).
De los distintos componentes de la SGA algunos permiten la gestin automtica completa y
otros han de ser establecidos manualmente.
Si se especifica el parmetro SGA_TARGET, las siguientes zonas de memoria obtienen su

tamao de forma automtica:
DB_CACHE_SIZE
SHARED_POOL_SIZE
LARGE_POOL_SIZE
JAVA_POOL_SIZE
STREAMS_POOL_SIZE
Los parmetros de inicializacin de los componentes gestionados de forma automtica
generalmente deben tener valor 0. Si se establecen a valores distintos de 0, entonces estos
valores se utilizan como niveles mnimos para la gestin automtica. Se podra establecer los
valores mnimos si un componente de aplicacin necesita una cantidad mnima de memoria
para funcionar correctamente.
Sin embargo, hay toda una serie de componentes que no pueden ser ajustados
automticamente. Es necesario establecer manualmente un valor a los siguientes
componentes:
Buffer de Redo Log (controlado por el parmetro LOG_BUFFER).
Buffers KEEP y RECYCLE (controlados por los parmetros DB_KEEP_CACHE_SIZE y
DB_RECYCLE_CACHE_SIZE)
Buffers para los tamaos de bloque no estndar (controlados por los parmetros
DB_nK_CACHE_SIZE, n=[2,4,8,16,32]).
Fixed SGA y otras asignaciones internas.
La memoria establecida para los componentes ajustados manualmente ha de reducirse de la
cantidad total de memoria establecida a travs del parmetro de inicializacin SGA_TARGET.
Si la instancia est utilizando un fichero de parmetros servidor (SPFILE), Oracle recordar
los valores de los componentes ajustados automticamente a lo largo de las paradas de la
instancia. De esta forma, el sistema no tendr que reajustar la memoria en cada arranque
empezando a trabajar con la informacin de la ltima parada y a partir de ah evala la carga
de trabajo para continuar con el ajuste.
Gestin automtica de memoria (PGA y SGA)

Oracle introdujo cambios en las funciones de gestin automatizada de memoria en el
servidor Oracle11g. Oracle Automatic Memory Management puede en esta versin
administrar automticamente tanto la memoria SGA como la PGA.
Esta funcionalidad adicional se controla mediante el uso de los nuevos parmetros
MEMORY_TARGET y MEMORY_MAX_TARGET. Tambin se han realizado algunos cambios en
los asesores e incluido nuevas vistas en el diccionario de datos.
Parmetro MEMORY_TARGET
El parmetro MEMORY_TARGET es una combinacin de los parmetros de inicializacin
SGA_TARGET y PGA_AGGREGATE_TARGET, y representa la cantidad total de memoria que
Oracle ha de repartir entre las distintas estructuras de memoria (SGA y PGA).
Cuando se establece este parmetro (MEMORY_TARGET) se debe tener en cuenta la

configuracin actual de la memoria, indicada mediante los parmetros SGA_TARGET y
PGA_AGGREGATE_TARGET. En la mayora de los casos, se calcula la suma de los tamaos de
SGA y PGA, estableciendo MEMORY_TARGET a este valor. A continuacin, se deben
configurar a 0 los parmetros SGA_TARGET y PGA_AGGREGATE_TARGET.
Este parmetro es dinmico y se puede cambiar hasta alcanzar el valor establecido en
MEMORY_MAX_TARGET, que explicaremos a continuacin.
Parmetro MEMORY_MAX_TARGET
El parmetro MEMORY_MAX_TARGET permite establecer el valor lmite que se puede
utilizar para cambiar dinmicamente el valor de MEMORY_TARGET. As se puede ajustar la
cantidad total de memoria disponible para la base de datos como un todo, en cualquier
momento.
Estos dos parmetros no se pueden utilizar cuando se ha establecido el parmetro
LOCK_SGA a TRUE. Tampoco pueden ser utilizados conjuntamente con huge pages en Linux.
En algunas plataformas pueden ocurrir problemas cuando se establece la configuracin de
MEMORY_TARGET. Por ejemplo, en Linux se necesita tener asignado en /dev/shm (o su
equivalente) una cantidad de espacio ms grande que el valor que se desea establecer en el
parmetro MEMORY_TARGET. Si se no hace esto dar como resultado el siguiente mensaje
de error:
ORA-00845: MEMORY_TARGET not supported on this system
Relacin entre parmetros de configuracin de memoria

Nuevo asesor de memoria

Oracle aadi una nueva vista en la versin 11g, V$MEMORY_TARGET_ADVICE, que
proporciona recomendaciones sobre cmo establecer el parmetro MEMORY_TARGET.
En este ejemplo, vemos que el aumento de tamao de la memoria en nuestra base de datos
no tendr un impacto positivo. Este tamao se encuentra representado en la columna
MEMORY_SIZE y es de 820MB (la situacin actual queda identificada si el valor de
MEMORY_SIZE_FACTOR es 1). Si se incrementa en un 25 por ciento, el tamao pasara a
1025MB (MEMORY_SIZE_FACTOR de 1,25) y slo dar lugar a un mnimo aumento en el
rendimiento como lo demuestra la diferencia en la columna de ESTD_DB_TIME de 74 a 73.
Vistas del diccionario de datos
Otra vista de diccionario, V$MEMORY_DYNAMIC_COMPONENTS, proporciona una visin
global de los diversos componentes de la memoria de la base de datos y de cmo Oracle
gestiona automticamente sus tamaos.
Se puede monitorizar cmo Oracle lleva a cabo la gestin automtica de la memoria

mediante la consulta de la vista V$MEMORY_RESIZE_OPS. sta contiene la relacin de las
ltimas 800 solicitudes de cambio de tamao de SGA tramitadas por Oracle.
Gestin de memoria desde OEM Database Express

Oracle Enterprise Manager Database Express permite la monitorizacin y gestin de la
memoria. Desde la pgina principal de OEM, se accede a la opcin Configuracin de la parte
superior, y luego se selecciona Memoria.
Se puede monitorizar desde esta pgina la configuracin de nuestra instancia ya que
aparecen distintas mtricas de rendimiento.
Desde la pgina Gestin de Memoria se pueden configurar los parmetros de inicializacin,

accediendo a la opcin Configurar Memoria.
Estructuras de procesos
Todos los usuarios conectados a Oracle deben ejecutar dos mdulos de cdigo para acceder
a una instancia de base de datos:
La aplicacin o herramienta Oracle que permita lanzar sentencias SQL a una base de
datos.
El cdigo del servidor de base de datos Oracle para interpretar y procesar las
sentencias SQL.
Estos mdulos de cdigo se ejecutan a travs de procesos. Un proceso es un hilo de control
(mecanismo dentro de un sistema operativo que puede ejecutar una serie de tareas).
Habitualmente tiene su propia rea de memoria privada dentro de la que se ejecuta.
Cada proceso dentro de una instancia Oracle realiza una tarea concreta repartiendo la carga
de trabajo para permitir el uso de una instancia por parte de mltiples usuarios.
Los procesos en un sistema Oracle pueden clasificarse en dos grupos:
Procesos de usuario (user processes) que ejecutan el cdigo de la aplicacin o de la
herramienta Oracle.
Procesos Oracle (Oracle processes) que ejecutan el cdigo del servidor de base de
datos. En esta categora estn incluidos los procesos servidores (server processes) y
los procesos de respaldo en segundo plano (background processes).
La estructura de procesos vara de una configuracin Oracle a otra dependiendo del sistema
operativo y de las opciones de instalacin elegidas.
Procesos de usuario
Cuando un usuario ejecuta un programa de aplicacin o una herramienta Oracle, se genera
un proceso de usuario para atenderlo.
Los trminos conexin y sesin puede parecer similares pero hay algunas diferencias entre
ellos:
Una conexin es una va de comunicacin entre el proceso de usuario y la instancia
Oracle. Esta se establece utilizando mecanismos entre los procesos disponibles en el
servidor o a travs de software de red.
Una sesin es la conexin especfica de un usuario a una instancia Oracle a travs del
proceso servidor. El tiempo de vida de una sesin comprende desde el momento de
la conexin del usuario hasta que ste se desconecta.
Procesos Oracle
Los procesos Oracle son llamados por otros procesos para realizar funciones para dichos
procesos. Se pueden clasificar de la siguiente forma:
Procesos servidores
Oracle genera procesos servidores para gestionar las peticiones de los procesos de usuario
conectados a la instancia.
Los procesos servidores pueden realizar las siguientes tareas:
Analizar (parse) y ejecutar sentencias provenientes de la aplicacin o herramienta de
usuario.
Leer de los ficheros de datos los bloques de informacin necesarios para ser
almacenados en el buffer cach de la SGA si stos no estn en memoria.
Devolver los resultados de forma que la aplicacin pueda procesarlos.
Los procesos servidores pueden ser de dos tipos: dedicados (dedicated) y compartidos
(shared).
Procesos Servidores Dedicados
En esta configuracin se mantiene el ratio uno-a-uno entre el nmero de procesos de
usuario y el de procesos servidores. De esta forma si el proceso usuario est inactivo, el
proceso servidor tambin lo est.
Procesos Servidores Compartidos

Esta arquitectura elimina la necesidad de utilizar un proceso servidor dedicado para atender
a cada conexin. Un dispatcher direcciona las mltiples peticiones que le llegan desde los
procesos de usuario a un conjunto de procesos servidores compartidos. Cualquier proceso
que est ocioso dentro de ese conjunto recoge la peticin desde una cola comn de
peticiones y al finalizar su trabajo, devuelve el resultado a una cola de respuestas. De esta
forma, un nmero bajo de procesos servidores compartidos pueden realizar la misma
cantidad de trabajo que muchos procesos servidores dedicados.
Procesos background
Una instancia Oracle puede tener varios procesos de respaldo (background) pero no todos
son obligatorios, es decir no siempre van a estar todos presentes. La vista V$BGPROCESS
muestra informacin sobre ellos.
Los procesos background ms importantes de una instancia Oracle son los siguientes:
Database Writer Process (DBWn)
Log Writer Process (LGWR)
Checkpoint Process (CKPT)
System Monitor Process (SMON)
Process Monitor Process (PMON)
Manageability Monitor Process (MMON)
Recoverer Process (RECO)
Archiver Processes (ARCn)
Job Queue Processes (CJQ0 Y Jnnn)
Database Writer Process (DBWn)

Este proceso escribe el contenido de los buffers del Database Buffer Cache a los ficheros de
datos en disco. Un solo proceso Database Writer (DBW0) es adecuado para muchos
entornos. Sin embargo se pueden configurar procesos adicionales (DBW1-DBW9 y DBWa-
DBWj) para proporcionar un mejor rendimiento en la escritura si el sistema modifica datos
de forma intensiva. En entornos monoprocesador no es aconsejable establecer ms de un
proceso Database Writer.
Su labor consiste en escribir los buffers dirty (bloques modificados) a disco para actualizar los
datos y para que los procesos de usuario sean capaces de encontrar buffers libres para
poder cargar nuevos bloques desde disco a memoria.
El parmetro de inicializacin DB_WRITER_PROCESSES especifica el nmero de procesos
DBWn de la instancia. El nmero mximo es 20. Si no se especifica ningn valor, Oracle
establece el nmero de procesos en base al nmero de CPUs del sistema durante el
arranque de la instancia.
El proceso DBWn escribe buffers en disco en base a las siguientes condiciones:
Cuando un proceso servidor no puede encontrar buffers libres enva una seal al
proceso DBWn para que escriba en disco. El proceso realiza la escritura en disco de
forma asncrona mientras realiza otras tareas.
Cuando se produce un checkpoint. Esta operacin fija un punto de sincronizacin
indicando que la informacin de la base de datos est consistente. A partir de este
punto comenzara un proceso de recovery en caso de fallo del sistema.
Log Writer Process (LGWR)

Este proceso es responsable de la gestin del Redo Log Buffer escribiendo su contenido en
los ficheros de Redo Log Online.
El Redo Log Buffer es circular. Cuando el proceso LGWR escribe en disco, los procesos
servidores pueden copiar nuevas entradas sobre las antiguas entradas ya guardadas. Este
proceso realiza la operacin rpidamente para asegurar que exista espacio suficiente en el
buffer para las nuevas entradas.
El proceso LGWR escribe:
Un registro commit cuando un proceso de usuario hace COMMIT de una transaccin,
guardando los cambios y el nmero SCN (System Change Number) de la operacin
inmediatamente en disco.
Los buffers de Redo Log:
Cada tres segundos.
Cuando el buffer de Redo Log ha alcanzado un tercio de su capacidad.
Antes que el proceso DBWn escriba dirty buffers a disco.
El proceso LGWR escribe de forma sncrona a todos los miembros del grupo de Redo Log
activo. Si alguno de los ficheros dentro del grupo est daado o no disponible, el proceso
contina escribiendo en otros ficheros del grupo y genera un mensaje de error en el fichero
de traza del proceso y el fichero de alertas de la base de datos. Si todos los ficheros de un
grupo estn daados o el grupo no est disponible, el proceso LGWR no puede continuar
con su funcin.
Los cambios correspondientes a los bloques de datos se difieren hasta que resulte ms
eficiente escribirlos (mediante el proceso DBWn). A este mecanismo se le denomina
fast commit. La escritura de la entrada de Redo Log contiene el registro commit de la
transaccin, siendo el nico evento que determina que la transaccin ha sido validada
aunque los bloques de datos an no se hayan sincronizado.
Checkpoint Process (CKPT)

Al producirse un checkpoint, Oracle debe sincronizar las cabeceras de todos los ficheros de
datos y de redo logs. Esta labor la realiza el proceso CKPT. En caso de que los archivos no se
encuentren sincronizados, el proceso CKPT no escribe bloques a disco, sino que fuerza al
proceso DBWn que realice esa tarea. Tambin actualiza el archivo de control con los detalles
del checkpoint.
System Monitor Process (SMON)

El proceso SMON realiza las siguientes tareas:
Monta la base de datos localizando y validando los archivos de control.
Abre la base de datos localizando y validando los archivos de datos y los redo log
online.
Realiza un recovery de la instancia durante el proceso de arranque, si es necesario.
Limpieza de segmentos temporales no utilizados.
Compactacin de espacios libres contiguos en tablespaces gestionados por el
diccionario de datos.
Si en tiempo de arranque hay ficheros off-line y necesitan recovery, el proceso llevar
a cabo esta labor cuando los ficheros pasen a estado on-line.
Process Monitor Process (PMON)

Las tareas realizadas por el proceso PMON son las siguientes:
Monitoriza los otros procesos background.
Realiza una recuperacin (recovery) de procesos cuando el proceso de usuario falla.
Libera recursos reservados por un proceso de usuario cuando este finaliza.
Chequea el estado de los procesos servidores y dispatcher, arrancando aquellos que
hayan parado.
Registra informacin de la instancia y los procesos dispatcher con el listener.
Manageability Monitor Process (MMON)

El proceso MMON lleva a cabo las tareas relacionadas con la recoleccin de estadsticas del
sistema para almacenarlas como una instantnea (snapshot) en el repositorio de AWR
(Automatic Workload Repository) lanzando a continuacin el ADDM (Automatic Database
Diagnostic Monitor). Esta tarea se realiza por defecto cada 60 minutos.
Recoverer Process (RECO)

Este proceso solo se utiliza en configuraciones de bases de datos distribuidas y su labor
consiste en resolver automticamente fallos relativos a transacciones distribuidas. El
proceso RECO de un nodo conecta de forma automtica con las bases de datos implicadas
en transacciones distribuidas y gestiona su problemtica.
Archiver Processes (ARCn)

Su labor consiste en copiar el contenido de los ficheros de Redo Log Online a otra ubicacin
cuando se produce un cambio de archivo de log (switch logfile). Estos procesos solo estn
presentes si la base de datos tiene el modo archivado establecido. (modo ARCHIVELOG).
Una instancia Oracle puede tener hasta 30 procesos archiver (ARC0..ARC9 y ARCa..ARCt). El
proceso LGWR arranca un nuevo proceso ARCn cuando el nmero actual de procesos de
archivado es insuficiente para gestionar la carga de trabajo. En el fichero de alertas de la
base de datos se genera un registro cuando el proceso LGWR arranca un nuevo proceso
archiver.
Puede especificarse que se utilicen mltiples procesos de archivado en paralelo a travs del
parmetro LOG_ARCHIVE_MAX_PROCESSES. La sentencia ALTER SYSTEM permite modificar
este parmetro de forma dinmica para incrementar o decrementar este nmero. Sin
embargo, en una situacin normal no es preciso modificar su valor por defecto, dado que el
proceso LGWR se encargar de hacerlo si es preciso.
Job Queue Processes (CJQ0 y Jnnn)

La funcionalidad de estos procesos se limita a encolar trabajos para ejecutarlos en procesos
batch (por lotes).
Los procesos encolados se gestionan dinmicamente. Esto permite a los clientes usar ms de
un proceso cuando es necesario. Los recursos utilizados por los nuevos procesos se liberan
cuando ya no se utilizan.
Existe un proceso coordinador de jobs denominado CJQ0 que peridicamente selecciona
aquellos trabajos que deben ser ejecutados en base a la tabla JOB$. El proceso CJQ0 arranca
procesos esclavos (J000J999) para ejecutar cada uno de los trabajos. Una vez terminada la
ejecucin de un job, el trabajo es liberado y se gestionan nuevos trabajos. Cuando no
quedan trabajos se le marca un periodo de espera al proceso CJQ0 tras el cual el finaliza.
El parmetro JOB_QUEUE_PROCESSES representa el nmero mximo de procesos de cola
que pueden ejecutarse de forma concurrente sobre una instancia. Si este parmetro esta
con valor 0, el proceso CJQ0 no arrancar.
Comprobacin de los procesos background

Es muy fcil ver estos procesos background si tienes una instalacin de Oracle en las
plataformas Linux o UNIX. Utiliza para ello el comando ps que permite realizar consultas
sobre los procesos del sistema operativo.
Tambin puedes consultar los procesos background de la instancia desde una sesin de SQL
mediante la vista V$PROCESS del diccionario de datos de Oracle.

Oracle 12 2017 Parte2

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Oracle 12 2017 Parte2

Загружено:

Авторское право:

Доступные форматы

Mdulo 1

Arquitectura de Oracle 12c

Oracle Database 12c: Administrator Certified Associate

Concepto de Instancia Oracle

Concepto de Instancia Oracle

Concepto de Instancia Oracle

Es posible configurar un servidor Oracle de una de las siguientes formas, mutuamente

Independientemente de si la configuracin es con una instancia o con varias, una instancia

System Global Area (SGA)

Si el sistema utiliza arquitectura de procesos servidores compartidos (Shared Servers), las

Database Buffer Cache

Tamao del Database Buffer Cache

Mltiples Buffer Pools

El parmetro DB_CACHE_SIZE especifica el tamao de

Redo Log Buffer

Shared Pool Area

Todas las unidades de programa son almacenadas en el diccionario de datos, tanto el

Data Dictionary Cache

Program Global Area (PGA)

El contenido de la PGA es variable dependiendo de si la instancia est funcionando con

rea SQL privada

reas de trabajo SQL

User Global Area (UGA)

reas de cdigo software

Gestin manual de la memoria compartida

Gestin automtica de la memoria compartida

Si se especifica el parmetro SGA_TARGET, las siguientes zonas de memoria obtienen su

Gestin automtica de memoria (PGA y SGA)

Cuando se establece este parmetro (MEMORY_TARGET) se debe tener en cuenta la

Relacin entre parmetros de configuracin de memoria

Nuevo asesor de memoria

Se puede monitorizar cmo Oracle lleva a cabo la gestin automtica de la memoria

Gestin de memoria desde OEM Database Express

Desde la pgina Gestin de Memoria se pueden configurar los parmetros de inicializacin,

Procesos Servidores Compartidos

Database Writer Process (DBWn)

Log Writer Process (LGWR)

Checkpoint Process (CKPT)

System Monitor Process (SMON)

Process Monitor Process (PMON)

Manageability Monitor Process (MMON)

Recoverer Process (RECO)

Archiver Processes (ARCn)

Job Queue Processes (CJQ0 y Jnnn)

Comprobacin de los procesos background

Вам также может понравиться