Capı́tulo 1

Aspectos generales de la
Arquitectura Oracle

1.1. Introducción
El Sistema Gestor de Bases de Datos Oracle, como cualquier sistema de información, está formado
por dos elementos:

Datos: conforman la propia BD y son de dos tipos:

Diccionario de Datos (catálogo del sistema): es un conjunto de tablas que describen todos los
objetos existentes en la BD: tablas, ı́ndices, vistas, clusters, etc. También incluye toda la información
correspondiente a usuarios, permisos, etc.
Datos: Incluye los datos de usuario, los segmentos de rollback, etc.

Tratamientos: conjunto de aplicaciones que permiten el manejo de datos: DBA Management Pack
(incluye DBA Studio y OEM), SQL Plus WorkSheet, SQL Forms, etc.

1.2. DBA Management Pack

Permite realizar tareas de administración a través de:

la consola Oracle Enterprise Manager (OEM) que permite manejar BDs, jobs, eventos y grupos

DBA Studio para tareas de seguridad, almacenamiento, instancias, esquemas, etc. Es una interfaz
central que permite acceder a todas las herramientas de DBA Management Pack:
Administrador de Instancia (INSTANCIA) para arranque, desconexión de BD y supervisión
de sesiones, modificación del fichero de párámetros INIT.ORA o resolver transacciones pendiente,
entre otros.
Administrador de Esquema (ESQUEMA) permite crear, editar, borrar, consultar objetos del
esquema (tablas, ı́ndices, disparadores, vistas, etc.)
Administrador de Seguridad (SEGURIDAD) donde el DBA trabaja con usuarios, papeles y
perfiles
Administrador de Almacenamiento (ALMACENAMIENTO) para administrar los tablespaces,
datafiles, segmentos de Rollback, ficheros de control, logs archivados y redo logs.

1
 1.3. COMPONENTES DEL SGBD ORACLE

1.3. Componentes del SGBD Oracle

1.3.1. Bases de Datos
Una BD Oracle es un conjunto de archivos sobre disco teniendo cada uno una estructura y un cometido
particular.
Una BD puede verse desde un punto de vista fı́sico o lógico

Punto de vista fı́sico: Hace referencia a los datos realmente almacenados

(1+) Archivos BASE: Permiten el almacenamiento de datos de usuarios, del diccionario de
datos y datos de trabajo (para manejo de transacciones)
(2+) Archivos REDO LOG: facilitan la recuperación ante fallos; estos ficheros registran todos
los cambios realizados sobre los datos y se utilizan en el proceso de recuperación, si ciertos cambios
no llegan a grabarse en la memoria permanente.
(1+) Archivos de CONTROL: permiten realizar el seguimiento de la estructura fı́sica de la BD.
Contienen la información de control, como el nombre de la BD, nombres de ficheros y ubicación
de los mismos, y marca de tiempo con la fecha de creación de la BD. Este ficheros también se
necesitará en el caso de tener operaciones de recuperación.
(1) Archivo de PARÁMETROS: empleado para optimización (tunning) Estos archivos no son
“visibles” más que para el DBA; sólo él puede crearlos y suprimirlos. El DBA no puede modificar su
contenido, porque esto es una de las tareas de los procesos background por Oracle. En su creación,
el DBA puede decidir su nombre, tamaño y emplazamiento.

Punto de vista lógico: Corresponde a una representación abstracta de los datos almacenados, de
acuerdo con el esquema conceptual de la BD.
TABLESPACES: Unidades lógicas que agrupan los archivos base
ESQUEMAS: Objetos de la BD (tablas, ı́ndices, vistas, clusters, triggers, etc.)

1.3.2. Instancias
Una instancia Oracle es el modo de acceder a una BD Oracle. Está compuesto por la zona de memoria
reservada para la BD y un conjunto de procesos background que se ejecutan en el servidor (uno de los
cuales es opcional).
Varias instancias pueden coexistir simultáneamente en una misma máquina, pero cada instancia tra-
baja sobre una sola BD.
Un usuario autorizado puede tener acceso a una BD a través de su instancia. En todo momento el
DBA (administrador de la BD) puede parar una instancia y hacer, por tanto, inaccesible su BD.
Cada instancia tiene sus propias caracterı́sticas, por ejemplo, el tamaño de la zona de memoria reserva-
da. Estas caracterı́sticas están definidas mediante unos parámetros contenidos en un archivo de arranque
(INIT.ORA). Este archivo se lee duratne el arranque de la instancia y el DBA puede modificarlo.
Cada usuario conectado a una BD constituye un proceso de usuario para la instancia que está uti-
lizando esta BD.

1.3.3. Núcleo Oracle

Es un programa ejecutable, residente en memoria y puede estar dividido para varias instancias Oracle.
Permite almacenamiento de datos (gestión de almacenamiento en disco), gestión del diccionario de datos,
búsqueda/modificación de datos, seguridad e integridad, acceso concurrente, etc.

