REPLICACION: preocupado por la performance de la aplicación

sql server 2000
Las instrucciones INSERT, UPDATE y DELETE en el publicador sobre columnas
text e image se admiten sin ninguna consideración especial. Sin embargo,
estas columnas no pueden ser actualizadas por suscriptores que utilicen la
duplicación de instantáneas o la duplicación transaccional y suscripciones
de actualización inmediata o de actualización en cola.

osea que la replicacion transaccional va a andar rapido !! por que no
funciona..


"Maxi" escribió en el mensaje
news:
Mostrar la cita

Hola, y esto que tiene que ver con la performance?


-
Microsoft M.V.P en SQLServer
SQLTotal Consulting - Servicios en SQLServer
Email:
"Germán Valdez" escribió en el mensaje
news:uGH8io$
Mostrar la cita

el problema es si tenes campos TEXT , IMAGE o IDENTITY


"Guillermo Villanueva" escribió en
el mensaje news:
Mostrar la cita

Hola , buenos días.
Hace un tiempo que vengo haciendo pruebas de replicación con la idea de
implementarla en la empresa donde trabajo, para que la base de datos de
la central esté sincronizada con las de las sucursale en forma
"automática".
Hasta ahora venía hacieéndolo a mano , usando backups y scripts.
Pude configurar una replicación de tipo MERGE y está funcionando ok en
un ambiente de pruebas, pero al ponerme a revisar , modificó el diseño
de tooodas las tablas, agregando tres triggers y una columna de
identificación, esto me preocupa mucho en como puede afectar a la
performance de la aplicación!!! si haría siempre transacciones simples,
no me preocupa mucho, pero tenemos procesos que generan transacciones
masivas insertando por ejemplo 1000 o 2000 filas a la vez. en distintas
tablas, si todas tienen triggers escuchando , mmmm esto no me convence
del todo.
Por favor, les pido que posteen su opinión al respecto.
Saludos y FELIZ NAVIDAD

Hola, creo que usted esta confundiendo algunas cosas amigo! que esos campos
no anden no quiere decir que ande mas rapido la replicacion, de hecho la
replicacion transaccional es la que menos sobrecarga genera pero nada que
ver con lo que usted esta comentando de limitaciones de este tipo de campos
que ademas hay que ver si nuestro amigo lo tiene, esto no tiene nada que ver
con la performance como bien ha preguntado el amigo en la pregunta inicial


Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"Germán Valdez" escribió en el mensaje de
noticias:#
Mostrar la cita

sql server 2000
Las instrucciones INSERT, UPDATE y DELETE en el publicador sobre columnas
text e image se admiten sin ninguna consideración especial. Sin embargo,
estas columnas no pueden ser actualizadas por suscriptores que utilicen la
duplicación de instantáneas o la duplicación transaccional y suscripciones
de actualización inmediata o de actualización en cola.

osea que la replicacion transaccional va a andar rapido !! por que no
funciona..


"Maxi" escribió en el mensaje
news:
Mostrar la cita

Hola, y esto que tiene que ver con la performance?


-
Microsoft M.V.P en SQLServer
SQLTotal Consulting - Servicios en SQLServer
Email:
"Germán Valdez" escribió en el mensaje
news:uGH8io$
Mostrar la cita

el problema es si tenes campos TEXT , IMAGE o IDENTITY


"Guillermo Villanueva" escribió en
el mensaje news:
Mostrar la cita

Hola , buenos días.
Hace un tiempo que vengo haciendo pruebas de replicación con la idea de
implementarla en la empresa donde trabajo, para que la base de datos de
la central esté sincronizada con las de las sucursale en forma
"automática".
Hasta ahora venía hacieéndolo a mano , usando backups y scripts.
Pude configurar una replicación de tipo MERGE y está funcionando ok en
un ambiente de pruebas, pero al ponerme a revisar , modificó el diseño
de tooodas las tablas, agregando tres triggers y una columna de
identificación, esto me preocupa mucho en como puede afectar a la
performance de la aplicación!!! si haría siempre transacciones simples,
no me preocupa mucho, pero tenemos procesos que generan transacciones
masivas insertando por ejemplo 1000 o 2000 filas a la vez. en distintas
tablas, si todas tienen triggers escuchando , mmmm esto no me convence
del todo.
Por favor, les pido que posteen su opinión al respecto.
Saludos y FELIZ NAVIDAD

Creo que la elección de MERGE es, al menos, apropiada, por el riesgo de
pérdida de conectividad y por la posibilidad de actualizaciones en
Publicador y Suscriptor. Además, el Distribuidor, tendrá una carga mínima en
el caso de MERGE, pudiendo utilizar una topología de Distribuidor Local. Y
además, soy un fanático de la Replicación de Mezcla ;-) Esto no quita,
que se pueda hacer o no con Replicación Transaccional...

En principio, en el rendimiento no debería de tener un impacto notable. Sin
embargo, existen consideraciones de diseño. Te indico alguna:

- La Replicación de Mezcla, soporta filtros por parámetros, filtros de
combinación para extender los filtros por parámetros, y filtros estáticos
(con esto podemos minimizar el número de Publicaciones, pues hay quien crea
múltiples Publicaciones con filtros estáticos, en vez de una Publicación con
un Filtro por parámetros o Filtro dinámico). También soporta replicar por
HTTPS (se puede utilizar un certificado autofirmado o emitido por una CA de
empresa no comercial), incluso sobre NLB para evitar convertir al IIS en un
punto crítico de nuestra infraestructura de IT. No sabría decirte de
memoria, si esto que te comento lo soportan Suscriptores MSDE, o sólo SQL
Express (la replicación por HTTPS seguro que sólo SQL Express o SQL Server
2005, los filtros, tendría que ver si hay compatibilidad en todos los casos
o no).

- Cuidado al realizar cargas masivas con BULK INSERT o BCP, pues si no
"saltan" los triggers de seguimientos de cambio de la réplica, puedes tener
problemas (http://technet.microsoft.com/en-us/...51206.aspx). Ojo
con DTS y SSIS, pues algunas tareas por "debajo" utilizan BCPs. Otras ETLs
como PowerCenter suelen hacer INSERTs (para que hacer BCPs, si puedo hacerlo
todo más lento !! ;-). En casos especiales, se puede utilizar BULK INSERT o
BPC, y luego reinicializar manualmente las Suscripciones, pero sabiendo de
ante mano sus implicaciones, ventajas e inconvenientes.

- Es útil crear el mayor número de Publicaciones posibles, para minimizar
el riesgo de un futuro cambio de esquema que pudiera implicar reinicializar
las Suscripciones (ej: un cambio, adición o eliminación de un filtro por
parámetro, implica aplicar una nueva Instantánea sin permitir Sincronizar
cambios antes - Riesgo de pérdida de datos locales !! ; Además, el que viaje
la Instantánea - se cambien filtros por parámetros o no - , tiene impacto en
el consumo de ancho de banda y en el tiempo de Mezcla). Si sólo tienes una
Publicación, un cambio sobre una tabla pequeña podría implicar que viajase
TODA la Instantánea por la red. Además, si utilizamos múltiples
Publicaciones, podemos aplicar distintos Filtros por Parámetros si lo
necesitásemos (es decir, en cada Suscripción del mismo Suscriptor sobre
distintas Publicaciones con Filtros por parámetros, podemos sobrescribir
HOST_NAME con valores distintos, lo cual es vital en muchos casos).

Espero que te sirvan estos comentarios.
Saludos, y Felices Fiestas !

GuilleSQL
http://www.guillesql.es




"Guillermo Villanueva" wrote in message
news:OPAij%
Mostrar la cita

Gracias Maxi por tu respuesta.
Elegí Merge porque la conexión no será muy estable que digamos (ADSL) y
porque solo el servidor principal es Standar y los demás son todos MSDE.
Debo cubrir la posibilidad que en todos los puntos se producirán
actualizaciones.
Te parece que está bien Merge?
Gracias de nuevo.



"Maxi" escribió en el mensaje
news:
Mostrar la cita

Hola, yo he implementado varias replicaciones, desde 5 server hasta 50
servidores, y no afecta como usted piensa la performance.
Un solo detalle, no se porque ha usado MERGE y no transaccional, pero
esta ultima es mas recomendada si es que su negocio lo soporta.


-
Microsoft M.V.P en SQLServer
SQLTotal Consulting - Servicios en SQLServer
Email:
"Guillermo Villanueva" escribió en
el mensaje news:
Mostrar la cita

Hola , buenos días.
Hace un tiempo que vengo haciendo pruebas de replicación con la idea de
implementarla en la empresa donde trabajo, para que la base de datos de
la central esté sincronizada con las de las sucursale en forma
"automática".
Hasta ahora venía hacieéndolo a mano , usando backups y scripts.
Pude configurar una replicación de tipo MERGE y está funcionando ok en
un ambiente de pruebas, pero al ponerme a revisar , modificó el diseño
de tooodas las tablas, agregando tres triggers y una columna de
identificación, esto me preocupa mucho en como puede afectar a la
performance de la aplicación!!! si haría siempre transacciones simples,
no me preocupa mucho, pero tenemos procesos que generan transacciones
masivas insertando por ejemplo 1000 o 2000 filas a la vez. en distintas
tablas, si todas tienen triggers escuchando , mmmm esto no me convence
del todo.
Por favor, les pido que posteen su opinión al respecto.
Saludos y FELIZ NAVIDAD

No estoy utilizando ese tipo de campos.

Muchas gracias Guille, si, una de las principales razones por la que elegí
MERGE es el tipo de conexión que utilizo y la necesidad de independencia ,
estén o no conectados los puntos.
FELIZ NAVIDAD!!!