Arquitectura réplicas sql entre diferentes servidores

[ericklanford]

Hola amigos.

En la organización para la que trabajo existen varios centros donde se genera cierta información. De manera general dichos centros están conectados a un nodo central donde se quiere registrar toda la información generada.

Inicialmente planeé que se creara en el nodo central una tabla para cada lugar con su información que debería viajar mediante réplicas transaccionales. El problema con esto es que voy a tener muchas tablas que acceder cuando necesite hacer cualquier consulta y que además cada vez que tenga que conectar un nuevo centro voy atener que modificar toda la estructura de mis programas.

Luego pensé que todas las tablas se pudieran réplicar hacia una en el nodo central. Pero esto tiene el inconveniente de que cada vez que se reinicie una réplica se borran todos los datos en el servidor central.

He leído bastante hacerca de réplicas sql y hasta hoy no he encontrado una respuesta a mi problema. Por favor, agradecería cualquier sugerencia.

Pd: Todas las tablas tienen por supuesto la misma estructura.
ejemplo:

lugar 1:
variable valor
A 1
B 2

lugar 2:
variable valor
C 1
D 32

nodo central:(quisiera tener)
variable valor
A 1
B 2
C 1
D 32

[Libras]

y porque no manejas un sistema de datawarehouse, que todos tus nodos envien la informacion hacia la base de datos central y ahi la proceses, por ejemplo yo tengo esa arquitectura con 6 consolas que envian informacion cada hora a un servidor central y en este servidor se procesa que nada mas se guarde la informacion nueva y la vieja se actualice...

Saludos!

[matanga]

Suponiendo que: la replicación se hace desde los nodos locales hacia el nodo central pero no entre nodos locales, que los nodos locales y el nodo central tienen el mismo modelo de tablas, y que el nodo central es read-only, tienes dos opciones para identificar los registros que se deben modificar en cada replicación:

1. Utilizar un identificador de nodo local agregando un campo en todas las tablas, por ejemplo:

Código:

--nodo 1
create table Clientes (
idNodo varchar(4) default 'NOD1',
idCliente int identity primary key,
...)
go

--nodo 2
create table Clientes (
idNodo varchar(4) default 'NOD2',
idCliente int identity primary key,
...)
go

--nodo central con pk compuesta
create table Clientes (
idNodo varchar(4),
idCliente int,
...)
go
alter table Clientes add constraint pk_clientes
 primary key (idNodo, IdCliente)
go

2. Utilizar un rango de valores, por ejemplo:

Código:

--nodo 1
create table Clientes (
idCliente int identity(1,1) primary key,
check (idCliente between 1 and 1000)
)
go

--nodo 2
create table Clientes (
idCliente int identity(2000,1) primary key,
check (idCliente between 2000 and 3000)
)
go

--nodo central con pk simple
create table Clientes (
idCliente int primary key,
...)
go

Con la opción 1 tienes la ventaja de no preocuparte por los rangos (límite de registros) y la desventaja de que ocupa más espacio, lo opuesto con la opción 2, que ocupa menos espacio y tiene un límite de registros por tabla en cada nodo, pero en ambos casos, agregar un nodo nuevo no afecta la estructura de los programas y permiten implementar la replicación con Transactional Replication, DTS, SSIS o consultas SQL con linked server.

Saludos

[ericklanford]

Libras, reconozco que no sé mucho de 'datawarehouse'. Pero te prometo que voy a investigar lo que me propones. Te agradezco.

[ericklanford]

matanga, en realidad el problema no es replicar ya que esto ya lo hago. El problema es cuando hay que reinicializar una suscripción (en algún nodo local); y es un problema pues como se copia un snapshop de esa tabla local hacia la central, lo que pasa es que borra todos los datos que ya existían de los otros nodos locales.
Para el ejemplo que puse anteriormente si hubiera que reinicializar la réplica desde el nodo local 2 el resultado en el nodo central sería el siguiente:

lugar 1:
variable valor
A 1
B 2

lugar 2:
variable valor
C 1
D 32

nodo central:
variable valor
C 1
D 32

[matanga]

Justamente por esto necesitas una forma de identificar las filas de cada nodo local, en el caso de Transactional Replication tienes la propiedad Row Filter, y en DTS, SSIS o Linkedserver la clausula where, que permiten borrar selectivamente las filas del nodo central.

Saludos

[ericklanford]

matanga, según entiendo la propiedad Row Filter de Transactional Replication se utiliza para especificar que información debería transmitirse hacia los suscriptores.

En mi caso ese no es el problema. De hecho yo soy capaz de poner a funcionar el sistema y todo bien.

El problema surge cuando se interrumpe una de las réplicas y es necesario reiniciaizarla.
Esto trae como consecuencia que se borre toda la información en el suscritor (que es el mismo para todas las publicación); por lo tanto se pierde toda la información de las otras publicaciones. Espero que me puedas ayudar pues ya no encuentro que hacer. Saludos.