Tema 4 - Instancias de BBDD Oracle (Curso 2011)

Curso de Administración de Base de Datos (ORACLE) 2011
TEMA 4
ARQUITECTURA
INSTANCIAS DE UNA
BBDD
1
1 Instancia de una Base de Datos

Un servidor de base de datos Oracle, consiste en una Base datos propiamente dicha y en una o
varias instancias corriendo sobre esa base de datos.
Una base de datos puede tener corriendo al mismo tiempo varias instancias, cada vez que se
arranca una base datos se arranca automáticamente una instancia.
Las instancias se componen de:
 Un área de memoria asignada:

o System Global Area – SGA.
Estructuras de Memoria compartida por todo el servidor y todos los procesos.
o Program Glabal Area – PGA
Estructuras de memoria no compartidas, que contienen datos e información
de control, para procesos propios de programas.
 Procesos de Background.
o Procesos de usuario
o Procesos de servidor
El esquema de la arquitectura sería:
2
Para la asignación de Memoria de una manera óptima, se recomienda la siguiente pauta para
los distintos componentes:
Componente % Memoria
SGA de Oracle 50
Sistema Operativo 15
Memoria de Usuario 35
En un servidor o en un sistema con 2 Gb de RAM, se traduciría por:
Componente Mb. de
Memoria
SGA de Oracle 1024
Sistema Operativo 306
Memoria de Usuario 694
1.1 SGA
Es un área de memoria compartida que se utiliza para la información de control y de datos de
la instancia. Se crea cuando la instancia se levanta y se elimina cuando se deja de usar
(shutdown).
La SGA es compartida por todos los procesos, tanto los de Servidor (Server Process) como los
de Background (Background process). Los daots incluidos en la SGA son por ejemplo los
bloques de datos cacheados o las áreas de SQL compartidas.
Consta de los siguientes elementos, cada uno de ellos con un tamaño fijo:
 El buffer de caché (database buffer cache).Almacena los bloques de datos

utilizados recientemente (se hayan o no confirmado sus cambios en el disco). Al
utilizarse este buffer se reducen las operaciones de entrada y salida y por esto se
mejora el rendimiento.
El tamaño del buffer cache se fija en el parámetro DB_BLOCK_BUFFERS, del
init.ora.
 El buffer de redo log: Guarda los cambios efectuados en la base de datos. Estos
buffers escriben en el archivo físico de redo log tan rápido como se pueda sin
perder eficiencia. Este último archivo se utiliza para recuperar la base de datos
ante eventuales fallas del sistema.
El tamaño del buffer de redo log se fija en el parámetro LOG_BUFFER
 El área shared pool: Esta sola área almacena estructuras de memoria compartida,
tales como las áreas de código SQL compartido e información interna del
diccionario. Una cantidad insuficiente de espacio asignado a esta área podría
redundar en problemas de rendimiento. En resumen, contiene las áreas del caché
de biblioteca y del caché del diccionario de datos.
3
o El caché de biblioteca se utiliza para almacenar código SQL compartido.

Aquí se manejan los árboles de parsing y el plan de ejecución de las
queries. Si varias aplicaciones utilizan la misma sentencia SQL, esta área
compartida garantiza el acceso por parte de cualquiera de ellas en
cualquier instante.
En esta zona se encuentra:
 Plan de ejecución de las sentencia SQL

 Texto de la sentencia
 Lista de objetos referenciados
Y los pasos para el procesamiento de cada petición son:
 Comprobar si la sentencia se encuentra en el área compartida

 Comprobar si los objetos referenciados son los mismos
 Comprobar si el usuario tiene acceso a los objetos referenciados
o El caché del diccionario de datos está conformado por un grupo de tablas

y vistas que se identifican la base de datos. La información que se
almacena aquí guarda relación con la estructura lógica y física de la base
de datos. El diccionario de datos contiene información tal como los
privilegios de los usuarios, restricciones de integridad definidas para
algunas tablas, nombres y tipos de datos de todas las columnas y otra
información acerca del espacio asignado y utilizado por los objetos de un
esquema.
El tamaño de la Share Pool viene dado por el parámetro

