MECANISMOS DE RECUPERACION EN

“ORACLE”
INTEGRANTE: CRISTIAN ARAYA G.
CURSO : INF_PC_502B
ASIGNATURA : BASE DE DATOS II
PROFESOR : MIGUEL OLGUIN C.
 ORACLE: BACKUP Y RECUPERACIÓN

Para conseguir un funcionamiento seguro de la BD y una pronta recuperación ante fallos se

necesita planear una estrategia de copias de seguridad, backup, y de recuperación, recovery,
ya que de nada sirve pensar que estamos a salvo de tales circunstancias, y que eso no me
puede pasar a mí. Y el primer paso a dar es definir las características fundamentales de la
implantación, porque mal vamos a conseguir unos objetivos si se desconocen o están
indefinidos. El segundo paso es establecer unos planes de copias de seguridad y
recuperación que nos permitan asegurar los objetivos.

INTRODUCCIÓN AL BACKUP Y A LA RECUPERACIÓN

Planear y comprobar los procedimientos de backup del sistema es la única garantía que
existe contra fallos del sistema, del SO, del software o cualquier otro tipo de circunstancias.

Las causas de error en una sistema de BD pueden agruparse en las siguientes categorías:
 Físicas : son causadas por fallos del hardware, como por ejemplo del disco o de la
CPU.
 de Diseño : son agujeros en el software, ya sea en el SO o en el SGBD.
 de Funcionamiento: son causadas por la intervención humana, debidos a fallos del
DBA, configuraciones inapropiadas o mal planteamiento de los procedimientos de
backup.
 del entorno: como por ejemplo desastres naturales, fallos de corriente, temperatura
excesiva.

De entre todas estas posibilidades, el DBA sólo puede influir y prever los errores de
funcionamiento, ya que el resto habitualmente no está dentro de sus responsabilidades y
capacidades.

Dada la complejidad de los sistemas actuales y las necesidades cada vez más críticas en la
disponibilidad de los sistemas, donde una BD caida puede causar pérdidas millonarias,
puede ser interesante considerar los mecanismos de protección hardware y de redundancia
que la tecnología nos proporciona:

 UPS o fuentes de corriente ininterrumpida,

 espejado de disco, o tecnología RAID,
 Componentes duplicados,
 Sistemas redundantes.

Una de las más importantes decisiones que un DBA debe tomar es decidir si arrancar la BD
en modo ARCHIVELOG o no. Esta decisión tiene sus ventajas e inconvenientes:
 Ventajas:
o Aunque se pierdan los ficheros de datos, siempre se puede recuperar la BD
con una copia antigua de los ficheros de datos y los ficheros de redo log
archivados.
o Es posible realizar backups en caliente.
 Inconvenientes:
o Se necesitará más espacio en disco.
o El trabajo del DBA se incrementa al tener que determinar el destino del
archivado de los redo log.
 PRESENTACIÓN DEL BACKUP

Los backups se pueden clasificar en físicos y lógicos. Los físicos se realizan cuando se
copian los ficheros que soportan la BD. Entre estos se encuentran los backups del SO, los
backups en frío y los backups en caliente.

Los backups lógicos sólo extraen los datos de las tablas utilizando comandos SQL y se
realizan con la utilidad export/import.

Backups del SO

Este tipo de backup es el más sencillo de ejecutar, aunque consume mucho tiempo y hace
inaccesible al sistema mientras se lleva a cabo. Aprovecha el backup del SO para almacenar
también todos los ficheros de la BD. Los pasos de este tipo de backup son los siguientes:
1. Parar la BD y el SO
2. Arrancar en modo superusuario.
3. Realizar copia de todos los ficheros del sistema de ficheros
4. Arrancar el sistema en modo normal y luego la BD.

Backups de la BD en Frio

Los backups en frio implican parar la BD en modo normal y copiar todos los ficheros sobre
los que se asienta. Antes de parar la BD hay que parar también todos las aplicaciones que
estén trabajando con la BD. Una vez realizada la copia de los ficheros, la BD se puede
volver a arrancar.

Backups de la BD en Caliente

El backup en caliente se realiza mientras la BD está abierta y funcionando en modo

ARCHIVELOG. Habrá que tener cuidado de realizarlo cuando la carga de la BD sea pequeña.
Este tipo de backup consiste en copiar todos los ficheros correspondientes a un tablespace
determinado, los ficheros redo log archivados y los ficheros de control. Esto para cada
tablespace de la BD.

Backups Lógicos con Export/Import

Estas utilidades permiten al DBA hacer copias de determinados objetos de la BD, así como
restaurarlos o moverlos de una BD a otra. Estas herramientas utilizan comandos del SQL
para obtener el contenido de los objetos y escribirlos en/leerlos de ficheros

Una vez que se ha planeado una estrategia de backup y se ha probado, conviene

automatizarla para facilitar así su cumplimiento.

PRESENTACIÓN DE LA RECUPERACIÓN
Oracle proporciona diferentes modos de recuperar un fallo en la BD, y es importante que el
DBA conozca como funciona cada uno de ellos para determinar cuándo ha de ser utilizado.

Una de las mayores responsabilidades del DBA consiste en tener la BD a punto, y

prepararla ante la posibilidad de que se produzca un fallo. Así, ante un fallo el DBA podrá
recuperar la BD en el menor tiempo posible. Los procesos de recuperación dependen del
tipo de error y de las estructuras afectadas.

Así, los tipos de error que se pueden producir son:

Errores de Usuario

Como por ejemplo un usuario borrando una fila o eliminando una tabla. Estos errores se
solucionan importando una tabla de una copia lógica anterior. Si no se dispone de la copia
lógica, se puede recuperar la BD en una instancia auxiliar, exportar la tabla en cuestión de
la instancia auxiliar e importarla en la instancia operativa.

Fallos de Sentencias

Se definen como la imposibilidad del SGBD Oracle de ejecutar alguna sentencia SQL. Un
ejemplo de esto se produce cuando se intenta una selección de una tabla que no existe.
Estos fallos se recuperan automáticamente mediante un rollback de la transacción que
contenía la sentencia fallida. El usuario necesitará volver a ejecutar otra vez la transacción
cuando se haya solucionado la causa del problema.

Fallos de Procesos

Es una terminación anormal de un proceso. Si el proceso era un proceso de usuario, del

servidor o de una aplicación el PMON efectuará la recuperación del proceso. Si el proceso
era alguno de los de background, la instancia debe de ser parada y arrancada de nuevo,
proceso durante el cual se recupera la caida efectuando un roll forward y un rollback de las
transacciones no confirmadas.

Fallos de la Red

Algunas veces los fallos en la red producen fallos de proceso, que son tratados por el
PMON. Si en el error de red se ve envuelta una transacción distribuida, una vez que se
reestablece la conexión, el proceso RECO resuelve los conflictos automáticamente.

Fallos de Instancia

Pueden deberse a fallos físicos o de diseño del software que hacen que algún proceso
background caiga y la instancia con él. La recuperación es automática cuando se levanta la
BD, tomandose más o menos tiempo en la recuperación.

Fallos del Sistema

Son los fallos más peligrosos, no sólo porque se pueden perder datos, sino porque se tarda
más tiempo en recuperar que los otros fallos. Además se depende mucho de la experiencia
del DBA para levantar la BD rápidamente y sin pédida (o casi) de datos.

MECANISMOS DE RECUPERACION EN “ORACLE”

Existen tres tipos de recuperación en Oracle: a nivel de bloque, de thread y física.

Recuperación de bloques

Es el mecanismo de recuperación más simple, y se realiza automáticamente. Se produce

cuando un proceso muere justo cuando está cambiando un bloque, y se utilizan los registros
redo log en línea para reconstruir el bloque y escribirlo en disco.

Recuperación de threads

Se realiza automáticamente cuando Oracle descubre que una instancia muere dejando
abierto un thread, entonces se restauran los bloques de datos modificados que estaban en el
cache de la instancia muerta, y cerrando el thread que estaba abierto. La recuperación se
efectua automáticamento cuando la BD se levanta.

Recuperación física

Se realiza como respuesta a un comando RECOVER. Se utiliza para convertir los ficheros de
backup en actuales, o para restaurar los cambios que fueron perdidos cuando un fichero de
datos fue puesto offline sin un checkpoint, aplicando los fichero redo log archivados y en
línea.
PRINCIPIOS DE LA RECUPERACIÓN

Para entender los principios de la recuperación, se necesita entender las estructuras de datos
subyacentes utilizadas en la recuperación.

DEFINICIONES Y CONCEPTOS

Los ficheros redo log contienen los cambios realizados sobre la BD. Conviene presentar
algunos conceptos relacionados con ellos.
Vector de Cambio
describe un cambio simple en un bloque de datos de la BD. Entre otros datos,
contiene el número de versión, el código de la transacción, y la dirección del bloque
afectado.
Registro Redo log
es un conjunto de vectores de cambio que describen un cambio atómico sobre la
BD. La transacción es también la unidad de recuperación.

Evolución de Redo log por día

 se puede calcular ejecutando el comando archive log list en dos días
consecutivos y calculando la diferencia del número de secuencia de los ficheros
redo log, multiplicado por el tamaño de un fichero redo log:

SVRMGR> archive log list;

Database log mode No Archive Mode
Automatic archival Disabled
Archive destination /opt/app/oracle/admin/demo/arch/arch.log
Oldest online log sequence 3
Current log sequence 5

System Change Number, SCN

es un dato que define la versión confirmada de la BD en este instante de tiempo.
Cuando una transacción es confirmada, se le asigna un SCN que la identifica
unívocamente. Los ficheros redo log son marcados con dos SCN. Cuando se abre
un nuevo fichero redo log se le marca con un SCN, low SCN, que es uno mas que el
SCN mayor del anterior fichero redo log; y su high SCN es puesto a infinito. Los
SCN también se asocian al fichero de control, ya que cuando se para una BD, un
tablespace o fichero de datos, se almacena para cada fichero de datos su stop SCN
en el fichero de control.

Cambio de redo log

es el proceso mediante el cual se deja de utilizar un fichero redo log y el LGWR
combia al siguiente fichero redo log disponible. Se puede hacer con el comando
alter system switch logfile;.

Checkpoints
son activados automáticamente durante el funcionamiento normal de la instancia,
pero pueden ser activados manualmente con el comando alter system
checkpoint local o alter system checkpoint global dependiendo si nos
referimos a la instancia en la que estamos, o si queremos que afecte a todas las
instancias activas, respectivamente. Cada checkpoint lleva implicito un SCN, y
Oracle asegura que todos los cámbios con un SCN menor que el del checkpoint
dado han sido escritos en el disco.
 MÉTODOS DE RECUPERACIÓN

Existen varios métodos de recuperación, pero todos ellos se basan en la aplicación de los
registros de redo log.

Aplicación de Redo Log

Cuando una BD se arranca con el comando startup, la BD pasa por los estados nomount,
mount y open. En este tercer estado, se verifica que se pueden abrir todos los ficheros de
log y de datos. Si la BD se arranca por primera vez después de una caida, se necesitará
efectuar una recuperación que consiste en dos pasos: avanzar la BD hacia adelante
aplicando los registros redo log, deshacer las transacciones no confirmadas.

Cada fichero de datos tiene en su cabecera el último checkpoint efectuado, así como el
fichero de control también lleva esa cuenta. El checkpoint lleva incluido el SCN. Este es
conocido como SCN de inicio de fichero. Asociado a cada fichero de datos el fichero de
control tiene el SCN de final, puesto inicialmente a infinito. El SCN de inicio se incrementa
con cada checkpoint.

Cuando la BD se para en modo normal o inmediato iguala el SCN de parada para cada
fichero de datos al SCN almacenado en cada fichero de datos. Cuando se abre otra vez la
BD se realizan dos comprobaciones. La primera es mirar si el contador de checkpoints en la
cabecera de los ficheros de datos coincide con el correspondiente del fichero de control. Si
es así, se compara el SCN de inicio de cada fichero de datos con el SCN de final
almacenado en el fichero de control. Si son iguales no se necesita recuperación en este
fichero de datos. Como parte de la apertura se pone a infinito el SCN de final para ese
fichero de datos.

Si la BD se paró con en modo abort no se ejecutó el checkpoint y el SCN de fin para los
fichero de datos está a infinito. Así, durante la BD se abre, y suponiendo que el contador de
checkpoints coincide, se comparan los SCN de inicio y de final, y como el último es infinito
se efectura una recuperación aplicando los cambios almacenados en los ficheros redo log
en línea para avanzar la BD, y los registros de roll back de los segmentos de roll back para
deshacer las transacciones no confirmadas.

Si después de parar la BD se reemplaza un fichero de datos por su copia de seguridad, al

arrancar la BD Oracle detecta que el contador de checkpoints del fichero de datos no
coincide con el almacenado en el fichero de control. Así, se tendrá que echar mano a los
ficheros redo log archivados, empezando por aquel cuyo número de secuencia aparece en la
cabecera del fichero de datos.

RECUPERACIÓN FÍSICA
La utilización de una copia de backup de ficheros de datos siempre necesita de una
recuperación física. También es así cuando un fichero de datos se pone offline sin un
checkpoint.

Oracle detecta que se necesita una recuperación física cuando el contador de checkpoints de
la cabecera del fichero de datos no coincide con el correspondiente contador de checkpoints
del fichero de control. Entonces se hace necesario el comando recover. La recuperación
comienza en el SCN menor de los ficheros de datos en recuperación, aplicando los registros
de redo log a partir de él, y parando en el SCN de final mayor de todos los ficheros de
datos.

Existen tres opciones para realizar una recuperacion física. La primera es una recuperación
de BD donde se restaura la BD entera. La segunda es una recuperación de tablespace
donde, mientras una parte de la BD está abierta, se puede recuperar un tablespace
determinado. Esto significa que serán recuperados todos los ficheros de datos asociados al
tablespace. El tercer tipo es la recuperación de un fichero de datos específico mientras el
resto de la BD está abierta.

