Replicacion SQL 2000

Hola:
Depende de los patrones de cambio y autonomia de los sitios. De forma
rapida:
a) Cuando los mismos datos se modifican en varios lugares simultaneamente la
de mezcla (merge) es la mejor.
b) Cuando los datos pueden ser divididos por filas y solo se actualizarn en
un solo sitio y rara vez se actualizan en dos lugares, suele ser mejor la
transaccional.
c) Cuando son pocos datos (catologos de sistema usualmente).que se modifican
esporadicamente lo mejor es snapshots.
Con poco ancho de banda, practicamente descartas snapshots.
Si los mismos datos se cambias muchas veces (ejemplo un saldo de
inventario) es mas eficiente mezcla que transaccional.
Saludos,


Javier Loria
Costa Rica-MVP
Solid Quality Learning


"Toti J" wrote in message
news:%23XA0GGF%

De los tres modos de replicación de bases de datos que nos proporciona SQL
2000 (snapshot, transaccional y de fusión) cual de ellas me recomendaríais
en el caso de replicar una BBDD entre 2 SQL 2000 SP3 Stantdard unidos por
VPN a través de Internet y con poco ancho de banda

He visto que hay agentes en la de merge (fusión) para casos de ancho de
banda pequeño se admiten sugerencias.

Por otro lado el distribuidor lo pondría en el publicador.

De antemano gracias mil.

Toti, primero deberias definir que tipo de replicacion usar, o sea: si los
datos van y vienen o solo van


Salu2

Microsoft MVP SQL Server
Culminis Speaker
INETA Speaker

"Toti J" escribió en el mensaje
news:%23XA0GGF%

De los tres modos de replicación de bases de datos que nos proporciona SQL
2000 (snapshot, transaccional y de fusión) cual de ellas me recomendaríais
en el caso de replicar una BBDD entre 2 SQL 2000 SP3 Stantdard unidos por
VPN a través de Internet y con poco ancho de banda

He visto que hay agentes en la de merge (fusión) para casos de ancho de
banda pequeño se admiten sugerencias.

Por otro lado el distribuidor lo pondría en el publicador.

De antemano gracias mil.

Gracias por contestar... la replicación por snapshot la tengo casi
descartada... el tema está en el que el publicador (BBDD origen) es donde
tiene más de 15 inserciones por segundo (me parecen muchas), la base de
datos destino (suscriptor) sólo debe leer los datos del publicador y
traerselos para luego poder hacer estadísticas.

Es decir, los datos sólo circularán desde la bbdd origen hacia la bbdd
destino y la bbdd destino solo leerá los datos de la origen y lo aplicará en
local.

De este modo, ¿cuál interesaría más de los dos modelos de replicación?
Además quiero que los datos esten en ambos extremos casi al instante
replicados, como mucho con una tardanza de unos 5 minutos.

Gracias.

"Maxi" wrote in message
news:utgv2SF%

Toti, primero deberias definir que tipo de replicacion usar, o sea: si los
datos van y vienen o solo van


Salu2

Microsoft MVP SQL Server
Culminis Speaker
INETA Speaker

"Toti J" escribió en el mensaje
news:%23XA0GGF%

De los tres modos de replicación de bases de datos que nos proporciona
SQL
2000 (snapshot, transaccional y de fusión) cual de ellas me
recomendaríais
en el caso de replicar una BBDD entre 2 SQL 2000 SP3 Stantdard unidos por
VPN a través de Internet y con poco ancho de banda

He visto que hay agentes en la de merge (fusión) para casos de ancho de
banda pequeño se admiten sugerencias.

Por otro lado el distribuidor lo pondría en el publicador.

De antemano gracias mil.

Otro dato interesante es que la bbdd ocupa más de 50 GB... y no quiero que
se cargue el servidor que tiene la bbdd origen, ¿puedo calcular el tamaño
estimado de la bbdd "distribution" que crea sql?¿Afectará el poco ancho de
banda junto al alto númeo de inserciones? Lo que no quiero es que se para el
servidor origen, porque ese sí está en producción.

"Toti J" wrote in message
news:%23nbRt6M%

Gracias por contestar... la replicación por snapshot la tengo casi
descartada... el tema está en el que el publicador (BBDD origen) es donde
tiene más de 15 inserciones por segundo (me parecen muchas), la base de
datos destino (suscriptor) sólo debe leer los datos del publicador y
traerselos para luego poder hacer estadísticas.