SHARED_POOL_SIZE
LRU esl el algoritmo para manejar el contenido del Shared Pool y del Database
Buffer Cache.
Cada componente del SGA (Buffer Cache, Shared Pool, etc) trabajan bajo
granulas, donde una granula equivale a:
o 4 mb, si el SGA_MAX_SIZE < 128.
o 16 mb, si el SGA_MAX_SIZE >= 128.
Mínimo el SGA necesita 12 MB, es decir una granula para el Buffer Cache, 1
granula para el Shared Pool y una granula para el Fixed Cache.
Los porcentajes óptimos para la gestión de la SGA, serían:
Componente SGA % Memoria SGA

Database Buffer Cache 80
Shared Pool Area 12
Fixed Size 1
Redo Log Buffer 0.1
En el sistema que habíamos previsto con 2 Gb, de memoria total en el que

dedicábamos 1 Gb a la SGA, el reparto sería aproximadamente:
4
Componente SGA Mb. Memoria

SGA
Database Buffer Cache 800
Shared Pool Area 128 – 188
Fixed Size 8
Redo Log Buffer 1
1.1.1 Gestión de la SGA

Existen dos formas de manejo de la SGA:
o Manejo automático de la memoria compartida

o Manejo manual de la memoria compartida
1.1.1.1 Gestión Automático de la memoria compartida

En este caso, el administrador de la base de datos, indica tan solo tamaño total de
memoria (Target memory size) en el parámetro de inicialización SGA_TARGET.
Este parámetro de inicialización es dinámico, por lo que puede ser cambiado sin
necesidad de reiniciar la Base de Datos y es la propia base de Datos la que se
encarga dinámicamente de realizar los ajustes necesarios en cada momento para
cada uno de los componentes de la SGA.
Hay que tener en cuenta que no se puede modificar el modo de gestión de

memoria a automático si el parámetro de inicialización LOCK_SGA tiene el valor
TRUE.
Para cambiar el modo de gestión de la SGA, será necesario parar y reiniciar la

Base de Datos, aunque una vez puesto en modo de gestión automático, se podrá
modificar dinámicamente la cantidad de memoria a gestionar.
A continuación se indican los componente de la SGA que automáticamente

obtienen sus tamaños de la SGA_TARGET, así como los parámetros que les
corresponden en la incialización:
o Shared Pool SHARED_POOL_SIZE

o Large Pool LARGE_POOL_SIZE
o Java Pool JAVA_POOL_SIZE
o Buffer Cache DB_CACHE_SIZE
o Streams Pool STREAMS_POOL_SIZE
Hay otros componentes que se deben indicar manualmente, aunque también

cogen la memoria del SGA_TARGET, siempre y cuando los anteriores tenga la
suya correspondiente, que son:
o Log Buffer LOG_BUFFER
o Buffer Caches DB_KEEP_CACHE_SIZE
5
 Diccionario de Datos
Diccionario de Datos Descripción

V$sgainfo Muestra la información de los tamaños de diversos
componentes de la SGA
V$sga Muestra la información esencial de la SGA
V$sga_target_advice Muestra información que ayuda a decidir el tamaño del
SGA_TARGET
V$sgastats Muestra estadísticas de uso de la SGA
V$sga_dynamic_components Muestra los tamaños actuales de los componentes de la
SGA y la última operación de cada uno
V$sga_dynamic_free_memory Muestra la cantidad de emoria disponible para futuros
redimensionamientos de la SGA
Ejemplo
Select * from v$sga_target_advice order by sga_size;
1.1.1.2 Gestión Manual de la memoria compartida

En este modo de gestión de la memoria, el administrador debe indicar el valor de
cada uno de los componentes de la SGA y de esa manera se configura el tamaño
total de la SGA.
Posteriormente en función de los valores de uso, el administrador deberá ajustar

los tamaños de cada uno de los componentes individualmente.
Estos valores inicialmente se han de especificar en el fichero de parámetros de

inicialización al utilizar la instrucción CREATE DATABASE y si no se
especifica y se ha escogido la gestión manual de la SGA, Oracle automáticamente
calcula unos valores adecuados mínimos para el funcionamiento de cada una de
los componentes.
Veamos la gestión de los distintos componentes:
 Buffer Cache
