REPLICACION: preocupado por la performance de la aplicación

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, 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:

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

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:

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:

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 , 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

el problema es si tenes campos TEXT , IMAGE o IDENTITY


"Guillermo Villanueva" escribió en el
mensaje news:

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