AA7-EV3-BLOG REPLICACIÓN DE BASE DE DATOS

Por:
GUSTAVO ADOLFO OROZCO DUQUE

Profesor:
JAVIER MAURICIO ALVAREZ VARGAS

SERVICIO NACIONAL DE APRENDIZAJE

GESTIÓN Y SEGURIDAD DE BASES DE DATOS
CENTRO DE SERVICIOS FINANANCIEROS
MEDELLIN-ANTIOQUIA
2019
REPLICACIÓN DE BASES DE DATOS

Replicación es el proceso de copiado y mantenimiento de objetos de la base de

datos, tales como tablas, en bases de datos múltiples “simulan” un sistema de bases
de datos distribuido. Los cambios hechos en un sitio son capturados y almacenados
locamente antes de ser enviados y aplicados en cada una de las locaciones
remotas. La replicación en Oracle es una característica del servidor Oracle, no es
un servidor separado. en este sentido se puede decir que no es un backup de datos,
ya que si borramos información de una base de datos se borrara automáticamente
de las otras bases de datos

TIPOS DE REPLICACIÓN DE BASE DE DATOS

Podemos hablar al menos de 3 tipos de replicación de base de datos:

Replicación Instantánea: los datos de un servidor son simplemente copiados a otro

servidor o a otra base de datos dentro del mismo servidor. Al copiarse todo no
necesitas un control de cambios. Se suele utilizar cuando los datos cambian con
muy poca frecuencia.

Replicación Transaccional: primero se envía una copia completa de la base de

datos y luego se van enviando de forma periódica (o a veces continua) las
actualizaciones de los datos que cambian. Se utiliza cuando necesitas que todos los
nodos con todas las instancias de la base de datos tengan los mismos datos a los
pocos segundos de realizarse un cambio.

Replicación de mezcla: los datos de dos o más bases de datos se combinan en

una sola base de datos. En primer lugar, se envía una copia completa de la base de
datos. Luego el Sistema de Gestión de Base de Datos va comprobando los cambios
que van apareciendo en los distintos nodos y a una hora programada o a petición
los datos se sincronizan. Es sobre todo útil cuando cada nodo suele utilizar solo los
datos que se actualizan allí pero que por circunstancias necesita tener también los
datos de los otros sitios.

BENEFICIOS DE LA REPLICACIÓN DE BASE DE DATOS

La replicación te puede ofrecer grandes beneficios relacionados principalmente con

el rendimiento, disponibilidad y seguridad de los datos.

Aumento de la fiabilidad: mediante la replicación de base de datos a través de

múltiples servidores, te aseguras que los datos van a estar disponibles incluso en el
caso de que una de
las máquinas tenga un fallo grave de hardware. El sistema distribuido de gestión de
bases de datos debe ser capaz de enrutar a los usuarios afectados a otro de los
nodos disponibles.

Mejora en el rendimiento: al estar los datos distribuidos en diferentes servidores,

los múltiples accesos no saturan los servidores. Esto es importante sobre todo en
el caso de aplicaciones que pueden tener miles o cientos de miles de peticiones
simultáneas. El rendimiento de las aplicaciones aumenta notablemente.

Mejora en la seguridad de los datos: en un sistema transaccional tradicional,

todas las actualizaciones de una base de datos se guardan en un mismo disco. La
seguridad de tus datos queda entonces en manos de la estrategia de copias de
seguridad que tengas implementada en ese servidor. Con la replicación de base
de datos aumentas la seguridad de los datos ya que las actualizaciones están
siendo escritas en varios servidores. Es decir, varios discos, varias fuentes de
alimentación, CPU’s, etc. son utilizadas para asegurar que tus datos estarán a salvo
en algunos servidores, aunque pueda ocurrir un desastre en otros.

DISTRIBUCION VS REPLICACION
Los términos distribución de datos y replicación de datos están relacionados, pero
son distintos.
En una BD distribuido 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.

PROCEDIMIENTO.

El laboratorio está compuesto por dos partes que permiten abordar el tema de la
replicación de la base de datos de la Secretaria de Salud de la alcaldía de San
Antonio del SENA. La primera parte está compuesta por la configuración de las
máquinas virtuales, para que se puedan comunicar entre sí. La segunda parte
corresponde a la configuración del servidor de la base de datos para luego poder
replicarlas teniendo a una de ellas como maestro, y teniendo la otra base de datos
como esclavo, trabajando con DATABASE LINK y con VISTAS MATERIALIZADAS.
A continuación, se describen las acciones que se deben desarrollar como parte de
este laboratorio:

CONFIGURAR EL DATABASE LINK DEL SISTEMA DESTINO (ESCLAVO)

PARA QUE RECIBA DATOS DEL SISTEMA PRIMARIO.
Inicialmente debemos ubicarnos en la máquina esclavo y debemos generar el
archivo tnsnames.ora que es aquel archivo que me permite realizar conexiones a
otros servidores ORACLE. Para ello haremos uso nuevamente del NETCA (Network
Configuration Assistant) que se encuentra ubicado en Inicio – Oracle 10g_home2 –
Configuration and Migration Tools – Net Configuration Assistant.

Imagen 1. Acceso a las Herramientas de Configuración

Iniciamos entonces el Net Configuration Assistant y elegimos la opción Nro. 2.

Configuración de los Métodos de Nomenclatura (esta opción nos permitirá
configurar los tnsnames) como se muestra en la siguiente imagen:

Imagen 2. Configuración de Métodos de Nomenclatura

Ahora hacemos clic en siguiente y llegamos al siguiente pantallazo:

Imagen 3. Métodos de Nomenclatura

Podemos entonces ahora elegir el Método de nomenclatura disponible. Vamos a
elegir Local ya que el tnsnames.ora estará ubicado localmente y allí se depositarán
las configuraciones necesarias para la conexión con el servidor maestro que será
el objeto de replicación. Para elegirlo lo seleccionamos y hacemos clic en la flecha
>: para que aparezca en la casilla siguiente
Luego hacemos clic en siguiente donde observaremos la siguiente opción, donde
nos confirma que hemos configurado los métodos de nomenclatura.

Imagen 4. Finalización del Proceso

Ahora ya se ha configurado la opción de métodos de nomenclatura, y debemos por
tanto realizar la configuración de las Bases de Datos que se encuentran en otros
servidores. Vamos a realizarlo con la herramienta NetManager.
Para ingresar al NetManager debemos ingresar a Inicio – Oracle 10g_ home2 –
Configuration and Migration Tools – Net Manager
Imagen 5. Acceso al Net Manager
Al hacer clic deberíamos observar el siguiente pantallazo:

Imagen 6. Configuración de Red

Ahora desplegamos la opción local, ingresamos a la opción Nomenclatura de
Servicios, y después hacemos clic en el más que se encuentra en la zona izquierda.
Después de esto debemos llegar a una opción como la que se muestra:

Imagen 7. Asistente de Nombre de Servicio de Red

Elijamos un nombre, que recordemos ya que lo usaremos para el resto de nuestro

laboratorio. Recomendamos colocar a este servicio DBMASTER. Entonces
digitamos DBMASTER y hacemos clic en siguiente, llegando a la siguiente opción
donde debemos elegir el protocolo TCP/IP y hacemos clic en siguiente como se
muestra en la siguiente imagen:

Imagen 8. Selección del protocolo.

Hemos elegido este protocolo que servirá de conexión entre nuestro servidor
instalado en este equipo que hemos denominado esclavo y el servidor maestro de
replicación.

Imagen 9. Valores del Protocolo

Ahora aparece de la imagen anterior, donde definimos el nombre del Host. Podemos
decidir si colocar la dirección IP, o el nombre del equipo (servidor1 o servidor2 de
acuerdo a la configuración que elegimos cuando construimos las 2 máquinas
virtuales). Dejamos configurado el puerto 1521 que es el puerto por defecto de
ORACLE, y hacemos clic en siguiente.
Luego colocamos en el nombre de servicio (posterior a 8i) el nombre del servicio,
que de acuerdo a los laboratorios realizados en ocasiones anteriores corresponde
a ORACLE. Entonces digitamos ORACLE en el nombre del servicio, como se
muestra en la siguiente figura:

Hacemos ahora clic en siguiente:

Luego clic en probar, (saldrá un error de “La cuenta está bloqueada” pero lo
ignoramos) y luego en probar conexión. Elegimos como usuario SYSTEM y como
clave SENA y volvemos a probar. Deberá aparecernos un mensaje de confirmación
de conexión exitosa damos clic en siguiente y por último nos aparecerá esta imagen:
Como verificación adicional debemos realizar una comprobación adicional para ello
hacemos clic en Inicio-Ejecutar-Cmd. Luego digitamos la instrucción tnsping
DBMASTER y debemos obtener conexión exitosa.

Imagen 13. Verificación de la conexión