Se utiliza para indicar diferentes tamaños de la cache para diferentes
tamaños de bloque utilizados.
Si se utiliza un tamaño pequeño de la buffer cache se origina una gran
cantidad de Entrada / Salida, mientras que si se determina un tamaño
grande aparte de necesitar una gran cantidad de memoria se puede originar
una gran cantidad de paginación y de swaping.
El valor por defecto se incluye en el parámetro DB_CACHE_SIZE y se
puede definir un parámetro para cada tamaño de bloque
(DB_2K_CAHCE_SIZE, DB_4K_CAHCE_SIZE,
DB_6K_CAHCE_SIZE…..) No se permite colocar el valor del cache para
el bloque por defecto, este estará en el genérico DB_CACHE_SIZE.
6
Se pueden utilizar diferentes buffer cache con diferentes pool que hacen
que se fijen los datos en diferentes buffers o que se reutilicen los buffer tan
pronto como se hayan usado los bloques de datos.
o KEEP buffer pool retiene los objetos de un esquema en un bloque
de datos de la memoria.
o RECYCLE buffer pool elimina los bloques de datos tan poronto
como dejan de ser utilizados.
o DEFAULT buffer pool contiene los objetos de un esquema que no
han sido asignados a ningún otro específicamente.
Estas modalidades se especifican en los parámetros de inicialización

llamados DB_KEEP_CACHE_SIZE y DB_RECYCLE_CACHE_SIZE.
 Shared Pool Size

En las versiones actuales oracle organiza automáticamente la Shared pool
size, aunque en versiones anteriores a la 10g siempre era igual a la
especificada en el parámetro de inicialización SHARED_POOL_SIZE y
era reservada esa memoria al realizar el startup de la Base de Datos.
 Large Pool Size
Este es un componente opcional de la SGA, aunque suele estar presente
casi siempres y se utiliza para el almacenamiento de objetos considerados
grandes de la Base de Datos.
Este se incializa en el parámetro LARGE_POOL_SIZE.
 Java Pool Size
Es la parte de la SGA utilizada para el almacenamiento de todos los
componentes java utilizados y se inicializa en el parámetro
JAVA_POOL_SIZE, aunque Oracle lo maneja automáticamente. No está
disponible en versiones anteriores a Oracle 9.
 Streams Pool Size
Esta es la parte de la memoria utilizada para realizar Streamings. Si este
parámetro se tiene a 0, Oracle cogerá parte de la buffer cache para
utilizarla en el streamings. Se inicializa en el parámetro
STREAMS_POOL_SIZE.
1.2 PGA
Es un área de memoria que contiene datos e información de control para los procesos de
Servidor. Estas regiones de la PGA no son compartidas y so creadas cada vez que se
arranca un proceso de servidor y liberada cada vez que ese proceso es finalizado.
Existe una PGA para cada proceso de servidor o para cada proceso de Background y
cada uno de esos procesos será asignado a su porción de memoria.
En el siguiente esquema se muestra como estaría distribuida la memoria en una

instancia, con varios procesos arrancados.
7
1.2.1 Gestión de la PGA

Existen dos formas de manejo de la pga:
o Manejo automático de la memoria de procesos de servidor

o Manejo manual de la memoria de procesos de servidor.
1.2.1.1 Gestión Automático de la memoria de procesos de servidor

En este caso, el administrador debe indicar el tamaño total de la memoria
disponible para la PGA, esto lo hace en el parámetro de incialización
PGA_AGGREGATE_TARGET.
Oracle intentará automáticamente asignar el máximo posible de memoria

disponible a los distintos procesos de Servidor, pero no sobrepasando nunca el
valor indicado en ese parámetro.
Si no se especifica este valor, Oracle lo inicializará en un valor que se considere el

mínimo imprescindible para su buen uso.
Cuando se utiliza esta modalidad Oracle automatiza su usa para todas las áreas de
trabajo de los procesos de SQL y todos los parámetros *_AREA_SIZE son
ignorados.

