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 siguiente |