WHERE dbb.autor.idautor@link = libro.idautor
AND nacionalidad = "Francia"
También es posible realizar operaciones de
actualización (insert, update, delete) en la BD remota,
siempre que tengamos el permiso necesario para
realizarlas.
SINONIMOS
Las referencias a las tablas de la BD remota en las
anteriores consultas no son transparentes al usuario: necesita
conocer el nombre del link y el propietario de la tabla. Para
hacerlas totalmente transparentes se pueden definir
sinónimos.
CREATE [PUBLIC] SYNONYM nombreSinomimo FOR
nombreObjeto;
Permite referirse a un nombre global de un objeto a
través del sinónimo.Esconde el acceso remoto a la tabla haciendo
transparente su acceso.El parámetro PUBLIC hace disponible el
sinónimo para todos los usuarios.
Ejemplo:
CREATE SYNONYM autores FOR
autores actúa como sinónimo de
dbb.autor@link
Ahora podemos definir consultas totalmente transparentes
al usuario:
SELECT nombre
FROM autores
WHERE nacionalidad = "Francia"
BORRADO DE SINONIMOS
DROP[PUBLIC] SYNONYM autores;
REPLICACIÓN DE
BASE DE DATOS EN ORACLE
Es el proceso de copiar y mantener objetos de bases de
datos como tablas, triggers, índices, programas en
múltiples bases de datos que constituyen una base de datos
distribuida.
Los cambios aplicados en un sitio son almacenados
localmente para posteriormente ser enviados y aplicados al sitio
remoto.
En una base de datos distribuida, existen datos
disponibles en muchos lugares, pero un objeto en particular (una
tabla) solo existe en un nodo de la BD.
En las bases de datos replicadas en cambio, los datos
están disponibles en muchos lugares, es decir, una tabla
puede estar en varios nodos del sistema.
Las razones para replicar una BD, incluyen
disponibilidad, Rendimiento, Computación desconectada,
Reducción de Carga en la red, entre otras.
Alternativas de Replicación
1. Vistas Materializadas.- contiene una
copia completa o parcial de un objeto en un instante puntual
de tiempo. Entres sus beneficios están que nos permite
el acceso local, lo cual mejora los tiempos de respuesta y la
disponibilidad. Se puede trabajar "off line". Aumenta la
seguridad de los datos ya que se puede definir una
replicación de acotada de los objetos.
2. Multimaster Replication.-
También conocido como peer-to-peer o nway replication
permite replicación multidireccional. Cada sitio en un
ambiente multimaster es master site y este se puede comunicar
con cualquier otra master site.
Podemos encontrar varias configuraciones la mas
común es Asynchronous Replication, en esta los cambios que
se efectúan en un master site son almacenados en un
espacio llamado "deferred transactions queue". Estos cambios son
propagados a los otros participantes del sistema de
replicación en intervalos regulares de tiempo.
En la replicación sincrónica los cambios
que ocurran en un master site son replicados inmediatamente a los
otros participantes del sistema. Si una transacción no
puede ser procesada por un master site, se producirá un
rollback de la transacción en todos los otros master
sites.
A continuación 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.
Ahora editaremos el archivo
"C:oracleproduct10.2.0db_1networkadmintnsnames.ora",
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 Configuration File:
D:oracleproduct10.2.0db_1networkadmintnsnames.ora
# Generated by Oracle configuration
tools.
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.
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:
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.
CONFLICTOS EN LA
REPLICACION
Es ampliamente necesario realizar y definir un sistema
altamente robusto, para resolver los conflictos de datos que se
puedan producir. Como se ha estado explicando anteriormente, los
cambios dentro de la Base de Datos Distribuida de producen y se
propagan concurrente y asincrónicamente, lo que produce
conflictos si dos o mas sitios modifican el mismo dato en sitios
distintos.
¿Por qué utilizar métodos de
resolución de conflictos?
Dichos métodos se usan, principalmente, por dos
motivos:
Para asegurar la convergencia de los datos: Esto quiere
decir, que los datos no deben ser actualizados inmediatamente,
pero si es imprescindible, que en algún tiempo finito se
propaguen todos los cambios en todos los repositorios, para
asegurar que todo el sistema posee los mismos datos.
Par evitar los errores en cascada: Esto, evita que el
sistema caiga en una falla que llevará al sistema a la
inestabilidad. El sistema debiese comportarse de manera suave y
sin problemas.
Es conveniente considerar lo siguiente, en el
diseño de un sistema de resolución de
conflictos:
Monitorear la ocurrencia de cualquier conflicto sin
resolver.Usar un método de notificación, para
enviar información a los demás sitios sobre
cualquier conflicto inesperado, que sea detectado.
Estos puntos son la base para cualquier sistema que
pretenda manejar los conflictos que se producen en la
actualización de los datos. En contraste con lo anterior,
si todos los sitios propagaran los cambios sincrónicamente
y no se tuviesen sitios "snapshot" actualizables, no debiesen
ocurrir conflictos y no se necesitaría diseñar un
método de resolución de conflictos.
Tipos de conflictos
Existen principalmente 3 tipos de conflictos que deben
ser detectados por el sistema en cuestión:
Conflictos de Actualización: vale decir,
cuando dos sitios intentan actualizar la misma
información. En este caso se debe decidir cual de las
dos actualizaciones debe ser hecha primero.Conflictos de Unicidad: En bases de datos, la
unicidad en las claves primarias, es imprescindible, y por lo
tanto, no es un problema menor en ambientes
distribuidos.Conflictos de Borrado: se producen conflictos al
borrar una determinada fila, sobre todo si un cliente intenta
realizar aplicaciones sobre ella y los cambios aun no han
sido realizados.
Eligiendo un Sistema de Resolución de Conflictos
Finalmente, la elección de un buen sistema de
resolución de conflictos puede tomar tres grandes
variantes:
Utilizar un Sistema Propietario: Existen muchos
motores de DDB, cada uno de los cuales posee sus propias
herramientas para solucionar estos conflictos.Diseñar un Sistema Propio: También se
puede diseñar un sistema propio para tratar de mejor
manera los requerimientos específicos para cada
caso.Utilizar un Híbrido entre Ambos:
También es posible utilizar el sistema propietario
como base, y atacar las debilidades de este con un sistema
diseñado propio.
DISTRIBUCION VS
REPLICACION
Los términos distribución
de datos y replicación de datos están
relacionados pero son distintos.En una BD distribuida pura (sin
replicación) el sistema maneja una copia simple de
todos los datos. Distribuir los datos consiste en situarlos
en las distintas BD.El término replicación se
refiere a realizar copias de los mismos datos en diferentes
BD.La replicación se utiliza en BDD
para mejorar la disponibilidad y seguridad de los datos. Se
pretende proporcionar distintas alternativas de acceso a los
mismos, así como mejorar el rendimiento, a
través de accesos locales a copias de datos
remotos.La replicación complica la
administración de la BDD ya que es necesario mantener
en todo momento la consistencia de los datos en todas las
réplicas.
CONCLUSIÓN
Aprendimos a hacer una replicación de
instantánea de una tabla en oracle usando dos
servidores uno que es el servidor que tiene la tabla a
replicar (RAMMS) y un cliente (YOS) el cual puede tener los
datos de la tabla para consultar, cabe señalar que la
vista materializada es de solo lectura, debido a que es una
instantánea, también configuramos los accesos
de los servidores mediante el archivo de configuración
tnsnames.ora y dimos de alta los servidores en los
archivos, lo que nos daba como resultado la
comunicación entre ambos y logrando así poder
generar el enlace de base de datos entre ellos.
Teniendo la posibilidad de realizar consultas
distribuidas entre los servidores.
Finalizando en la creación de la tabla de
LOGS y la vista materializada, para poder consultar los datos
replicados de manera local.
El aprender a usar ORACLE requiere una curva de
aprendizaje no muy complicada, y se puede hacer con la ayuda
de una guía que es difícil de encontrar. Mucha
información está en ingles.
Autor:
Robert Cupuerán
Facultad de sistemas mercantiles
Carrera de sistemas e
informatica
Sistemas distribuidos II
Asesor: Ing. Oscar Llerena
Ibarra 2010
 Página anterior | Volver al principio del trabajo | Página siguiente  |