V$pgastats Muestra estadísticas de uso de la PGA
V$sql_workarea Muestra la información de las áreas de sql utilizadas estén
8
o no activas
V$sql_workarea_active Muestra la información de las áreas de sql utilizadas que
estén activas.
V$process Algunos campos de esta vista nos informan de la memoria
asignada a los diferentes procesos.
1.2.1.2 Gestión Manual de la memoria de procesos de servidor

En la versiones anteriores a la 10g el administrador controlaba el tamaño máximo
de las áreas de trabajo de SQL con los siguientes parámetros de inicialización:
 SORT_AREA_SIZE
 HASH_AREA_SIZE
 BITMAP_MERGE_AREA_SIZE
 CREATE_BITMAP_AREA_SIZE
La gestión manual de estos parámetros es compleja ya que depende de los datos

tratados, por lo que es conveniente que sea Oracle el que se encargue de ello de
forma automática.
1.3 Procesos de la Instancia
Los procesos de Background son los encargados de realizar asíncronamente todas las
operaciones de Entrada / Salida y monitorizar otros procesos de la base de datos para
incrementar el paralelismo para una mayor eficiencia de la propia instancia.
Los principales procesos que se ejecutan en una instancia son los siguientes:
 DBWR (database writer): Es el responsable de la escritura en disco de toda la

información almacenada en los buffers de bloques que no se han actualizado.
Este proceso baja a disco en las siguientes situaciones:
o No hay espacio libre en el buffer cache para nueva data.
o Demasiados commits que no han bajado a disco.
o Usando shutdown o usando checkpoint.
o El tablespace es puesto en modo backup, offline o readonly.
o Un segmento es borrado.
 LGWR (log writer): Es el responsable de escribir información desde el buffer de

log hacia el archivo redo log. Este proceso baja a Disco en las siguientes
situaciones:
o Cada 3 segundos.
o Cuando se hace un commit.
o Cuando el redo buffer tiene 1 MB de redo información.
o Checkpont.
9
 CKPT (checkpoint): Es el responsable de advertir al proceso DBWR de efectuar

un proceso de actualización en el disco de los datos mantenidos en memoria,
incluyendo los datafiles y control files (para registrar el checkpoint). Este
proceso es opcional, si no está presente, es el proceso LGWR quien asume la
responsabilidad de la tarea.
Los checkpoint se producen cuando:
o Un tablespaces se coloca Offline
o Se llena el fichero de Redo log activo
o Se para la Base de Datos mediante un Shutdown
o Se alcanza el límete de los bloques de redo log desde le último
checkpoint (parámetro LOG_CHECKPOINT_INTERVAL)
o Se produce un timeout desede el último checkpoint. (parámetro
LOG_CHECKPOINT_TIMEOUT)
Este proceso se activa a través del parámetro CHECKPOINT_PROCESS para

versiones anteriores a la 8i.
 PMON (process monitor): Su misión es monitorizar los procesos del servidor y

tomar acciones correctivas cuando alguno de ellos se interrumpe en forma
abrupta, limpiando la caché y liberando los posibles recursos que pudieran estar
asignados en ese momento. También es responsable por el restablecimiento de
aquel proceso que se ha interrumpido bruscamente.
 SMON (system monitor): Levanta una instancia cuando se le da la instrucción de

partida (al comienzo del trabajo, encontrándose previamente en shutdown).
Enseguida limpia los segmentos temporales y recupera las transacciones que
pudieran haberse interrumpido debido a una falla del sistema. Además
disminuye la fragmentación del sistema agrupando aquellas extensiones libres
que existen dentro de la base de datos.
 ARCH (archiver): La función de este proceso es la de respaldar la información

almacenada en los archivos redo log cuando éstos se llenan. Este proceso está
siempre activo cuando se ha establecido el modo ARCHIVELOG. Si el sistema
no está operando en este modo se hace más difícil recuperar el sistema sin
problemas luego de una falla general.
Existen otros procesos que se ejecutan en el motor de Base de datos:
 Job Queue (J): Ejecuta jobs de la base de datos que han sido shedule.
 Job Queue Monitor (CJQ): Asigna jobs a la cola de jobs.
 MMNL (Memory Monitor Light): Recolecta estadísticas para AWR.
 MMAN (Memory Manager): Es activado en el Database Control y esto permite