Ahora pasamos a configurar el DATABASE LINK, en la máquina
esclavo. (en la que estamos actualmente).
Para ello se abre el SQLDeveloper que, para este caso, recordemos se encuentra
instalada en nuestras máquinas virtuales en la siguiente ruta:
C:\sqldeveloper
Y lanzamos el aplicativo.
Debemos recordar, vamos a conectar con el usuario: salud contraseña: SENA. Luego
abrimos el generador de consultas y después de ello aparecerá la siguiente pantalla:
Imagen 14. Conexión en el SQLDeveloper

Ahora, dentro del generador de consultas, estando dentro del usuario salud,
deberemos digitar la instrucción SQL para crear el DATABASE LINK. (Dentro del
generador de consultas). Teniendo en cuenta la siguiente sintaxis:
CREATE DATABASE LINK [NOMBRE]
CONNECT TO [USUARIO]
IDENTIFIED BY [CONTRASEÑA]
USING [cadena de
conexión] Donde:
[NOMBRE ] : Es el nombre del link simbólico
[USUARIO ] : Nombre del usuario remoto en la
BD [CONTRASEÑA] : Contraseña del usuario
[USING] : es la cadena de conexión que debemos utilizar para acceder a
nuestro servidor.
Para saber que cadena que cadena es la que debemos usar en [USING] debemos
ir al archivo tnsnames.ora que fue generado en la siguiente ruta:
“C:\oracle\product\10.1.0\db_2\NETWORK\ADMIN”
Hacemos doble clic sobre él y lo abrimos usando el bloc de notas. Nos
encontramos con la siguiente imagen: Imagen 16. Texto a ejecutar en
SQLDeveloper Imagen
Para probar si nuestra configuración fue correcta ejecutamos la siguiente
consulta: SELECT * FROM EPS@DB Deberíamos obtener los siguientes
resultados:

Imagen 17. Prueba de Configuración

Aquí comprobamos que el DBLINK ha sido un éxito.
CREAR UN VIEW_LOG MATERIALIZADO DESDE LA TABLA ORIGEN QUE SE
ENCUENTRA DENTRO DE LA BASE DE DATOS ORIGEN.
Ahora debemos ir al servidor maestro que servirá como fuente de datos a nuestro
servidor esclavo. Se hace claridad que la tabla de replicación (vista materializada)
se trabajará desde el usuario SALUD. Este View log permite preparar a ORACLE el
manejar los view_log (parámetros de vista)
Abrimos el SQLDeveloper que se encuentra en el servidor, entramos al generador
de consultas y ejecutamos la siguiente instrucción SQL:
CREATE MATERIALIZED VIEW LOG
ON EPS
WITH PRIMARY KEY
INCLUDING NEW VALUES;

De esta manera estamos indicando que vamos a realizar la replicación sobre la

tabla SecSalud.EPS y el materialized view log estará sobre el esquema salud.
Debemos tener entonces un mensaje al ejecutar la consulta mencionándonos que el
proceso ha sido ejecutado con éxito.

Imagen 18. Creación de la vista materializada

Ahora procedemos a crear la vista materializada en el servidor esclavo.
CREAR UNA VISTA MATERIALIZADA SOBRE LA BASE DE DATOS DESTINO.
Crear una vista materializada sobre la base de datos destino que seleccione todos
los datos de la tabla remota y colocarla en modo “fast refreshable” de manera que
y configurarla de manera que hagamos la actualización cada 5 minutos.
Ahora debemos ir nuevamente al servidor esclavo (quien recibirá la réplica) abrimos
el sqldeveloper y ejecutamos la siguiente instrucción sql (recordar que en este
debemos estar conectados como usuario salud).

CREATE MATERIALIZED VIEW

salud_replicada REFRESH FAST
START WITH sysdate +
5/(24*60) NEXT sysdate +
5/(24*60)
AS
SELECT * FROM EPS@DB
Mediante esta sentencia, la actualización de replicación es de 5 minutos, si
queremos aumentar o disminuir el tiempo, cambiamos el valor que se encuentra en
la parte superior.
Se evidencia entonces que se ha creado una vista materializada que representa la
tabla EPS que se encuentra en el servidor maestro.
Hagamos clic entonces en vistas materializadas y observamos que se encuentra
creada, y hacemos doble clic para ver su contenido.

Imagen 20. Contenido de la Vista

Probemos ahora insertar un dato en la tabla EPS en la tabla servidor y vemos si la
vista materializada se actualiza en el intervalo especificado (5 minutos).
De esta manera hemos realizado la replicación de datos de un servidor ORACLE a
otra instancia ORACLE.