Source: http://www.plusformacion.com/Recursos/r/Distribucion-Replicacion-Oracle
Timestamp: 2016-05-27 02:13:03+00:00

Document:
Distribucion y Replicación en Oracle | Plusformación
Distribucion Replicación Oracle
Distribucion y Replicación en Oracle
Bases de datos distribuidas en Oracle
Replicación de base de datos en Oracle
Conflictos en la replicación
Distribución vs replicación
Hay un interés cada vez mayor en los protocolos asincrónicos, en los cuales las transacciones de base de datos se ejecutan localmente, y sus efectos se incorporan asincrónicamente en copias remotas, sin afectar seriamente su funcionamiento.
Se inicia con una explicación básica de la distribución de BDD en Oracle, el uso de DBLINKS, nombre de servicio y consultas remotas, uso de sinónimos, luego se tratarán aquellos puntos que permitan comprender la extensión y profundidad de la replicación, desde el punto de vista de quien se interese en trabajar e implementar dichos sistemas, dando para ello las cualidades y virtudes, así como sus desventajas y debilidades, de modo de tener una visión amplia de sus aplicaciones.
Se explicará a grandes rasgos, como se compone y comporta la replicación, permitiendo observar dos grandes divisiones, la replicación básica y la replicación avanzada, dando mayor énfasis a cada punto de esta sección.
En la parte final se trata sobre los métodos de resolución de conflictos para resolver problemas con los datos y mantener un sistema altamente robusto y una comparación de la distribución y la replicación.
Conocer la forma en forma básica cómo funciona la plataforma ORACLE
Aprender a configurar DBLINKS y realizar consultas a BDD remotas
Conocer el uso de las Vistas Materalizadas
Conocer el manejo de replicación multimaster
Un sistema (homogéneo) de bases de datos distribuidas en Oracle es una red de dos o más BD Oracle que residen en uno o más servidores de modo que es posible acceder a sus datos como si de una única BD se tratara.
Posee arquitectura cliente/servidor. Cada ordenador en al red es un nodo que pude actuar como cliente, servidor o ambos.
El software de red Oracle Net debe ejecutarse en todos los servidores y hace posible la comunicación entre las BD.
Concepto central en las BD distribuidas en ORACLE
Un DB Link define un camino unidireccional desde una BD ORACLE a otra.
Un usuario local puede acceder a través de un link a objetos de esquemas de otros usuarios en BD remotas (siempre que tenga permiso suficiente para hacerlo) como si se tratara de una única BD.
Se almacenan en el catálogo:
CREACIÓN DB LINK: Crea un link público de nombre nombreLink que establece un enlace a una BD remota cuya ubicación está descrita en el nombre de servicio a través un usuario y contraseña de dicha BD.
CREATE PUBLIC DATABASE LINK nombreLink
CONNECT TO usuario IDENTIFIED BY contraseña
USING 'nombre de servicio';
BORRADO DBLINK
DROP [PUBLIC] DATABASE LINK nombreLink;
Cada BD es identificada unívocamente en una BD distribuida por un nombre global de BD. Este consta del nombre de la BD junto con el nombre del host en la red en la que esta BD está ubicada.
Este nombre se hace transparente al usuario mediante el uso de nombres de servicio (service names) en la definición de los enlaces (links).
Los nombres de servicio se definen en el archivo tnsnames.ora de Oracle, cuya ubicación depende del ordenador: c:\oracle\ora92\network\admin\tnsnames.ora
TIPOS DE DBLINKS
Privados: Sólo lo puede usar el que los crea.
- (CREATE DATABASE LINK ....)
Públicos: Lo pueden usar todos los usuarios de la BD.
- (CREATE PUBLICDATABASE LINK ....)
Los tipos de usuarios de un enlace pueden ser:
Fixed: Hay que indicar en la definición usuario y contraseña.
Connected User (sin CONNECT): Válido para el usuario conectado. Debe tener en la BD remota una cuenta con el mismo nombre de usuario y misma contraseña.
ACCESO A OBJETOS REMOTOS VIA LINKS
El nombre de un objeto en una BD es unívoco dentro del esquema de su propietario. Sin embargo, en una BD remota puede existir un esquema con el mismo nombre, que puede tener un objeto con el mismo nombre...
Acceso a través de un link a un objeto remoto de un determinado propietario en una BD remota:
propietario.nombreObjeto@nombreLink
nombreObjeto@nombreLink
si el usuario que accede al objeto es el propietario del mismo.
CONSULTA A BDD REMOTAS
Para realizar consultas en una BD distribuida podemos utilizar objetos situados en una BD remota. Se utiliza para ello los links previamente creados.
FROM dbb.autor@link
WHERE nacionalidad = "Francia"
FROM dbb.autor@link, libro
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.
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.
CREATE SYNONYM autores FOR dbb.autor@link
autores actúa como sinónimo de dbb.autor@link
Ahora podemos definir consultas totalmente transparentes al usuario:
BORRADO DE SINONIMOS
DROP[PUBLIC] SYNONYM autores;
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.
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:\oracle\product\10.2.0\db_1\network\admin\tnsnames.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.
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
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
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.
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.
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.
Robert Cupuerán
rcupueran[arroba]yahoo.com
Carrera de sistemas e informatica
Asesor: Ing. Oscar Llerena
Ibarra 2010
Distribucion y Replicación en Oracle Indica tu mail: *
Contenidos relacionadosBlogLink Buillding y backlink
Motores de búsqueda online
Segmentación avanzada Google Analytics. Parte I
Curso Auditor de Calidad Ver oferta 29.00€
El objetivo del Curso Auditor de Calidad es adquirir los conocimientos teóricos y prácticos necesarios para formarse como... Continuar leyendo 85%

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 Resolución 
 resolución