que el ADDM ajuste database buffer cache según los estadísticas. El MMAN a
cada componente del SGA lo dimensiona.
 Recovery Writer (RVWR): Escribe recovery information cuando se habilita el
flash recovery.
10
 Change Tracking Writer (CTWR): Mantiene tracks de los bloques cambiados

desde un backup incremental por el RMAN.

V$process Muestra los procesos activos
1.4 Ciclo de Ejecución
Para ilustrar el funcionamiento del servidor Oracle vamos a ver el ciclo de ejecución de
una sentencia de lectura y otra de actualización.
 Ciclo de Lectura
Las sentencias de lectura siguen el siguiente ciclo:
1. El proceso cliente pasa la sentencia SQL (SELECT) al proceso servidor por medio
de la SGA.
2. Los procesos del servidor buscan en la zona de SQL compartido una versión
ejecutable de la sentencia. Si la encuentran no tienen que procesarla.
3. Se procesa la sentencia SQL y su versión ejecutable se coloca en la zona de SQL
compartido.
4. El proceso del servidor intenta leer los bloques de datos de la SGA. Si no están,
se han de leer del fichero de datos. Si los bloques están en la SGA pero han sido
modificados por otro usuario y esa modificación no ha sido validada aún, el
proceso de servidor debe reconstruir la imagen de la fila a partir de los
segmentos de rollback, para conseguir consistencia en lectura.
5. El proceso servidor pasa los datos solicitados al proceso cliente.
 Ciclo de Actualización
Las sentencias de actualización siguen el siguiente ciclo:
1. El proceso cliente pasa la sentencia SQL (UPDATE) al proceso servidor por medio
de la SGA.
2. Los procesos del servidor buscan en la zona de SQL compartido una versión
ejecutable de la sentencia. Si la encuentran no tienen que procesarla.
3. Se procesa la sentencia SQL y su versión ejecutable se coloca en la zona de SQL
compartido.
4. El proceso del servidor intenta leer los bloques de datos de la SGA. Si no están,
se han de leer del fichero de datos.
5. Se registra el valor antiguo de los datos en un segmento de rollback y se crea un
registro redo log.
6. Se crea una copia de la transacción en un registro redo log.
11
7. Se ejecuta la sentencia SQL modificando los datos, y se crea un registro redo log
que así lo refleja.
8. El proceso usuario valida la transacción (COMMIT), registrándose en un registro
redo log.
9. El LGWR escribe los buffers del redo log en el disco.
10. El servidor indica al cliente que la operación ha sido completada de manera
satisfactoria.
11. Se registra la terminación de la transacción en un registro redo log.
12. Se libera la información del rollback, pues ya no va a necesitarse.
Si a partir del paso 6 el usuario cancela la transacción (ROLLBACK), se puede utilizar la

información de rollback para restablecer el valor original.
Si sucede algo que impida que la transacción validada por el usuario pueda llevarse a
cabo, se puede utilizar la información contenida en los registros redo log para rehacer la
transacción (a partir del paso 6).
Como ocurre con todas las transacciones, en algún momento el DBWR escribe en el
archivo de datos la copia de los bloques de datos modificados que se encuentran en el
buffer cache.
1.5 Arranque y Parada de una BBDD.

Al arrancar un instancia, lo primero que hace Oracle es leer los parámetros de
inicialización de la instancia, bien desde un spfile o bien desde un pfile. El orden en el
que busca Oracle los ficheros de parámetros es:
 Spfile$ORACLE_SID.ora
 Spfile.ora
 Init$ORACLE_SID.ora
O bien se especifica el fichero con su ruta en el comando de inicio.
STARTUP PFILE = c:\/oracle\dbs\init.ora
Los pasos para arrancar una instancia en SQL*Plus son los siguientes:
 Asegurarse que las variables de entorno están correctamente asignadas.

 Arrancar SQL*PLus en sql*plus sin logarse
 Conectase como SYSDBA
La instancia se arranca (STARTUP) en diferentes modos según las necesidades:
 OPEN