Es decir, los datos sólo circularán desde la bbdd origen hacia la bbdd
destino y la bbdd destino solo leerá los datos de la origen y lo aplicará
en local.

De este modo, ¿cuál interesaría más de los dos modelos de replicación?
Además quiero que los datos esten en ambos extremos casi al instante
replicados, como mucho con una tardanza de unos 5 minutos.

Gracias.

"Maxi" wrote in message
news:utgv2SF%

Toti, primero deberias definir que tipo de replicacion usar, o sea: si
los datos van y vienen o solo van


Salu2

Microsoft MVP SQL Server
Culminis Speaker
INETA Speaker

"Toti J" escribió en el mensaje
news:%23XA0GGF%

De los tres modos de replicación de bases de datos que nos proporciona
SQL
2000 (snapshot, transaccional y de fusión) cual de ellas me
recomendaríais
en el caso de replicar una BBDD entre 2 SQL 2000 SP3 Stantdard unidos
por
VPN a través de Internet y con poco ancho de banda

He visto que hay agentes en la de merge (fusión) para casos de ancho de
banda pequeño se admiten sugerencias.

Por otro lado el distribuidor lo pondría en el publicador.

De antemano gracias mil.

Hola:
El tamaño de la BD de distribución depende del tipo de replicación.
En la replicación Transaccional se requiere que la BD de Distribución
mantenga los cambios que los Agentes lectores del Log leen, y es posible que
tenga que mantenerse hasta semanas de cambios.
En la replicación Merge la BD Replicada es la que aumenta de tamaño al
agregar una columna UNIQUEIDENTIFIER y algunas tablas adicionales para
llevar control de la tabla y fila que cambio con su GUID. Estas tablas son
de un tamaño importante.
Adicionalmente tienes que calcular que el folder donde se hacen los
snapshots, tendra los scripts de la BD y un volcado completo de los datos.
Si usar formato de propietario de SQL ocupa mas o menos el mismo tamaño que
la BD sin los indices, si usar formato compatible con otros motores de BD
ocupa mucho mas. Se puede habilitar la compresion de estos archivos y se
reduce sustancialmente el tamaño.
Para replicaciones con minutos de diferencia es mejor la transaccional.
Yo normalmente calculo un 20% mas de carga de trabajo para el servidor
cuando usar replicacion transaccional y es su propio distribuidor.
Saludos,


Javier Loria
Costa Rica-MVP
Solid Quality Learning


"Toti J" wrote in message
news:%23AZzE8M%

Otro dato interesante es que la bbdd ocupa más de 50 GB... y no quiero que
se cargue el servidor que tiene la bbdd origen, ¿puedo calcular el tamaño
estimado de la bbdd "distribution" que crea sql?¿Afectará el poco ancho de
banda junto al alto númeo de inserciones? Lo que no quiero es que se para
el servidor origen, porque ese sí está en producción.

"Toti J" wrote in message
news:%23nbRt6M%

Gracias por contestar... la replicación por snapshot la tengo casi
descartada... el tema está en el que el publicador (BBDD origen) es donde
tiene más de 15 inserciones por segundo (me parecen muchas), la base de
datos destino (suscriptor) sólo debe leer los datos del publicador y
traerselos para luego poder hacer estadísticas.

Es decir, los datos sólo circularán desde la bbdd origen hacia la bbdd
destino y la bbdd destino solo leerá los datos de la origen y lo aplicará
en local.

De este modo, ¿cuál interesaría más de los dos modelos de replicación?
Además quiero que los datos esten en ambos extremos casi al instante
replicados, como mucho con una tardanza de unos 5 minutos.

Gracias.

"Maxi" wrote in message
news:utgv2SF%

Toti, primero deberias definir que tipo de replicacion usar, o sea: si
los datos van y vienen o solo van


Salu2

Microsoft MVP SQL Server
Culminis Speaker
INETA Speaker

"Toti J" escribió en el mensaje
news:%23XA0GGF%

De los tres modos de replicación de bases de datos que nos proporciona
SQL
2000 (snapshot, transaccional y de fusión) cual de ellas me
recomendaríais
en el caso de replicar una BBDD entre 2 SQL 2000 SP3 Stantdard unidos
por
VPN a través de Internet y con poco ancho de banda

He visto que hay agentes en la de merge (fusión) para casos de ancho de
banda pequeño se admiten sugerencias.

Por otro lado el distribuidor lo pondría en el publicador.

De antemano gracias mil.