Sincronizar Bases de Datos Sql server vs oracle
Ojalá me puedan ayudar, tengo una aplicación en SQL SERVER y tengo la necesidad de crear un espejo de ésta (solo tablas e información) en ORACLE.
La idea es que cada vez que realicen una transacción que afecte la información en SQL SERVER, de manera automática se vea registrada en ORACLE, de manerar transparente.
Si alguien me pudiera orientar al respecto se los voy a agradecer.
La idea es que cada vez que realicen una transacción que afecte la información en SQL SERVER, de manera automática se vea registrada en ORACLE, de manerar transparente.
Si alguien me pudiera orientar al respecto se los voy a agradecer.
1 Respuesta
Respuesta de neosys
1
Respecto a tu pregunta, la solución más fácil y transparente para el usuario es el uso de 'ORACLE TRANSPARENT GATEWAY'. Es muy fácil de instalar.
LO que hace es crear una BB. DD. Oracle 'parcial' (en la maquina donde tengas SQL*Server) que hace de puente con tu BB. DD. ORACLE real en la maquina que tengas la replica ORACLE real.
Creas una entrada de comunicación en el 'tnsnames. Ora' de la real contra la ficticia.
Luego, para acceder, por ejemplo desde el ORACLE real a SQL*Server es como si accedieses mediante database link.
select * from tabla_sql_server@instancia_remota
Si quiere te creas un sinónimo para no escribir siempre el @instancia remota de cada tabla.
Sino, no lo crees, ya que si quieres almacenar los cambios de SQLSERVER, lo que tendrás que hacer son MATERIALIZED VIEW, es en las que pondrás la select anterior para cada tabla que te interese guardar datos y un 'log' de la 'View Materializada'. Por temas de rendimiento.
Pero si no quieres duplicar la información, simplemente con acceder como te he dicho antes (creando sinónimo de las tablas) tendrás información on-line de todo lo que tengas en SQL*Server.
Consejo : Cuidado con el ancho de banda y con crear consultas complejas.
Si lo haces sin almacenamiento propio (en Oracle) el tiempo de acceso a los datos de SQL*Server será igual a :
"La carga que tenga el servidor SQL*Server" + "un pequeño diferencial de tiempo en la traducción, despreciable" + "Comunicación de Datos por la red".
Espero que te haya servido de ejemplo o solución válida. Ambos modos, el duplicar la información o el acceder son válidos. Ahora eres tu el que debe de decidir por que opción optar, en función de tu contexto.
Un Saludo y espero que haya sido de tu ayuda.
Ramón
LO que hace es crear una BB. DD. Oracle 'parcial' (en la maquina donde tengas SQL*Server) que hace de puente con tu BB. DD. ORACLE real en la maquina que tengas la replica ORACLE real.
Creas una entrada de comunicación en el 'tnsnames. Ora' de la real contra la ficticia.
Luego, para acceder, por ejemplo desde el ORACLE real a SQL*Server es como si accedieses mediante database link.
select * from tabla_sql_server@instancia_remota
Si quiere te creas un sinónimo para no escribir siempre el @instancia remota de cada tabla.
Sino, no lo crees, ya que si quieres almacenar los cambios de SQLSERVER, lo que tendrás que hacer son MATERIALIZED VIEW, es en las que pondrás la select anterior para cada tabla que te interese guardar datos y un 'log' de la 'View Materializada'. Por temas de rendimiento.
Pero si no quieres duplicar la información, simplemente con acceder como te he dicho antes (creando sinónimo de las tablas) tendrás información on-line de todo lo que tengas en SQL*Server.
Consejo : Cuidado con el ancho de banda y con crear consultas complejas.
Si lo haces sin almacenamiento propio (en Oracle) el tiempo de acceso a los datos de SQL*Server será igual a :
"La carga que tenga el servidor SQL*Server" + "un pequeño diferencial de tiempo en la traducción, despreciable" + "Comunicación de Datos por la red".
Espero que te haya servido de ejemplo o solución válida. Ambos modos, el duplicar la información o el acceder son válidos. Ahora eres tu el que debe de decidir por que opción optar, en función de tu contexto.
Un Saludo y espero que haya sido de tu ayuda.
Ramón
Hola Ramón,
Muchas gracias por la respuesta, de echo ya había pensado en el transparent gateway, pero aquí tengo la duda, ¿esta herramienta me sirve si deseo comunicarme desde oracle a sql server o no?
De echo por el contexto que voy a a manejar si voy a tener que duplicar toda la información de sql server a oracle, ahí viene mi duda, el transparent gateway me sirve si lo que deseo es por cada transacción que hagan en sql server se me actualize de manera automática la db de en oracle, ¿o tendría que tener una herramienta similar en sql server?
Gracias y perdón por la lata.
Muchas gracias por la respuesta, de echo ya había pensado en el transparent gateway, pero aquí tengo la duda, ¿esta herramienta me sirve si deseo comunicarme desde oracle a sql server o no?
De echo por el contexto que voy a a manejar si voy a tener que duplicar toda la información de sql server a oracle, ahí viene mi duda, el transparent gateway me sirve si lo que deseo es por cada transacción que hagan en sql server se me actualize de manera automática la db de en oracle, ¿o tendría que tener una herramienta similar en sql server?
Gracias y perdón por la lata.
Tranquilo no das la lata, y aquí estoy para intentarte ayudar en lo posible.
Te comentaba que hay dos opciones :
1.- Que desde Oracle accedas a los datos residentes en SQL*SERVER.
2.- Que realices copias instantáneas = a duplicidad de datos en 2 BB. DD.
El controlador en Transparent Gateway es ORACLE. Pero es el que manda. Eso no quita el que sea bi-direccional. Pero siempre mandando Oracle.
Desde tu instancia Oracle podrás acceder en lectura, modificación, alta y baja registros de SQL*Server si lo deseas sin necesidad de duplicar la información.
Si por contra, lo que quieres es 'migrar' o 'mantener dos sistemas sincronizados' hasta realizar una migración total' puedes optar por la replica (con Vistas materializadas) o bien 'tirar' del acceso remoto.
En cuanto a tus preguntas en concreto, decirte que esta herramienta o componente permite comunicar Oracle con Sql*Server, DB2, MySql, ..., etc.
Y a la segunda, si deseas duplicar la información de cada transacción de SQL*Server en Oracle, las Vistas Materializadas se encargan de eso. En cada evento o cada cierto tiempo 'Materializan' la información canviada en SQL*Server en un objeto ORACLE llamado MATERIALIZED VIEW (que se comporta como tablas, -puedes definir indices, ..., etc).
No es necesario tener ninguna herramienta de SQL*Server para lo que necesitas.
Recuerda que o bien accedes de forma transparente a unas tablas de SQL*Server (totalmente on-line y con posibilidades de modificar, borrar, dar de alta y consultar) pero viéndolas desde una instancia Oracle y como si de objetos virtuales se tratasen, O bien tiendes a replicar, que lo único que conseguirás es tener la última copia provocada por la última transacción realizada en SQL*Server en un Objeto de BB. DD. Oracle.
Espero que te quede claro el concepto. La idea es bastante clara el único problema que puedes tener es que por saturación de carga en los recursos del Servidor de BB. DD. Sql*Server, una petición desde ORACLE con TG tarde más de lo debido. Pero eso no se puede evitar, a no ser que optimices la carga transaccional de esa máquina y sus recursos.
Ah! Y si optas por duplicar con las Vistas Materializadas, tranquilo que hay commit two-phrase. Y te recomiendo la creación de 'log, s' de estas vistas (que guardan información de todo lo que desde la última actualización se ha realizado. Con lo cual, el refresco es inmediato.
Lo único que no puedes hacer es que SQL*Server sea el que manda. No puede actualizar explícitamente objetos ORACLE. Pero como en todo hay un truco.
Te creas una tabla de comunicación, marcas un campo 'flag' y en Oracle creas un JOB. Este que analice a ver si el 'flag' lo ha activado SQL*Server. Y si es así, que haga sobre Oracle lo que SQL*Server le está indicando con la activación de ese flag (que no es más que una columns de una tabla de SQL*Server que ORACLE consulta, realiza el proceso que desea SQL*Server y actualiza el 'flag' a no activo (modificando la columna de la tabla SQL*Server'.
Como puedes ver todas las situaciones pueden ser cubiertas por esta solución.
Es más, en las ultimas versiones ha desaparecido un producto complementario que se llamaba 'Oracle Procedural Gateway' y creo que desde Oracle con esta nueva version del TG puedes invocar o ejecutar 'procedimientos' en 'Transac SQL' de SQL*Server.
Espero haberte ayudado. No tenia sueño y por eso me he extendido tanto, esperando que hayas comprendido la dimensión y funcionalidad de este componente.
Un Saludo
Ramón.
NOTA : Por cierto, si estás en una empresa de BCN y necesitáis de un perfil similar al mio, te recuerdo que estoy buscando cambiar de empresa.
Te comentaba que hay dos opciones :
1.- Que desde Oracle accedas a los datos residentes en SQL*SERVER.
2.- Que realices copias instantáneas = a duplicidad de datos en 2 BB. DD.
El controlador en Transparent Gateway es ORACLE. Pero es el que manda. Eso no quita el que sea bi-direccional. Pero siempre mandando Oracle.
Desde tu instancia Oracle podrás acceder en lectura, modificación, alta y baja registros de SQL*Server si lo deseas sin necesidad de duplicar la información.
Si por contra, lo que quieres es 'migrar' o 'mantener dos sistemas sincronizados' hasta realizar una migración total' puedes optar por la replica (con Vistas materializadas) o bien 'tirar' del acceso remoto.
En cuanto a tus preguntas en concreto, decirte que esta herramienta o componente permite comunicar Oracle con Sql*Server, DB2, MySql, ..., etc.
Y a la segunda, si deseas duplicar la información de cada transacción de SQL*Server en Oracle, las Vistas Materializadas se encargan de eso. En cada evento o cada cierto tiempo 'Materializan' la información canviada en SQL*Server en un objeto ORACLE llamado MATERIALIZED VIEW (que se comporta como tablas, -puedes definir indices, ..., etc).
No es necesario tener ninguna herramienta de SQL*Server para lo que necesitas.
Recuerda que o bien accedes de forma transparente a unas tablas de SQL*Server (totalmente on-line y con posibilidades de modificar, borrar, dar de alta y consultar) pero viéndolas desde una instancia Oracle y como si de objetos virtuales se tratasen, O bien tiendes a replicar, que lo único que conseguirás es tener la última copia provocada por la última transacción realizada en SQL*Server en un Objeto de BB. DD. Oracle.
Espero que te quede claro el concepto. La idea es bastante clara el único problema que puedes tener es que por saturación de carga en los recursos del Servidor de BB. DD. Sql*Server, una petición desde ORACLE con TG tarde más de lo debido. Pero eso no se puede evitar, a no ser que optimices la carga transaccional de esa máquina y sus recursos.
Ah! Y si optas por duplicar con las Vistas Materializadas, tranquilo que hay commit two-phrase. Y te recomiendo la creación de 'log, s' de estas vistas (que guardan información de todo lo que desde la última actualización se ha realizado. Con lo cual, el refresco es inmediato.
Lo único que no puedes hacer es que SQL*Server sea el que manda. No puede actualizar explícitamente objetos ORACLE. Pero como en todo hay un truco.
Te creas una tabla de comunicación, marcas un campo 'flag' y en Oracle creas un JOB. Este que analice a ver si el 'flag' lo ha activado SQL*Server. Y si es así, que haga sobre Oracle lo que SQL*Server le está indicando con la activación de ese flag (que no es más que una columns de una tabla de SQL*Server que ORACLE consulta, realiza el proceso que desea SQL*Server y actualiza el 'flag' a no activo (modificando la columna de la tabla SQL*Server'.
Como puedes ver todas las situaciones pueden ser cubiertas por esta solución.
Es más, en las ultimas versiones ha desaparecido un producto complementario que se llamaba 'Oracle Procedural Gateway' y creo que desde Oracle con esta nueva version del TG puedes invocar o ejecutar 'procedimientos' en 'Transac SQL' de SQL*Server.
Espero haberte ayudado. No tenia sueño y por eso me he extendido tanto, esperando que hayas comprendido la dimensión y funcionalidad de este componente.
Un Saludo
Ramón.
NOTA : Por cierto, si estás en una empresa de BCN y necesitáis de un perfil similar al mio, te recuerdo que estoy buscando cambiar de empresa.