Requisitos para Utilizar Recuperación Física

La primera condición que se ha de poner para poder recuperar físicamente una BD es que
ésta se esté utilizando en modo ARCHIVELOG. De otro modo, una recuperación completa
puede que no sea posible. Si trabajamos con la BD en modo NOARCHIVELOG, y se hace una
copia semanal de los ficheros de la BD, se debería estar preparado para perder, en el peor
de los casos, el trabajo de la última semana si sucede un fallo. Ya que los ficheros de redo
log contendrían un agujero y no se podia avanzar la BD hasta el intante anterior al fallo. En
este caso el único medio para reconstruir la BD es hacerlo desde un export completo,
recreando el esquema de la BD e importando todos los datos.

Recuperación de la BD

La BD debe estar montada pero no abierta. El comando de recuperación es el siguiente:

RECOVER [AUTOMATIC] [FROM 'localizacion'] [BD]

[UNTIL CANCEL]
[UNTIL TIME fecha]
[UNTIL CHANGE entero]
[USING BACKUP CONTROLFILE]

Recuperación de un tablespace

La BD debe estar abierta, pero con el tablespace a recuperar offline. El comando de

recuperación es el siguiente:
RECOVER [AUTOMATIC] [FROM 'localizacion']
TABLESPACE nombre_tablespace [, nombre_tablespace]

Recuperación de un Fichero de Datos

La BD debe estar abierta o cerrada, dependiendo del fichero a recuperar. Si el fichero a

recuperar es de un tablespace de usuario la BD puede estar abierta, pero con el fichero a
recuperar offline. Si el fichero es del tablespace SYSTEM la BD debe estar cerrada, ya que no
puede estar abierta con los ficheros del SYSTEM offline. El comando de recuperación es el
siguiente:

RECOVER [AUTOMATIC] [FROM 'localizacion']

DATAFILE nombre_fichero [, nombre_fichero]

Aquí se nombraron algunos tipos de recuperacion mas usados en el motor de base de datos
oracle en el cual se da como una idea como se pueden recuperar los datos, tablas, registros,
e incluso bases de datos completas aquí se muestra lo cuan presente y esencial estan los
mecanismos de recuperación si no existieran estas acciones se podrian perder millones y
millones de pesos y datos para una empresa seria muy lamentable tambien debemos
mencionar los mecanismos de recuperación lógica en el cual tambien dispone de
herramientas muy esenciales a la hora de recuperar o restaurar los datos de una BD esto
parte de los parametros del import en el cual se ejecutan sentencias que se almacenan
creando las tablas y llenandolas de datos, con esto se concluye el trabajo en el cual se deben
tener muy en claro los conceptos de recuperación para poder entender bien lo que se decea
y se quiere hacer dentro de una base de datos.
 INACAP
AREA INFORMATICA
SEDE CONCEPCIÓN – TALCAHUANO

Estructura física de las tablas

CARRERA : Ingeniería de gestión en informática

ASIGNATURA : Base de Datos II
PROFESOR : Miguel Olguin Cavieres
ALUMNO : Daniel Adrián Peña Ormeño

TALCAHUANO - CHILE
2004
 ÍNDICE

1. Espacio de tablas............................................................................1
2.- Gestión de Espacio........................................................................1
3. - Poniendo los tablespaces offline..................................................1
4.- Poniendo los ficheros offline........................................................1
5.- El Tablespace System..................................................................1
6.- Manipulando Tablespaces............................................................1
7.- Crear un Tablespace......................................................................1
8.- Aumentar de tamaño un Tablespace.............................................1
9. -Borrando un tablespace.................................................................1

1
 INTRODUCCIÓN

Una base de datos está formada por una o varias unidades lógicas
llamadas tablespaces. Además, cada una de estos tablespaces está formado por
uno o varios ficheros físicos que son los datafiles. Un datafile solamente puede
pertenecer a un tablespace. Por lo tanto, los datafiles de una base de datos son
todos los datafiles que forman parte de todos los tablespaces de la base.

Cuando se crea una base de datos, hay que crear al menos un tablespace,
por lo que durante el proceso de creación de la base de datos siempre se indica el
tablespace principal de ésta, que se llama SYSTEM.

De igual manera, cuando se crea un tablespace que, como hemos dicho, es

una unidad lógica, se debe indicar obligatoriamente también el nombre de al
menos un datafile que formará parte de ese tablespace. El datafile es un fichero
físico al que le tendremos que asignar un directorio, un nombre y un tamaño.

2
1. Espacio de tablas

Los espacios de tablas se utilizan para realizar tareas de gestión de

espacio, controlar la disponibilidad de los datos y ejecutar copias de seguridad y
recuperaciones parciales.

2.- Gestión de Espacio

El primer espacio de tablas es el SYSTEM. Este espacio de tablas debe estar

disponible siempre durante el funcionamiento normal de la BD porque contiene el
diccionario de datos. Después de la creación de la BD, se recomienda la creación
de otros espacios de tablas para que los datos de los usuarios puedan ser
separados de los del diccionario de datos. Incluso, si varias aplicaciones se van a
ejecutar sobre la misma BD es recomendable que sus datos estén separados.
Para crear un espacio de tablas se puede utilizar el comando create tablespace:

SVRMGR> create tablespace nombre_tablespace

2> datafile 'nombre_fichero' size 50M online;

En el ejemplo anterior se ha creado un espacio de tablas de 50 Mb. de

tamaño. Cada espacio de tabla tiene un conjunto de parámetros de
almacenamiento que controla su crecimiento:

 initial: tamaño de la extensión inicial (10k).

 next: tamaño de la siguiente extensión a asignar (10k).
 minextents: número de extensiones asignadas en el momento de la
creación del espacio de tablas (1).
 maxextents: número máximo de extensiones.
 pctincrease: Porcentaje en el que crecerá la siguiente extensión antes de
que se asigne, en relación con la última extensión utilizada.
 optimal: Tamaño óptimo declarado para este espacio de tablas.
 pctused: porcentaje de utilización del bloque por debajo del cual Oracle
considera que un bloque puede ser utilizado para insertar filas nuevas en él.

Si el espacio de tablas necesita más espacio después de su creación se

puede alterar para añadir uno o más ficheros. Para ello se puede utilizar el
comando alter tablespace:

SVRMGR> alter tablespace nombre_tablespace

2> add datafile 'nombre_fichero' size 30M;

3
 Si se necesitara variar la localización de los ficheros asociados a un espacio
de tablas se puede hacer con los comandos alter tablespace (el espacio de tablas
debe estar offline) o alter database (la BD debe estar montada pero no abierta).
Antes de ejecutar los anteriores comandos los ficheros asociados al espacio de
tablas deben de haber sido movidos a su nueva localización utilizando los
comandos del SO oportunos.

3. - Poniendo los tablespaces offline

Llevar a un espacio de tablas al estado offline significa que se impide el

acceso a los datos que almacena. El espacio de tablas SYSTEM nunca puede estar
offline. Las razones para poner un espacio de tablas offline pueden ser varias: un
error de escritura en los ficheros que lo soportan, el mover los ficheros de sitio,
etc. Después de realizar estas operaciones hay que poner otra vez disponible el
espacio de tablas, esto es on line

Los espacios de tablas se pueden poner offline de tres modos: normal,

temporary e immediate. Si no existe ningún error lo recomendable es poner el
espacio de tablas offline usando el modo normal. Así, se colocará un checkpoint
en el espacio de tablas antes de ponerlo offline.

SVRMGR> alter tablespace nombre_tablespace offline normal;

Si alguno de los ficheros está corrupto, la opción normal fallará y se

necesitará el modo temporary. La opción immediate se utilizará sólo cuando la BD
está en modo ARCHIVELOG, ya que no se produce checkpoint alguno.

4.- Poniendo los ficheros offline

No es normal poner los ficheros offline/online. Si un determinado fichero de

datos se corrompe, se tendrá que pone offline, repararlo y ponerlo online de
nuevo. Esta operación puede suponer sustituirlo por su copia de seguridad, lo que
implicará ejecutar el comando recover datafile antes de poner el fichero online.

4
5.- El Tablespace System

Cuando se crea una base de datos es obligatorio crear un tablespace inicial

en el que se van a crear los usuarios SYS y SYSTEM automáticamente. Estos
usuarios son los que tienen la información necesaria para que funcione nuestra
base de datos y podamos hacer todo tipo de operaciones como, por ejemplo, crear
nuevos usuarios o crear nuevos tablespaces y tablas en esos nuevos tablespaces.

Este tablespace inicial se llama por defecto SYSTEM. Es una pieza clave
para un buen funcionamiento de la base de datos ya que en él residen todos los
objetos de los usuarios SYS y SYSTEM.

Es muy recomendable crear al menos otro tablespace nuevo distinto al

SYSTEM. Así, todos los nuevos usuarios que creemos en nuestra base de datos,
junto con todas sus tablas e índices se almacenarán en un tablespace diferente a
SYSTEM. Se realiza esta separación para evitar que se bloquee toda la base de
datos si ocurre algo grave en el tablespace SYSTEM. Suele ser habitual que para
nuestras aplicaciones creemos usuarios y tablas en las que introducimos
información y que sin darnos cuenta se llene de información el tablespace en el
que están estas tablas. Si no hemos sido previsores, podemos haber llenado el
tablespace SYSTEM con lo que es posible que se paralice toda la base de datos.

6.- Manipulando Tablespaces

Ahora que nos hemos hecho una idea acerca de qué es un tablespace,
vamos a realizar sobre él las manipulaciones básicas.

Partimos de una base de datos creada y levantada. Nos conectaremos a la

misma con el usuario SYSTEM y su contraseña. La contraseña del usuario
SYSTEM al crear la base de datos es, por defecto, MANAGER. Como medida de
seguridad se recomienda cambiarla cuanto antes. Por lo tanto nos conectaremos
bien al SqlPlus mediante sqlplus system/manager, o bien al server manager mediante
el comando svrmgrl system/manager.

7.- Crear un Tablespace.

En primer lugar vamos a crear un tablespace llamado Prueba. Esto lo

podemos hacer por ejemplo desde el SQLPLUS conectados como system.

Create tablespace prueba datafile '/users/oradata/orcl/prueba01.dbf' size 100M;

5
 Con esta sentencia estamos creando en nuestra base de datos un
tablespace nuevo llamado "prueba" y que está formado físicamente por un fichero
(datafile) llamado prueba01.dbf de 100 Mbytes y que está en el directorio
"/users/oradata/orcl". Esta sentencia crea físicamente dicho fichero.

8.- Aumentar de tamaño un Tablespace.

Para aumentar el tamaño de un tablespace que se nos ha quedado ya

pequeño, tenemos varias posibilidades. La primera de ellas es crear un nuevo
datafile y asignárselo al tablespace que queremos aumentar. Esto lo podemos
hacer con la instrucción siguiente.

Alter tablespace prueba add datafile '/users/oradata/orcl/prueba02.dbf' size 50M;

Con esta sentencia hemos creado un nuevo fichero físico en nuestro

directorio /users/oradata/orcl de 50 Mbytes de tamaño y se lo hemos asignado al
tablespace "prueba".

Otra posibilidad es ampliar el tamaño de uno de los ficheros físicos o

datafiles que forman el tablespace. Esto lo podemos hacer fácilmente con la
siguiente instrucción:

Alter datafile '/users/oradata/orcl/prueba01.dbf' resize 150M;

Con esta sentencia lo que hacemos es aumentar el datafile que forma parte
de nuestro tablespace en 50 Mbytes.

Tanto en la instrucción de creción como en la de aumentar el tamaño de un

tablespace se puede observar fácilmente cómo un datafile pertenece solamente a
un tablespace ya que en la propia sentencia se crea el fichero físico o datafile.

9. -Borrando un tablespace.

Para eliminar un tablespace de la base de datos se debe utilizar la

sentencia:

Drop tablespace prueba;

6
Nombre: Félix Rivera

7
 El diccionario de datos de Oracle es una estructura de tablas y vistas, de
sólo lectura, que contiene información de la base de datos, tal como:

 las definiciones de todos los esquemas en la BD (tablas, índices,

vistas, clusters, sinónimos, secuencias, procedimientos, funciones,
paquetes, triggers, etc)
 el espacio asignado y actualmente ocupado por un esquema
 los usuarios de la base de datos
 los privilegios y roles que cada usuario tiene
 información sobre quienes han accesado y actualizado esquemas
 información general de la base de datos

EL diccionario de datos es creado cuando la base de datos es creada.

Para reflejar con exactitud el estado de la BD en todo momento, el
diccionario de datos es automáticamente actualizado por Oracle en
respuesta a acciones específicas (tales como cuando la estructura de la
BD es modificada). La importancia del diccionario de datos radica en que
Oracle cuenta con éste para operar la base de datos.

PL/SQL DEVELOPER

PL/SQL Developer es un ambiente integrado de desarrollo que está

específicamente enfocado al desarrollo de programas de unidades de
almacenamiento para Databases Oracle. A través del tiempo hemos visto mas y
mas negocios lógicos y aplicaciones lógicas trasladarse al Oracle Server, por lo
cual la programación PL/SQL ha empezado a ser parte importante del proceso de
desarrollo. PL/SQL Developer se ha centrado en la facilidad de uso, calidad de
código y productividad, claves durante el desarrollo de la aplicación Oracle.

PRINCIPALES CARACTERISTICAS

 Poderoso Editor PL/SQL. Con su sintaxis destacada, SQL y PL/SQL help,

Descripción de objetos y muchas otras sofisticadas características, el editor
impresiona a los mas exigentes usuarios.
 Depurador (debugger) integrado. Ofrece todas las opciones que pueda
desear: Step In, Step Over, Step Out, etc.
 Query Builder. Esta herramienta gráfica hace fácil crear nuevas expresiones
o modificar las existentes.
 PL/SQL Beautifier. Le permite formatear el código a través de unas reglas