Cuando se ejecuta el comando startup open la BD pasa por tres estados (nomount,
mount y open) antes de estar disponible. El DBA puede arrancar la BD hasta uno de los
estados con el comando startup: startup nomount, startup mount. A continuaciÓn
12
vamos a describir cada uno de los estados por los que pasa la BD en el proceso de
arranque.
 NOMOUNT
Oracle lee el fichero init.ora, localiza los ficheros de control, crea e inicializa la SGA, y
finalmente arranca todos los procesos Oracle. En este estado la instancia de BD está
arrancada. Se deberá llevar la BD al estado nomount cuando se está creando la BD o
cuando se está restaurando un fichero de control después de haberlo perdido.
STARTUP NOMOUNT
 MOUNT
Oracle abre los ficheros de control para localizar los ficheros de datos y los redo log,
pero no se realizan ninguna comprobaci�n en ellos en este momento. La instancia
monta la BD y la bloquea, verificando que ninguna otra instancia ha montado la misma
BD.
Hay varias razones para querer tener la BD en el estado mount. En general, todas las
sentencias SQL del tipo alter database se deben ejecutar en esta etapa. Algunas de las
operaciones a realizar cuando la BD está montada son:
 efectuar recuperaciones,
 poner online/offline un fichero de datos,
 recolocar los ficheros de datos y redo log,
 Crear un nuevo grupo o miembro redo log, o borrar un grupo o miembro redo
log existente.
STARTUP MOUNT
Se puede realizar un paso desde NOMOUNT a MOUNT, mediante una instrucción de

ALTER DATABASE
ALTER DATABASE MOUNT;
 OPEN
Durante esta etapa, la instancia abre la BD, bloquea los ficheros de datos, y abre todos
los ficheros redo log. Si la instancia abre la BD después de una terminación anormal, o
después de una caída, se ejecutar�automáticamente el proceso de recuperación
utilizando los ficheros redo log. Al final de esta etapa la BD está dispuesta para su uso
normal.
STARTUP OPEN / STARTUP
Se puede realizar un paso desde MOUNT a OPEN, mediante una instrucción de ALTER
DATABASE
ALTER DATABASE OPEN;
13
Una Base de Datos abierta se puede modificar también para colocarla en modo
READ ONLY o en modo READ WRITE, mediante un comando ALTER
DATABASE.
ALTER DATABASE OPEN READ ONLY;

ALTER DATABASE OPEN READ WRITE;
 RESTRICT
Se puede iniciar una base de datos en un modo restrictivo, que estará disponible tan
solo para el personal de administración.
Los motivos por lo que se inica la base de datos en este modo son:
o Realizar Export o Import de los datos
o Cargas realizadas mediante SQL* Loader
o Deshabilitar el acceso a los datos de forma preventiva a los usuarios
o Realizar operaciones de migración o actualización.
Los usuarios con el role de CREATE_SESSION pueden acceder a una base de datos
abierta pero para acceder a una abierta en modo restrictivo además hay que tener el
role RESTRICTED_SESSION.
En este modo no se puede acceder a la Base de Datos en modo Remoto, a través de

Oralce Net.
STARTUP RESTRICT
Se puede modificar este estado y pasarlo a abierto mediante un comando ALTER

SYSTEM.
ALTER SYSTEM DISABLE RESTRICTED SESSION;
 FORCE
Se puede forzar a una Base de Datos a arrancar, después de una parada inesperada o
forzada o si simplemente la base de datos no se cierra normalmente.
Este modo primero realiza un shutdown abort para después realizar un forzado de la
inicialización.
STARTUP FORCE
La instancia se para (SHUTDOWN) de tres formas distintas:
 NORMAL
Se impide el acceso a la BD, espera a que todos los usuarios completen todas sus
peticiones y se desconecten del servidor. Purga todos los buffers de datos y caches de
redo log, actualizando los ficheros de datos y de redo log, se eliminan los bloqueos de
ficheros, se completan las transacciones en marcha, se actualizan las cabeceras de
ficheros, elimina los threads, libera los bloqueos de la BD por parte de la instancia, y
14
sincroniza los ficheros de control y de datos. En resumen, la opción normal cierran la

