Replicacion SQL 2000

25/10/2006 - 18:20 por Toti J | Informe spam
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.

Preguntas similare

Leer las respuestas

#6 Toti J
27/10/2006 - 14:34 | Informe spam
Gracias Javier.

En el piloto que me he montado en el suscriptor me indica un error:

"El proceso no pudo recuperar la información de seguridad del suscriptor
para el distribuidor server01"

El suscriptor lo tengo montado en el server02 y el distribuidor y publicador
en el server01.

¿Se te ocurre a qué puede deberse?

Gracias

"Javier Loria" wrote in message
news:OHuB8QQ%

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.























Respuesta Responder a este mensaje
#7 Javier Loria
27/10/2006 - 16:04 | Informe spam
Hola:
Este error suele ocurrire cuando el servidor02 no puede ver el folder
compartido donde estan los snapshots, esto puede deberse a filtros en el
firewalls o a permisos.
Puedes usar la cuenta del agente de SQL para hacer login en el
servidor02 y tratar de alcanzar el folder para verificarlo.
Saludos,


Javier Loria
Costa Rica-MVP
Solid Quality Learning


"Toti J" wrote in message
news:OYvqBRc%

Gracias Javier.

En el piloto que me he montado en el suscriptor me indica un error:

"El proceso no pudo recuperar la información de seguridad del suscriptor
para el distribuidor server01"

El suscriptor lo tengo montado en el server02 y el distribuidor y
publicador en el server01.

¿Se te ocurre a qué puede deberse?

Gracias

"Javier Loria" wrote in message
news:OHuB8QQ%

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.




























email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida