Replicar bbdd

"Javier Loria" escribió en el mensaje
news:#

Hola:
La replicacion maneja 2 objetivos de diseno contradictorios: Autonomia

y

Latencia.
a) Que tan autonomos requieres los sitios?, si se cae el enlace

podrian

ambos sitios continuaroperando normalmente?, solo uno?, etc.
b) Que tanto puedes esperar a tener datos "actualizados" 1 segundo, 1
hora, 1 dia?.
Estos 2 objetivos, junto con la cantidad de datos, la frecuencia de

las

modificaciones, en donde ocurren, tipo de enlace, cantidad de servidores,
etc. te permiten escoger mejor el tipo de replica. Pero no pierdas de

vista

(Autonomia/Latencia), los demas ojetivos cambian con relativa frecuencia y
no afectan tanto como estos.
Saludos,

En principio pienso que media hora o una hora puede ser una elección buena.

Esto no significa que *todos* los datos esperen una hora a actualizarse ¿no?
Me imagino que en momentos de inactividad (o bien lo antes posible), las
bases tenderían a sincronizarse, siendo una hora simplemente el tope máximo.

Es decir, que cada transacción realizada, intentará replicarse en la otra
bbdd lo antes posible ¿no?

Eso se configura, puede ser cada X o lo más pronto posible (continua), pero
javier creo que va mas por si caen las comunicaciones por ejemplo, también
hay errores (por ejemplo una clave duplicada) que te paran la publicación,
igual de muchas tablas. Aunque es muy buena opción la replicación, obliga a
tareas fuertes de administración.

Saludos
Miguel Egea
"iDeafix" escribió en el mensaje
news:br74g2$2fmu$

"Javier Loria" escribió en el mensaje
news:#
> Hola:
> La replicacion maneja 2 objetivos de diseno contradictorios:

Autonomia

y
> Latencia.
> a) Que tan autonomos requieres los sitios?, si se cae el enlace
podrian
> ambos sitios continuaroperando normalmente?, solo uno?, etc.
> b) Que tanto puedes esperar a tener datos "actualizados" 1 segundo,

1

> hora, 1 dia?.
> Estos 2 objetivos, junto con la cantidad de datos, la frecuencia de
las
> modificaciones, en donde ocurren, tipo de enlace, cantidad de

servidores,

> etc. te permiten escoger mejor el tipo de replica. Pero no pierdas de
vista
> (Autonomia/Latencia), los demas ojetivos cambian con relativa frecuencia

y

> no afectan tanto como estos.
> Saludos,

En principio pienso que media hora o una hora puede ser una elección

buena.

Esto no significa que *todos* los datos esperen una hora a actualizarse

¿no?

Me imagino que en momentos de inactividad (o bien lo antes posible), las
bases tenderían a sincronizarse, siendo una hora simplemente el tope

máximo.

Es decir, que cada transacción realizada, intentará replicarse en la otra
bbdd lo antes posible ¿no?

Puedes montar una replicación transaccional, utilizando la actualización en
cola.

Busca en el índice de la ayuda "actualización en cola" y encontrarás amplia
información sobre el tema".

Creo que la solución a tu problema es montar una replicación transaccional
con actualización en cola.

Copiado de la ayuda:

La actualización en cola permite que los suscriptores de duplicación de
instantáneas y transaccional modifiquen los datos publicados sin recurrir a
una conexión de red activa con el publicador.

Cuando crea una publicación con la opción de actualización en cola
habilitada y el suscriptor ejecuta instrucciones INSERT, UPDATE o DELETE en
los datos publicados, los cambios se almacenan en una cola. Las
transacciones en cola se aplican de forma asíncrona en el publicador cuando
se restaura la conexión de red.

Debido a que las actualizaciones se propagan de forma asíncrona al
publicador, los mismos datos pueden haber sido actualizados por el
publicador o por otro suscriptor y, por lo tanto, se pueden producir
conflictos al aplicar las actualizaciones.

Los conflictos se detectan y resuelven según una directiva de resolución de
conflictos establecida al crear la publicación. La transacción se propaga a
otros suscriptores mediante los mecanismos de duplicación típicos (la
detección de bucle de retorno evita el envío de la actualización al
suscriptor en que se originó la transacción).

La actualización en cola es más apropiada para las aplicaciones en que la
mayoría de las operaciones de los usuarios son de lectura de datos y sólo se
realizan actualizaciones ocasionalmente. Los suscriptores estarán conectados
la mayor parte del tiempo, pero si trabajan sin conexión, podrán continuar
las actualizaciones sin interrupción.

Tanto la actualización en cola como la duplicación de mezcla permiten la
actualización sin conexión; sin embargo, hay diferencias significativas
entre los dos métodos. Para obtener más información, consulte Duplicación de
mezcla o suscripciones actualizables.



Un saludo
Salvador Ramos
Murcia - España

No puedes conseguir software rápidamente disminuyendo su calidad.
En cambio, si que lo consigues aumentando la calidad.

www.helpdna.net (información sobre Windows DNA, SQL Server, .NET, ...)


Microsoft MVP SQL Server
MCP SQL Server
PASS Spanish Group (www.sqlpass.org)


"iDeafix" escribió en el mensaje
news:br6udr$28i9lf$

"Salvador Ramos" escribió en el
mensaje news:
> Hola:
>
> En principio, sin conocer, el volumen de datos y de transacciones que se
> están realizando y otros datos, es muy aventurado dar una respuesta.

Pero

en
> principio creo que si que sería suficiente.
>

En una sede trabajan unas 10 personas máximo, leyendo y corrigiendo datos
durante todo el día.
En la otra podrá llegar a haber 50 como máximo, realizando un uso
esporádico, digamos unas tres inserciones de nuevos registros (unos

treinta

campos) a lo largo de todo el día. También habrá dos o tres usuarios que
realicen consultas frecuentes (de un único registro) pero no cambiarán
datos.

saludos


> Sólo una cosa, ten cuidado si utilizas transacciones distribuidas, ya

que

si
> se cae la línea (cosa que puede ocurrir) quedarían ambos servidores sin
> poder introduccir nuevas transacciones.
>
¿Que otra opción de transacciones hay?

gracias

tengo algunas dudas de conceptos
¿duplicar?
¿replicar?
¿publicar?
¿suscriptor?
¿usuario?

¿podeis recomendarme un texto introductorio para empezar con buen pie?

gracias


PD: por lo que voy viendo existen publicadores, suscriptores y
distribuidores, acabo de crear un distribuidor, ¿se puede ser distribuidor y
publicador al mismo tiempo? Es que no veo la publicación desde el otro
servidor.


"iDeafix" escribió en el mensaje
news:br4rha$28jb15$

A ver si pudierais darme algún consejo práctico a la hora de replicar

bbdd.

Problemas, cosas con las que andar con ojo, etc.

Quiero que la mitad de la empresa acceda a un servidor y la otra mitad al
otro y, por supuesto, que los cambios hechos por unos se reflejen en lo

que

ven los otros y viceversa.

¿Funcionará sobre una conexión compuesta de dos enlaces ADSL de 2Mb?

saludos
gracias

replicar y duplicar es lo mismo,

Publicador> El escritor del libro
Distribuidor > el del kiosko
Suscriptor > el que lee la información

Los libros en pantalla están bastante bien.

Al crear una publicación determinas el distribuidor que naturalmente puede
ser el mismo servidor (crea una base de datos llamada distribution), luego
te suscribres a una publicación desde un cliente o creas la sucripción desde
el propio servidor..

Saludos
Miguel egea
"iDeafix" escribió en el mensaje
news:br9cdk$kl9g$

tengo algunas dudas de conceptos
¿duplicar?
¿replicar?
¿publicar?
¿suscriptor?
¿usuario?

¿podeis recomendarme un texto introductorio para empezar con buen pie?

gracias


PD: por lo que voy viendo existen publicadores, suscriptores y
distribuidores, acabo de crear un distribuidor, ¿se puede ser distribuidor

y

publicador al mismo tiempo? Es que no veo la publicación desde el otro
servidor.


"iDeafix" escribió en el mensaje
news:br4rha$28jb15$
> A ver si pudierais darme algún consejo práctico a la hora de replicar
bbdd.
> Problemas, cosas con las que andar con ojo, etc.
>
> Quiero que la mitad de la empresa acceda a un servidor y la otra mitad

al

> otro y, por supuesto, que los cambios hechos por unos se reflejen en lo
que
> ven los otros y viceversa.
>
> ¿Funcionará sobre una conexión compuesta de dos enlaces ADSL de 2Mb?
>
> saludos
> gracias
>
>