definidas por el usuario.
 SQL Window. Le permite ingresar cualquier expresión SQL y ver y editar los
resultados fácilmente.
 Command Window. Para desarrollar y ejecutar scripts sin tener que dejar el
confortable PL/SQL Developer IDE.

8
 Reportes. Le permite usar facilmente reportes standard o reportes creados
por usted mismo.
 Proyectos. PL/SQL le permite organizar los items de proyectos que usted
necesite, compilarlos, moverlos de un proyecto a otro.
 Browser de objetos. Este elemento configurable, de tres vistas, muestra
toda la información que es relevante.
 Optimización de rendimiento. Para optimizar el rendimiento de su código
usted puede usar el PL/SQL Profiler.

Tablas base
Estas tablas que almacenan información acerca de la base de datos.
Sólo Oracle debe escribir y leer esas tablas. Los usuarios rara vez
accedan a ellas directamente porque no están normalizadas y la
mayoría de los datos están encriptados.

Vistas accesibles por el usuario

Estas vistas resumen la información almacenada en las tablas base del
diccionario de datos.

Todas las tablas y vistas del diccionario de datos son almacenadas en el

tablespace SYSTEM.
El usuario SYS es el propietario de todas las tablas base y las vistas
accesibles por el usuario del diccionario de datos.

Principalmente se usa de tres maneras:

 Oracle accesa el diccionario de datos para hallar la información

acerca de los usuarios, esquemas y estructuras almacenadas.
 Oracle modifica el diccionario de datos cada vez que una instrucción
DDL es usada.
 Cualquier usuario puede usar el diccionario de datos

9
 TRABAJO DE INVESTIGACION

ADMINISTRACIÓN DE ORACLE

10
 POR: Job Llanos.
INDICE TEMATICO

INDICE TEMATICO.............................................................................................................2
INTRODUCCIÓN..................................................................................................................3
Roles y Responsabilidades del DBA de Oracle............................................................................................4
Tareas básicas del DBA................................................................................................................................4
Tareas adicionales del DBA.........................................................................................................................5
La Base de Datos.............................................................................................................................................5
Los Tablespaces y los Datafiles...................................................................................................................5
Segmentos, Extensiones y Bloques..............................................................................................................6
El Esquema de la base de datos....................................................................................................................7
Arquitectura de Oracle..................................................................................................................................8
El Área Global del Sistema (SGA)................................................................................................................8
Procesos de la Instancia.................................................................................................................................9
El Área Global de Programas (PGA).........................................................................................................10
Tablespaces y Datafiles................................................................................................................................10
Manipulación de Datafiles..........................................................................................................................10
Los segmentos de Rollback..........................................................................................................................11
Estados de un segmento de Rollback.........................................................................................................12
Los archivos “Redo Log”...............................................................................................................................13

INTRODUCCIÓN

Este trabajo está dirigido a la Administración de Oracle y que se topan por primera vez con
la necesidad de efectuar una administración básica de la base de datos, movidos por el afán
de personalizarla según los requerimientos del proyecto al que se vean enfrentados.
Considerando en las áreas físicas y lógicas para una buena administración.

11
 Roles y Responsabilidades del DBA de Oracle
El administrador de la base de datos de una empresa es siempre considerado como la
persona con más experiencia en el área de bases de datos. Por lo anterior, es conveniente
tener muy claras las expectativas que se generan en torno a su trabajo y cuáles son los
principales roles que debe asumir dentro del marco corporativo o de un proyecto.

Tareas básicas del DBA

Instalación de nuevos componentes del software

Una de las tareas principales del DBA consiste en la instalación periódica de nuevas actualizaciones de
software de Oracle, tanto en lo referente a programas de aplicaciones como a herramientas administrativas.
También es recomendable que el propio DBA y otros usuarios de Oracle prueben la instalación y nuevas
configuraciones antes de migrarlas a los ambientes de producción.

Interacción con el administrador del sistema

En la mayoría de los casos los programas sólo pueden ser instalados o accedidos por el administrador del
sistema. En este caso, el DBA debe trabajar siempre muy bien coordinado con él para garantizar que tanto la
instalación y configuración de software como de hardware permita un adecuado funcionamiento del motor de
base de datos y de las aplicaciones.

Garantizar la seguridad del sistema

El DBA debe siempre monitorear y administrar la seguridad del sistema. Esto involucra la incorporación y
eliminación de usuarios, administración de espacios de disco (cuotas), auditorias y una revisión periódica para
detectar probables problemas de seguridad.

Monitorización
El DBA debe monitorear continuamente el rendimiento del sistema y estar preparado para efectuar ajustes de
sintonización de éste. En ciertas oportunidades esto involucra cambiar sólo algunos parámetros y otras veces
reconstruir índices o reestructurar tablas.

Respaldos
Debido a que la tarea más importante del DBA es proteger la integridad de los datos, se deberá desarrollar una
estrategia efectiva de respaldos y recuperación de datos para mantener la estabilidad de toda la información
guardada. Las frecuencias de estos respaldos deberán decidirse dependiendo de la cantidad de procesos que
alteran los datos a través del tiempo.

Prevención de riesgos
Otra tarea del DBA es la de calenda rizar mantenciones a las bases de datos (archivos lógicos) o cooperar en
el mantenimiento de las máquinas al administrador del sistema. El DBA debe fortalecer sus esfuerzos en
orden a eliminar problemas o situaciones potencialmente peligrosas.

Tareas adicionales del DBA

Otras tareas de importancia que corresponden con frecuencia realizar a un DBA son:
- Analizar datos y efectuar recomendaciones concernientes a mejorar el rendimiento y la eficiencia en
el manejo de aquellos datos que se encuentran almacenados.
- Apoyar en el diseño y optimización de modelos de datos.
- Asistir a los desarrolladores con sus conocimientos de SQL y de construcción de procedimientos
almacenados y triggers, entre otros.
- Apoyar en la definición de estándares de diseño y nomenclatura de objetos.

12
 - Documentar y mantener un registro periódico de las mantenciones, actualizaciones de hardware y
software, cambios en las aplicaciones y, en general, todos aquellos eventos relacionados con cambios
en el entorno de utilización de una base de datos.
La Base de Datos
La base de datos de Oracle tiene una capa lógica y otra física. La capa física consiste de
archivos que residen en el disco y los componentes de la capa lógica son estructuras que
mapean los datos hacia estos componentes físicos.

Los Tablespaces y los Datafiles

Como se mencionó, una base de datos se encuentra dividida en una o más piezas lógicas
llamadas tablespaces, que son utilizados para separar la información en grupos y así
simplificar la administración de los datos. Los tablespaces pueden ocupar uno o más
datafiles. Si se decide que utilice varios datafiles, el administrador del sistema puede
gestionar que éstos queden localizados en discos diferentes, lo que aumentará el
rendimiento del sistema, principalmente por la mejora en la distribución de la carga de
entrada / salida.

En la figura siguiente se aprecia la diferencia entre estos tres conceptos. Una base de datos
de ejemplo contiene tres tablespaces lógicos (parte superior de la figura) que utiliza para
almacenar información del sistema, de los datos del usuario y de los índices de las tablas.
Asimismo, existen los espacios físicos (datafiles) que guardan esta información en los
diferentes discos disponibles y que se señalan en la parte inferior del dibujo.

13
 Figura No. 1 Relación entre la base de datos, los tablespaces y los datafiles

Segmentos, Extensiones y Bloques

Dentro de los tablespaces y datafiles, el espacio utilizado para almacenar datos es

controlado por el uso de ciertas estructuras; éstas son las siguientes:

Bloques: Un bloque es la unidad de almacenamiento más pequeña en una base de datos