BD, desmonta la BD y para la instancia con cuidado y es la opción recomendada para
parar la BD.
SHUTDOWN NORMAL
 INMEDIATE
En ciertas ocasiones puede ser necesario parar la BD de modo inmediato. Si es as�, las
sentencias en proceso son terminadas inmediatamente, cualquier transacción no
confirmada (uncommitted) es vuelta atrás (rolled back) y la BD es parada. La �nica
desventaja de utilizar esta opción es que Oracle no espera a que los usuarios se
desconecten. Sin embargo, la BD será consistente y no se necesitará recuperación en el
siguiente arranque.
SHUTDOWN INMEDIATE
 ABORT
En situaciones de emergencia, y cuando todo lo demás falla, se debe realizar una

parada de este tipo. Por ejemplo, cuando un proceso de la instancia muere y la BD no
puede pararse de modo normal o inmediato. Cuando se utiliza la opción abort las
sentencias SQL son terminadas bruscamente, y las transacciones no confirmadas no
son vueltas atrás. Parar la BD con la opción abort requiere recuperación en la siguiente
vez que arranque la BD y esta opción debe ser utilizada sólo cuando no quede más
remedio.
SHUTDOWN ABORT
1.6 Sesiones
Una Sesión es una conexión por parte de un usuario a la base de datos.
El inicio de una sesión implica el inicio de unos procesos que a su vez reservan la memoria
pertinente dentro de la Base de Datos.
Oracle administra automáticamente las sesiones y cuando dejan de estar conectados elimina
todos los procesos y libera toda la memoria que utilizaba. Sin embargo en algunas ocasiones es
necesario finalizar sesiones que se quedan colgadas en la Base de Datos y que están
bloqueando datos que no pueden ser accedidos por otros usuarios.
Para realizar este proceso de terminar una sesión se han de realizar los siguientes pasos:
 Identificar la sesión finalizar
15
 Terminar la sesión, que tiene dos modalidades

o Terminar una sesión activa
o Terminar una sesión inactiva
Cuando una sesión es finalizada todas las transacciones activas se hace rollback y todos los
recursos utilizados son devueltos al sistema para se reutilizados.
Para identificar las sesiones de un usuario se debe realizar la siguiente consulta:
SELECT SID, SERIAL#, STATUS

FROM V$SESSION
WHERE USERNAME = 'JWARD';
SID SERIAL# STATUS

----- --------- --------
7 15 ACTIVE
12 63 INACTIVE
Una sesión se considera Activa si se encuentra en una transacción SQL con una llamada a la
Base de Datos, mientras que está Inactiva si no tiene ninguna transacción pendiente.
Si una transacción Activa se finaliza, se realiza el rollback de todas las transacciones asociadas y
al usuario se le envía un mensaje
ORA-00028: your session has been killed
Si el usuario intenta realizar nuevas operaciones recibirá el mensaje:
ORA-01012: not logged on
Si la sesión es inactiva el usuario no recibe ningún mensaje hasta que intenta reutilizar la
sesión que ha sido finalizada.
Cuando una sesión inactiva es finalizada aparece con un estado KILLED, en la vista V$SESSION,
este registro desaparece una vez que el usuario ha intentado volver a utilizar la sesión que se
ha finalizado.
Para finalizar una sesión se ha de utilizar el comando:
ALTER SYSTEM KILL SESSION ‘n,m’;
Donde n es el identificador SID de la sesión y m es el valor de SERIAL de la sesión.
Ejemplo
SELECT SID,SERIAL#,STATUS,SERVER
FROM V$SESSION
16
SID SERIAL# STATUS SERVER

----- -------- --------- ---------
7 15 INACTIVE DEDICATED
2 rows selected.
ALTER SYSTEM KILL SESSION '7,15';

Statement processed.
SELECT SID, SERIAL#, STATUS, SERVER

FROM V$SESSION
SID SERIAL# STATUS SERVER

----- -------- --------- ---------
7 15 KILLED PSEUDO
2 rows selected.

V$session Muestra todas las sesiones actuales
V$sess_io Estadísticas de Entrada Salida para cada sesión de usuario
V$session_wait Muestra la última espera de cada sesión
V$session_wait_history Historial de esperas de cada sesión.
V$wait_chains Da información sobre las sesiones bloqueadas
V$sysstat Muestra las estadísticas de las sesiones.
17