2
 1.4. ELEMENTOS FÍSICOS DE UNA BD

1.4. Elementos fı́sicos de una BD

1.4.1. Archivos base
Es un fichero fı́sico de la BD que almacena los datos de usuario, del diccionario de datos y los
datos de trabajo.
Los datos de los usuarios y del DD constituyen el corazón de la BD Oracle. Estos datos están repre-
sentados en forma de tablas y de ı́ndices. Los datos de trabajo son necesarios para generar la noción de
transacción.
Es parametrizable por el usuario tanto el tamaño total (que, a partir de la versión 7.2 de Oracle puede
ser ilimitado), como el tamaño de los bloques que incluye, aunque bajo la limitación de que los bloques
deben tener el mismo tamaño para toda la BD.
Un Archivo Base es un conjunto de octetos (bytes). Los bytes se agrupan en bloques, llamados
bloques Oracle. Un bloque Oracle es la unidad más pequeña de transferencia memoria/disco. Parte de
estos bloques están reservados para los datos de los usuarios y del DD, y parte para los datos de trabajo.
Los archivos base solo pueden suprimirse borrando el tablespace al que esté asignado.

Segmentos de datos y de ı́ndices

Una tabla de usuario o del diccionario de datos ocupa un cierto número de bloques Oracle. Los bloques
ocupados por una tabla forman lo que se llama un segmento de datos. Un ı́ndice ocupa un segmento
de ı́ndices.
El segmento de datos o de ı́ndices está compuesto por una o varias series de bloques llamadas exten-
siones. El número de bloques por extensión, y el número de extensiones son parametrizables por objeto
de modo que puede variar de una tabla a otra y de un ı́ndice a otro. Generalmente los bloques de una
misma extensión están contiguos en el disco. Por el contrario, dos extensiones de una misma tabla no
estarán contiguos necesariamente.

¿Cómo se asignan las extensiones? Cada segmento tiene un bloque cabecera que describe las car-
acterı́sticas del segmento y contiene un directorio con las extensiones asociadas.
Cuando se crea una tabla, ı́ndice, cluster o segmento de Rollback, Oracle reserva para este objeto
al menos una extensión, vacı́a de partida. En el futuro y a medida que se crean las ocurrencias de este
objeto, Oracle utiliza progresivamente los bloques de la extensión. Cuando todos los bloques de una
extensión están utilizados y se tiene necesidad de espacio, Oracle busca bloques libres en las extensiones
ya existentes. Si no los encuentra, asigna al objeto una nueva extensión.
Cuando se necesita una extensión adicional para un segmento, se busca en el espacio libre del ta-
blespace asociado y se asigna el primer espacio contiguo de bloques/páginas del tamaño requerido, y se
actualiza el bloque cabecera.
Una extensión asignada a un objeto deja de pertenecerle cuando se borra el objeto. Es decir, si se
borran tuplas únicamente, entonces los bloques libres siguen perteneciendo a la tabla (ı́ndice), no a los
otros objetos de la BD. Cuando se borra un objeto sus extensiones quedan disponibles para ser utilizadas
por otros objetos del tablespace.

Parámetros de asignación de espacio en SQL Cada objeto de la BD (tabla, ı́ndice, cluster o

segmento de Rollbak) es creado con unas caracterı́sticas de asignación de espacio, que vienen determinadas
mediante los parámetros de la cláusula STORAGE:

STORAGE [INITIAL entero] [NEXT entero]

[MINEXTENTS entero] [MAXEXTENTS entero] [PCTINCREASE entero]

siendo:
INITIAL tamaño de la primera extensión. Se redondea al tamaño del bloque

3
 1.4. ELEMENTOS FÍSICOS DE UNA BD

NEXT tamaño de las siguientes extensiones

MAXEXTENTS máximo número de extensiones para el objeto
MINEXTENTS mı́nimo número de extensiones (por defecto 1), es decir, número de extensiones que se
asignan al crear el segmento
PCTINCREASE porcentaje de crecimiento por extensión (por defecto 50). Si vale 0 todas las extensiones
serán iguales. Se redondea al siguiente múltiplo del tamaño del bloque
Si no se asigna STORAGE a un objeto, toma del de su tablespace. Los valores predeterminados de los
parámetros de almacenamiento de cada tablespace se encuentran en las vistas DBA TABLESPACES y
USER TABLESPACES.

Ampliación del tamaño de un Archivo Base Cuando se crean archivos de datos, se pueden es-
pecificar parámetros que permitan a Oracle ampliarlos automáticamente cuando se exceda su longitud
asignada actual. En cada Archivo Base se pueden especificar tres parámetros de dimensionamiento:

AUTOEXTEND [ON|OFF] si está a ON se permite que el archivo se amplı́e automáticamente. Si su valor es

OFF, el resto de los parámetros de dimensionamiento tomarán el valor cero.
NEXT tama~
no [K|M] tamaño (en bytes) del área de espacio de disco que se va a asignar al Archivo Base,
cuando se necesite más espacio.
MAXSIZE tama~ no [K|M] tamaño máximo (en bytes) hasta el cual se deberı́a permitir ampliarse el Archivo
Base. Si no se especifica, el tamaño máximo sólo estará limitado por el espacio disponible en el disco
del archivo.

Se pueden especificar estos parámetros utilizando las órdenes CREATE DATABASE, CREATE TABLESPACE
y ALTER TABLESPACE

Segmentos de trabajo
Los segmentos de trabajo representan una parte de los bloques de los archivos base. Esta parte es
utilizada por Oracle para sus propias necesidades. Existen cuatro tipos de segmentos de trabajo: los
segmentos de Rollback, los segmentos temporales, los segmentos diferidos y los de arranque(bootstrap).

Segmentos de Rollback: almacenan la imagen anterior de los bloques de datos o ı́ndices que se están
modificando. Un elemento de un segmento de Rollback es el conjunto de bloques con la imagen anterior
de las tuplas que son modificadas por una transacción. En efecto, todos los bloques de datos y de ı́ndices
en curso de modificación son copiados con sus valores antiguos (la imagen anterior) en un segmento de
Rollback. La copia se hace en memoria (en el buffer de Rollback). Únicamente en caso de un checkpoint
se llevan los datos al Archivo Base. Si la transacción de modificación se termina normalmente, estos
bloques con la imagen anterior no son utilizados. Por el contrario, si la transacción es anulada o termina
anormalmente, estos bloques serán utilizados para restituir el estado de la BD al momento anterior al
inicio de la transacción, llevándolos a memoria.
Toda base de datos contiene el segmento de Rollback System, y si existen varios tablespaces debe
existir al menos un segundo segmento de Rollback. Por defecto se crea un segmento de Rollback por cada
nuevo usuario. En el caso de varios segmentos de Rollback, es Oracle quien decide la distribución de los
bloques imagen anterior sobre estos segmentos y quien “dirige” las transacciones hacia los segmentos de
Rollback. El número de estos últimos puede tener influencia sobre el rendimiento de la BD.
Los segmentos de Rollback se gestionan con extensiones igual que los segmentos de datos: hay siempre
una extensión inicial y, eventualmente, otras extensiones en función de las necesidades. El mecanismo de
asignación de la extensiones es la siguiente: los bloques correspondientes a varias transacciones pueden
estar en una misma extensión. Cuando ésta se llena y la transacción tiene necesidad de más espacio,
Oracle busca si existe una extensión ya asignada pero libre (por ejemplo, no conteniendo bloques de
transacción). Si no la encuentra, asigna una nueva extensión.

4
 1.4. ELEMENTOS FÍSICOS DE UNA BD

De esta forma, se puede decir que el mecanismo de gestión de transacciones está contenido en los
segmentos de Rollback, tanto más cuanto que una extensión creada no será nunca devuelta a la BD
aunque esté vacı́a.
Cada extensión deberı́a ser lo suficientemente grande como para gestionar todos los datos de una
sola transacción. Si no es ası́, o si demasiados usuarios solicitan el mismo segmento de anulación, dicho
segmento de Rollback podrı́a ampliarse.
Los segmentos de Rollback se pueden contraer dinámicamente hasta un tamaño especı́fico, o pueden
ser contraı́dos manualmente hasta un tamaño de nuestra elección. La cláusula optimal permite que los
segmentos de Rollback se contraigan hasta un tamaño óptimo después de ampliarse.
Los segmentos de Rollback se almacenan en los Archivos Base, al igual que los datos de usuario. Sin
embargo, se suelen almacenar juntos todos los segmentos de Rollback para una BD determinada (excepto
el segmento de Rollback System que se encuentra en el archivo base asociado con el Tablespace System),
en un archivo base asociado con un Tablespace denominado habitualmente RBS.
Los comandos SQL relacionados son:

CREATE [PUBLIC] ROLLBACK SEGMENT nombre

TABLESPACE ts STORAGE param almacenamiento

donde:
PUBLIC indica si puede ser utilizado para todas las instancias de la BD (en otro caso solo podrá ser
utilizado por las instancias especificadas en INIT.ORA) en el parámetro ROLLBACK SEGMENTS.
TABLESPACE indica el tablespace donde será creado (por defecto en el tablespace SYSTEM)
STORAGE especifica el tamaño y número de extensiones. En este caso, no se permite establecer PCTIN-
CREASE.

ALTER [PUBLIC] ROLLBACK SEGMENT nombre

[STORAGE param almacenamiento] [OFFLINE]

permite modificar los parámetros de almacenamiento de un segmento de Rollback ya existente, o desac-

tivarlo.

DROP [PUBLIC] ROLLBACK SEGMENT nombre

borra el segmento de Rollback nombre. No puede estar en uso. Para ello es posible consultar el atributo
STATUS de la tabla del catálogo DBA ROLLBACK SEGS. Si el tablespace está ONLINE debe desactivarse
OFFLINE.

Segmentos Temporales: son utilizados por Oracle para las sentencias SQL que no pueden ser real-
izadas en memoria: la creación de ı́ndices, la ordenación y la combinación sin ı́ndices sobre tablas grandes
(CREATE INDEX, SELECT ORDER BY, DISTINCT, GROUP BY, UNION, INTERSECT, ...).
Estos segmentos son tomados del tablespace SYSTEM o de los tablespaces de usuario. La asignación de
extensiones se hace de la misma forma que para los segmentos de datos. Los parámetros de asignación son
los del tablespace donde se encuentre el segmento temporal. El segmento se amplı́a por sı́ mismo cuando
es preciso y se elimina cuando la operación concluye o encuentra un error. Las diferentes extensiones que
ha utilizado una operación son suprimidas y por tanto, devueltas a la BD.
Se deben mantener los objetos temporales en su propio tablespace. Haciéndolo ası́ se eliminan los
problemas de rendimiento asociados con la mezcla de segmentos temporales con otros objetos de la BD.

5
 1.4. ELEMENTOS FÍSICOS DE UNA BD

Segmentos Rollback Diferidos: son utilizados por Oracle para colocar los bloques imagen anterior
de un tablespace cuando éste está offline. Estos bloques serán recuperados cuando el tablespace sea puesto
de nuevo en servicio (online) y, por la misma razón, el espacio que ellos ocupaban será liberado.

Segmento de arranque (BOOTSTRAP): es un segmento de al menos 50 bloques, creado por Oracle

para sus propias necesidades durante la creación de la BD. Este segmento no crece durante toda la vida
de la BD.

1.4.2. Archivo Redo Log

Los archivos Redo Log son archivos fı́sicos que recogen las sucesivas modificaciones. Contienen los
cambios producidos en la BD y se utilizan para su restauración cuando hay un fallo. La restauración
consiste en la aplicación del contenido de los archivos Redo Log sobre la BD.
Un archivo Redo Log se va rellenando de modo circular y secuencial con registros, denominados reg-
istros Redo Log, que contienen los valores de las columnas (atributos) antes y después de la modificación.
Se necesitan un mı́nimo de 2 archivos Redo Log, por tanto. El proceso servidor encargado de su manejo
es LGWR (Log Writer).
El contenido del registro Redo Log es de la forma: No Transacción, Fecha/Hora, Estado (“en curso”,
“validada”, “anulada”), Dirección del Atributo (A.Base, Bloque, Lı́nea, Columna), Valor antes de la
modificación, Valor después de la modificación.
La utilización de los archivos Redo Log es circular. Cuando un archivo Redo Log está lleno, Oracle
escribe sobre el siguiente, y ası́ sucesivamente hasta el último archivo. Cuanto este último está lleno, se
retorna y reutiliza el primero, y ası́ sucesivamente.
Existen dos modos de trabajo: modo ArchiveLog o NoArchiveLog. Si la BD está en modo ArchiveLog
Oracle hace una copia de seguridad del archivo Redo Log antes de sobrescribirlo. En caso contrario,
Oracle los utiliza “machacando” su contenido sin previa copia de seguridad. Por defecto, toda BD está en
modo NoArchiveLog.
El modo Archive Log permite la recuperación para un instante determinado. El modo NoArchive Log
está diseñado para protección frente a fallos de instancia.

1.4.3. Archivo de control

Es un archivo fı́sico que recoge los cambios en la estructura de la BD. Contiene, esencialmente,
información sobre los archivos base, archivos Redo Log, fecha de creación de la BD, checkpoints sobre el
estado de coherencia de la BD, información sobre los tablespaces que contienen la BD, etc.
Toda BD debe tener al menos un archivo de control; los otros son únicamente una copia exacta del
primero y desempeñan un papel de seguridad. Todos los archivos de control son generados automática-
mente por Oracle y modificados al mismo tiempo.

1.4.4. Archivo de parámetros

Caracteriza a una instancia de la BD. No pueden ser modificados hasta parar la BD, hacer la modifi-
cación sobre el archivo INIT.ORA y volver a arrancarla.
Los parámetros pueden clasificarse en:

Parámetros de limitación: ponen lı́mites y cuotas a los usuarios de la BD. Cabe destacar:
OPEN CURSORS: número máximo de cursores (órdenes SQL) que puede abrir simultánea-
mente un proceso de usuario.
PROCESSES: número máximo de procesos trabajando simultáneamente sobre la BD (incluyen-
do los procesos background y el de conexión)
TRANSACTIONS: número máximo de transacciones concurrentes

6
 1.5. CREACIÓN / BORRADO DE UNA BD

Parámetros que nombran objetos, archivos y directorios