Oracle. Contiene una pequeña porción de información (header) referente al
bloque en sí y el resto a los datos que guarda. Generalmente, un bloque de
datos ocupará aprox. 2 KB de espacio físico en el disco (asignación típica.
Extensiones: Es un grupo de bloques de datos. Se establecen en un tamaño fijo y crecen a
medida que van almacenando más datos. También se pueden redimensionar
para aprovechar mejor el espacio de almacenamiento.
Segmentos: Es un grupo de extensiones utilizados para almacenar un tipo particular de
datos. Existen 4 tipos de segmentos: datos, índices, rollback y temporales.

14
 Figura No. 2 Relación entre bloques, extensiones y segmentos

El Esquema de la base de datos

Un esquema es una colección de objetos lógicos, utilizados para organizar de manera más
comprensible la información y conocidos como objetos del esquema. Una breve
descripción de los objetos que lo componen es la siguiente:

Tabla: Es la unidad lógica básica de almacenamiento. Contiene filas y columnas

(como una matriz) y se identifica por un nombre. Las columnas también
tienen un nombre y deben especificar un tipo de datos. Una tabla se guarda
dentro de un tablespace (o varios, en el caso de las tablas particionadas).
Cluster: Un cluster es un grupo de tablas almacenadas en conjunto físicamente como
una sola tabla que comparten una columna en común. Si a menudo se necesita
recuperar datos de dos o más tablas basado en un valor de la columna que
tienen en común, entonces es más eficiente organizarlas como un cluster, ya
que la información podrá ser recuperada en una menor cantidad de
operaciones de lectura realizadas sobre el disco.
Indice: Un índice es una estructura creada para ayudar a recuperar datos de una
manera más rápida y eficiente. Un índice se crea sobre una o varias columnas
de una misma tabla. De esta manera, cuando se solicita recuperar datos de ella
mediante alguna condición de búsqueda (cláusula where de la sentencia), ésta
se puede acelerar si se dispone de algún índice sobre las columnas-objetivo.
Vista: Una vista implementa una selección de varias columnas de una o diferentes
tablas. Una vista no almacena datos; sólo los presenta en forma dinámica. Se

15
 utilizan para simplificar la visión del usuario sobre un conjunto de tablas,
haciendo transparente para él la forma de obtención de los datos.
Proced. Almacenado: Son programas que permiten independizar el manejo de datos desde
una aplicación y efectuarla directamente desde el motor de base de datos,
disminuyendo así el tráfico de información a través de la red y mejorando el
rendimiento de los procesos implementados mediante estos programas.
Trigger: Un trigger es un procedimiento que se ejecuta en forma inmediata cuando
ocurre un evento especial. Estos eventos sólo pueden ser la inserción,
actualización o eliminación de datos de una tabla.
Secuencias: El generador de secuencias de Oracle se utiliza para generar números únicos
y utilizarlos, por ejemplo, como claves de tablas. La principal ventaja es que libera al
programador de obtener números secuenciales que no se repitan con los que pueda generar
otro usuario en un instante determinado.

Arquitectura de Oracle

Figura No. 3 Vista general de la Arquitectura de Oracle

La Arquitectura general de Oracle consiste de varios procesos corriendo en la máquina

donde reside la instancia, más los espacios de memoria dedicados a ejecutar procesos
específicos o al almacenaje de información de cada proceso y la base de datos física
propiamente tal, con sus archivos de control, de datos y de transacciones.

16
 El Área Global del Sistema (SGA)
El SGA es un área de memoria compartida que se utiliza para almacenar información de
control y de datos de la instancia. Se crea cuando la instancia es levantada y se borra
cuando ésta se deja de usar (cuando se hace shutdown). La información que se almacena en
esta área consiste 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 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 á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.
- 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.
- 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.

17
 Procesos de la Instancia
Los procesos que se implementan en una instancia de Oracle y su función principal
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.
LGWR (log writer): Es el responsable de escribir información desde el buffer de log
hacia el archivo redo log.
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.
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.

El Área Global de Programas (PGA)

Esta área de memoria contiene datos e información de control para los procesos que se
ejecutan en el servidor de Oracle (relacionados con la base de datos, por supuesto. El
tamaño y contenido de la PGA depende de las opciones del servidor que se hayan instalado.

AREAS LOGICAS Y ARCHIVOS FISICOS

18
 Tablespaces y Datafiles
Ya hemos dicho que un tablespace es una unidad lógica que denota el espacio de
almacenamiento de datos dentro de una base de datos y que están constituidos por uno o
más datafiles, que son los archivos físicos que ocupan efectivamente el espacio en el disco
duro. Cuando se crea una base de datos, hay que crear al menos un tablespace, por lo que
durante el proceso de creación de ésta siempre se indica el tablespace principal, de nombre
SYSTEM. Su correspondiente datafile será entonces el fichero físico al que habrá que
asignar una ruta, un nombre y un tamaño.
Los usuarios con características de DBA que se generan automáticamente al crear una
instancia son SYS y SYSTEM. Es a partir del trabajo de ellos que la base de datos
comienza a crecer y es posible configurar nuevos usuarios, otras áreas de datos
(tablespaces) e implementar en forma física un modelo de datos en algún esquema.
No es recomendable crear nuevos usuarios o procesos que compartan el tablespace del
sistema, por lo que una de las primeras tareas del DBA consiste en crear nuevos esquemas
(cuentas de usuario) y asignarles tablespaces diferentes (que también se deberán crear).

Manipulación de Datafiles

Mediante el manejo de los archivos físicos de una base de datos (datafiles) podemos
redimensionar los tablespaces, permitiendo la asignación de más espacio.
Para aumentar el tamaño de un tablespace se puede optar por alguno de estos dos caminos,
representados por las instrucciones que permiten implementar la medida:
Agregar un datafile (por ejemplo, al tablespace datos_prueba):
alter tablespace datos_prueba add datafile ‘c:\oracle81\oradata\mkt\tb_mkt02.dbf’ size
50M;
O aumentar el tamaño de un datafile ya existente:
alter datafile ‘c:\oracle81\oradata\mkt\tb_mkt01.dbf’ resize 150M;

La primera instrucción indica que se va a crear un nuevo datafile para el tablespace que se
ha quedado pequeño, aumentando su capacidad en 50 megabytes.

19
En el segundo ejemplo, no se menciona el tablespace porque lo que se hace es
redimensionar un datafile, cuyo nombre es único en la ruta mencionada y que Oracle ya
conoce que está asociado a algún tablespace (datos_prueba en el ejemplo). Su tamaño se
debe escribir de nuevo, por lo que realmente no se han añadido 150 megabytes como dice
la instrucción, sino sólo 50, porque ya tenía 100 megabytes al inicio.
Los segmentos de Rollback
Los segmentos de rollback son áreas lógicas de la base de datos que contienen información
de las transacciones que se encuentran en curso y que aún no han sido confirmadas o
deshechas. Recuerde que todas las transacciones deben confirmarse en la base de datos en
algún momento, con la instrucción COMMIT de SQL. Asimismo, se puede deshacer un
grupo de transacciones completamente (mientras no se haya hecho el commit) mediante la
instrucción ROLLBACK.
Mientras las transacciones se ejecutan, los cambios se van almacenando en estos segmentos
de rollback para disponer de ellos en la eventualidad que haya que deshacerlos. Estos
segmentos se utilizan en forma concurrente por una o más transacciones. Es labor del DBA
el ajustar sus parámetros adecuadamente para proveer un uso eficiente del espacio que
utilizan.
Siendo un área que almacena datos, ocupa también extensiones, que son grupos lógicos de
bloques de datos. Cada una de estas extensiones va almacenando la información de las
transacciones pendientes de confirmarse y va liberando espacio a medida que éstas se van
confirmando. Cada vez que una extensión se completa se busca más espacio y se toma otra
extensión. Este algoritmo de búsqueda de extensiones va a verificar siempre que la primera
se haya desocupado (verificando que las transacciones que almacena ya se han confirmado)
y volverá a utilizarla. Por lo anterior se debe pensar en un segmento de rollback como un
buffer circular, ya que intenta utilizar siempre las mismas extensiones de datos.

20
 Figura No. 4 Extensiones en un segmento de rollback

Estados de un segmento de Rollback

Un segmento de rollback puede encontrarse en cualesquiera de los siguientes estados:

- OFFLINE: No ha sido asociado a ninguna instancia de la base de datos.

- ONLINE: Ha sido adquirido por alguna de las instancias y puede contener datos de
transacciones activas.
- NEEDS RECOVERY: Contiene datos de transacciones que no pueden hacer
rollback porque alguno de sus datafiles se encuentra inaccesible o corrupto.
- PARTLY AVAILABLE: Contiene información de una transacción “en duda” que
son transacciones en entornos de base de datos distribuidas de las que aún no se ha
recibido respuesta.
- INVALID: El segmento ha sido borrado.

Para cambiar el estado de un segmento de rollback se debe ejecutar una instrucción cuya sintaxis es
como sigue:
ALTER ROLLBACK SEGMENT nombre_segmento estado;

Para conocer qué segmentos de rollback existen en todos los tablespaces y el estado en que
se encuentran, podemos ejecutar la siguiente sentencia:

SELECT segment_name, tablespace_name, status FROM dba_rollback_segs;

Que ciertamente, por los objetos a los que accede, sólo podrá ejecutar un DBA.

21
 Esto es particularmente importante si se desea poner algún tablespace en estado
offline, ya que en primer lugar deberían encontrarse también offline todos los segmentos de
rollback que contiene.
Los archivos “Redo Log”
Los archivos de “deshacer” se utilizan para almacenar la información de todas las
transacciones que se llevan a cabo en la base de datos. De esta manera, se cuenta con un
registro fiable de las operaciones que se han llevado a cabo para poder reconstruirlas en un
eventual proceso de recuperación de la base de datos, si se hubiera producido una falla.
Una base de datos usualmente mantiene dos o más archivos de redo log, los que van
guardando todas las transacciones que se van efectuando. De hecho, la instrucción
COMMIT no se completa mientras no se efectúa la escritura en esos archivos.

Figura No. 5 Mecanismo de escritura en los archivos redo log

Para establecer el tamaño apropiado de un archivo de este tipo deberá considerarse el

tamaño del dispositivo que contendrá el respaldo del redo log, es decir, si se va a almacenar
en una cinta de 525 MB, entonces el tamaño de un archivo de este tipo no debiera superar
los 520 MB.

GLOSARIO DE TERMINOS

22
 La siguiente es una lista de los términos más utilizados cuando se trabaja con bases de datos Oracle.
Las definiciones ayudarán a comprender con mayor claridad algunos conceptos que se mencionan a lo
largo de los diferentes capítulos de este manual.
Administrador de Base de Datos
El administrador o DBA es el principal responsable de la operación, configuración y rendimiento de
una base de datos. Su principal tarea consiste en resguardar la integridad de los datos almacenados en
la base, proveyendo para esto mecanismos de respaldo, efectuando monitorizaciones periódicas al
sistema, implementando medidas de seguridad, etc.
Bloque
Un bloque es la unidad más pequeña de almacenamiento en una base de datos Oracle. El tamaño
mínimo es de 2 KB y el máximo no debiera superar los 16 KB.
Buffer
Este término se refiere a una cantidad de memoria utilizada para almacenar información.
Un buffer comúnmente almacena datos que están a punto de ser usados o se acaban de
utilizar recientemente. En la mayoría de los casos son copias exactas de datos que se
encuentran almacenados en el disco y se mantienen en memoria con el fin de lograr un
acceso más rápido y ayudar de esa manera a mejorar el rendimiento de un sistema.
En Oracle, los buffers del SGA almacenan los bloques de datos usados más recientemente.
El conjunto de buffers que guardan estos bloques reciben el nombre de database buffer
cache; y aquellos que se utilizan para guardar temporalmente las entradas del tipo redo log
hasta que se escriben en el disco, se conocen como redo log buffers.
Caché
Es un área de almacenamiento implementada en la memoria RAM del computador que
permite accesos más rápidos a la información ya que es mucho más veloz que la memoria.
En Oracle, los buffers de bloques y el área shared pool son consideradas áreas caché. Estas
guardan los datos que se utilizan con mayor frecuencia y los mantienen disponibles por si
son requeridos en los procesos de consulta hasta que nuevos datos más frecuentemente
usados los reemplazan.
Checkpoint
Un checkpoint es una operación que fuerza a que todos los cambios registrados en bloques
de datos en memoria, sean escritos en el disco.

Clean buffer

23
Un buffer de este tipo es aquel que no ha sido modificado y que por lo tanto el proceso
DBWR no utilizará para confirmar los cambios en el disco (porque no ha sufrido cambios).
Concurrencia
Este término se refiere a la capacidad de permitir muchas funciones al mismo tiempo.
Oracle provee a muchos usuarios el acceso simultáneo a sus servicios, implementando de
esta forma la concurrencia.
Memoria Virtual
Indica la memoria que puede ser utilizada por programas que corren en un sistema operativo y que
está implementada físicamente en sectores del disco y no en la RAM. El proceso de copiar datos de la
RAM al disco (o memoria virtual) se llama paginación (paging, en inglés). El archivo resultante es
llamado el “swap file” y cada vez que un programa accede a esta memoria virtual disminuye el
rendimiento del mismo debido a que realmente está accediendo al disco y no a la RAM.

24
_________________________________________________________________________

NOMBRE : JOSÉ CIFUENTES.

ASIGNATURA : B. DATOS II
PROFESOR : SR. MIGUEL OLGUÍN.
_________________________________________________________________________

INTRODUCCIÓN

Este Informe, tiene por finalidad, dar a conocer en forma resumida, todas aquellas
consideraciones que debe tomar un DBA en la Implementación de una base de
datos, tanto en su estructura física cómo lógica, también veremos cuál es la
diferencia entre ellas y el por qué es tan necesario dedicar tanto esfuerzo en esta
etapa.

Creación de una base de datos

Diseñar una base de datos y definir sus propiedades y características de

implementación (lógicas y físicas) pensando en los sistemas que harán uso de ella
es una tarea muy compleja. Todo el esfuerzo que se debe invertir en esta etapa
tendrá como resultado que su administración se haga más fácil o más compleja en
el futuro.

Una base de datos se comienza creando los archivos de redo log, los archivos de
control y el tablespace de sistema (de nombre System). Este último almacena una
estructura muy importante que es el diccionario de datos (data dictionary) que es
el área que contiene toda la información de los data files, los esquemas y el resto
de información relevante de la base de datos.

Al igual que en el caso de las instancias, es mucho más cómodo utilizar alguna de
las herramientas gráficas. En la secuencia de creación de una base de datos se
deberá ingresar una gran cantidad de información de configuración, tal como:

 Nombre, SID, password de la cuenta interna

 Ruta del archivo de inicialización (initxxx.ora; donde xxx corresponde al
SID)
 Ruta de los archivos de control y tamaño de sus data files
 Datos de tamaño de data files para los tablespaces de usuarios, de sistema
y temporal, entre otros
 Tamaño de los archivos redo log
 etc.

AREAS LOGICAS Y ARCHIVOS FISICOS

Tablespaces y Data files

Ya hemos dicho que un tablespace es una unidad lógica que denota el espacio de
almacenamiento de datos dentro de una base de datos y que están constituidos
por uno o más data files, que son los archivos físicos que ocupan efectivamente el
espacio en el disco duro. Cuando se crea una base de datos, hay que crear al
menos un tablespace, por lo que durante el proceso de creación de ésta siempre
se indica el tablespace principal, de nombre SYSTEM. Su correspondiente data
_________________________________________________________________________
file será entonces el fichero físico al que habrá que asignar una ruta, un nombre y
un tamaño.

Los usuarios con características de DBA que se generan automáticamente al crear

una instancia son SYS y SYSTEM. Es a partir del trabajo de ellos que la base de
datos comienza a crecer y es posible configurar nuevos usuarios, otras áreas de

Datos (tablespaces) e implementar en forma física un modelo de datos en algún

esquema.

No es recomendable crear nuevos usuarios o procesos que compartan el

tablespace del sistema, por lo que una de las primeras tareas del DBA consiste en
crear nuevos esquemas (cuentas de usuario) y asignarles tablespaces diferentes
(que también se deberán crear).

Ficheros de la Base de Datos

•Los datos se almacenan en uno o más ficheros físicos situados en uno o varios
discos.
•Cada fichero sólo puede estar asociado a una BD.
•Oracle crea un espacio físico del tamaño que elija el DBA y luego lo va rellenando
con datos.
Espacios de Tabla (Tablespaces)
•Unidades lógicas de almacenamiento en las que se divide una BD.
•Un espacio de tabla puede estar almacenado en varios ficheros físicos; para
Oracle son una única unidad.
•Sirven para racionalizar la información. Mejora de funcionamiento.

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

(Ficheros del Sistema Operativo)

(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 fichero 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 el 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.
(Son conceptos de Almacenamiento a Nivel de Base de Datos)

TABLESPACES: Unidades lógicas que agrupan los archivos base

ESQUEMAS: Objetos de la BD (tablas, ´ındices, vistas, clusters, triggers, etc.)

Elementos lógicos de una BD

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.

El tablespace sirve para almacenar datos de usuario para evitar problemas 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 que

Tablespace será depositado. Como ya se ha mencionado, el usuario no puede

elegir el archivo físico donde se almacenaría 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 el un

archivo físico.
________________________________________________________________________
_
I n a c a p
Concepción - Talcahuano

Alumno : José M. Luengo S.

Profesor: Miguel Olguin
Curso : InfPc502B
Ramo : Base de Datos II
________________________________________________________________________
_

Introducción

Todo el mundo puede conducir un automóvil sin necesidad de conocer cómo funciona un
motor de combustión interna y todos los subsistemas asociados a él. Pero entonces ciertos
conceptos como aprovechamiento de la potencia, compresión, endurecimiento de la
suspensión, motricidad, etc., le serán ajenos y nunca podrá sacar lo mejor del automóvil.
Y si tiene algún problema se quedará tirado en la carretera.

De la misma manera, no podremos aspirar a que nuestras aplicaciones de BD funcionen

bien si no conocemos la arquitectura del motor de la BD, el servidor. Es indispensable
conocer los factores y parámetros que influyen en el funcionamiento de nuestro SGBD
para poder solucionar los problemas que se pueden plantear en cuanto nos salgamos de
las aplicaciones estándares y básicas de BD, o en cuanto tengamos algún problema.

Estructuras de Proceso

El servidor se vale de una serie de procesos que son el enlace entre las estructuras físicas
y de memoria. A continuación se describen cada proceso y el papel que juega en la
gestión de la BD. Todo esto se puede ver en la siguiente figura.
________________________________________________________________________
_

System Monitor, SMON

El SMON es el supervisor del sistema y se encarga de todas las recuperaciones

que sean necesarias durante el arranque. Esto puede ser necesario si la BD se paró
inesperadamente por fallo físico, lógico u otras causas. Este proceso realiza la
recuperación de la instancia de BD a partir de los ficheros redo log. Además
limpia los segmentos temporales no utilizados y compacta los huecos libres
contiguos en los ficheros de datos. Este proceso se despierta regularmente para
comprobar si debe intervenir.

Process Monitor, PMON

Este proceso restaura las transacciones no validadas de los procesos de usuario

que abortan, liberando los bloqueos y los recursos de la SGA. Asume la identidad
del usuario que ha fallado, liberando todos los recursos de la BD que estuviera
utilizando, y anula la transacción cancelada. Este proceso se despierta
regularmente para comprobar si su intervención es necesaria.
________________________________________________________________________
_
Database Writer, DBWR

El proceso DBWR es el responsable de gestionar el contenido de los buffers de

datos y del caché del diccionario. Él lee los bloques de los ficheros de datos y los
almacena en la SGA. Luego escribe en los ficheros de datos los bloques cuyo
contenido ha variado. La escritura de los bloques a disco es diferida buscando
mejorar la eficiencia de la E/S.

Es el único proceso que puede escribir en la BD. Esto asegura la integridad. Se

encarga de escribir los bloques de datos modificados por las transacciones,
tomando la información del buffer de la BD cuando se valida una transacción.
Cada validación no se lleva a la BD física de manera inmediata sino que los
bloques de la BD modificados se vuelcan a los ficheros de datos periodicamente o
cuando sucede algún checkpoint o punto de sincronizaión: grabación diferida:

o Los bloques del buffer de la BD (bloques del segmento de rollback y

bloques de datos) menos recientemente utilizados son volcados en el disco
continuamente para dejar sitio a los nuevos bloques.
o El bloque del segmento de rollback se escribe SIEMPRE antes que el
correspondiente bloque de datos.
o Múltiples transacciones pueden solapar los cambios en un sólo bloque
antes de escribirlo en el disco.

Mientras, para que se mantenga la integridad y coherencia de la BD, todas las

operaciones se guardan en los ficheros de redo log. El proceso de escritura es
asíncrono y puede realizar grabaciones multibloque para aumentar la velocidad.

Log Writer, LGWR

El proceso LGWR es el encargado de escribir los registros redo log en los

ficheros redo log. Los registros redo log siempre contienen el estado más reciente
de la BD, ya que puede que el DBWR deba esperar para escribir los bloques
modificados desde el buffer de datos a los ficheros de datos.

Conviene tener en cuenta que el LGWR es el único proceso que escribe en los
ficheros de redo log y el único que lee directamente los buffers de redo log
durante el funcionamiento normal de la BD.

Coloca la información de los redo log buffers en los ficheros de redo log. Los
redo log buffers almacenan una copia de las transacciones que se llevan a cabo en
la BD. Esto se produce:

o a cada validación de transacción, y antes de que se comunique al proceso

que todo ha ido bien,
o cuando se llena el grupo de buffers de redo log
o cuando el DBWR escribe buffers de datos modificados en disco.
________________________________________________________________________
_
Así, aunque los ficheros de DB no se actualicen en ese instante con los buffers de
BD, la operación queda guardada y se puede reproducir. Oracle no tiene que
consumir sus recursos escribiendo el resultado de las modificaciones de los datos
en los archivos de datos de manera inmediata. Esto se hace porque los registros de
redo log casi siempre tendrán un tamaño menor que los bloques afectados por las
modificaciones de una transacción, y por lo tanto el tiempo que emplea en
guardarlos es menor que el que emplearía en almacenar los bloques sucios
resultado de una transacción; que ya serán trasladados a los ficheros por el
DBWR. El LGWR es un proceso único, para asegurar la integridad. Es asíncrono.
Además permite las grabaciones multibloque.

Checkpoint, CKPT

Este proceso escribe en los ficheros de control los checkpoints. Estos puntos de
sincronización son referencias al estado coherente de todos los ficheros de la BD
en un instante determinado, en un punto de sincronización. Esto significa que los
bloques sucios de la BD se vuelcan a los ficheros de BD, asegurándose de que
todos los bloques de datos modificados desde el último checkpoint se escriben
realmente en los ficheros de datos y no sólo en los ficheros redo log; y que los
ficheros de redo log también almacenan los registros de redo log hasta este
instante. La secuencia de puntos de control se almacena en los ficheros de datos,
redo log y control. Los checkpoints se produce cuando:

o un espacio de tabla se pone inactivo, offline,

o se llena el fichero de redo log activo,
o se para la BD,
o el número de bloques escritos en el redo log desde el último checkpoint
alcanza el límite definido en el parámetro LOG_CHECKPOINT_INTERVAL,
o cuando transcurra el número de segundos indicado por el parámetro
LOG_CHECKPOINT_TIMEOUT desde el último checkpoint.

Está activo si el parámetro CHECKPOINT_PROCESS tiene un valor verdadero.

Archiver, ARCH

El proceso archivador tiene que ver con los ficheros redo log. Por defecto, estos
ficheros se reutilizan de manera cíclica de modo que se van perdiendo los
registros redo log que tienen una cierta antigüedad. Cuando la BD se ejecuta en
modo ARCHIVELOG, antes de reutilizar un fichero redo log realiza una copia del
mismo. De esta manera se mantiene una copia de todos los registros redo log por
si fueran necesarios para una recuperación. Este es el trabajo del proceso
archivador.
________________________________________________________________________
_
Recoverer, RECO

El proceso de recuperación está asociado al servidor distribuido. En un servidor

distribuido los datos se encuentran repartidos en varias localizaciones físicas, y
estas se han de mantener sincronizadas. Cuando una transacción distribuida se
lleva a cabo puede que problemas en la red de comunicación haga que una de las
localizaciones no aplique las modificaciones debidas. Esta transacción dudosa
debe ser resuelta de algún modo, y esa es la tarea del proceso recuperador. Está
activo si el parámetro DISTRIBUTED_TRANSACTIONS tiene un valor distinto de 0.

Lock, LCK

El proceso de bloqueo está asociado al servidor en paralelo.

INSTITUTO INACAP
AREA INFORMATICA
TALCAHANO

TEMA DE INVESTIGACIÓN:

DICCIONARIO DE DATOS EN ORACLE

CARRERA : Ingeniería en Gestión Informática

ASIGNATURA : Base de Datos II
DOCENTE : Sr. Miguel Olguín
CURSO : Inf Pc 502-B
INTEGRANTES : Sr. Juan Pablo Mellado

TALCAHUANO – CHILE
2004
 I.- INTRODUCCIÓN

El Diccionario de Datos es central para cada Base de Datos, además es una

herramienta importante para todos los usuarios, desde usuarios finales, a desarrolladores
de aplicaciones y administradores.

Todos los usuarios se pueden beneficiar de conocer y utilizar las tablas de

diccionario.

Los usuarios no deben nunca modificar las tablas del Diccionario de Datos
(update, delete, insert) ni otros objetos de diccionario, ya que puede peligrar la integridad
de los datos.

II.- DEFINICIÓN DE DICCIONARIO DE DATOS

El diccionario de datos de Oracle es una estructura de tablas y vistas, de

sólo lectura, que contiene información de la base de datos, tal como:
 las definiciones de todos los esquemas en la BD (tablas, índices, vistas,
clusters, sinónimos, secuencias, procedimientos, funciones, paquetes,
triggers, etc);
 el espacio asignado y actualmente ocupado por un esquema;
 los usuarios de la base de datos;
 los privilegios y roles que cada usuario tiene;
 información sobre quienes han accesado y actualizado esquemas;
 información general de la base de datos.

EL diccionario de datos es creado cuando la base de datos es creada. Para

reflejar con exactitud el estado de la BD en todo momento, el diccionario de datos es
automáticamente actualizado por Oracle en respuesta a acciones específicas (tales
como cuando la estructura de la BD es modificada). La importancia del diccionario de
datos radica en que Oracle cuenta con éste para operar la base de datos.

III.- ESTRUCTURA DEL DICCIONARIO DE DATOS

Tablas base:
Estas tablas almacenan información acerca de la base de datos. Sólo Oracle
debe escribir y leer esas tablas. Los usuarios rara vez accesan a ellas
directamente porque no están normalizadas y la mayoría de los datos están
encriptados.
Vistas accesibles por el usuario:
Estas vistas resumen la información almacenada en las tablas base del
diccionario de datos.
 Todas las tablas y vistas del diccionario de datos son almacenadas en el
tablespace SYSTEM.

El usuario SYS es el propietario de todas las tablas base y las vistas accesibles
por el usuario del diccionario de datos.

IV.- USO DEL DICCIONARIO DE DATOS

Principalmente se usa de tres maneras:

 Oracle accesa el diccionario de datos para hallar la información acerca de los
usuarios, esquemas y estructuras almacenadas.
 Oracle modifica el diccionario de datos cada vez que una instrucción DDL es
usada.
 Cualquier usuario Oracle puede utilizar el Diccionario de Datos como una
referencia de solo-lectura para informarse acerca de la Base de Datos.

V.- BIBLIOGRAFIA

 Apuntes Auditoría y Seguridad en Base de Datos. Enfoque Práctico

con Oracle 8i. Autor: Juan Coy Vergara.
 Apuntes de Administración de Bases de Datos Oracle 9i.
 I. INTRODUCCION A PL/SQL

¿QUE ES PL/SQL?

PL/SQL es una abreviatura de "Procedural Language/SQL". Es un lenguaje que

extiende SQL mediante la incorporación a SQL de construcciones que se
encuentran en los lenguajes procedurales, tales como:

 Variables y tipos
 Estructuras de control
 Procedimientos y funciones

A través de PL/SQL podemos emplear las estructuras de SQL para manipular

datos en ORACLE, y estructuras de flujo para procesar los datos.

Además podemos declarar variables y constantes, definir subprogramas

(procedimientos y funciones) y atrapar los errores de ejecución.

Esto es, PL/SQL combina el poder de la manipulación de datos de SQL con el

poder de procesamiento de datos de un lenguaje procedural.

[DECLARE

-- Declaraciones

BEGIN

-- Estructuras

[EXCEPTION

-- Manejadores de excepciones ]

END;

Tipos de datos en PL/SQL

Cada constante y variable tien un tipo de dato en el cual se especifica el

formato de almacenamiento, restricciones y rango de valores validos.

PL/SQL proporciona una variedad predefinida de tipos de datos ESCALARES y

COMPUESTOS.

COMPUESTOS: Contienen componentes internos que pueden se manipulados

en forma individual.

Casi todos los tipos de datos manejados por PL/SQL son similares a los
soportados por SQL.
A continuación se muestran los TIPOS de DATOS más comunes:

 NUMBER (Numúrico): Almacena números enteros o de punto flotante,

virtualmente de cualquier longitud, aunque puede ser especificada la
precisión (Número de digitos) y la escala que es la que determina
cuando se llevará a cabo el redondeo.

NUMBER [(precision, escala)]

 CHAR (Caracter): Almacena datos de tipo caracter con una longitud

maxima de 32767 y cuyo valor de longitud por default es 1

CHAR [(longitud_maxima)]

 VARCHAR2 (Caracter de longitud variable): Almacena datos de tipo

caracter empleando sólo la cantidad necesaria aun cuando la
longitud máxima sea mayor.

VARCHAR2 (longitud_maxima)

 BOOLEAN (lógico): Se emplea para almacenar valores TRUE o FALSE

pero no de tipo NULL.
 DATE (Fecha): Almacena datos de tipo fecha en el rango de ENERO 1
de 4712 A.C. a Diciembre 31 de 4712 D.C.

Interacción con Oracle

Podemos manipular los datos almacenados de una manera flexible y segura

porque PL/SQL soporta todos los comandos de manipulacion de datos , control
de transacciones, funciones y operadores manejados por SQL.

Sin embargo PL/SQL no soporta comandos de definicion de datos tales como

CREATE, o comandos de control del sistema tal como ALTER SYSTEM.

Para la manipulación de los datos pueden ser empleadas las operaciones

siguientes:

 INSERT
 UPDATE
 DELETE
 SELECT
 LOCK TABLE
TRIGGERS

Un database TRIGGER es una unidad de programa en PL/SQL almacenado en

la base de datos asociado con una tabla especifica de la base de datos

ORACLE ejecuta el TRIGGER de la la base de datos cuando la tabla asociada

con este es afectada por una operacion SQL, es decir los TRIGGERS son
ejecutados de manera implicita.

Pueden ser asociados un maximo de 12 TRIGGERS con una tabla de la base

de datos.

Los TRIGGERS pueden ser empleados para :

 Verificar la modificacion de datos en una tabla

 Transparencia de algun evento
 Derivacion de valores en columnas de manera automatica
 Implementacion de Sistemas de seguridad Complejos
 Mantenimiento General de las Tablas

Ejemplo de un TRIGGER
CREATE TRIGGER checa_salario

BEFORE INSERT OR UPDATE sal, trabajo ON PRUEBA

FOR EACH ROW

WHEN (new.job != 'PRESIDENT');

DECLARE

minsal NUMBER;

maxsal NUMBER;

BEGIN

SELECT losal, hisal, INTO minsal, maxsal FROM SALS;

IF (:new.sal < minsal OR :new.sal > maxsal) THEN

raise_aplication_error(-20225,'Salario fuera de
Rango');

END IF;
END;
Excepciones

Dentro de PL/SQL una condicion de advertencia o de Error es llamada una

Excepcion , dichas Excepciones pueden ser definidas de manera interna o por
el usuario
Dentro de ORACLE, cada error tiene un numero, pero los excepciones deben
ser manejadas por nombre. A continuacion se listan las excepciones internas
definidas dentro del paquete estandar:

 CURSOR_ALREADY_OPEN  NO_DATA_FOUND
 NOT_LOGGED_ON
 DUP_VAL_ON_INDEX  PROGRAM_ERROR
 INVALID_CURSOR  STORAGE_ERROR
 INVALID_NUMBER  TOO_MANY_ROWS
 LOGIN_DENIED  VALUE_ERROR
 ZERO_DIVIDE

Este es un ejemplo de como manejar las excepciones

create or replace procedure bajas (nombre in varchar2) is
n prueba.sueldo%TYPE;
begin
htp.print('Nombre: '||'==> '||nombre);
htp.nl;
select sueldo into n from prueba where nom=nombre;
htp.print('El empleado '||nombre||' tiene un sueldo de: '||to_char(n));
if n > 1000 then
delete from prueba where nom=nombre;
htp.nl;
htp.nl;
htp.print('Este registro ha sido borrado');
else
htp.nl;
htp.nl;
htp.print('Este no es un registro valido para ser borrado');
end if;
htp.nl;
htp.nl;
htp.anchor('http://isla.lania.mx:8900index.html', 'Listado de Pruebas');
exception
when no_data_found then
htp.nl;
htp.print('El empleado '||nombre||' no fue localizado');
htp.nl;
htp.nl;
htp.print('por lo tanto este registro no puede ser ELIMINADO');
htp.nl;
htp.nl;
htp.anchor('http://isla.lania.mx:8900index.html','Listado de Pruebas');
end;
Procedimientos

Los subprogramas en PL/SQL son nombrados que pueden recibir parámetros y

ser invocados. PL tiene dos tipos de subprogramas llamados
PROCEDIMIENTOS y FUNCIONES . Generalmente usamos un procedimiento
para ejecutar una acción y una funcion para calcular un valor.
 Sintaxis de un Procedimiento
PROCEDURE nombre [(parametro1, [parametro2, ....])] IS

[declaraciones locales]

BEGIN

[Estructuras Ejecutables]

[EXCEPTION]

Majenadores de Excepciones

END [nombre];
Ejemplo de un procedimiento

create or replace procedure almacena (

ctrl in varchar2,
nom in varchar2,
direc in varchar2,
tele in varchar2,
xsue number,
xdias number) as
begin
insert into agenda values (ctrl, nom, direc, tele);
insert into sueldos values (xsue, xdias, ctrl);
commit;
htp.print('Este es el final favor de selecionar Back');
htp.nl;
end;
Funciones

Una función es un subprograma que calcula un valor. Las funciones y los

procedimientos son estructurados de la misma forma excepto que las funciones
cuentan con la clausula RETURN.

Sintaxis de una Función

PROCEDURE nombre [(parametro1, [parametro2, ....])] RETURN
tipo_de_dato IS

[declaraciones locales]

BEGIN

[Estructuras Ejecutables]

[EXCEPTION]

Majenadores de Excepciones

END [nombre];

El cuerpo de la función INICIA con la palabra IS y finaliza con la clausula

RETURN, el cual especifica el tipo de dato del resultado a devolver.
La estructura RETURN completa inmediatamente la ejecución del subprograma
y regresa el control al programa que la llamó.

Esta estructura debera contener una expresión la cual será evaluada cuando la
estructura RETURN sea ejecutada, esta debera estar presente en la
declaración de cualquier función y en caso de no estar presente seraá invocada
la excepción PROGRAM_ERROR durante la ejecución.

Paquetes

Un paquete es un objeto de una base de datos que agrupa tipos, objetos, y

subprogramas en Pl/SQL relacionados entre si. Un paquete usualmente tiene 2
partes, una ESPECIFICACION y un CUERPO (body), el algunas veces el
BODY es innecesario.

La ESPECIFICACION es la Interface con tu aplicacion, esta declara los tipos,

variables, constantes, excepciones, cursores y subprogramas disponibles . El
BODY define completamente CURSORES y subprogramas.

Los paquetes no pueden ser llamados o pasados como parametros.

Sintaxis para un paquete

PACKAGE nombre IS
-- Declaraciones de tipos y objetos publicos
-- especificaciones de los subprogramas
END [nombre];

PACKAGE BODY nombre IS

-- Declaraciones de tipos y objetos privados
-- Cuerpos de los subprogramas
[BEGIN
-- Estructura de Inicializacion ]
END [name];

Referencia a paquetes

Para hacer referencia a los tipos, objetos y subprogramas declarados dentro de

un paquete debe emplearse la notacion siguiente:

 package_nombre.type_name
 package_nombre.objeto_name
 package_nombre.subprograma_name

II. MODIFICACIONES A LA BASE DE DATOS

Instrucciones DML (Data Manipulation Language)
Las instrucciones DML consultan o manipulan datos de los objetos de un
esquema. Permiten
 Recuperar datos de una o más tablas o vistas (SELECT)
 Agregar registros a una tabla o vista (INSERT)
  Cambiar los valores de las columnas en los registros de una tabla o
vista (UPDATE)
 Eliminar registros de una tabla o vista (DELETE)
 Bloquear una tabla o vista temporalmente para limitar el acceso a
usuarios (LOCK TABLE)

Instrucciones DDL (Data Definition Language)

Las instrucciones DDL definen, modifican la estructura de los objetos de un

esquema, o los eliminan de la base de datos. Con ellas es posible

 Crear, modificar y eliminar objetos del esquema y otras estructuras

de la base de datos, incluyendo a la BD y a los usuarios (CREATE,
ALTER, DROP)
 Cambiar los nombres de los objetos del esquema (RENAME)
 Eliminar los todos los datos en los objetos del esquema sin remover
la estructura de los objetos (TRUNCATE)
 Obtener estadísticas acerca de los objetos del esquema, validar la
estructura, y listar registros vinculados dentro de los objetos
(ANALYZE)
 Otorgar y remover privilegios y roles (GRANT, REVOKE)
 Agregar comentarios al diccionario de datos (COMMENT)

Las instrucciones DDL implícitamente ejecutan un COMMIT.

Modificación de tablas

Para modificar la definición y las restricciones de una tabla se usa la instrucción

ALTER TABLE seguida del nombre de la tabla y las especificaciones de lo que se
quiere modificar:

(nombre_columna tipo_de_dato
ADD restricción_de_columna [,])
ADD CONSTRAINT [nombre_restriccion] restricción_de_tabla
(nombre_columna tipo_de_dato
MODIFY restricción_de_columna [,])
MODIFY
CONSTRAINT [nombre_restriccion] restricción_de_tabla
DROP COLUMN nombre_columna
PRIMARY KEY
DROP UNIQUE ( columna [,])
CONSTRAINT nombre_restricción
COLUMN columna CASCADE CONSTRAINTS
SET UNUSED (columna [,]) CASCADE COSNTRAINTS
RENAME TO nombre_tabla
Restricciones en columnas ADD
NOT NULL
 NULL
UNIQUE
PRIMARY KEY
nombre_tabla [( columna )] [ON DELETE CASCADE ]
REFERENCES nombre_tabla [( columna )] [ON DELETE SET NULL ]
CHECK ( condición )
Restricciones en tablas ADD CONSTRAINT
UNIQUE ( columna [,] )
PRIMARY
KEY ( columna [,] )
FOREIGN ( columna [,]) REFERENCES tabla [( columna [,] )] [ON
KEY DELETE CASCADE ¦ SET NULL]
CHECK ( condición )
Restricciones en columnas MODIFY
NOT NULL
NULL
UNIQUE
PRIMARY KEY
nombre_tabla [( columna )] [ON DELETE CASCADE ]
REFERENCES nombre_tabla [( columna )] [ON DELETE SET NULL ]
CHECK ( condición )
Restricciones en tablas MODIFY CONSTRAIN
UNIQUE ( columna [,] )
PRIMARY
KEY ( columna [,] )
FOREIGN ( columna [,]) REFERENCES tabla [( columna [,] )] [ON
KEY DELETE CASCADE ¦ SET NULL]
CHECK ( condición )

III. UNIDADES DE PROGRAMACIÓN

Bloques PL/SQL

Un bloque PL/SQL es la unidad básica de todo programa. Todos los programas

PL/SQL están compuestos por bloques, los cuales pueden ser secuenciales o
anidados.

Los tipos de bloques son:

 Bloques anónimos:
Se construyen generalmente dinámicamente y sólo se ejecutan una vez.

 Bloques con nombre:

Son como los bloques anónimos, pero tienen una etiqueta que le da al
bloque un nombre.
  Subprogramas:
Son procedimientos, funciones y paquetes que son almacenados en
base de datos y se ejecutan cuando son invocados.

 Triggers:
Son bloques con nombre que son almacenados en la base de datos.
Son ejecutados implícitamente cuando cierto evento ocurre.

Procedimientos

 Los procedimientos en PL/SQL tienen la siguiente estructura:

CREATE [OR REPLACE] PROCEDURE nombre

[(param1 [IN | OUT | IN OUT] tipo1,
...
paramN [IN | OUT | IN OUT] tipoN)] IS
cuerpo_procedimiento

 donde cuerpo_procedimiento es un bloque PL/SQL, que usar la

palabra DECLARE. Ejemplo:

CREATE OR REPLACE PROCEDURE

ejemplo(param1 IN NUMBER,
param2 OUT NUMBER,
param3 IN OUT VARCHAR2,
param4 IN CHAR DEFUALT 'valor') IS
var1 NUMBER;
var2 VARCHAR2(10);
BEGIN
/* Asignaciones legales */
var1 := param1;
var2 := param3;
param3 := 8;

/* Asignaciones ilegales
var1 := param2;
param1 := 11; */
END;

 Para ejecutar un procedimiento se debe tener el privilegio

EXECUTE.

-- Ejemplo: Insertar un registro en la tabla TEMP, la cual tiene dos

-- columnas, col1 de tipo NUMBER y col2 de tipo varchar2(40). En el
-- procedimiento sólo se da el valor para col2 ya que el valor
-- de col1 es tomado de la secuencia TEMP_SEQ.

CREATE OR REPLACE PROCEDURE

registro_temp(icol2 in varchar2) IS
val binary_integer;
BEGIN
 if icol2 is not null then
insert into temp(col1, col2)
values(temp_seq.nextval, substr(icol2, 1, 40));
commit;
end if;
END;

 Para ejecutar este procedimiento desde la línea de comando se

usa la instrucción:

execute registro_temp('algun valor');

Funciones

 Las funciones son similares a los procedimientos. La diferencia

es que las funciones al menos deben de regresar un valor. Su
sintaxis es:

CREATE [OR REPLACE] FUNCTION nombre

[(param1 [IN | OUT | IN OUT] tipo1,
...
paramN [IN | OUT | IN OUT] tipoN)]
RETURN tipo IS
Cuerpo _ función

 Donde cuerpo _ función es un bloque PL/SQL que contiene el código

para la función, y dentro de éste debe estar la instrucción RETURN para
devolver el valor que resulte al evaluar una expresión.

Ejemplo: Cálculo del factorial.

CREATE OR REPLACE FUNCTION factorial(n in number) RETURN NUMBER IS

BEGIN
IF n<0 THEN
return NULL;
END IF;
IF n=0 THEN
return 1;
ELSE
return n*factorial(n-1);
END IF;
END;

 La llamada a una función debe de ser parte de una instrucción

SQL. Así, una manera de ejecutar la función factorial podría
ser:

select factorial(10) from dual;

Paquetes

PL/SQL permite agrupar todos las unidades de programa relacionadas en un

objeto de la BD llamado paquete.

CREATE [OR REPLACE] PACKAGE nombre AS

/* Especificaciones del paquete */
END;

CREATE [OR REPLACE] PACKAGE BODY nombre AS

/* Especificaciones del cuerpo */
END;

CREATE [OR REPLACE] PACKAGE nombre: es la instrucción que inicia la construcción

del paquete en la BD. En esta parte se especifican los objetos y las subrutinas
del paquete que pueden ser invocadas desde por otras unidades de programa
que no pertencen al paquete. A esta sección se también se le llama
encabezado.

La instrucción CREATE OR REPLACE PACKAGE BODY principia el área de

especificación de los objetos y subprogramas que pertenecen al paquete.

Las declaraciones del los subprogramas en el encabezado y cuerpo del

paquete tienen que ser idénticas.

El paquete sólo tiene un subprograma que puede ser llamado externamente,

reporte, y es que genera el reporte. Para invocarlo usamos:

execute temporal.reporte
 BASES DE DATOS
ORACLE

INTEGRIDAD DE TRANSACCIÓN

ALUMNO : NELSON A. SAN MARTIN B.

RAMO : BASE DE DATOS.
DOCENTE : MIGUEL OLGUIN.
 INTRODUCCIÓN.

Dentro del mundo de la informática, nos encontramos día a día con la

imperiosa necesidad de trabajar con grandes volúmenes de datos e
información, los cuales, debido a su importancia en las empresas, deben contar
con un sistema robusto que nos otorgue el máximo de confiabilidad para
asegurar la integridad y rápido acceso a la información cuando se requiera.

En los sistemas de bases de datos relacionales como Oracle, existen una

enorme cantidad de transacciones que son realizadas por los usuarios
conectados a las bases de datos, todas estas transacciones deben reflejar en
forma integra la información que contienen.

En el presente informe se abordará el tema de la Integridad de

Transacciones que se realizan en una base de datos Oracle, como trabajan las
transacciones al momento de las peticiones realizadas por los usuarios, etc.

INTEGRIDAD DE TRANSACCIONES.

Una transacción es una serie de operaciones sobre la base de datos

considerados como una única operación, de manera que cuando se cierra la
transacción la base de datos queda en un estado consistente.

Las transacciones pueden involucrar a múltiples registros, múltiples

relaciones e incluso múltiples bases de datos. Siendo precisos, todas las
operaciones sobre una base de datos son transacciones. Incluso la
actualización de un único registro existente es una transacción. Estas
transacciones de bajo nivel las realiza el motor de base de datos de forma
transparente y normalmente se puede ignorar este nivel de detalle.

Toda transacción es una secuencia de operaciones que se ejecutan

completamente o bien no se realizan. Una transacción NO puede quedarse en
un estado intermedio.

Ejemplo: una transferencia entre dos cuentas no puede quedarse en un

estado intermedio, o se deja el dinero en la primera cuenta o en la segunda,
pero no se puede sacar el dinero de la primera cuenta, que falle algo en ese
momento y no entregarlo en la segunda.

PROPIEDADES DE UNA TRANSACCIÓN.

Atomicidad: Se realizan o todas las instrucciones o ninguna.

Corrección (Preservación de la consistencia): La transacción siempre deja la

Base de Datos en un estado consistente (Si no lo hace puede ser por errores
lógicos o físicos).

Aislamiento: Los efectos de una transacción no se ven en el exterior hasta que

esta finaliza.

Persistencia: Una vez finalizada la transacción los efectos perduran en la BD.

Seriabilidad: La ejecución concurrente de varias transacciones debe generar el

mismo resultado que la ejecución en serie de las mismas.

ESTADOS DE UNA TRANSACCIÓN

Activa: Estado inicial (realizando sus instrucciones)

Parcialmente finalizada: Tras acabar la última instrucción

Fracasada: Tras descubrirse que no puede continuar la ejecución normal, por

ejemplo por un error lógico (violación limitante de integridad).

Abortada: Tras deshacer la transacción y devolver la BD al estado anterior

(consistente).

Finalizada: Tras completarse con éxito (cambios visibles).

Cuando una transacción finaliza con éxito, se graba (COMMIT).

Si fracasa, se restaura el estado anterior (ROLLBACK).

 Los segmentos de rollback son áreas lógicas de la base de datos que
contienen información de las transacciones que se encuentran en curso y que
aún no han sido confirmadas o deshechas. Todas las transacciones deben
confirmarse en la base de datos en algún momento, con la instrucción
COMMIT de SQL.

Asimismo, se puede deshacer un grupo de transacciones completamente

(mientras no se haya hecho el commit) mediante la instrucción ROLLBACK.
Mientras las transacciones se ejecutan, los cambios se van almacenando en
estos segmentos de rollback para disponer de ellos en la eventualidad que
haya que deshacerlos. Estos segmentos se utilizan en forma concurrente por
una o más transacciones. Es labor del Administrador de Base de Datos el
ajustar sus parámetros adecuadamente para proveer un uso eficiente del
espacio que utilizan.
Inacap
Concepción-Talcahuano

Nombre: Nicolasa Albornoz

Curso: Inf_pc_502-b
Docente: Miguel Olguín
Introducción

El siguiente informe trata de las tablas de índices, y de los índices, es un pequeño

informe que quiere conceptuar un poco estos términos.

Índices:

Un índice es una estructura diseñada para obtener un acceso más rápido a los datos
contenidos dentro de una tabla.

Un índice es independiente de los datos almacenados en la tabla y cuando se encuentra

bien definido, es decir, cuando se forma atendiendo a la gran mayoría de las consultas
que se harán sobre una tabla, reduce significativamente la búsqueda, aumentando el
rendimiento.

Inmediatamente luego de creado el índice, Oracle comienza a mantenerlo de acuerdo a

las inserciones, actualizaciones y eliminaciones de registros de la tabla en la cual se ha
implementado.

Tipos de índices:

Existen tres tipos de índices cuya naturaleza depende de la forma en que haya sido
creado. Estos tipos son:

 Un índice único es aquel que tiene la restricción adicional de que el grupo de

columnas indexadas define una única fila. Sin embargo, si no van a existir más
grupos de columnas con esta características dentro de una misma tabla, se
recomienda crear el conjunto como una clave primaria ya que de todas formas
Oracle asociará un índice único a esta restricción (la clave primaria).
 Un índice no único, que es aquel que no impone la restricción de que las filas
no deban repetirse.
 Un índice compuesto es aquel que agrupa varias columnas de la tabla. Este tipo
es muy útil cuando las sentencias de selección (SELECT) efectúan búsquedas
por varios criterios (columnas) en una misma tabla. Es importante el orden en
que se ponen las columnas al crear el índice; la columna más referenciada
debería ser puesta en primer lugar y así sucesivamente.
Cuando se crea un índice (de cualquier tipo) también se crea un segmento de datos para
guardar esa información, que también se verá afectada por la misma cláusula storage
que se estudió para el caso de las tablas.

Consideraciones en el diseño de índices

Un índice sólo es efectivo cuando es utilizado. Es por eso que debe asegurarse que la
frecuencia de uso sea muy alta y que su implementación redunde en mejoras de
rendimiento de las consultas efectuadas a la tabla donde reside el índice. Sin embargo,
no debe explotarse el uso de los índices dentro de una misma tabla porque con cada
operación de inserción, actualización o eliminación que se lleva a cabo sobre una tabla,
sus índices se deben recrear, con el consiguiente overhead que se produce. A menudo es
conveniente eliminar o desactivar temporalmente un índice cuando sabemos que se va a
efectuar una operación de carga/actualización/eliminación masiva en la tabla para evitar
este overhead y

Conceptos:

TABLAS BASE: Una tabla en un sistema relacional se compone de una fila de

cabeceras de columnas, junto con cero o mas filas de valores de datos (diferente
número de filas de datos en diferente momentos).Para una tabla dada:

(a) La fila de cabeceras de columna especifica una o mas columnas (dando,

entre otras cosas, un tipo de datos para cada una).
(b) Cada fila de datos contiene un solo valor escalar para cada una de las
columnas especificadas en la fila de cabeceras de columna. Además
todos los valores de una columna dada tienen el mismo tipo de datos, a
saber, el tipo especificado en la fila de cabeceras de columna para esa
columna.

INDICES: Los índices como las tablas base, se crean y se desechan mediante
proposiciones de definición de datos de SQL. Sin embargo, CREATE INDEX (crear
índice) son las únicas proposiciones del lenguaje SQL que hacen referencia a los
índices; otras proposiciones- sobre todo las de manipulación de datos, como SELECT -
evitan a propósito cualquier referencia a ellos.
TABLAS DE UNA BASE DE DATOS.- una base de datos es el conjunto de tablas
relacionados que contienen la información necesaria para el manejo de un proceso,
entonces se dirá que para almacenar los datos de las entidades y relaciones de una base
de datos se utilizan tablas, que está formado por un conjunto de filas y columnas donde
cada fila contiene la información de un individuo y cada columna los valores de un
atributo particular de la entidad.

Bibliografía
*C.J. Date “introducción a los sistemas de bases de datos” volumen 1 Quinta edición.
*Manual de Oracle.
ORGANIZACIÓN INACAP

ÁREA INFORMÁTICA

BASE DE DATOS II

“ESTRUCTURA BASE DE DATOS ORACLE”

Nombre : Noelia Riquelme C.

Profesor : Sr. Milton Olguin
Curso : INF PC 502 B
Fecha : 12.04.2004.-
 INDICE

1. Estructura de DBMS Oracle..........................................................................2

2. Espacios de tablas........................................................................................ 2
3. Ficheros Oracle.............................................................................................4
4. Instancias...................................................................................................... 4
5. Estructuras Internas de la BD........................................................................5
5.1.Tablas y Columnas...................................................................................5
5.2. Restricciones de Tablas.........................................................................5
5.3. Usuarios................................................................................................... 5
5.4. Esquemas.................................................................................................6
5.5. Indices...................................................................................................... 6
5.6. Clusters.................................................................................................... 6
5.7. Vistas........................................................................................................6
5.8. Secuencias...............................................................................................7
5.9. Procedimientos y Funciones..................................................................7
5.10. Paquetes, Packages..............................................................................7
5.11. Disparadores, Triggers.........................................................................7
5.12. Sinónimos..............................................................................................7
5.13. Privilegios y Roles.................................................................................7
5.14. Segmentos, Extensiones y Bloques....................................................8
5.15. Segmento de Rollback..........................................................................8
6. Estructuras de Memoria Internas....................................................................8
6.1. Área Global del Sistema, SGA................................................................8
6.2 Área Global de Programa......................................................................10
7. Estructuras de Proceso.................................................................................10
1. Estructura de DBMS Oracle

Una Base de Datos Oracle es un conjunto de datos almacenado y accesible

según el formato de tablas relacionales. Una tabla relacional tiene un nombre y
unas columnas, su definición. Los datos están almacenados en las filas. Las
tablas pueden estar relacionadas con otras.

Una Base de Datos Oracle está almacenada físicamente en ficheros, y la

correspondencia entre los ficheros y las tablas es posible gracias a las
estructuras internas de la BD, que permiten que diferentes tipos de datos estén
almacenados físicamente separados. Está división lógica se hace gracias a los
espacios de tablas.

2. Espacios de tablas

Un espacio de tablas es una división lógica de la BD. Cada BD tiene al menos

uno (SYSTEM). Un espacio de tablas puede pertenecer sólo a una BD. Los
espacios de tablas se utilizan para mantener juntos los datos de usuarios o de
aplicaciones para facilitar su mantenimiento o mejorar las prestaciones del
sistema.

De esta manera, cuando se crea una tabla se debe indicar el espacio de tablas
al que se destina. Por defecto se depositan en el espacio de tablas SYSTEM,
que se crea por defecto. Este espacio de tablas es el que contiene el
diccionario de datos, por lo que conviene reservarlo para el uso del servidor, y
asignar las tablas de usuario a otro.

Lo razonable y aconsejable es que cada aplicación tenga su propio espacio de

tablas.

Hay varias razones que justifican este modo de organización de las tablas en
espacios de tablas:

Un espacio de tablas puede quedarse offline debido a un fallo de disco,

permitiendo que el SGBD continúe funcionando con el resto.

Los espacios de tablas pueden estar montados sobre dispositivos ópticos si

son de sólo lectura.

Permiten distribuir a nivel lógico/físico los distintos objetos de las aplicaciones.

Son una unidad lógica de almacenamiento, pueden usarse para aislar

completamente los datos de diferentes aplicaciones.

Oracle permite realizar operaciones de backup/recovery a nivel de espacio de

tabla mientras la BD sigue funcionando.

Cuando se crean se les asigna un espacio en disco que Oracle reserva

inmediatamente, se utilice o no. Si este espacio inicial se ha quedado pequeño
Oracle puede gestionar el crecimiento dinámico de los ficheros sobre los que
se asientan los espacios de tablas. Esto elimina la posibilidad de error en las
aplicaciones por fallos de dimensionamiento inicial. Los parámetros de
crecimiento del tamaño de los espacios de tablas se especifican en la creación
de los mismos.

Se pueden ver los espacios de tablas definidos en nuestra BD con el comando

SQL siguiente:

SQL> select * from user_tablespaces;

Dentro de cada espacio de tabla se pueden almacenar objetos de distinta

naturaleza: tablas, índices, etc. Pero no se pueden mezclar. Una manera de
separarlos es por medio de los segmentos.

Se pueden almacenar más de un segmento por espacio de tabla. Un segmento

está contenido en su totalidad en un espacio de tabla. Un segmento está
constituido por un conjunto de extensiones, que no son más que grupos de
bloques de disco ORACLE contiguos. Cuando se borra un segmento, el
espacio es devuelto al espacio de tabla.

Todos los datos de la BD están almacenados en segmentos. Y existen 5 tipos

de segmentos:

 De datos: Almacenan las tablas.

 De índices: Permiten un acceso rápido a los datos dependiendo de la

cantidad de los mismos (árboles B). Las consultas que sólo referencian
a columnas indexadas se resuelven en el índice. Establecen un control
de unicidad (los índices son automáticos cuando se definen claves
primarias). Cada índice ocupa un segmento independiente del segmento
de datos y deberían estar en un espacio de tablas distinto al de los
datos, para mejorar el rendimiento.

 De rollback: Son objetos internos de la BD que permiten efectuar la restauración

de las transacciones no validadas asegurando la consistencia en lectura. La
estructura de los registros de rollback es :

- Identificador de la transacción.
- Dirección del bloque donde está la tabla.
- Número de fila.
- Número de columna.
- Valor del dato antiguo (antes de ser modificado).

Son tan importantes que una BD no puede arrancar si

no puede acceder al menos a un segmento de rollback.
Si la BD tiene múltiples espacios de tablas, deben
existir al menos dos segmentos de rollback y cada
segmento de rollback debe tener al menos dos
 extensiones, reutilizables de manera cíclica. Esto
segmentos son un objeto compartido de la BD, aunque
se puede asinar un segmento de rollback particular a
una transacción dada.
 Temporales: Son creados por Oracle para un uso temporal cuando debe
realizar una ordenación que no le cabe en memoria, y en las
operaciones: create index, order by, group by, distinct, union, intersect,
minus. Son eliminados cuando la sentencia finaliza.

 De bootstrap: Se crea en SYSTEM y contiene definiciones del

diccionario para sus tablas, que se cargan al abrir la BD. No requiere
ninguna acción por parte del DBA. No cambia de tamaño.

La tabla que guarda la información de los segmentos de usuario es

user_segments, y se puede visualizar la información sobre los segmentos con
la sentencia SQL siguiente:

SQL> select * from user_segments;

3. Ficheros Oracle

Cada espacio de tablas se compone de uno o más ficheros en disco. Un fichero

puede pertenecer sólo a un espacio de tablas. Los ficheros reciben un tamaño
fijo en el momento de su creación, y cuando se necesita más espacio se deben
añadir más ficheros a espacio de tablas.

Dividir los objetos de la BD entre múltiples espacios de tablas permiten que los
objetos sean almacenados físicamente en discos separados, dependiendo de
donde estén los ficheros sobre los que se asientan.

4. Instancias

Para permitir el acceso a los datos, Oracle utiliza un conjunto de procesos que
son compartidos por todos los usuarios. Además, existen estructuras de
memoria que son utilizadas para almacenar los datos más recientemente
solicitados a la BD.

Una instancia de BD es el conjunto de estructuras de memoria y de procesos

que acceden a los ficheros de datos.

Los parámetros que determinan el tamaño y composición de una instancia

están almacenados en un fichero llamado init.ora. Este fichero es leido durante
el arranque de la BD y puede ser modificado por el DBA. Cualquier
modificación de este fichero no tiene efecto hasta la siguiente vez que se
arranque la BD.

Las estructuras de la BD Oracle pueden ser divididas en tres clases:

  Aquellas que son internas a la BD

 Aquellas que son internas a las áreas de memoria

(incluidas la memoria compartida y procesos)
 Aquellas que son externas a la BD.

5. Estructuras Internas de la BD

5.1.Tablas y Columnas

Los datos son almacenados en la BD utilizando tablas. Cada tabla está

compuesta por un número determinado de columnas.

Las tablas propiedad del usuario SYS son llamadas tablas del diccionario de
datos. Proveen el catálogo del sistema que permite que la BD se gestione a sí
misma.

Las tablas se pueden relacionar entre ellas a través de las columnas que las
componen. La BD se puede utilizar para asegurar el cumplimiento de esas
relaciones a través de la integridad referencial, que se concreta en las
restricciones de tablas.

5.2. Restricciones de Tablas

Una tabla puede tener asociadas restricciones que deben cumplir todas las
filas. Entre las restricciones que se pueden fijar algunas reciben nombres
especiales.: clave primaria, clave ajena.

La clave primaria de una tabla está compuesta por las columnas que hacen a
cada fila de la tabla una fila distinta.

La clave ajena se utiliza para especificar las relaciones entre tablas. De modo
que un conjunto de columnas declaradas como clave ajena de una tabla deben
tener valores tomados de la clave primaria de otra tabla.

5.3. Usuarios

Una cuenta de usuario no es una estructura física de la BD, pero está

relacionada con los objetos de la BD: los usuarios poseen los objetos de la BD.
Existen dos usuarios especiales: SYS y SYSTEM. El usuarios SYS posee las
tablas del diccionario de datos; que almacenan información sobre el resto de
las estructuras de la BD. El usuario SYSTEM posee las vistas que permiten
acceder a las tablas del diccionario, para el uso del resto de los usuarios de la
BD.

Todo objeto creado en la BD se crea por un usuario, en un espacio de tablas y

en un fichero de datos determinado. Toda cuenta de la BD puede estár unida a
una cuenta del S.O., lo que permite a los usuarios acceder a la cuenta de la BD
sin dar la clave de acceso.

Cada usuario puede acceder a los objetos que posea o a aquellos sobre los
que tenga derecho de acceso.

5.4. Esquemas

El conjunto de objetos de un usuario es conocido como esquema.

5.5. Indices

Un índice es una estructura de la BD utilizada para agilizar el acceso a una fila

de una tabla. Cada fila tiene un identificador de fila, ROWID, que determina el
fichero, bloque y fila dentro del bloque donde está almacenada la fila.

Cada entrada del índice consite en un valor clave y una ROWID. Cada una de
estas entradas se almacena en un árbol B+.

Los índices se crean automáticamente cuando se define una restricción

UNIQUE o PRIMARY KEY.

5.6. Clusters

Las tablas que son accedidas juntas frecuentemente pueden ser almacenadas
juntas. Para ello se crea un cluster. De este modo se minimiza el número de
E/S.
Las columnas que relacionan las tablas de un cluster se llaman clave del
cluster.

5.7. Vistas

Conceptualmente, una vista puede considerarse como una máscara que se

extiende sobre una o más tablas, de modo que cada columna de la vista se
corresponde con una o más columnas de las tablas subyacentes. Cuando se
consulta una vista, esta traspasa la consulta a las tablas sobre las que se
asienta.

Las vistas no se pueden indexar.

Las vistas no generan almacenamiento de datos, y sus definiciones se

almacenan en el diccionario de datos.

5.8. Secuencias

Las definiciones de secuencias se almacenan en el diccionario de datos. Son

mecanismos para obtener listas de números secuenciales.
5.9. Procedimientos y Funciones

Un procedimiento es un bloque de código PL/SQL, que se almacena en el

diccionario de datos y que es llamado por las aplicaciones. Se pueden utilizar
para implementar seguridad, no dando acceso directamente a determinadas
tablas sino es a través de procedimientos que acceden a esas tablas. Cuando
se ejecuta un procedimiento se ejecuta con los privilegios del propietario del
procedimiento. La diferencia entre un procedimiento y una función es que ésta
última puede devolver valores.

5.10. Paquetes, Packages

Se utilizan para agrupar procedimientos y funciones. Los elementos dentro de

los paquetes pueden ser públicos o privados. Los públicos pueden ser
llamados por los usuarios, los privados están ocultos a los usuarios y son
llamados por otros procedimientos.

5.11. Disparadores, Triggers

Son procedimientos que son ejecutados cuando se procure un determinado

evento en la BD. Se pueden utilizar para mejorar y reforzar la integridad y la
seguridad de la BD.

5.12. Sinónimos

Para identificar completamente un objeto dentro de una BD se necesita

especificar el nombre de la máquina, el nombre del servidor, el nombre del
propietario y el nombre del objeto. Para hacer transparente todo esto al usuario
se pueden utilizar los sinónimos. Éstos apuntarán a los objetos y si el objeto
cambia de lugar o propietario, sólo habrá que modificar el sinónimo.

Existen sinónimos públicos y privados. Los públicos son conocidos por todos
los usuarios de una BD. Los privados son locales a un usuario.

5.13. Privilegios y Roles

Para que un objeto pueda ser accedido por un usuario debe de tener otorgado
ese privilegio. Ejemplos de privilegios son INSERT, SELECT, UPDATE,
EXECUTE, etc.

Los roles son grupos de privilegios que pueden ser utilizados para facilitar la
gestión de los privilegios. Los privilegios se pueden otorgar a un rol, y los roles
pueden ser otorgados a múltiples usuarios.

5.14. Segmentos, Extensiones y Bloques

Los segmentos son los equivalentes físicos de los objetos que almacenan
datos. El uso efectivo de los segmentos requiere que el DBA conozca los
objetos que utiliza una aplicación, cómo los datos son introducidos en esos
objetos y el modo en que serán recuperados.
Como los segmentos son entidades físicas, deben estar asignados a espacios
de tablas en la BD y estarán localizados en uno de los ficheros de datos del
espacio de tablas. Un segmento está constituido por secciones llamadas
extensiones, que son conjuntos contiguos de bloques Oracle. Una vez que una
extensión existente en un segmento no puede almacenar más datos, el
segmento obtendrá del espacio de tabla otra extensión. Este proceso de
extensión continuará hasta que no quede más espacio disponible en los
ficheros del espacio de tablas, o hasta que se alcance un número máximo de
extensiónes por segmento.

5.15. Segmento de Rollback

Para mantener la consistencia en lectura y permitir deshacer las transacciones,

Oracle debe tener un mecanismo para reconstruir la imágen previa a una
transacción incompleta. Oracle utiliza los segmentos de rollback para esto.

Los segmentos de rollback pueden crecer tanto como sea necesario para
soportar las transacciones.

6. Estructuras de Memoria Internas

Oracle mantiene dos estructuras principales de memoria: el Área Global de

Programa, Program Global Area, PGA; y el Área Global del Sistema, System
Global Area o también Shared Global Area, SGA.

El PGA es la zona de memoria de cada proceso Oracle. No está compartida y

contiene datos e información de control de un único proceso.

El SGA es la zona de memoria en la que la BD Oracle guarda información

sobre su estado. Esta estructura de memoria está disponible para todos los
procesos, por eso se dice que está compartida.

6.1. Área Global del Sistema, SGA

Sirve para facilitar la transferencia de información entre usuarios y también

almacena la información estructural de la BD más frecuentemente requerida.

La SGA se divide en varias partes:

Buffers de BD, Database Buffer Cache

Es el caché que almacena los bloques de datos leidos de los segmentos de

datos de la BD, tales como tablas, índices y clusters. Los bloques modificados
se llamas bloques sucios. El tamaño de buffer caché se fija por el parámetro
DB_BLOCK_BUFFERS del fichero init.ora.

Como el tamaño del buffer suele ser pequeño para almacenar todos los
bloques de datos leidos, su gestión se hace mediante el algoritmo LRU.
Buffer Redo Log

Los registros Redo describen los cámbios realizados en la BD y son escritos en

los ficheros redo log para que puedan ser utilizados en las operaciones de
recuperación hacia adelante, roll-forward, durante las recuperaciones de la BD.
Pero antes de ser escritos en los ficheros redo log son escritos en un caché de
la SGA llamado redo log buffer. El servidor escribe periódicamente los registros
redo log en los ficheros redo log.

El tamaño del buffer redo log se fija por el parámetro LOG_BUFFER.

Área de SQL Compartido, Shared SQL Pool

En esta zona se encuentran las sentencias SQL que han sido analizadas. El
analisis sintáctico de las sentencias SQL lleva su tiempo y Oracle mantiene las
estructuras asociadas a cada sentencia SQL analizada durante el tiempo que
pueda para ver si puede reutilizarlas. Antes de analizar una sentencia SQL,
Oracle mira a ver si encuentra otra sentencia exactamente igual en la zona de
SQL compartido. Si es así, no la analiza y pasa directamente a ejecutar la que
mantinene en memoria. De esta manera se premia la uniformidad en la
programación de las aplicaciones. La igualdad se entiende que es lexicografica,
espacios en blanco y variables incluidas. El contenido de la zona de SQL
compartido es:

· Plan de ejecución de la sentencia SQL.

· Texto de la sentencia.
· Lista de objetos referenciados.

Los pasos de procesamiento de cada petición de análisis de una sentencia

SQL 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.
Si no, la sentencia es nueva, se analiza y los datos de análisis se almacenan
en la zona de SQL compartida.

También se almacena en la zona de SQL compartido el caché del diccionario.

La información sobre los objetos de la BD se encuentra almacenada en las
tablas del diccionario. Cuando esta información se necesita, se leen las tablas
del diccionario y su información se guarda en el caché del diccionario de la
SGA.

Este caché también se administra mediante el algoritmo LRU. El tamaño del

caché está gestionado internamente por el servidor, pero es parte del shared
pool, cuyo manaño viene determinado por el parámetro SHARED_POOL_SIZE.

6.2 Área Global de Programa

El Program Global Area es un área de memoria utilizada por un proceso
Oracle. Esta zona de memoria no se puede compartir.

7. Estructuras de Proceso

El servidor se vale de una serie de procesos que son el enlace entre las
estructuras físicas y de memoria. A continuación se describen cada proceso y
el papel que juega en la gestión de laBD. Todo esto se puede ver en la
siguiente figura.
TÉCNICAS DE CONTROL DE CONCURRENCIA

 Similares a las aplicadas en sistemas operativos.

 Se usan para asegurar la seriabilidad en la ejecución de transacciones

concurrentes.

- Técnicas pesimistas: Evitan que se produzcan los problemas,

como bloqueos (cerrojos)...

- Técnicas optimistas: Sólo actúan en caso de que aparezca

algún problema.

Pueden estar totalmente controladas por el programador, o realizadas

internamente por el SGBD al procesar las transacciones o de una forma
mixta.

BLOQUEOS (CERROJOS)

 Indican para cada variable de datos su estado respecto a las

posibles operaciones que se pueden realizar con ella en cada
momento.
 Se trata de evitar el acceso a un dato por otras transacciones
(cuando este acceso produzca problemas) bloqueando el dato al
resto. Reteniendo un cerrojo o bloqueo sobre el dato.
 Es similar a las exclusiones mutuas.
 El SGBD lo puede hacer automáticamente en algunos casos.
 Puede ser establecido arbitrariamente en las transacciones.
Tipos de bloqueo

 Exclusivo (Escritura)

El dato no puede ser accedido por otra transacción, ni

siquiera para adquirir un bloqueo.

Normalmente se usa cuando hay que actualizar un

dato.

Una vez que se tiene un bloqueo exclusivo sobre un

dato, este no puede ser usado por otra transacción.

 Compartido (Lectura)

Otras transacciones pueden consultar el dato, pero no

modificarlo (adquiriendo previamente un bloqueo
compartido sobre el dato).

Una vez que se tiene un bloqueo compartido sobre un

dato, este no sólo puede ser consultado por otra
transacción.

Bloqueo en dos fases

 Es un protocolo que usa bloqueos y asegura la seriabilidad.

 El uso de bloqueos únicamente no la garantiza. La transacción
puede estar mal diseñada a nivel lógico, etc.
 Cada transacción puede hacer peticiones de bloqueos y desbloqueos
en dos fases:

- Fase de crecimiento: Una transacción puede obtener un bloqueo,

pero no liberar ninguno.

- Fase de encogimiento: Una transacción puede liberar bloqueos,

pero no adquirirlos.

- Se trata de pedir todos los bloqueos antes de empezar a soltarlos.

- Esta técnica logra la serialización, pero no evita ínter bloqueos (Ej:

2 transacciones piden bloqueos cruzados).
 - Para evitar ínter bloqueos pueden usarse otras técnicas (SO), o
bien codificar las transacciones cuidadosamente...

Granularidad: fina/gruesa

 Determinada por el tamaño del ítem de datos que se bloquea

(comparte):

- Campo de un registro (Atributo)

- Registro (Tupla)

- Conjunto de registros (Conj. de tuplas)

- Fichero (Relación)

- Toda la base de datos

 Cuanto más fina es la granularidad, mayor es el grado de

concurrencia posible, pero se complica la gestión de los bloqueos al
ser estos más.

TÉCNICAS OPTIMISTAS

- Se permite el acceso libre de las transacciones a los objetos.

- Se determina antes de finalizarlas si ha habido interferencias (problemas)

y se finalizan unas y se relanzan otras de manera adecuada.

Fases de las transacciones en estos esquemas (normalmente):

  Lectura: Las transacciones hacen operaciones en copias privadas
de los objetos.
 Validación: Se comprueba si el conjunto de los objetos tratados en
una transacción se solapa con el de los modificados en otra (que ya
los haya validado) (Condiciones de Bernstein)
 Grabación: Si no hay interferencias, se graban las modificaciones. Si
las hay, se relanza la transacción.

- En lugar de evitar los problemas, sólo se actúa en el caso de que

verdaderamente los haya.

- El uso de técnicas optimistas o pesimistas dependerá de la probabilidad

de conflictos. Si esta es alta, con técnicas optimistas habrá que relanzar
muchas transacciones, desperdiciando el trabajo anterior.

MARCAS DE TIEMPO (TIMESTAMPING)

 Es una técnica que podría encuadrarse dentro de las optimistas.

 Se asigna a cada transacción un identificador único, su marca de
tiempo (tiempo de inicio).
 No hay bloqueos. Se retardan las actualizaciones hasta el final de la
transacción.
 Si una transacción quiere actualizar o consultar un dato que ha sido
actualizado por una transacción de fecha posterior (más reciente),
entonces se deshace y se vuelve a lanzar.
 Es decir si se intenta usar un dato que se ha modificado después de
que la transacción se inicie, no se puede continuar porque el valor
inicial que tenía el dato para la transacción ha cambiado.
 Este mecanismo asegura la seriabilidad al ordenar las transacciones
evitando solapamientos, basándose en el momento de inicio de cada
transacción.
 Además, no se pueden producir ínter bloqueos al no usar
mecanismos que impliquen la espera de las transacciones.