Tema 4 - Instancias de BBDD Oracle (Curso 2011)

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 4 - Instancias de BBDD Oracle (Curso 2011)

Cargado por

Copyright:

Formatos disponibles

Curso de Administración de Base de Datos (ORACLE) 2011

1 Instancia de una Base de Datos

Las instancias se componen de:

 Un área de memoria asignada:

El esquema de la arquitectura sería:

En un servidor o en un sistema con 2 Gb de RAM, se traduciría por:

 El buffer de caché (database buffer cache).Almacena los bloques de datos

El tamaño del buffer de redo log se fija en el parámetro LOG_BUFFER

o El caché de biblioteca se utiliza para almacenar código SQL compartido.

En esta zona se encuentra:

 Plan de ejecución de las sentencia SQL

Y los pasos para el procesamiento de cada petición son:

 Comprobar si la sentencia se encuentra en el área compartida

o El caché del diccionario de datos está conformado por un grupo de tablas

El tamaño de la Share Pool viene dado por el parámetro

Los porcentajes óptimos para la gestión de la SGA, serían:

Componente SGA % Memoria SGA

En el sistema que habíamos previsto con 2 Gb, de memoria total en el que

Componente SGA Mb. Memoria

1.1.1 Gestión de la SGA

o Manejo automático de la memoria compartida

1.1.1.1 Gestión Automático de la memoria compartida

Hay que tener en cuenta que no se puede modificar el modo de gestión de

Para cambiar el modo de gestión de la SGA, será necesario parar y reiniciar la

A continuación se indican los componente de la SGA que automáticamente

o Shared Pool SHARED_POOL_SIZE

Hay otros componentes que se deben indicar manualmente, aunque también

Diccionario de Datos Descripción

Select * from v$sga_target_advice order by sga_size;

1.1.1.2 Gestión Manual de la memoria compartida

Posteriormente en función de los valores de uso, el administrador deberá ajustar

Estos valores inicialmente se han de especificar en el fichero de parámetros de

Veamos la gestión de los distintos componentes:

Estas modalidades se especifican en los parámetros de inicialización

 Shared Pool Size

En el siguiente esquema se muestra como estaría distribuida la memoria en una

1.2.1 Gestión de la PGA

o Manejo automático de la memoria de procesos de servidor

1.2.1.1 Gestión Automático de la memoria de procesos de servidor

Oracle intentará automáticamente asignar el máximo posible de memoria

Si no se especifica este valor, Oracle lo inicializará en un valor que se considere el

Diccionario de Datos Descripción

1.2.1.2 Gestión Manual de la memoria de procesos de servidor

La gestión manual de estos parámetros es compleja ya que depende de los datos

1.3 Procesos de la Instancia

 DBWR (database writer): Es el responsable de la escritura en disco de toda la

 LGWR (log writer): Es el responsable de escribir información desde el buffer de

 CKPT (checkpoint): Es el responsable de advertir al proceso DBWR de efectuar

Este proceso se activa a través del parámetro CHECKPOINT_PROCESS para

 PMON (process monitor): Su misión es monitorizar los procesos del servidor y

 SMON (system monitor): Levanta una instancia cuando se le da la instrucción de

 ARCH (archiver): La función de este proceso es la de respaldar la información

Existen otros procesos que se ejecutan en el motor de Base de datos:

 Change Tracking Writer (CTWR): Mantiene tracks de los bloques cambiados

Diccionario de Datos Descripción

1.4 Ciclo de Ejecución

Las sentencias de lectura siguen el siguiente ciclo:

Las sentencias de actualización siguen el siguiente ciclo:

Si a partir del paso 6 el usuario cancela la transacción (ROLLBACK), se puede utilizar la

1.5 Arranque y Parada de una BBDD.

O bien se especifica el fichero con su ruta en el comando de inicio.

STARTUP PFILE = c:\/oracle\dbs\init.ora

 Asegurarse que las variables de entorno están correctamente asignadas.

La instancia se arranca (STARTUP) en diferentes modos según las necesidades: