UNIANDES

UNIVERSIDAD REGIONAL AUTÓNOMA DE LOS ANDES

CENTRO DE APOYO IBARRA

FACULTAD DE SISTEMAS MERCANTILES

CARRERA DE SISTEMAS E INFORMÁTICA

TEMA:

MANUAL ORACLE 9i

AUTOR:

TLGA. JENIFFER MANOSALVAS

TUTOR:

ING. OSCAR LLERENA

IBARRA 2010

INTRODUCCIÓN

Está concebido con el fin de manejar grandes cantidades de información, además de

admitir conexiones concurrentes de multitud de usuarios (entornos multi-usuario) hacia

los mismos datos.

Oracle aporta un SGBD que estará ubicado en un hardware específico y bajo un sistema

operativo determinado.

La elección del entorno de trabajo (hardware, S.O. y tipología de la

estructura cliente/servidor) será una decisión que estará acorde con las necesidades

del propio sistema de información.

Las principales funcionalidades aportadas por todo el SGBD Oracle son:

• Soporte y tratamiento de una gran cantidad de datos (Gbytes).

• Soporte de una gran cantidad de usuarios accediendo concurrentemente a los

datos.

• Seguridad de acceso a los datos, restringiendo dicho acceso según las

necesidades de cada usuario.

• Integridad referencial en su estructura de base de datos.

• Conectividad entre las aplicaciones de los clientes en sus puestos de trabajo y el