BACKGROUND DUMP TEST: ruta de los archivos de traza de los procesos background
USER DUM DEST: nombre del directorio que contendrá los archivos de traza de los procesos
de usuario
LOG ARCHIVE DEST: ruta de los archivos ARCHIVELOG
DB NAME: nombre interno de la BD
CONTROL FILES: nombre de los archivos de control y ruta
ROLLBACK SEGMENTS: nombre de los segmentos de Rollback asignados a la instancia. Si
es NULL, la BD utilizará los segmentos de Rollback públicos.
Parámetros de Definición de la SGA:
DB BLOCK BUFFERS: número de bloques para zona de datos y Rollback
DB BLOCK SIZE: tamaño en octetos de un bloque Oracle. No puede modificarse tras la
creación de la BD.
LOG BUFFER: tamaño en octetos de la zona de registro de redo Log.
Parámetros del entorno
AUDIT TRAIL: si es cierto Oracle traza las auditorı́as del DD
LOG ARCHIVE START: si es cierto Oracle archiva los archivos Redo llenos sobre un soporte
particular
TIMED STATISTICS: si es cierto, Oracle produce estadı́sticas del tiempo de ejecución de las
sentencias
SQL TRACE: si es cierto, Oracle realiza la traza del plan de ejecución de cada orden SQL

1.5. Creación / Borrado de una BD

1.5.1. Estados de una BD
Una BD puede estar en diferentes estados:

Activa: tiene una instancia asociada y, por lo tanto, una zona de memoria asociada. A su vez puede
estar en tres estados posibles:
No Montada (NOMOUNT): se utiliza para crear la BD o testear los parámetros de archivo de
configuración INIT.ORA
Montada y Cerrada (MOUNT + CLOSE): se utiliza para operaciones de mantenimiento (recu-
peración, adición/supresión de Archivos Redo Log, renombramiento de archivos o cambio de modo
ARCHIVE LOG a NOARCHIVELOG)
Montada y Abierta (MOUNT + OPEN): es el estado en producción
Parada: no es accesible a los usuarios. Para activarla hay que arrancarla (desde OEM con permisos
SYSDBA o SYSOPER, o implı́citamente tras la creación de la BD)

1.5.2. Sentencias SQL asociadas

Los comandos SQL relacionados son:
donde:
nombre indica el nombre de la BD. Su valor por defecto viene especificado en el parámetro DB NAME
de INIT.ORA.
fic Log1, fic Dat1 tienen el formato: nombre [SIZE entero [K|M]] [REUSE]

7
 1.6. ELEMENTOS LÓGICOS DE UNA BD

CREATE DATABASE nombre [CONTROLFILE REUSE]

[LOGFILE fic Log1 [, fic Log2]] [MAXLOGFILES entero]
[DATAFILE fic Dat1 [, fic Dat2]] [MAXDATAFILES entero]
[MAXINSTANCES entero] [ARCHIVE LOG | NOARCHIVELOG] [EXCLUSIVE]

CONTROLFILE REUSE indica que se deben reutilizar los ficheros de control especificados en el parámetro
CONTROL FILES de INIT.ORA.

LOGFILE nombre de los Archivos Redo Log

MAXLOGFILES número máximo de Archivos Redo Log que pueden crearse

DATAFILE nombre de los Archivos Base. Formarán parte del tablespace System

MAXDATAFILES número máximo de Archivos Base. Por defecto lo indicado en el parámetro DB FILES de
INIT.ORA

MAXINSTANCES número máximo de instancias que pueden montar la BD

EXCLUSIVE sólo puede acceder una instancia a la BD. Es la opción por defecto.

ALTER DATABASE nombre

[ADD LOGFILE fic Log1 [, fic Log2]] [DROP LOGFILE fic Log1 [, fic Log2] ...]
[RENAME FILE fichero1 [, fichero2] ... TO fichero3 [, fichero4] ...]
[ARCHIVE LOG | NOARCHIVELOG | MOUNT [EXCLUSIVE | SHARED] |
DISMOUNT | OPEN | CLOSE [NORMAL|INMEDIATE]]

donde:

RENAME FILE permite renombrar ficheros de la BD

MOUNT DISMOUNT indica si se cambia el estado de la BD a montado o desmontada

OPEN CLOSE indica si la BD debe estar abierta para un acceso normal o cerrada. El cierre puede ser
NORMAL (espera a que todos los usuarios se desconecten antes de parar los procesos de la instancia
y liberar la zona de memoria SGA) o INMEDIATE (deshace las transacciones en curso y desconecta
a los usuarios).

1.6. Elementos lógicos de una BD

1.6.1. Tablespace
Desde un punto de vista fı́sico, una BD es un conjunto de archivos junto al S.O. Un archivo puede
contener una parte de una tabla o de un ı́ndice, una o varias tablas, o uno o varios ı́ndices, ...
Un tablespace es una unidad lógica para la agrupación de tablas, ı́ndices, clusters, ..., relacionados.
Es la unidad más pequeña para operaciones de mantenimiento (supresión, puesta en activo (online) o no
(offline), copias de seguridad y restauración, entre otros).
Un tablespace tiene un nombre y consiste en uno o varios archivos. Una BD tiene al menos un
tablespace denominado System que es creado automáticamente por Oracle en el momento de la creación
de la BD y agrupa las tablas del DD y el segmento de Rollback System. Este tablespace no puede ser
suprimido, tampoco pueden suprimirse los archivos que lo constituyen. Se recomienda no utilizar este

8
 1.6. ELEMENTOS LÓGICOS DE UNA BD

tablespace para almacenar datos de usuario para evitar problamas de gestión del espacio, que obligarı́an a
reconstruir el tablespace. DAdo que la única forma de reconstruir el tablespace System consiste en volver
a crear la BD, debe desplazarse de SYSTEM todo aquello que se pueda.
Una tabla, un ı́ndice o un segmento de Rollback se encuentran en un, y sólo en un, tablespace. En el
momento de su creación es cuando el usuario decide en qué tablespace será depositado. Como ya se ha
mencionado, el usuario no puede elegir el archivo fı́sico donde se almacenará el objeto. El DBA puede
imponer un tablespace particular para los objetos de un usuario.
El DBA no puede suprimir un archivo de un tablespace si no ha suprimido antes el propio tablespace.
Por el contrario, este puede siempre “aumentar” un tablespace añadiendo en él un archivo fı́sico.

¿Por qué crear varios tablespaces?

Además del tablespace System, otros tablespaces habituales son:

Temp = agrupa los segmentos temporales

Tools = agrupa los objetos de los procesos cliente, como SQL Worksheet, DBA Studio, etc.

Users = agrupa los objetos de la BD que pertenecen a los usuarios

Indx = agrupa los ı́ndices del usuario. No conviene almacenar los segmentos de ı́ndice en el mismo
tablespace que las tablas a las que estén asociados, ya que registran un gran volumen de operaciones
de E/S concurrentes durante la manipulación de datos y las consultas.

Rbs = agrupa los segmentos de Rollback. Los segmentos de Rollback se amplı́an dinámicamente
hasta adquirir el tamaño de la transacción de mayor tamaño, y se contraen hasta adquirir un tamaño
óptimo especificado. Las operaciones de E/S que afectan a los segmentos de Rollback suelen ser
concurrentes con las operaciones de E/S que afectan a los tablespaces de datos de usuario e INDX.
Su separación ayuda a evitar la contienda de E/S y los hace más fáciles de administrar.

El DBA puede crear varios tablespaces para:

repartir los segmentos de datos y de trabajo sobre varios discos; esto permite evitar la contención
a nivel de disco y mejorar los tiempos de respuesta.

establecer cuotas de espacio de usuario

organizar los datos en unidades lógicas, cada una conteniendo los datos de una aplicación particular
o de un usuario particular; este es el contexto que determina la elección del modo de organización
de los datos.

facilitar las operaciones de salvaguardia y restauración. Por ejemplo para hacer una copia de se-
guridad de los datos de una aplicación solamente se hará del tablespace que la contiene

controlar la disponibilidad de los datos, puesto que un DBA no puede poner en activo o desactivar
una tabla directamente, es necesario que lo haga vı́a su tablespace.

generar el espacio que se asignará a los segmentos de datos y de trabajo, imponiendo los tablespaces
a los creadores de objetos y, eventualmente, unas cuotas de espacio en disco.

Comandos SQL asociados

Los comandos SQL asociados son:
donde:

fichero1, fichero2 son los ficheros de datos con el formato: nombre [SIZE entero [K|M]] [REUSE]

DEFAULT STORAGE param almacenamiento son los parámetros de almacenamiento por defecto para todos
los objetos creados en el tablespace.

9
 1.7. COMPONENTES DE UNA INSTANCIA ORACLE

CREATE TABLESPACE nombre

DATAFILE fichero1 [,fichero2]...
[DEFAULT STORAGE param almacenamiento] [ONLINE|OFFLINE]

ALTER TABLESPACE nombre

[ADD DATAFILE fichero1 [,fichero2]...]
[RENAME DATAFILE nombrefich3 [, nombrefich4] ... TO nuevo1 [, nuevo2] ...]
[DEFAULT STORAGE param almacenamiento ONLINE | OFFLINE
[NORMAL|INMEDIATE|FOR RECOVER|TEMPORARY]] [BEGIN|END BACKUP]

ONLINE|OFFLINE si el tablespace está accesible o no para los usuarios con permiso. Para conocer el estado
de los tablespaces puede consultarse el atributo STATUS de la vista del catálogo DBA TABLESPACES.
donde:

ONLINE indica que el tablespace se active

OFFLINE indica que el tablespace debe desconectarse: INMEDIATE inmediatamente, TEMPORARY tempo-
ralmente, NORMAL cuando ningún usuario esté accediendo a él, FOR RECOVER para propósitos de
recuperación
BEGIN BACKUP indica que se va a realizar una copia de seguridad
END BACKUP indica que se ha completado la copia de seguridad.

