REPLICACION

Hola Emilio

Pues ahi tienes que el Servidor2, solo es para
contingencias, solo cuando falle el Servidor1.

Consideraciones:la base del Servidor1 es un SAP con 150GB
y tiene un bus de 1GB.

Mis temores:

Que baje demasiado el performance del servidor de
produccion (Server1).

¿Que tipo de REPLICACION implementar?

Saludos che

Amigo Isaias,

lo que propone Fernando es un simil-proceso de Log Shipping manual. No esta
mal y funciona de maravillas pero tiene la pega que si uno implementa eso
debe aceptar que puede haber perdida de datos. Dicho en forma mas clara, el
primer proceso del Log Shipping es transferira un estado consistente de la
BBDD de un servidor al otro (es como el snapshot inicial de toda
replicacion). Una vez hecho esto se van tomando backups de Log del primario
y se van restaurando en el secundario. Cuando el servidor primario se daña
se debe hacer un backup de log ya que entre el ultimo backup hecho y el daño
se asume que hubo operaciones. El problema radica en que si el servidor
primario se daña en forma talq ue no es posible hacer un backup del Log el
servidor secundario tendra una porcion de datos sin recibir. Esa es la
perdida de datos que se debe asumir si se implementa Log Shipping. Si esto
no es aceptable para tu esquema y ambos deben tener la misma info en todo
momento, te recomiendo consideres la opcion de un cluster, pues hasta tanto
no este disponible SQL Server 2005 con su capacidad de Data Mirroring (un
Log Shipping continuo, parece replicacion pero es Log Shipping) no tendras
otra solucion provista por SQL Server ... a lo mejor un producto de terceros
...

Vale aclarar que el Log Shipping automatico es parte del plan de
mantenimiento de las BBDD en la edicion Enterprise de SQL Server 2000. En la
Standard habra que programarse los backups y restores a pulso.


Saludos !

Emilio Boucau
Buenos Aires - Argentina
http://www.portalsql.com

Isaias,

el problema con la replicacion es cuando se caiga. En este caso necesitas un
esquema de Alta Disponibilidad, por lo que antes te recomende un cluster o
Log Shipping. Si bien con replicacion lograras hacer 'circular' los datos
cuando tu publicador se caiga deberas levantar el suscriptor. Lo unico seria
que establecieras una replicacion tipo merge y que sea pull para que cada
suscriptor sincronice 'on demand' y no automatico ... pero aun asi no me
gusta la idea.


Saludos !

Emilio Boucau
Buenos Aires - Argentina
http://www.portalsql.com

Gracias Emilio

De hecho mi primera propuesta fue precisamente este
esquema, mas sin embargo no he podido convencer a la gente
de hacerlo asi, como nunca he implementado una REPLICACION
como tal, los unicos argumentos que tengo a la mano, es
que el performance se vera afectado (del servidor
primario), ya que se estableceran nuevos servicios como lo
son el PUBLICADOR y DISTRIBUIDOR.

Seguire insistiendo en lo que tu comentas, por otro lado,
¿crees que la cantidad de datos (150 GB) sea un factor
importante en la REPLICACION?

Saludos

Hola Isaias:
Mi opinion:
Replicacion esta disenado para la distribucion GEOGRAFICA de datos. Aun
cuando es posible utilizarla para otras cosas su objetivo de diseno es
comunicarse por medio de enlaces WAN. Si para esto tiene que penalizar el
desempeno del servidor bien, mientras logre su objetivo, comunicarse en
enlaces con fallos frecuentes y de bajo ancho de banda.
Dependiendo el modelo de replicacion se producen importanes cambios en
el esquema (Columnas Adicionales, CHECKs, Tablas Adicionales, Triggers,
etc.), Mi experiencia es que la replicacion Transaccional/Merge tiene un
costo del 30% al 100%, en desempeno.
La tolerancia a Fallas puede construirse mucho mejor usando las
herramientas apropiadas: Clusters o Log Shipping. La propuesta de Fernando
aunque manual, es muy valida.
Por ultimo, haz una encuesta informal entre los proveedores de servicios
que tienes a ver cuantos han montado replicacion de SQL, y que te den casos.
Esto porque ahora de los balazos conseguir quien te de soporte de
replicacion va ha ser dificil.
La diferencia entre el profesional y el aprendiz es que el profesional
usa la herramienta adecuada para el trabajo adecuado. Insiste en tu punto
porque tienes la razon. Si no te creen monta un laboratorio y realiza
pruebas.
Suerte,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Isaías escribio:

Gracias Emilio

De hecho mi primera propuesta fue precisamente este
esquema, mas sin embargo no he podido convencer a la gente
de hacerlo asi, como nunca he implementado una REPLICACION
como tal, los unicos argumentos que tengo a la mano, es
que el performance se vera afectado (del servidor
primario), ya que se estableceran nuevos servicios como lo
son el PUBLICADOR y DISTRIBUIDOR.

Seguire insistiendo en lo que tu comentas, por otro lado,
¿crees que la cantidad de datos (150 GB) sea un factor
importante en la REPLICACION?

Saludos