servidor de datos Oracle (estructura cliente/servidor.

• Conectividad entre bases de datos remotas (estructura de bases de

datos distribuidas)

• Portabilidad.

• Compatibilidad.

ARQUITECTURA CLIENTE SERVIDOR.

Los sistemas cliente/servidor involucran varias computadoras conectadas a una red. Las

computadoras que procesan programas de aplicaciones se conocen como clientes y las

que procesan bases de datos se conocen como servidor. Arquitectura Cliente Servidor

Un sistema cliente servidor puede tener varios servidores de procesamiento de bases de

datos, cuando esto ocurre cada servidor debe procesar una base de datos distinta. Cuando

dos o más servidores procesan una misma base de datos, el sistema no es considerado

cliente servidor, más bien, es conocido como sistema de base de datos distribuido.

QUÉ ES UN CLIENTE

Es el que inicia un requerimiento de servicio. El requerimiento inicial puede convertirse en

múltiples requerimientos de trabajo a través de redes LAN o WAN. La ubicación de los

datos o de las aplicaciones es totalmente transparente para el cliente.

Funciones del cliente:

• Administrar la interfaz de usuario.

• Aceptar datos del usuario.

• Procesar la lógica de la aplicación.

• Generar las solicitudes para la base de datos.

• Trasmitir las solicitudes de la base de datos al servidor.

• Recibir los resultados del servidor.

• Dar formatos a los resultados.

TIPOS DE CLIENTES

• "cliente flaco": Servidor rápidamente saturado.

Gran circulación de datos de interface en la red.

• "cliente gordo": Casi todo el trabajo en el cliente.

No hay centralización de la gestión de la BD.

Gran circulación de datos inútiles en la red.

QUÉ ES UN SERVIDOR

Es cualquier recurso de cómputo dedicado a responder a los requerimientos del cliente.

Los servidores pueden estar conectados a los clientes a través de redes LANs o WANs,

para proveer de múltiples servicios a los clientes y ciudadanos tales como impresión,

acceso a bases de datos, fax, procesamiento de imágenes, etc.

Funciones del servidor:

• Aceptar las solicitudes de la base de datos de los clientes.

• Procesar las solicitudes de los clientes.

• Dar formato a los resultados y trasmitirlos al cliente.

• Llevar a cabo la verificación de integridad.

• Mantener los datos generales de la base de +{}datos.

• Proporcionar control de acceso concurrente.

• Llevar a cabo la recuperación.

• Optimizar el procesamiento de consulta/actualización. Una desventaja de los

sistemas cliente servidor es el control. Las computadoras clientes operan en

forma simultánea y procesan las aplicaciones en paralelo, lo cual hace más

difícil el control de los problemas de pérdidas por actualización y otros

problemas que provoca el control multiusuario.

TIPOS DE SERVIDOR

• Servidores de archivos

Servidor donde se almacena archivos y aplicaciones de productividad como por ejemplo

procesadores de texto, hojas de cálculo, etc.

• Servidores de bases de datos

Servidor donde se almacenan las bases de datos, tablas, índices. Es uno de

los servidores que más carga tiene.

• Servidores de transacciones

Servidor que cumple o procesa todas las transacciones. Valida primero y recién genera un

pedido al servidor de bases de datos.

• Servidores de Groupware

Servidor utilizado para el seguimiento de operaciones dentro de la red.

• Servidores de objetos

Contienen objetos que deben estar fuera del servidor de base de datos. Estos objetos

pueden ser videos, imágenes, objetos multimedia en general.

• Servidores Web

Se usan como una forma inteligente para comunicación entre empresas a través de

Internet.

FILOSOFÍA CLIENTE SERVIDOR:

El término cliente/servidor describe un sistema en el que una máquina cliente solicita a

una segunda máquina llamada servidor que ejecute una tarea específica.

El cliente suele ser una computadora personal común conectada a una LAN, y el servidor

es, por lo general, una máquina anfitriona, como un servidor de archivos PC, un servidor

de archivos de UNIX o una microcomputadora o computadora de rango medio.

PREVIO A LA INSTALACIÓN DEL SISTEMA DE GESTIÓN DE BASES DE DATOS ORACLE

Para establecer un entorno de trabajo en Oracle vamos a necesitar:

1. Software Oracle para servidor (Oracle Server Software)

Una versión determinada específicamente diseñada para un sistema operativo concreto

(UNIX,

Windows NT, etc.).

Este software incluye los ejecutables para el funcionamiento del propio gestor de la base

de datos, un conjunto de herramientas para el tratamiento de la información y

un software específico (Net8) para que sean posibles las conexiones de los usuarios

al servidor en arquitecturas cliente/servidor.

2. Software Oracle para cliente (Oracle Cliente Software)

Este software se ubicará en los puestos de trabajo de los usuarios (también bajo un

determinado sistema operativo-9i Windows 95, NT, etc.), el cual estará formado

por un conjunto de herramientas específicas para cliente/servidor (Designar/2000,

Developper/2000, etc.) y de su correspondiente software (Net8) para el

establecimiento de las conexiones al servidor.

3. Archivos de base de datos

La base de datos en sí, los cuales serán creados a través de herramientas o comandos

específicos de Oracle. La ubicación de la base de datos se realizará sobre los discos del

propio servidor donde se ha establecido el Oracle Server Software.

4. Recursos suficientes en nuestro servidor

Previamente, habrá que realizar un estudio de nuestro sistema de información para

conocer el alcance del mismo. Posteriormente, habrá que estimar la cantidad de

memoria, discos y unidades centrales de proceso que van a ser necesarias para un

correcto funcionamiento.

Oracle requiere estos requisitos mínimos:

Windows 2000 con service pack 1 o Windows XP Professional o Windows 2003 Server

Protocolo TCP/IP o TCP/IP con SSL 3

256 MB de memoria RAM

Al menos 200 MB de memoria virtual mínima y 400 MB de máxima VGA de 256 colores,

140 MB en el disco duro del sistema (normalmente C) y otras 300 MB más en ese

mismo disco para el software de Administrador y otras herramientas de Oracle.

Además se requiere 2,85 GB en el disco que albergará la carpeta raíz de Oracle, el

llamado Oracle Home, 1 GB más si se usa el Oracle Management Server y otros 2,35 GB

más si se usa el Oracle Internet Directory. Las herramientas de administrador

requieren 750 MB y las de ejecución (Runtime) otras 300 MB.

Además hay que tener en cuenta que los tamaños de disco indicados sólo son válidos si se

usan discos duros con el sistema NTFS, si es FAT32 hay que doblar el tamaño

(llegando a las 13 GB con instalación absoluta).

Se requiere también un navegador web. Especialmente Internet Explorer 5 o superior o

Netscape 4.7 o superior (o cualquiera compatible)

5. Desinstalar el software Oracle previo.

Si tuviera una versión de Oracle anterior, deberá desinstalarlo.

6. Desinstalar Oracle

Para una instalación limpia o bien porque ya no se desea utilizar el SGBD Oracle, a veces

se requiere desinstalar este software. El proceso de desinstalación ha de ser muy

cuidadoso para evitar dejar residuos en el ordenador.

Los pasos son:

• Desinstalar el software de Oracle

• Borrar las entradas en el registro de Windows

• Cambiar las variables de entorno de Oracle

• Reiniciar el ordenador

• Borrar las carpetas de Oracle

INSTALACION DE ORACLE

Antes de instalar hay que tener en cuenta que debemos asegurar que disponemos de 400

MB en el disco duro. Este espacio es temporal. Por defecto se tomará en la carpeta

TEMP del sistema, hay que comprobar de que el disco duro en el que se encuentra esa

carpeta dispone de ese espacio, de otro modo habrá que cambiar la ubicación de TEMP a

otro disco duro con ese espacio.

Para cambiar la ubicación de esa carpeta se debe modificar la ruta de la variable de

entorno temp (desde el apartado de variables de entorno en Sistema en el Panel de

Control.

Pasos en la instalación

ORACLE DATABASE

Tras lanzar la instalación, se ejecuta el Universal Installer de Oracle, el programa Java

encargado de realizar las instalaciones y desinstalaciones. Tras su ejecución ocurre lo

siguiente:

1. Aparecerá la ventana de bienvenida del instalador. Pulsar Siguiente

2. Elegir una ruta para la carpeta Home de Oracle. Esa carpeta es la encargada de

almacenar el software de base de datos de Oracle. Se nos pregunta qué nombre

tendrá esa carpeta Home (por defecto se llama OraHome92) y la ubicación de la

misma (normalmente dentro de la carpeta Oracle en el disco con más espacio

disponible). Pulsar Siguiente

3. Aparece una lista con las posibles instalaciones que permite el CD.

Lógicamente se elegirá Database si es la base de datos lo que queremos instalar.

4. La opción “Client” permite instalar sólo las aplicaciones necesarias para utilizar un

servidor Oracle previamente instalado (la instalación cliente puede instalar

herramientas de Administración o herramientas Runtime, para desarrolladores).

5. En la siguiente pantalla se nos pregunta qué versión de Oracle instalaremos. Se nos

ofrecen tres posibilidades:

Versión Enterprise. Versión con todas las posibilidades de Oracle

Versión Estándar. Versión para grupos de trabajo o aplicaciones de un solo

departamento.

Versión Personal. Como la Enterprise pero para un solo usuario y ordenador

Personalizada. Permite clarificar mejor la forma de instalar Oracle (es la más

complejo, pero la que más opciones permite)

Elegir nuestra opción y pulsar Siguiente

6. Se nos pregunta (salvo que hayamos elegido la versión personalizada) por el tipo

de base de datos que se creará en la instalación. Ya en la instalación se crea una

base de datos que puede ser:

Propósito general. Bases de datos que se utilizan para todo tipo de tareas (ante la

duda conviene utilizar esta opción).

Procesamiento de transacciones, preparada para utilizar transacciones muy a

menudo.

Almacenes de datos, base de datos pensada para primar el almacenamiento de

grandes volúmenes de datos (Warehousing).

Personalizada, permite especificar más claramente la base de datos a utilizar (esta

opción requiere más pasos que las otras)

Sólo software, instala el software de base de datos sin crear una primera base de

datos (habrá que crearla más adelante.

7. Elegir la opción preferida (ante la duda elegir uso General) y pulsar Siguiente.

8. Si se está migrando de una versión anterior aparecerá un cuadro que nos permite

migrar (o no) los datos de la versión anterior.

9. Si el equipo tiene Microsoft Transaction Server se nos pedirá el número de puerto

(normalmente el 2030) que ha de utilizarse para usar dicho software de

transacciones.

10. Se nos pide el identificador (SID, System Identifier) y el nombre global de la base

de datos. El nombre global es un nombre único para la red a la que pertenece el

servidor en el que instalamos Oracle (por ejemplo inicial.donbosdco.local). El SID

es el nombre que identifica a la base de datos en el ordenador en el que estamos.

En el cuadro se pone primero el nombre global el instalador sugiere el SID

correspondiente. Pulsar Siguiente

11. Indicar la ruta en la que se instalarán por defecto los archivos de la base de datos.

Es conveniente que esta carpeta esté en una unidad distinta a la de la carpeta

Home de Oracle, para acelerar el rendimiento. Esta carpeta se suele llamar

OraData.

12. Indicar el juego de caracteres que se utilizará en la base de datos. Normalmente se

toma el juego de caracteres que utiliza el sistema operativo. Este dato si se rellena

mal ocasiona que algunos de nuestros caracteres nacionales, nunca se muestren

adecuadamente.

13. Tras aceptar el cuadro anterior se nos muestra un resumen de la instalación. Tras

este resumen comienza la copia de los archivos en nuestro disco duro. Este es el

paso más largo, se pueden tardar bastantes minutos (incluso alguna hora) en

completarse).

14. En segundo plano se configurarán los servicios de red necesarios para el

funcionamiento de Oracle, la base de datos y el servidor http de Oracle. (Ver

imagen anterior).

15. En cuanto se instala la base de datos y se lanza la instancia asociada a ella (la

instancia es la base de datos en ejecución, desde ese instante al arrancar Windows

la instancia estará en memoria salvo que la detengamos) se nos piden las

contraseñas asociadas a los usuarios administrativos SYS y SYSTEM. Es muy

importante recordarlas y no perderlas.

16. Tras el paso anterior se lanza el Agente de Oracle (Oracle Intelligent Agent) y el

servidor http. Al final se indicarán los puertos necesarios para comunicar con el

servidor http de Oracle (añadiendo el texto /isqlplus a esa dirección se podrá

conectar desde un navegador con el servidor Oracle vía http). En el caso de

instalaciones más personalizadas se nos preguntarán más datos sobre la

configuración de la base de datos y el servidor http, pero eligiendo las opciones

indicadas en este manual, no habrá más preguntas.

17. En el caso de instalaciones más personalizadas se nos preguntarán más datos

sobre la configuración de la base de datos y el servidor http, pero eligiendo las

opciones indicadas en este manual, no habrá más preguntas.

PRUEBA DE LA INSTALACIÓN.

Para comprobar si la instalación es correcta, se debe hacer lo siguiente.

1. Ir al grupo de programas de Oracle en Windows (normalmente Inicio-Programas-

Oracle Home92) y hacer clic sobre Enterprise Manage Console (consola de

administración).

2. Activar la casilla Iniciar en modo autónomo y aceptar el cuadro.

3. Desde el programa de administración, expandir el apartado Bases de datos.

Aparecerán las bases que hemos creado, después se nos pedirá un nombre de

usuario y contraseña para conectarnos con la base de datos. Inicialmente habrá

que conectar con el usuario SYSTEM y la contraseña que especificamos para dicho

usuario en la instalación indicar que conectamos como SYSDBA (administrador) lo

que nos permite realizar todo tipo de tareas.

4. Si aparecen subapartados dentro de la base de datos (Instancia, Seguridad,...) es

que hemos conectado correctamente. Podremos realizar cualquier operación de

administración sobre la base de datos.

CONECTAR MEDIANTE ISQL*PLUS

Durante la instalación se habrá iniciado un servidor http para Oracle. Para verificar que

funciona habrá que probar si podemos conectar con él. Para ello, simplemente hay que

abrir un navegador cualquiera (Explorer por ejemplo) y escribir http:// seguido del

nombre de nuestro ordenador dos puntos y el número de puerto en el que se instaló el

servidor (se nos indicó el mismo durante la instalación, véase paso 16 de la instalación),

por ejemplo http://ordenata:7778. Si sale bien aparecerá la pantalla del servidor Apache.

Si a la dirección anterior le añadimos /isqlplus (por ejemplo

http://ordenata:7778/isqlplus) entonces aparece la pantalla inicial de iSQL*Plus:

ORACLE CLIENT

Tras lanzar la instalación, se ejecuta el Universal Installer de Oracle, el programa Java

encargado de realizar las instalaciones y desinstalaciones. Tras su ejecución ocurre lo

siguiente:

1. Aparecerá la ventana de bienvenida del instalador. Pulsar Siguiente

2. Pulsaremos en "Siguiente" y seleccionamos el destino (carpeta) de instalación:

3. Seleccionaremos "Oracle9i Cliente”:

4. Dependiendo de las utilidades que queramos instalar seleccionaremos

"Administrador"

(instala todas las herramientas para administrar Oracle desde un PC Cliente),

"Runtime"

(instala las herramientas básicas para acceso a Oracle, es la recomendada)

"Personalizada" (permite seleccionar las herramientas a instalar):

5. Dejaremos el puerto por defecto 2030 para "Oracle Services para Microsoft

Transaction

Server". Este puerto no es relevante si no tenemos un Cluster de servidores:

6. Una vez comprobadas las herramientas que se van a instalar pulsaremos en

"Instalar":

7. Tras la instalación realizaremos la configuración de red de Oracle

8. Desmarcaremos la opción "Realizar una configuración típica" y

pulsaremos en "Siguiente".

9. Marcamos "No, deseo diferir la configuración" y pulsamos en "Siguiente".

10. Pulsamos en "Siguiente".

11. Marcamos "Base de datos o servicio Oracle8i o posterior" y pulsamos en

"Siguiente"

12. Introducimos el nombre del servicio que normalmente coincidirá con el de la base

de datos a la que nos conectaremos.

13. Seleccionamos el protocolo TCP y pulsamos en "Siguiente".

14. Introducimos el nombre o IP del PC que tiene la base de datos de Oracle (servidor

de

Oracle) y pulsamos en "Siguiente".

15. Si aparece algún error en la primera prueba de conexión es habitual pues

utiliza el usuario y contraseña que Oracle configura por defecto. Para

probar la conexión correctamente pulsaremos en "Cambiar Conexión" e

introduciremos un usuario y contraseña existentes en la Base de Datos. Si no

hay problemas mostrará "Conectado... Prueba realizada correctamente".

16. Introduciremos el nombre de red, que por defecto será el mismo que el nombre

de la base de datos y pulsamos en "Siguiente".

17. Pulsamos en "Siguiente".

18. Pulsamos en "Siguiente".

19. Pulsamos en "Terminar".

20. Pulsamos en "Finalizar".

ARQUITECTURA DE ORACLE

Una Base de Datos (BD) Oracle es un conjunto de datos organizados según el modelo

relacional.

Cada servidor de Oracle está constituido por una BD y una instancia.

Base de Datos (BD) es el lugar donde se almacenan los datos esta instancia constituye el

mecanismo que permite su manipulación.

La Base de Datos Oracle se compone de:

1. Estructura lógica: compuesta por tablespaces y un conjunto de objetos

(tablas,vistas,índices...).

2. Estructura física: tres tipos de ficheros:

• uno o más ficheros de datos,

• dos o más ficheros de rehacer y

• uno o más ficheros de control.

Una instancia es el conjunto de estructuras de memoria (SGA) y procesos en background:

• Procesos de usuario: Ejecutan el código de una aplicación.

• Procesos de Oracle: Atienden a los procesos de usuario y realizan el

mantenimiento de la BD.

1. Estructura de la Base de Datos

1.1 Ficheros de datos y espacios de tablas.

Oracle almacena lógicamente los datos en unas estructuras llamadas tablespaces, las

cuales se almacenan físicamente en datafiles (ficheros de datos).Las BD se componen de

uno o más tablespaces. Cada tablespace consiste de uno o más ficheros de datos. Cada

fichero de datos no puede contener más de un tablespace.

Oracle cuenta con un tablespace especial llamado SYSTEM creado automáticamente

durante el proceso de instalación. Utilizado para la propia gestión de la BD.

Una BD puede estar constituida únicamente por un tablespace SYSTEM: recomendable

crear al menos un tablespace adicional.

TAREAS DEL ADMINISTRADOR DE LA BASE DE DATOS.

• Controlar el espacio de disco reservado para los datos.

• Añadir datafiles a los tablespaces.

• Asignar cuotas de espacio a los usuarios.

• Realizar copias de seguridad o recuperaciones parciales de la BD.

Los tablespaces constituyen la ‘ventana’ a través de la cual los usuarios y diseñadores de

la BD ven los datos almacenados en los datafiles. Administrador encargado de mantener

las relaciones entre tablespaces y datafiles.

1.2 Objetos.

Un objeto Oracle es un elemento creado y almacenado en la BD (en los tablespaces).

Ejemplos: tablas, vistas, sinónimos, índices, secuencias, clusters etc.

a) Tablas:

Unidad básica de almacenamiento de datos que consta de un número fijo de

columnas que describen los atributos de la entidad que representa la tabla. Cada

columna es de un tipo de datos y se identifica por un nombre, sobre la tabla se

pueden imponer restricciones.

Tipos de restricciones:

-Clave primaria (PRIMARY KEY)

-Valor nulo no admitido (NOT NULL)

-Columna exclusiva (UNIQUE)

-Valor por omisión (DEFAULT).

-Clave ajena (FOREIGN KEY).

b) Esquema:

Es el conjunto de objetos que posee una cuenta, para referirnos a un objeto

determinado deberemos indicar a que esquema pertenece:

nom_esquema.nom_objeto.

c) Vistas:

Una vista es básicamente un subconjunto de las columnas y/o filas de una tabla (u

otras vistas), se define como una consulta y es tratada como una tabla.

Una vista no almacena datos, sólo se almacena la consulta que la define.

d) Secuencias:

Cada secuencia genera una serie única de números, útil en la generación única de

claves.

Pueden ser cíclicas o crecer hasta un valor máximo

e) Sinónimos:

Identificador alternativo para denotar un objeto, se utilizan para: enmascarar el

nombre y propietario de un objeto, dar transparencia a objetos remotos de BD

distribuidas y simplificar sentencias SQL.

f) Índices:

Proporcionan un acceso más rápido a los datos, una vez creados son mantenidos

por Oracle y utilizados para la recuperación de datos. Se pueden crear hasta un

máximo de 32 columnas.

g) Clusters:

Agrupamiento de tablas que se almacenan juntas físicamente.

Ventajas:

-Se reduce el acceso a disco cuando están involucradas esas tablas

-Las columnas comunes se almacenan una sola vez.

h) Procedimientos, funciones, paquetes:

Funciones y procedimientos son bloques de sentencias PL/SQL que se almacenan

en el diccionario de datos, se pueden agrupar procedimientos y funciones en

paquetes.

i) Disparadores:

Procedimientos que se ejecutan cuando se produce un evento en la BD, se utilizan

para aumentar la integridad referencial, conseguir mayor seguridad o mejorar las

opciones de auditoría.

j) Enlaces de BD:

Sirven para especificar una vía de acceso a un objeto situado en una BD remota.

1.3 Bloques de datos, extensiones y segmentos.

Bloques de datos

Unidad de entrada/salida más pequeña usada por Oracle, se define en la creación

de la BD y no se puede modificar.

Extensiones

Una extensión está compuesta por un número específico de bloques de datos

contiguos en disco.

Segmentos

Conjunto de extensiones no necesariamente contiguas en disco, alojan los objetos

de la BD (tablas, índices, clusters, etc).

Un segmento es creado inicialmente con al menos una extensión: INITIAL EXTENT,

se añade otra extensión (INCREMENTAL EXTENT) cuando se llena. Tamaño

depende del tipo de datos que almacene.

1.4 Archivos de registros de rehacer y de control

Archivos de registros de rehacer

Almacenan las modificaciones realizadas en la BD por las transacciones, se utilizan

para recuperar la BD en caso de fallo.

Estos archivos permiten también que se optimice el rendimiento de la BD

(se realizan series de escrituras a disco).

Se deben tener al menos dos ficheros (redo logs) circulares, se escribe en ellos de

forma circular: cuando se llena uno de ellos se pasa al siguiente. Cuando se llena el

último se vuelve a utilizar el primero.

El fichero que se está actualmente utilizando se llama activo y al resto inactivos, si

la BD está trabajando en modo ARCHIVELOG cuando se llene el último archivo se

realiza una copia de ellos en alguna unidad de almacenamiento.Cada vez que se

vacían bloques desde la memoria de Oracle a los ficheros físicos se produce un

checkpoint.

Archivos de control

Un fichero de control contiene entradas que especifican la estructura física de la

BD, se encuentra la siguiente información: nombre de la BD, nombre y localización

de los ficheros de datos y ficheros de rehacer, fecha de creación de la base de

datos.

Se utiliza cada vez que se arranca la BD, los nombres y ubicación de estos

ficheros se especifica con el parámetro control_files del fichero config.ora.

2. Arquitectura de la BD

2.1 Estructuras de memoria

Cuando se arranca la BD, Oracle reserva un área de memoria llamada System

Global Area (SGA) y arranca una serie de procesos.

Una instancia es la combinación de la SGA y los procesos.

Estructuras básicas asociadas a una instancia

• Área de código de programas:

Porciones de memoria usadas para almacenar código que está siendo o puede ser

ejecutado. El tamaño de esta área es fijo y depende del sistema operativo.

• Área global del programa:

Cada vez que un proceso de usuario se conecta a la BD y se crea una sesión se le

aloja un área global del programa. Contiene datos e información de control de

dicho proceso.

• Área de ordenación:

Cuando una consulta solicita una ordenación de un resultado, ORACLE utiliza una

zona de memoria del proceso de usuario.

• Área global del sistema:

a) Búferes del bloque de datos (DBB):

Es una porción del SGA que almacena los bloques de datos más recientemente

usados. Pueden contener datos modificados todavía no escritos a disco.

Aumenta la eficiencia del sistema ya que se requieren menos accesos a disco.

b) Búfer del registro de rehacer:

c) Búfer circular que mantiene información sobre los cambios realizados en la BD.

Información necesaria para reconstruir los cambios hechos a la BD por las

instrucciones: insert, update, delete, create, alter o drop.

d) Fondo compartido:

Es un área donde se encuentran construcciones tales como el área de SQL

compartida y la cache del diccionario de datos.

Información almacenada en la caché del diccionario de datos:

• Nombre de todas las tablas y vistas de la BD.

• Nombre y tipos de todas las columnas de las tablas de la BD.

• Privilegios de todos los usuarios.

• Tamaño de esta área: SHARED_POOL_SIZE.

2.2 Procesos

Los procesos se dividen en dos categorías: procesos de usuario y procesos de

Oracle.

Procesos de usuario son las aplicaciones en sí, que realizan peticiones a la BD.

Los procesos ORACLE se pueden dividir en 2 tipos:

• Procesos servidores: atienden las peticiones del usuario y se comunican con

ORACLE a través de SGA.

Compilan y ejecutan las sentencias SQL.

Leen los bloques de datos desde el disco a los búferes.

Devuelve el resultado de las operaciones a la aplicación.

• Procesos background gestionan los recursos de la BD.

• Escritor de la BD (DBWR).

• Escritor de registros (LGWR).

• Punto de control (CKPT).

• Supervisor del sistema (SMON).

• Supervisor del proceso (PMON).

• Archivador (ARCH).

• Recuperador (RECO).

• Bloqueo (LCKn).

• Despachador (Dnnn).

• Escritor de la BD (DBWR)

Es el proceso encargado de escribir todos los búferes a los ficheros de

datos. Mantener limpio los búferes de bloque de datos.

• Escritor de registros (LGWR)

Se encarga de escribir los registros del bufer de rehacer al fichero de rehacer.

• Punto de control (CKPT)

Cuando se alcanza un punto de control se deben actualizar las cabeceras de los

ficheros para señalizarlo.

• Supervisor del sistema (SMON)

Este proceso tiene asignada varias tareas:

-Recupera la instancia cuando esta se arranca.

-Limpia los segmentos temporales cuando se dejan de utilizar.

-Junta el espacio libre en disco.

• Supervisor de procesos (PMON)

Es el encargado de la recuperación de los procesos cuando falla un proceso de

usuario.

Tareas:

-Limpiar recursos que tuviera cogidos en la cache.

-Liberar los posibles bloqueos.

-Eliminar de la tabla de transacciones activas las de este proceso.

-Quitar de la lista de procesos activos a los que se hayan caído.

• El PMON se activa cada cierto tiempo igual que el SMON o lo pueden activar otros

procesos.

• Recuperador (RECO)

Encargado de resolver los fallos de las transacciones dudosas en BD distribuidas.

Este proceso se conecta a todas las BD involucradas en una transacción dudosa.

Cuando consigue la conexión se elimina esta transacción de la tabla de

transacciones pendientes de las otras BD.

• Archivador (ARCH)

La tarea de este proceso consiste en copiar los ficheros REDO_LOG que se hayan

llenado los ficheros de rehacer.

• Bloqueo (LCKn)

En instalaciones con servidor paralelo se utiliza para gestionar los bloqueos entre

las distintas instancias de una misma BD.

• Despachador (Dnnn)

Este proceso permite compartir a los procesos de usuario un número limitado de

procesos servidores.

3. Configuraciones de ORACLE

• Procesos usuario y servidor combinados

Para cada usuario ambos módulos de código (aplicación y servidor) son

combinados en un solo proceso.

Factible en sistemas operativos que puedan mantener la separación entre la

aplicación y el código de Oracle en el mismo proceso.

• Servidor dedicado

Para cada usuario, la aplicación (proceso usuario) es diferente del código ejecutado

por el servidor.

Proceso usuario es ejecutado en una máquina y el proceso servidor en otra.

También se puede ejecutar el proceso de usuario y el servidor en la misma

máquina.

• Servidor multi-thread

Cada usuario ejecuta un proceso usuario diferente del código ejecutado por el

servidor.

Además cada proceso servidor puede servir a múltiples procesos usuarios.

Varios procesos de usuario se conectan con un proceso dispatcher , el despachador

(dispatcher) distribuye las peticiones de los procesos cliente entre los procesos

servidores.

El número de usuarios puede ser mayor que con un servidor dedicado.

4. Concurrencia Oracle

La ejecución concurrente de varias transacciones debe garantizar que producirán el

mismo resultado que las mismas en serie.

En general, las BD multi-usuarios utilizan bloqueos en el control de concurrencia.

Niveles de bloqueo:

Bloqueo exclusivo. No permite que un recurso sea compartido. La primera transacción

que lo bloquea es la única que puede alterarlo.

Bloqueo compartido. Permite que un recurso sea compartido. Muchas transacciones

pueden adquirir este tipo de bloqueo sobre el mismo recurso.

4.1 Control de concurrencia multiversión

Oracle automáticamente proporciona consistencia de lectura: datos que una consulta

ve son de un mismo punto en el tiempo (consistencia de lectura a nivel de sentencia).

También puede proporcionar consistencia de lectura a todos las consultas de una

transacción (consistencia a nivel de transacción).

¿Cómo?

- Oracle utiliza la información existente en el segmento de anulación (datos

antiguos).

- Cuando una consulta comienza se le asigna un número (SCN).

- Datos leidos por una consulta tienen un SCN más pequeño.

- Bloques con SCN más alto (más reciente) son reconstruidos con la

información contenida en el segmento de anulación.

Oracle proporciona consistencia de lectura a dos niveles:

Nivel de sentencia:

Oracle garantiza que los datos devueltos por una consulta son consistentes con

respecto al tiempo en que empezó la consulta.

Nivel de transacción:

Los datos vistos por todas las consultas de una transacción son consistentes con

respecto a un punto en el tiempo.

Se debe indicar que la transacción es Read-Only, si las transacciones son de solo

lectura, se actúa como en el caso anterior.

Si existen otro tipo de consultas (modificar, borrar,insertar..) se deben utilizar

bloqueos.

Oracle proporciona tres niveles de aislamiento:

read-committed: Nivel de aislamiento por defecto. Cada consulta de una transacción

solo ve los datos que fueron confirmados antes de que la consulta comenzara. Se

producen lecturas no reproducibles.

serializable transactions: Solamente se ven los cambios realizados por transacciones

confirmadas + cambios efectuados por ella misma.

read-only : transacciones de solo lectura ven datos confirmados antes de empezar y

no permiten modificaciones de los datos.

serializable : -Adecuado cuando es poco probable que dos transacciones concurrente

modifiquen las mismas filas.

Cuando las transacciones de larga duración son principalmente de solo lectura.

No aparecen lecturas no reproducibles.

4.2 Bloqueos en Oracle

Son los mecanismos que utiliza Oracle para evitar que dos transacciones accedan al

mismo recurso.

Automáticamente Oracle obtiene los bloqueos necesarios cuando ejecuta alguna

sentencia en SQL.

ORACLE utiliza el nivel menos restrictivo guiándose por las siguientes reglas:

• Operaciones de lectura no esperan a las de escritura sobre los mismos datos.

• Operaciones de escritura no esperan a las de lectura sobre los mismos datos.

• Operaciones de escritura solamente esperan a otras operaciones de escritura que

intentan modificar la misma tupla.

5. Recuperación en Oracle

Siempre existe la posibilidad de que el sistema falle: se debe recuperar la BD lo más

rápidamente posible e intentar que exista una pérdida de datos mínima.

Las recuperaciones requieren los siguientes pasos:

1. Determinar qué estructuras de datos está intacta y cuáles necesitan recuperación.

2. Seguir según el caso los pasos apropiados

3. Restaurar la BD para que continúe el funcionamiento normal.

4. Asegurarse que no se ha perdido ningún dato.

Posibles fallos:

• Fallo del usuario:

Un error del usuario (ej. borrado de tabla) puede requerir recuperar la BD a un pto

anterior al error.

• Fallo del proceso:

Cuando un proceso que está accediendo a la BD falla. El proceso PMON se encarga

de detectar el fallo realizando un rollback de la transacción en curso así como de

los recursos utilizados.

• Fallo de la instancia:

Cuando una instancia se aborta inesperadamente se necesita una recuperación de

la instancia. Oracle la recupera automáticamente cuando se arranca la BD.

1. Rolling forward para recuperar los ficheros redo loglos datos que no han

sido grabados en los ficheros de datos.

2. Rolling back las transacciones que han sido explícitamente rechazadas o

no han sido aceptadas

3. Eliminar cualquier bloqueo de las transacciones en el momento del

fallo.

4. Resolver cualquier transacción pendiente de confirmación en dos fases

(BD distribuida).

• Fallo físico de algún fichero:

Ocurre cuando un disco, un fichero o una porción de un fichero no puede leerse

por estar dañado.

La recuperación depende del modo archivelog.

• Si la BD opera sin archivar los ficheros de rehacer (NO ARCHIVELOG) la

recuperación consiste en una simple recuperación de la última copia de

seguridad completa.

• Si la BD opera en el modo ARCHIVELOG la BD puede recuperarse a un

estado consistente en el tiempo especificado.

5.1 Copias de seguridad

• Copia física off-line

Se copiarán todos los ficheros de la BD con ella parada: esto nos asegura que

tenemos la BD en un estado consistente.

• Copia física on-line

En este modo la BD se salva consistente hasta el comienzo de la copia de

seguridad.

Ventaja: se puede realizar una copia de seguridad mientras los usuarios están

trabajando.

5.2 Recuperación

Se tiene que realizar cuando ocurre algún desastre.

La pérdida podría darse en todos los ficheros como son:

Ficheros de datos.

Ficheros de control

Ficheros de rehacer

Ficheros archive log

REPLICACIÓN Y DISTRIBUCIÓN DE BASES DE DATOS CON ORACLE.

La replicación y la distribución de bases de datos es una tecnología usada en servidores y

redes de almacenamiento. En el caso de Replicación de Bases de Datos una vez que los

datos han sido escritos en el sitio de almacenamiento primario, nuevas escrituras a ese

sitio pueden ser aceptadas, sin tener que esperar que el sitio de almacenamiento

secundario o remoto también termine su escritura. La desventaja de la replicación, está en

la posibilidad de pérdida de datos, si ocurre que el sitio primario falla antes de que los

datos hayan sido escritos en el sitio secundario, de todas formas la Replicación es una

alternativa muy interesante para trabajar con varios usuarios a la vez sin hacer colapsar

nuestra Base de Datos por encontrarse trabajando con una réplica que luego será unida a

su Base original.

En el caso de Distribución de Bases de Datos Se trata de una base de datos a nivel lógico

(los usuarios la manejan como una base de datos normal), pero que en realidad

(físicamente) está implementada en varias ubicaciones físicas, incluso en máquinas

diferentes y distantes.

Cada máquina ejecuta su propia instancia y conjuntos de archivos y todas se conectan en

red para hacer que el usuario no tenga que cambiar su código para reflejar esta

distribución. La dificultad de esta estructura suele estar aliviada por medio de

instantáneas que graban momentáneamente los datos de las tablas distantes. Permiten

trabajar con los datos copiados y se programan para que cada cierto tiempo recojan

nuevamente los datos a fin de reflejar sus cambios.

Gracias a las instantáneas no hace falta una sobrecarga tan excesiva de las instantáneas de

la base de datos.

DISTRIBUCIÓN DE BASE DE DATOS

Definición: Un sistema gestión de bases de datos distribuida no es más que el software

que permite la administración de la base de dato distribuida y hace que tanto como la

distribución y el control de concurrencia de las transacciones, las fallas, sean transparente

para el usuario que opera con el sistema. Cuando las bases de datos son distribuidas,

diferentes usuarios tienen acceso sin interferir unos con otros. Sin embargo, el sistema de

gestión de bases de datos distribuidas (SGBBD) debe sincronizar periódicamente las bases

de datos dispersas, para asegurar que todas tengan sus datos uniformes. El acceso a los

datos en los SBDD se realiza mediante los enlaces de comunicación que conformen la red

en la que se encuentren los sitios que contengan alguna de las partes los datos. Los sitios

pueden estar en una habitación o geográficamente separados, cada uno de ellos tiene

capacidad de procesamiento autónomo y de ejecución de aplicaciones locales.

ARQUITECTURA DE UN SISTEMA DE BASE DE DATOS DISTRIBUIDA

En un sistema de bases de datos distribuidas, existen varios factores que deben tomar en

consideración que definen la arquitectura del sistema:

• Distribución: Los componentes del sistema están localizados en la misma

computadora o no.

• Heterogeneidad: Un sistema es heterogéneo cuando existen en él componentes

que se ejecutan en diversos sistemas operativos, de diferentes fuentes, etc.

• Autonomía: Se puede presentar en diferentes niveles, los cuales se describen a

continuación:

- Autonomía de diseño: Habilidad de un componente para decidir cuestiones

relacionadas a su propio diseño.

- Autonomía de comunicación: Habilidad de un componente para decidir cómo y

cuándo comunicarse con otros SMBD.

- Autonomía de ejecución: Habilidad de un componente para ejecutar

operaciones locales como quiera.

Arquitectura Distribuida de base de datos. La tecnología y prototipo de los sistemas de

gestión de bases de datos distribuidas se han desarrollado de uno a otro y cada sistema

adopta una arquitectura particular propia.

¿Cuál es la diferencia entre un SGBDD homogéneo y otro heterogéneo? ¿En qué

circunstancias es preferible utilizar ambos tipos de sistemas?

La diferencia es que los nodos del sistema homogéneo utilizan el mismo tipo de SGBD

mientras que un sistema heterogéneo puede utilizar diferentes tipos de SGBD

Los homogéneos cuando la implementación de las bases de datos se realizan en conjunto

Los heterogéneos cuando se tienen ya las bases de datos implementadas por separado y

se las quiere integrar para poder comunicarlas

DISEÑO DE UN SISTEMA DE BASE DE DATOS DISTRIBUIDA

Cuando diseñamos un sistema de base de datos distribuida debemos tener en cuenta

algunas características claves que caracterizan este tipo de sistemas, como son:

• Permitir que cada sitio almacene y mantenga su propia BD facilita el acceso

inmediato y eficaz de sus datos que se usan más frecuentes.

• Mejora la fiabilidad si la computadora de un sitio se cae, el resto de la red sigue

funcionando.

• Permitir el control local de los datos en un sitio mejora el grado de satisfacción de

los usuarios con relación al sistema de BD.

• Cuando cada sitio procesa sus datos locales se elimina un poco el tráfico de la red,

pero si los sitios usan frecuentemente datos almacenados en otros sitios las

comunicaciones pueden convertirse en un cuello de botella.

El diseño de una BDD involucra 4 pasos:

1. Diseño del esquema conceptual donde se describe la BD integral.

2. Diseño de fragmentación.

3. Diseño de la asignación de los fragmentos.

4. Diseño de la BD física (transformar los esquemas locales en áreas de

almacenamiento y determinar métodos de acceso apropiados). La fragmentación y

asignación de los datos caracterizan el diseño de BDD. La fragmentación se ocupa

fundamentalmente de los criterios lógicos que motivan la división de relaciones

globales en fragmentos, mientras que la asignación se ocupa de los aspectos físicos de

su ubicación y réplicas en sitios; aunque hay una diferencia entre ambos procesos, su

interrelación es importante para obtener un diseño óptimo. En caso que también se

distribuyan las aplicaciones debemos tener en cuenta el diseño de los esquemas, los

requerimientos más importantes de las aplicaciones tenemos las siguientes:

1. Sitio que comparte una aplicación.

2. Frecuencia de activación de la aplicación

3. Cantidad, tipo y distribución estadística de los accesos de cada aplicación a cada

dato requerido. En el diseño de un sistema de bases de datos distribuidas debemos

tener en cuenta algunas estrategias y objetivos y se deben en paralelo tomar

decisiones sobre cómo hay que distribuir los datos entre los sitios de la red.

A los problemas que presentamos en el diseño de las Bases de Datos Centralizadas (BDC)

se le añaden otros nuevos cuando diseñamos Bases de Datos Distribuidas (BDD) entre los

cuales se destacan la distribución óptima de datos y de las aplicaciones en los diferentes

sitios. Cuando pensamos en el diseño de las bases de datos distribuidas debemos tener en

cuenta la ubicación de los programas que accederán a las bases de datos y sobre los

propios datos que constituyen la base de datos, en diferentes puntos de una red. Sobre la

ubicación de los programas supondremos que tenemos una copia de ellos en cada

máquina donde se necesite acceder a la base de datos. Sin embargo el problema radica en

cómo ubicaremos los datos en la red, existen diferentes formas de repartir los datos: En

solo una maquina que almacene todos los datos y se encargue de responder a todas las

consultas del resto de la red (sistema centralizado), ubicaríamos la base de dato en cada

máquina donde se utilice, o pensaríamos en repartir las relaciones por toda la red.

ORGANIZACIÓN DE UN SISTEMA DE BASE DE DATOS DISTRIBUIDOS

La organización de los sistemas de bases de datos distribuidos se ha clasificado

tradicionalmente sobre el nivel de compartición, características de acceso y nivel de

conocimiento de los datos:

1. Inexistencia. Los datos y programas se ejecutan en un ordenador sin que exista

comunicación entre ellos.

2. Se comparten datos y no programas. Existe una réplica de los programas de aplicación

en cada máquina y los datos viajan a través de la red.

3. Se comparten datos y programas. Los datos y programas se reparten por los diferentes

sitios de la red, dado un programa ubicado en un determinado sitio puede acceder a un

servicio a otro programa de segundo sitio solicitando acceder a los datos ubicados en un

tercero.

DUPLICACIÓN DE DATOS

La duplicación de los datos ocurre si el sistema mantiene varias copias de una relación, R,

con cada copia almacenada en un sitio diferente. Existen dos modelos básicos de replica:

1. Consistencia estrecha. Este modelo que garantiza que todas las réplicas sean

constantemente idénticas a la original, requiere una red de alta velocidad, disminuye la

disponibilidad de la base de datos.

2. Consistencia ancha. El modelo de consistencia ancha permite un retardo entre el

momento en que los datos originales son modificados y las copias de los mismos son

actualizadas, lo que permite que la base de datos esté disponible más tiempo que el

modelo de consistencia estrecha. Permite conexiones tanto rápidas como lentas

soportadas en WANs o LANs. La duplicación se introduce para aumentar la disponibilidad

del sistema: cuando una copia no está disponible debido a un fallo de un sitio sería posible

tener acceso a otra copia. Con la duplicación también se mejora el rendimiento puesto

que las transacciones tienen mayor probabilidad de encontrar una copia localmente. El

inconveniente está en el costo extra del almacenamiento adicional y del mantenimiento

de la consistencia mutua entre las copias cuando tenemos replicación.

PROCESO DE DISEÑO TOP – DOWN.

Top – Down es adecuada cuando creamos un sistema de BD por vez primera sin

restricciones de otros sistemas ya instalados y que deban ser integrados al sistema

distribuido, es decir, primero elaboramos el esquema conceptual global del proyecto y

trabajamos en función de resolver las diferentes partes de dicho proyecto.

El diseño de abajo hacia arriba (bottom-up). Se utiliza particularmente a partir de bases de

datos existentes, generando con esto bases de datos distribuidas. En forma resumida, el

diseño bottom-up de una base de datos distribuida requiere de la selección de un modelo

de bases de datos común para describir el esquema global de la base de datos. Esto se

debe es posible que se utilicen diferentes SMBD. Después se hace la traducción de cada

esquema local en el modelo de datos común y finalmente se hace la integración del

esquema local en un esquema global común

ARQUITECTURA CLIENTE SERVIDOR.

Los sistemas cliente/servidor involucran varias computadoras conectadas a una red. Las

computadoras que procesan programas de aplicaciones se conocen como clientes y las

que procesan bases de datos se conocen como servidor. Arquitectura Cliente Servidor

Un sistema cliente servidor puede tener varios servidores de procesamiento de bases de

datos, cuando esto ocurre cada servidor debe procesar una base de datos distinta. Cuando

dos o más servidores procesan una misma base de datos, el sistema no es considerado

cliente servidor, más bien, es conocido como sistema de base de datos distribuido.

Funciones del cliente:

• Administrar la interfaz de usuario.

• Aceptar datos del usuario.

• Procesar la lógica de la aplicación.

• Generar las solicitudes para la base de datos.

• Trasmitir las solicitudes de la base de datos al servidor.

• Recibir los resultados del servidor.

• Dar formatos a los resultados.

Funciones del servidor:

• Aceptar las solicitudes de la base de datos de los clientes.

• Procesar las solicitudes de los clientes.

• Dar formato a los resultados y trasmitirlos al cliente.

• Llevar a cabo la verificación de integridad.

• Mantener los datos generales de la base de +{}datos.

• Proporcionar control de acceso concurrente.

• Llevar a cabo la recuperación.

• Optimizar el procesamiento de consulta/actualización. Una desventaja de los

sistemas cliente servidor es el control. Las computadoras clientes operan en

forma simultánea y procesan las aplicaciones en paralelo, lo cual hace más

difícil el control de los problemas de pérdidas por actualización y otros

problemas que provoca el control multiusuario.

FILOSOFÍA CLIENTE SERVIDOR:

El término cliente/servidor describe un sistema en el que una máquina cliente solicita

a una segunda máquina llamada servidor que ejecute una tarea específica.

El cliente suele ser una computadora personal común conectada a una LAN, y el

servidor es, por lo general, una máquina anfitriona, como un servidor de archivos PC,

un servidor de archivos de UNIX o una microcomputadora o computadora de rango

medio.

LOS SOCKETS.

“Los sockets no son más que puntos o mecanismos de comunicación entre procesos

que permiten que un proceso hable (emita o reciba información) con otro proceso

incluso estando estos procesos en distintas máquinas”.

Un socket es al sistema de comunicación entre ordenadores lo que un buzón o un

teléfono es al sistema de comunicación entre personas: un punto de comunicación

entre dos agentes (procesos o personas respectivamente) por el cual se puede emitir

o recibir información

El mecanismo de comunicación vía sockets tiene los siguientes pasos:

1) El proceso servidor crea un socket con nombre y espera la conexión.

2) El proceso cliente crea un socket sin nombre.

3) El proceso cliente realiza una petición de conexión al socket servidor.

4) El cliente realiza la conexión a través de su socket mientras el proceso servidor

mantiene el socket servidor original con nombre.

El RPC

(del inglés Remote Procedure Call, Llamada a Procedimiento Remoto) es un

protocolo que permite a un programa de ordenador ejecutar código en otra máquina

remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo

es un gran avance sobre los sockets usados hasta el momento. De esta manera el

programador no tenía que estar pendiente de las comunicaciones, estando éstas

encapsuladas dentro de las RPC.

Las RPC son muy utilizadas dentro del paradigma cliente-servidor. Siendo el cliente el

que inicia el proceso solicitando al servidor que ejecute cierto procedimiento o

función y enviando éste de vuelta el resultado de dicha operación al cliente.

RPC es un protocolo de llamada a procedimiento remoto que usa XML para codificar

los datos y HTTP como protocolo de transmisión de mensajes

CORBA

(Common Object Request Broker Architecture), es una arquitectura estándar para

sistemas de objetos distribuidos. Permite una distribución, colección heterogénea de

objetos para interoperar. Corba es un estándar de sistema de objetos distribuidos que

especifica la arquitectura que debe tener un sistema de objetos distribuidos y establece

un modelo de objetos mínimo, donde cada objeto obedece a una interfaz. CORBA define

una arquitectura para objetos distribuidos. El paradigma básico de CORBA es de una

solicitud para servicios de objetos distribuidos. Los servicios que un objeto provee son

dados por su interface. Las interfaces son definidas en el Lenguaje de Definición de

Interface (IDL).Los objetos distribuidos son identificados por referencias a objetos, las

cuales son definidas por las interfaces IDL.

REPLICACION DE BASE DE DATOS CON ORACLE

Se muestra la forma de replicar de manera sencilla los datos de una base de datos en

oracle hacia otro servidor oracle, mediante el uso de vistas materializadas.

La replicación te permite tener una copia exacta de una base de datos alojada

en un servidor (maestro) que se guardará en otro servidor (esclavo).

Todas las modificaciones que se hagan en la base de datos del servidor

maestro se actualizarán inmediatamente en el servidor esclavo.

Esto no es una copia de seguridad, ya que si borramos una fila en la base de datos

maestra, también se borrará en la base de datos esclava.

A continuación tenemos los pasos para instalar y configurar nuestro servidor para replicar

datos.

QUÉ ES LA REPLICACIÓN

La replicación es el proceso de copiar los objetos y el mantenimiento de base de datos en

varias bases de datos que componen un sistema de base de datos distribuida. Los

cambios aplicados en el mismo sitio se capturan y almacenan localmente antes de ser

transmitida y aplicada en cada una de las ubicaciones remotas. La replicación le

proporciona al usuario un acceso rápido y locales a los datos compartidos y protege la

disponibilidad de aplicaciones debido a opciones alternativas de acceso a datos existen.

Incluso si un sitio no está disponible, los usuarios pueden seguir para consultar o incluso

actualizar las ubicaciones restantes.

OBJETOS DE REPLICACIÓN

Es una base de datos de objetos existentes en varios servidores en un sistema de base de

datos distribuida. En un entorno de replicación, las posibles actualizaciones efectuadas a

un objeto en un sitio de replicación se aplican a los ejemplares en todos los otros sitios.

Avanzada de replicación le permite replicar los siguientes tipos de objetos:

• Tablas

• Indices

• Vistas y vistas de objetos

• Paquetes y Paquetes Cuerpos

• Procedimientos y funciones

• Tipos definidos por el usuario y los órganos de tipo

• Los desencadenantes

• Sinónimos

• Indextypes

• Los operadores definidos por el usuario

En cuanto a las tablas, la replicación soporta características avanzadas tales como tablas

con particiones, tablas organizadas en índices, las tablas con columnas que se basan en

tipos definidos por el usuario, y las tablas de objetos.

TIPOS DE ENTORNOS DE REPLICACIÓN

Avanzada replicación admite los siguientes tipos de entornos de replicación:

• Multimaestro replicación

• Ver materializadas replicación

• Multimaestro y materializada

MULTIMAESTRO REPLICACIÓN.- (también llamados "peer-to-peer o n-forma de

replicación) permite a varios sitios, en calidad de pares iguales, para administrar grupos de

objetos de base de datos replicada. Cada sitio en un entorno de replicación con varios

maestros es un sitio maestro, y cada lugar se comunica con los sitios de otro maestro.

Las aplicaciones pueden actualizar cualquier tabla replicada en cualquier sitio en una

configuración de varios maestros, servidores de bases de datos Oracle que operan como

lugares de maestro en un entorno de trabajo de varios maestros de forma automática a

converger los datos de todas las réplicas de mesa y para garantizar la coherencia global de

las transacciones y la integridad de datos.

La replicación asíncrona.- es la forma más común de implementar la replicación con

varios maestros. Otras formas incluyen la replicación sincrónica y replicación de

procedimiento, que se analizan más adelante en este capítulo. Cuando se utiliza la

replicación asincrónica, información sobre un lenguaje de manipulación de datos (LMD) el

cambio en una tabla se almacena en la cola de transacciones diferidas en el sitio principal

donde se produjo el cambio. Estos cambios se llaman transacciones diferidas. Las

transacciones diferidas se insertan (o se han reproducido) a los sitios de otros maestros

participantes a intervalos regulares. Puede controlar la cantidad de tiempo en un

intervalo.

Uso de la replicación asíncrona significa que los conflictos de datos son posibles porque el

valor de la misma fila que actualizarse en dos sitios diferentes en maestro casi al mismo

tiempo. Sin embargo, puede utilizar las técnicas para evitar conflictos y, si se producen

conflictos, Oracle ofrece precompilados mecanismos que se pueden implementar para

resolverlos. Información acerca de los conflictos no resueltos se almacena en un registro

de errores.

VER MATERIALIZADAS REPLICACIÓN.- Una vista materializada contiene una copia

completa o parcial de un maestro de destino desde un único punto en el tiempo. El

capitán blanco puede ser una tabla maestro en un sitio maestro o una maestra se

materializó la visión en un sitio de vista materializada. Un maestro materializado punto de

vista es una vista materializada que funciona como un maestro de otra vista materializada.

Un multinivel materializado punto de vista es que se basa en otra vista materializada, en

lugar de en una tabla maestra las vistas materializadas proporcionar los siguientes

beneficios:

• Habilitar el acceso local, lo que mejora los tiempos de respuesta y disponibilidad.

• De descarga consultas desde el sitio principal o maestro materializado ver sitio,

porque los usuarios pueden consultar la vista local se materializó en lugar.

• Aumentar la seguridad de los datos por lo que le permite replicar sólo un

subconjunto de los datos del maestro de destino establecido

Una vista materializada puede ser de sólo lectura y actualizables, o puede escribir, y este

tipo de vistas materializadas proporcionan beneficios adicionales a los mencionados

anteriormente.

MULTIMAESTRO Y MATERIALIZADA VER CONFIGURACIONES HÍBRIDAS.- y la replicación

con varios maestros vistas materializadas se pueden combinar de híbridos o

"configuraciones mixtas para cumplir con diferentes requisitos de aplicación,

configuraciones híbridas puede tener cualquier número de sitios principal y varios sitios se

materializó vista para cada maestro.

La Figura con varios maestros (o vías n) la replicación entre dos maestros pueden admitir

la mesa de replicación entre las bases de datos que soportan dos regiones geográficas,

vistas materializadas se pueden definir en los maestros para replicar las mesas completas

o subconjuntos de mesa a los sitios dentro de cada región.

Principales diferencias entre vistas materializadas y replicado tablas maestras son las

siguientes:

• Tablas replicadas maestro debe contener los datos de la tabla completa se replica,

mientras que vistas materializadas pueden replicar los subconjuntos de datos de la

tabla maestra.

• De replicación con varios maestros le permite replicar los cambios para cada

transacción como se produzcan cambios. actualiza vista materializada se

establecen orientado, propagación de los cambios de varias transacciones de una

manera más eficiente, la operación orientada a lotes, pero a intervalos menos

frecuentes.

• Si los conflictos se producen debido a cambios realizados en múltiples copias de los

mismos datos, a continuación, la detección y resolución de conflictos siempre se

produce en un sitio de capitán o un maestro materializado ver sitio.

Replicación síncrona.- Un entorno de replicación con varios maestros puede utilizar la

replicación asíncrona o síncrona para copiar los datos, con la replicación asincrónica, los

cambios realizados en el lugar de un maestro se producen en un momento posterior en

todos los sitios maestro de otros participantes. Con la replicación sincrónica, los cambios

realizados en el lugar de un maestro de producirse de inmediato en todos los sitios

maestro que participe.

Cuando se utiliza replicación sincrónica, una actualización de una tabla de resultados en la

replicación inmediata de la actualización en todos los sitios maestro participantes. De

hecho, cada transacción incluye todos los sitios maestro, por lo tanto, si un sitio maestro

no puede procesar una transacción por cualquier razón, entonces la transacción se

revierte en todos los sitios maestro.

A pesar de que evitar la posibilidad de conflictos cuando se utiliza replicación sincrónica,

se requiere un ambiente muy estable para funcionar sin problemas. Si la comunicación de

un sitio maestro no es posible debido a un problema de red, por ejemplo, las tablas a

continuación, los usuarios pueden reproducirse consulta, pero no hay transacciones se

puede completar hasta que se restablezca la comunicación. Además, es posible configurar

la replicación asincrónica de manera que simula la replicación síncrona.

INSTALANDO ORACLE.

Para nuestro caso usaremos la de oracle llamada oracle Express Edition, la cual es gratuita

para nuestro servidor. Nos dirigimos a la página:

http://www.oracle.com/technology/software/products/database/xe/htdocs/102xewinsof

t.html

Y aceptamos los términos de licenciamiento del programa, en este momento

descargaremos el producto para posteriormente instalarlo en nuestro sistema.

Una vez descargado lo instalaremos dando clic derecho en el instalador y eligiendo la

opción, abrir.

Esperamos un momento y podremos ver las opciones del programa.

El programa de instalación nos muestra la pantalla de bienvenida para la

instalación, en este momento tenemos que dar click en siguiente.

Aceptamos los términos y condiciones del programa y pulsamos siguiente, en seguida

seleccionamos la ubicación de los archivos de instalación, si queremos instalarlos

en otra ubicación podemos seleccionarla pulsando el botón Examinar, después de esto

pulsamos siguiente.

Ahora tecleamos una contraseña para los usuarios SYS y SYSTEM, los cuales son los

usuarios (dba) administradores en oracle, y pulsamos en siguiente, ahora nos mostrara

un resumen de la instalación si estamos de acuerdo con este daremos clic en instalar.

CONFIGURANDO EL SERVIDOR

Ahora editaremos el archivo

“C:\oracle\product\10.2.0\db_1\network\admin\tnsnames.o ra”, y agregaremos las

siguientes líneas de configuración (resaltadas en cursiva y negrita) para que el servidor

oracle reconozca nuestro servidor remoto, usando una resolución de nombres tns.

# tnsnames.ora Network

(HOST =

Configuration File:

RAMMSCORP.gateway.2wire.net)

D:\oracle\product\10.2.0\db_1\net

(PORT = 1522)

work\admin\tnsnames.ora

)

# Generated by Oracle

(CONNECT_DATA =

configuration tools.

(SERVER = DEDICATED)

(SERVICE_NAME = orcl)

LISTENER_ORCL =

)

(ADDRESS =

)

(PROTOCOL = TCP)

(HOST =

RAMMSCORP.gateway.2wire.net)

YOS =

(PORT = 1522)

(DESCRIPTION =

)

(ADDRESS_LIST =

(ADDRESS =

(COMMUNITY = TCP)

ORCL =

(PROTOCOL = TCP)

(DESCRIPTION =

(HOST = yosy1)

(ADDRESS =

(PORT = 1521)

(PROTOCOL = TCP)

)

)

(ADDRESS =

(CONNECT_DATA =

(PROTOCOL = IPC)

(SID = XE)

(KEY = EXTPROC1)

)

)

)

)

(CONNECT_DATA =

(SID = PLSExtProc)

EXTPROC_CONNECTION_DATA =

(PRESENTATION = RO)

(DESCRIPTION =

)

(ADDRESS_LIST =

)

Donde

YOS es el nombre del servidor remoto que agregamos, es decir un alias,

PROTOCOL es el protocolo de comunicación hacia el servidor,

HOST es el nombre ó la dirección IP de la computadora que tiene el servidor,

PORT indica el numero de puerto al cual se conectara el servidor y finalmente

SID que es el nombre de servicio del servidor remoto.

De esta manera nos podremos conectar con el servidor remoto usando la

nomenclatura de conexión:

Usuario/Password@Alias_Del_Servidor:[Puerto]

Donde

Usuario es cualquier usuario valido del servidor remoto,

Password es la contraseña del usuario remoto,

@Alias_del_servidor es el nombre que hemos añadido en el archivo de

configuración tnsnames.ora, y finalmente el

Puerto que indica a que puerto se conectara este parámetro es opcional, por defecto las

conexiones se realizan al puerto 1521.

Una vez editado y configurado archivo, tendremos que configurar nuestro servidor

estableciendo un DBLink ó un enlace a base de datos.

Usando la siguiente instrucción:

Create database link "Nombre_Del_DBLink" connect to Usuario identified by

"Password" using 'HOST[: PUERTO]/SID'

De la siguiente instrucción tenemos

Nombre_Del_DBLink el cual es un nombre cualquiera para identificar a que base

de datos estamos ligados,

Usuario el cual debe de ser un usuario remoto valido,

Password es la contraseña del usuario remoto,

HOST es el nombre ó dirección ip del servidor,

PUERTO indica el numero del puerto al que se conectara el parámetro es

opcional, el puerto por defecto es el 152, y por ultimo

SID es el nombre del servicio al cual se conectara nuestro servidor.

La cual nos proporcionara la facilidad de hacer consultas del tipo:

OBJETO@DBLINK

Donde Objeto puede ser cualquier tipo de objeto en la base de datos remota y @DBLink

es el enlace a la base de datos, de este modo podremos usar las tablas, vistas, triggers y

demás objetos en el servidor.

Estos pasos de configuración se hacen en los dos servidores para que se puedan

comunicar, es decir tenemos que dar de alta el servidor 1 en el servidor 2 y

viceversa; además tenemos que dar de alta un DBLink para cada uno de ellos,

una vez teniendo configurados los servidores podremos iniciar la replicación.

REPLICANDO DATOS

Ahora antes de replicar los datos tenemos que tener datos, necesitamos tener

cuando menos una tabla en la base de datos, ahora crearemos una tabla para hacer

esta práctica la cual llamaremos: COMPRAS; la cual estará en el servidor 1 (RAMMS)

y será replicada hacia el servidor 2 (YOS).

Utilizaremos las sentencias de SQL Plus para crear la tabla con los siguientes

campos de la siguiente manera:

CREATE TABLE RAMMS.COMPRAS

Y posteriormente:

(

CODIGO VARCHAR2 (8 BYTE) NOT

ALTER TABLE RAMMS.COMPRAS

NULL,

ADD (

PROVEEDOR VARCHAR2 (30

PRIMARY KEY

BYTE) NOT NULL,

(CODIGO)

PRODUCTO VARCHAR2 (45 BYTE)

USING INDEX

NOT NULL,

TABLESPACE USERS

PRECIOCOMPRA INTEGER NOT

PCTFREE 10

NULL,

INITRANS 2

PRECIOVENTA INTEGER NOT

MAXTRANS 255

NULL,

STORAGE (

CANTIDAD NUMBER NOT NULL

INITIAL 64K

)

MINEXTENTS 1

MAXEXTENTS

UNLIMITED

PCTINCREASE 0

));

Después de crear la tabla agregaremos datos en ella, quedando de la siguiente manera:

Ahora realizaremos una consulta desde el servidor 2 (YOS) usando los DBLink, quedando

de la siguiente manera:

SELECT * FROM COMPRAS@DBLINKRAMMS

Arrojando la siguiente información:

Como podemos observar la consulta funciona es decir que podemos consultar

objetos desde el servidor 2, ahora crearemos en el servidor 1

(RAMMS), una tabla LOG para la replicación de la tabla COMPRAS, con la

siguiente instrucción:

CREATE MATERIALIZED VIEW LOG ON RAMMS.COMPRAS

NOCACHE

LOGGING

NOPARALLEL;

Esta tabla guardara los datos cambiados y actualizara de manera instantánea

todas las replicas de la tabla COMPRAS.

Ahora desde el servidor 2 (YOS) crearemos nuestra vista materializada para recibir los

datos de la tabla original, a este procedimiento de replica se le denomina replica

en forma de instantánea o de snapshot, lo haremos usando la siguiente

instrucción.

CREATE MATERIALIZED VIEW RAMMS.COMPRAS

BUILD IMMEDIATE

REFRESH FAST ON COMMIT

AS

SELECT * FROM COMPRAS@DBLINKRAMMS;

Ahora en el servidor 2 (YOS), ya disponemos de una copia exacta de la tabla compras del

servidor 1 (RAMMS), y se actualizara automáticamente cuando se haga un commit en

las transacciones, ahora podemos ejecutar la sentencia:

SELECT * FROM COMPRAS;

E inmediatamente después podremos apreciar el resultado de la consulta, nótese que

en el servidor 2,no existían datos para la tabla COMPRAS de hecho COMPRAS no

es una tabla es una ¡vista!

De esta manera cualquier cambio realizado en el servidor 1, se verá reflejado

inmediatamente en el servidor 2, de esta manera tenemos la información

actualizada y lo más importante distribuida en varios nodos al mismo tiempo.

PARA RECORDAR

Oracle es una herramienta tipo cliente/servidor que nos permite la creación, manejo, modificación, de bases de datos, es una herramienta de alta tecnología que tiene como fin manejar grandes cantidades de información además de permitir cantidades ilimitadas y al mismo tiempo de usuarios para gestionar los mismos datos.

Al elegir oracle como herramienta de trabajo se debe determinar un hardware y un sistema operativo específico de funcionamiento.

Entre las características más relevantes de Oracle tenemos las siguientes:

Soporta grandes cantidades de información.

Soporta gran cantidad de usuarios accediendo al mismo tiempo a la misma información.

Permite la creación de seguridades a través de la creación de usuarios con privilegios y roles

Tiene una estructura cliente servidor.

Conectividad entre bases de datos remotas (estructura de base de datos distribuidas)

Compatibilidad

1. Los componentes del SGA y su utilización. (estructuras compartidas que información tienen sql shared)

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.

Á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 leídos de los segmentos de datos de la

BD, tales como tablas, índices y clústeres. Los bloques modificados se llaman 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 leídos, su gestión se hace mediante el algoritmo LRU.

• Buffer Redo Log

Los registros Redo describen los cambios 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 análisis 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 mantiene en memoria. De esta manera se premia la uniformidad en la programación de las aplicaciones. La igualdad se entiende que es lexicográfica, 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 tamaño viene determinado por el parámetro SHARED_POOL_SIZE.

2. Componentes del PGA y su utilización (dvw dvr, lgw, pmon, sismon)

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.

Área Global de Programa PGA

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

• 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 periódicamente o cuando sucede algún checkpoint o punto de sincronización, grabación diferida.

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.

El bloque del segmento de rollback se escribe SIEMPRE antes que el correspondiente bloque de datos.

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:

A cada validación de transacción, y antes de que se comunique al proceso que todo ha ido bien,

Cuando se llena el grupo de buffers de redo log

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 producen cuando:

Un espacio de tabla se pone inactivo, offline

Se llena el fichero de redo log activo

Se para la BD

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

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, LC K

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

3. Privilegios de sistemas de Oracle 9iy para qué sirve

PRIVILEGIOS DEL SISTEMA

Permite al usuario hacer ciertas tareas sobre la BD, como por ejemplo crear un Tablespace. Estos permisos son otorgados por el administrador o por alguien que haya recibido el permiso para administrar ese tipo de privilegio.

En general los permisos de sistema, permiten ejecutar comandos del tipo DDL (Data definition Language), como CREATE, ALTER y DROP o del tipo DML (Data Manipulation Language.

Privilegio Descripción

CREATE ANY INDEX Crear cualquier índice.

CREATE [PUBLIC] SYNONYM

Crear sinónimos [públicos].

CREATE [ANY] TABLE Crear tablas. El usuario debe tener cuota en el espacio de tablas, o ha de tener asignado el privilegio UNLIMITED TABLESPACE.

CREATE [ANY] VIEW Crear vistas.

ALTER ANY INDEX Alterar cualquier índice.

ALTER ANY TABLE Alterar cualquier tabla

DROP ANY INDEX Borrar cualquier índice.

DROP ANY SYNONYM Borrar cualquier sinónimo.

DROP PUBLIC SYNONYM Borrar sinónimos públicos.

DROP ANY VIEW Borrar cualquier vista.

DROP ANY TABLE Borrar cualquier tabla.

SELECT ANY TABLE Efectuar selecciones de cualquier tabla o vista.

INSERT ANY TABLE Insertar en cualquier tabla o vista.

DELETE ANY TABLE Borrar filas de cualquier tabla o vista, y también truncar.

ALTER SESSION Alterar los parámetros de la sesión.

CREATE SESSION Conectarse a la BD.

CREATE PROFILE Crear perfiles de usuario.

CREATE ROLE Crear roles.

CREATE ROLLBACK SEGMENT

Creación de segmentos de rollback.

CREATE TABLESPACE Crear espacios de tablas.

CREATE USER Crear usuarios.

ALTER PROFILE Alterar perfiles existentes.

ALTER ANY ROLE Alterar cualquier rol.

ALTER ROLLBACK SEGMENT

Alterar segmentos de rollback.

ALTER TABLESPACE Alterar espacios de tablas.

ALTER USER Alterar usuarios.

DROP PROFILE Borrar un perfil existente.

DROP ANY ROLE Borrar cualquier rol.

DROP ROLLBACK SEGMENT

Borrar un segmento de rollback existente.

DROP TABLESPACE Borrar un espacio de tablas.

DROP USER Borrar un usuario. Añadir CASCADE si el usuario posee objetos.

ALTER DATABASE Permite una sentencia ALTER DATABASE.

GRANT ANY PRIVILEGE Otorgar cualquiera de estos privilegios.

GRANT ANY ROLE Otorgar cualquier rol a un usuario.

UNLIMITED TABLESPACE Puede usar una cantidad de almacenamiento ilimitada.

DROP PROFILE Borrar un perfil existente.

4. Privilegios de objetos que maneja Oracle 9i y para qué sirve

PRIVILEGIOS SOBRE LOS OBJETOS

Este tipo de privilegios le permite al usuario hacer cierta acción en un objeto de la base de datos, como puede ser una tabla, vista, función etc. Si a un usuario no se le dan estos privilegios solo podrías acceder a sus propios objetos. Y estos tipos de privilegios los da el dueño del objeto, el administrador o alguien que haya recibido este permiso explícitamente. Los privilegios sobre objetos consienten que un objeto (creado por un usuario) estos privilegios puede ser de SELECT, de UPDATE, de DELETE, de INSERT.

Privilegio Descripción

SELECT Puede consultar a un objeto.

INSERT Puede insertar filas en una tabla o vista. Puede especificarse las columnas donde se permite insertar dentro de la tabla o vista.

UPDATE Puede actualizar filas en una tabla o vista. Puede especificarse las columnas donde se permite actualizar dentro de la tabla o vista.

DELETE Puede borrar filas dentro de la tabla o vista.

ALTER Puede alterar la tabla.

INDEX Puede crear índices de una tabla.

REFERENCES Puede crear claves ajenas que referencie a esta tabla.

EXECUTE Puede ejecutar un procedimiento, paquete o función.

READ Permite leer archivos asociados con objetos BFILE en el directorio del sistema

5. Cuáles son los roles y privilegios que vienen instalados en Oracle

Inicialmente Oracle tiene predefinidos los siguiente roles (entre otros):

• CONNECT Todos los permisos necesarios para iniciar una sesión en Oracle

• RESOURCE Todos los permisos necesarios para tener recursos para la creación de objetos

• DBA Todos los permisos para un administrador de base de datos (DBA)

• EXP_FULL_DATABASE Permisos para poder exportar toda la base de datos.

• IMP_FULL_DATABASE Permisos para poder importar toda la base de datos.

Podemos decir que un usuarios normal, debe tener al menos los permisos de CONNECT (para conectarse) y de RESOURCE (para poder crear objetos).

Roles Privilegios

CONNECT CREATE SESSION, CREATE TABLE, CREATE

VIEW, CREATE SYNONYM, CREATE

SEQUENCE,

CREATE DATABASE LINK, CREATE CLUSTER,

ALTER SESSION

RESOURCE CREATE TABLE, CREATE PROCEDURE,

CREATE SEQUENCE, CREATE TRIGGER,

CREATE TYPE, CREATE CLUSTER, CREATE

INDEXTYPE, CREATE OPERATOR

SCHEDULER_

ADMIN

CREATE ANY JOB, CREATE JOB, EXECUTE

ANY CLASS, EXECUTE ANY PROGRAM,

MANAGE SCHEDULER

DBA Tiene la mayoría de los privilegios, no

asignar a los que no son administradores,

todos los privilegios de sistema con la opción

with admin option

SELECT_CATALOG_ROLE No tiene privilegios de sistema, pero tiene

cerca de 1600 privilegios de objeto.

6. Cuáles son los perfiles y para qué sirven cada uno que vienen instalados en Oracle

Los perfiles se crean para limitar las posibilidades de los usuarios del sistema de base de

datos.

Administradores: Que podrían tener acceso a recursos ilimitados dentro del sistema.

Desarrolladores: Que podrían disponer de un número ilimitado de sesiones pero

restringida la utilización de la CPU.

Otros.

En síntesis, los perfiles se utilizan para suavizar las tareas de administración de la

seguridad, manteniendo siempre bajo control los accesos a los recursos de todos los

usuarios, por muchos que éstos puedan llegar ser.

Los perfiles se crean y modifican con los comandos CREATE PROFILE y ALTER PROFILE. La

sintaxis de estos comandos no necesitan ser repetidas aquí porque vienen extensamente

explicados en la ayuda del software; sólo vale la pena destacar que algunas de las

cláusulas hacen referencia a cuánto ciclo de CPU se le asignará a cada usuario, cuántas

sesiones concurrentes podrán tener, etc.