DROP TABLESPACE nombre [INCLUDING CONTENTS]

donde:

INCLUDING CONTENTS borra el tablespace y su contenido. Si no se pone esta cláusula el tablespace sólo
se borra si el tablespace no tiene contenido.

1.7. Componentes de una instancia Oracle

1.7.1. Zona de memoria
Cuando una BD Oracle está en actividad, utiliza cuatro tipos de zonas de memoria:
Zona de ejecutables: contiene el ejecutable del núcleo Oracle y de los instrumentos Oracle y
aplicaciones de los usuarios.
Zona SGA: almacena la información de una instancia Oracle. Tiene un tamaño fijo establecido en
el fichero INIT.ORA. Esta zona es liberada al parar la instancia.
El tamaño de la SGA puede influir en los tiempos de respuesta. Cuanto más grande es la SGA más
trabajará Oracle en memoria y menos accesos hará a disco.
La SGA contiene varios tipos de información:
la caché de datos: bloques de datos e ı́ndices de usuarios correspondiente a la imagen anterior
/ posterior de una modificación. Está formada, por tanto, por el buffer de datos y el buffer de

10
 1.7. COMPONENTES DE UNA INSTANCIA ORACLE

Rollback. El número de bloques que forman la caché de datos viene establecido en el parámetro
DB BLOCK BUFFER de INIT.ORA. El algoritmo empleado para su gestión es LRU (se eliminan
en primer lugar los bloques de menor uso).
la caché de DD: incluye un conjunto de bloques que almacenan una parte del diccionario de
datos en memoria para evitar un acceso sistemático al disco: es lo que se llama diccionario caché.
Entre la información almacenada en estos bloques se incluyen los datos de las cuentas de usuario,
los nombres de los archivos de datos , los nombres de los segmentos, la ubicación de las extensiones,
las descripciones de las tablas y los privilegios.
Esta memoria caché también se gestiona mediante un algoritmo LRU. La BD gestiona interna-
mente su tamaño. Esta memoria forma parte de la Zona de órdenes SQL, cuyo parámetro se define
mediante el parámetro SHARED POOL SIZE del archivo INIT.ORA de la BD.
el buffer de Log: es la memoria donde se almacenan los registros Redo Log antes de ser
llevados al archivo Redo Log. Su tamaño viene establecido en el parámetro LOG BUFFER de
INIT.ORA.
Zona de órdenes SQL: cada orden SQL (el texto de la sentencia SQL y la ruta de acceso
a los datos) se almacena en una zona de memoria denominada cursor. El tamaño del cursor y el
número de cursores por usuario pueden ser parametrizados por el DBA. Una buena utilización de
los cursores por las aplicaciones puede tener influencia sobre los tiempos de respuesta.

Zona PGA: zona utilizada por cada proceso (Oracle o de usuario) conectado a la BD. Contiene
información sobre el estado de cada proceso y su actividad (datos e información de control).

1.7.2. Procesos de servidor

Una instancia Oracle está compuesta por un conjunto de procesos background y los procesos de usuario
que solicitan información a los procesos background. Los procesos background relacionan las estructuras
fı́sicas y de memoria de la BD. Su número varı́a en función de la configuración de la BD. Son creados en
el arranque de una instancia y funcionan de una forma ası́ncrona, teniendo cada uno de ellos un cometido
muy especı́fico, como se muestra a continuación.

DBWR (Database Writer) Es el proceso encargado de la escritura en la BD. Escribe los bloques de
SGA a los Archivos Base.
Para cada sentencia de actualización (UPDATE, INSERT o DELETE) el DBWR copia los registros
originales en la parte del buffer de Rollback de la SGA y efectúa las modificaciones sobre los bloques de
la parte buffer de datos. A continuación escribe un registro en la parte del buffer de Log.
En caso de validación de una transacción (COMMIT), el DBWR libera el espacio de los registros
de la transacción en el buffer de Rollback. En caso de anulación de la transacción (ROLLBACK), estos
registros sustituyen a los correspondientes en el buffer de datos de modo que estos últimos recuperan su
estado inicial. En ambos casos, DBWR modifica el contenido de los registros en el buffer de Log.
El DBWR escribe únicamente en el archivo de disco los bloques menos utilizados. Una escritura es
disparada principalmente en los tres casos siguientes: cuando Oracle necesita espacio en la caché de datos,
tras haberse modificado un cierto número de bloques o a la salida de un punto de control (checkpoint).
En este último caso, el DBWR escribe sobre el disco todos los bloques modificados después de la última
escritura. Un punto de control es sistemáticamente disparado cuando el buffer de Log está lleno.
Es posible tener múltiples procesos DBWR ejecutándose a la vez, en función de la plataforma y del
SO. La utilización de varios procesos DBWR ayuda a minimizar la contienda dentro del DBWR durante
consultas de gran tamaño que afecten a varios archivos de datos. El número de esclvos DBWR de E/S
en ejecución se configura mediante el parámetro DBWR IO SLAVES del archivo INIT.ORA de la BD.

LGWR (Log Writer) Este proceso escribe secuencialmente en el Archivo Redo Log los registros Log
ubicados en la zona de buffer de Log. Estos registros corresponden a los datos modificados y garantizan
la posibilidad de restaurar la BD ante un fallo.

11
 1.7. COMPONENTES DE UNA INSTANCIA ORACLE

La escritura se produce cuando una transacción genera un COMMIT o cuando el buffer de Log
está lleno. En este último caso, LGWR escribe sobre el archivo Redo Log todos los registros Log que
contienen la transacción y su estado.
Es posible crear múltiples esclavos LGWR para mejorar el rendimiento de la escritura en los archivos
Redo Log. El número de esclavos LGWR de E/S en ejecución se configura mediante el parámetro
LGWR IO SLAVES del archivo INIT.ORA de la BD.

SMON (System Monitor) Este proceso tiene como tarea principal la restauración de la coherencia
de la BD durante su arranque. Al lanzamiento de la BD, el cometido del SMON consiste en verificar si
la parada fue normal la última vez; en este caso no tiene nada que hacer. En caso contrario, el SMON
restaura la BD recuperando desde el archivo Redo Log las modificaciones que han sido terminadas (por
un COMMIT o un ROLLBACK) y que Oracle no habı́a aún escrito en la BD antes de la parada anormal.
SMON cumple una segunda función: agrupa extensiones libres contiguas en extensiones de mayor
tamaño.

PMON (Process Monitor) El proceso monitor interviene cuando un proceso de usuario tiene un
problema o cuando éste termina anormalmente. Esta intervención consiste en liberar los recursos ocupados
por el proceso de usuario y suprimir este último de la lista de procesos de usuario de la instancia, además
de deshacer la transacción interrumpida.
Al igual que SMON, PMON se activa de forma periódica para comprobar si es necesaria su interven-
ción.

CKPT (Checkpoint) Los checkpoints ayudan a reducir la cantidad de tiempo necesario para realizar
la recuperación de las instancias. Hacen que DBWR escriba en los archivos de datos todos los bloques
que se hayan modificado desde el último checkpoint, y que actualice los archivos de control y las cabeceras
de los archivos de datos para registrar el checkpoint. Los checkpoints se producen de forma automática
cuando se llena el buffer de Log. Para configurar un checkpoint más frecuente, puede utilizarse el parámetro
LOG CHECKPOINT INTERVAL, especificado en el archivo INIT.ORA.
Para separar las dos funciones del proceso LGWR (señalar los checkpoints y copiar los registros de
Redo Log) entre dos procesos background, puede crearse un proceso background opcional, de tipo CKPT.
Este proceso se habilita definiendo como TRUE el parámetro CHECKPOINT PROCESSS del archivo
INIT.ORA. CKPT no es necesario a menos que la BD experimente un elevado volumen de transacciones,
que puede provocar retardos en las conmutaciones de registro.

ARCH (Archiver) Este proceso es opcional y sólo está activo cuando la BD está en modo ArchiveLog.
Cuando está activo, su misión consiste en archivar (copiar) cada uno de los archivos Redo Log lleno en
un dispositivo particular.
Una vez copiado un archivo Redo Log en el soporte de seguridad, éste puede ser reutilizado en escritura
para el proceso LGWR. Estas copias de seguridad podrán ser utilizadas para restaurar una BD cuando
ésta haya sido perdida.

1.7.3. Ejemplo
Ejemplo 1.7.1 Especifica los pasos del procesamiento en memoria que el proceso DBWR (Database
Writer) realiza como resultado de la instrucción de actualización:
update tabla1
set campo1 = 300
where campo2 = "valor"
indicando las zonas de memoria SGA que intervienen en cada paso
u
t
1. lleva los bloques donde se almacenan las tuplas de tabla1 afectadas por la consulta (aquellas cuyo
campo2 tenga “valor”) al buffer de datos de la zona SGA

12
 1.7. COMPONENTES DE UNA INSTANCIA ORACLE

2. realiza una copia de los bloques desde el buffer de datos al buffer de Rollback (ambos en la zona
SGA)
3. escribe un registro Log “PREPARE (comienzo de transacción)”. El registro Redo Log se crea y
almacena en el buffer de Log
4. modifica los datos en el buffer de datos
5. si COMMIT libera el buffer de Rollback

6. si ROLLBACK se copia el buffer de Rollback en el buffer de datos

7. escribe un registro Log “COMMIT” o “ABORT” en el buffer de Log

Se pueden crear varios esclavos ARCH de E/S, para mejorar el rendimiento de escritura en los archivos
Redo Log. El número de esclavos ARCH se define mediante el parámetro ARCH IO SLAVES del archivo
INIT.ORA de la BD.

13