- Duplicación SQLServer 2000 -

Hola,

Creo que por el volumen de máquinas que indicas, creo que sería conveniente
separar la figura del publicador y distribuidor en máquinas diferentes. De
todas formas, sería conveniente tener más datos, sobre volúmenes de
información, de transacciones, máquina actual, etc...

Un saludo
Salvador Ramos
Murcia - España
[Microsoft MVP SQL Server]
www.helpdna.net (información sobre SQL server, Windows DNA y .NET)

"keko" escribió en el mensaje
news:

Hola, ya hace dos años, con la ayuda de este foro y algunas web configuré
el sistema de duplicación de sql, GRACIAS, funciona bien salvo en
ocasiones con el tema de los conflictos.

Ahora la pregunta es, tengo en un servidor 100 bases de datos, cada una
publicada en una de mezcla y esta con dos suscripciones, una del cliente y
otra del asociado de sincronización alternativo.

1.- Es una burrada tener 100 (posiblemenete mas) bases de datos publicadas
en el mismo servidor?.

2.- Cuando se lanza (continuamente) los agentes de mezcla para el tema del
asociado de sincronización alternativo el ordenador levanta un proceso por
cada uno y, claro, me tumba el equipo, no llega a tumbarlo pero se queda
hecho una pasa y al final empiezan a provocar errores 70 de los 100
agentes... he sobrepasado el límite?, si amplio la maquina?...

3.- En vista de esto, debería plantearme el tener una sola base de datos
(centralizar todas las de los clientes en una sola) y por lo tanto sólo
una publicación con muchos suscriptores?.

4.- El caso es que tengo una por cada cliente porque en su día pensé si
existía algun problema en una base de datos de un cliente no afectaría al
resto, de hecho, esto es cierto en 90% de los casos*, mientras que si las
centralizo me juego todos los clientes a una carta, ¿me explico o digo una
tontería?

*Todas las bases de datos se "suponen" iguales.

Muchas gracias.
Keko

Hola Keko,

Primero comentarte que yo estoy en una situacion muy parecida a la tuya pero
al reves ;-).
Tengo replicacion por mezcla y una única base de datos con todos los
clientes.

Paso a intentar contestarte tus preguntas:

1) --> A mi personalmente 100 bases de datos me parecen demasiadas , se te
multiplican por 100 las tareas de mantenimiento (backup, indices ), y si
además las tienes publicadas ... bufff. ¿Que volumen de datos tiene cada
base de datos?.

2) Si no te he entendido mal se levantan de forma simultanea los 100 agentes
?¿. Y si los pones para que se levante de forma espaciada , uno cada X
tiempo, o varios en grupitos , pero todos a la vez la verdad es que son
muchos.

3) Esta es la opción que estoy implementado yo, si lo haces aparte de los
temas de replicación ten en cuenta que:
* Tendias que modificar tu aplicación
* Si antes en una tabla tenias 5 filas ahora tendras 500 lo digo por los
temas de rendimiento.
* Si tienes que añadir un campo a una tabla Solo tendras que hacerlo
una vez y no 100 !!!!
* .
Es posible que una solución intermedia sea la mejor , por ejemplo 10 bases
de datos en lugar de 100 o una única.

4) En cuanto a este punto, valora que supone tener parado a tu/s cliente/s,
y una vez valorado decide si tener un backup es suficiente, si necesitas un
cluster, bbdd en standby ... etc. Pero este punto deberias sopesarlo tanto
para una como para 100 base de datos.

Aprovecho y te hago unas preguntillas sencillas:

* ¿Has tenido algun problema que la replicación?

* ¿La consideras estable y fiable?. Yo estoy haciendo pruebas y la verdad es
que me asusta un poco ... (Bueno un mucho ;-)).

Saludos.



www.metasincro.es
"keko" wrote in message
news:

Hola, ya hace dos años, con la ayuda de este foro y algunas web configuré
el sistema de duplicación de sql, GRACIAS, funciona bien salvo en
ocasiones con el tema de los conflictos.

Ahora la pregunta es, tengo en un servidor 100 bases de datos, cada una
publicada en una de mezcla y esta con dos suscripciones, una del cliente y
otra del asociado de sincronización alternativo.

1.- Es una burrada tener 100 (posiblemenete mas) bases de datos publicadas
en el mismo servidor?.

2.- Cuando se lanza (continuamente) los agentes de mezcla para el tema del
asociado de sincronización alternativo el ordenador levanta un proceso por
cada uno y, claro, me tumba el equipo, no llega a tumbarlo pero se queda
hecho una pasa y al final empiezan a provocar errores 70 de los 100
agentes... he sobrepasado el límite?, si amplio la maquina?...

3.- En vista de esto, debería plantearme el tener una sola base de datos
(centralizar todas las de los clientes en una sola) y por lo tanto sólo
una publicación con muchos suscriptores?.

4.- El caso es que tengo una por cada cliente porque en su día pensé si
existía algun problema en una base de datos de un cliente no afectaría al
resto, de hecho, esto es cierto en 90% de los casos*, mientras que si las
centralizo me juego todos los clientes a una carta, ¿me explico o digo una
tontería?

*Todas las bases de datos se "suponen" iguales.

Muchas gracias.
Keko

Primero gracias por contestar y perdon porque he estado enfermo de baja
y no he podido leer las noticias... falta de ganas, la verdad.

1.- En efecto las tareas de mantenimiento dan miedo, pero o cierto es
que las programo con el asisten y programando una vez me hace los
mantenimientos sober todas... de todos modos eso normalmente no recae en
mi persona, aunque ahora si, de momento no tengo demasiados problemas.
El volumen de datos, bien, algunas mas que otras, podría decirte que de
media suelen ser bases de datos de 150megas, aunque ya te digo, de
media, y mas o menos se incrementan de 50 a 100 por año... aunque cada
año se vuelve a empezar de cero. es decir, desde septiembre a septiembre
aumentan unos 100 megas.

2.- En efecto tengo los agentes programados en cuatro grupos a distintas
horas... a las 12, a las 2, a las 4, etc.. de ese modo ahora levanto
25agentes en cada franja pero eso si, es un poco cutre porque en
cualquier momento puede ser que tenga que dar de alta un nuevo cliente y
es un trabajo farragoso y delicado he pensado en automatizarlo pero
lo de siempre, no hay tiempo...


3.- La aplicación, en efecto, ya esta implementada y no puedo hacer
cambios drásticos en menos de dos años, pero ya estamos empezando a
pensar en la nueva versión que saldrá, como digo, en dos años, y por eso
estoy a tiempo de pensar en cambiar o no el sistema o que. Respecto al
número de filas por tabla, pensaba que con el filtrado de filas ese
podía hacer que solo se mezclen las filas necesarias en cada cliente,
aunque aun asi, la aplicación web y la de computacion telefonica es
posible que se resintieran al acceder a la base de datos... ufff. Sobre
campos a añadir, si, se me convierte en un problema. De ahi pensar en el
cambio, por el mantenimiento de una sola frente a 100... lo de la
solución intermedia no se me había ocurrido.. es posible que no sea mala
idea...

4.- El tema del cluster ya se propuso pero es cierto que vale una pasta,
ahora mismo la empresa me ha comunicado que quizá mas adelante se
implante pero no ahora... el hecho es que si me dan carta blanca eso
iria hacia delante.

-

Respecto a tus preguntas, algunos problemas si he tenido, primero porque
un error en el diseño de la base de datos relacionado con los identity,
cagada, pero bueno, en principio lo tengo solucionado, aunque a veces es
para volverse loco, por otro lado el hecho del poco control que se tiene
sobre la mezcla, no sabes quien ha mezclado que y donde... es decir, no
puedes saber en que tabla que filas... eso me parece una carencia...
pero bueno, a mi en general me va bien salvo alguna que otra
incidencia... que he solucionado con algunas horitas extras por amor al
arte :D pero si, me da bastante miedo en ocasiones. Tambien me crea
problemas el hecho de que nadie en la empresa salvo mi mano derecha y yo
parece entender como funciona la duplicación y a veces nos vemos en
conversaciones que asustan de verdad...

Pero resummiendo, a mi me ha funcionado durante algo mas de dos años...
y como te cuento los problemas que he tenido han sido por los identity y
ah! si, se me olvidaba, en muchas ocasiones el hecho de tener que
depender de internet es un problema (menor) a la hora de los firewalls,
de las continuas caidas de la ADSL del cliente o de increible latencia
que pega unos timeouts de miedo

Por lo demás, bien, de hecho no he perdido datos de ningun cliente.
Incluso cuando me cayó el servidor principal sin tener aun el asociado y
lo cierto es que en 4 horas tenia restauradas y republicadas todas las
bases de datos, eso si, hubo que reinicializar a 50 clientes de entonces
:D

Un saludo, para lo que necesites... aqui estoy.
Un saludo,
KEKO


Oscar wrote:

Hola Keko,

Primero comentarte que yo estoy en una situacion muy parecida a la tuya pero
al reves ;-).
Tengo replicacion por mezcla y una única base de datos con todos los
clientes.

Paso a intentar contestarte tus preguntas:

1) --> A mi personalmente 100 bases de datos me parecen demasiadas , se te
multiplican por 100 las tareas de mantenimiento (backup, indices ), y si
además las tienes publicadas ... bufff. ¿Que volumen de datos tiene cada
base de datos?.

2) Si no te he entendido mal se levantan de forma simultanea los 100 agentes
?¿. Y si los pones para que se levante de forma espaciada , uno cada X
tiempo, o varios en grupitos , pero todos a la vez la verdad es que son
muchos.

3) Esta es la opción que estoy implementado yo, si lo haces aparte de los
temas de replicación ten en cuenta que:
* Tendias que modificar tu aplicación
* Si antes en una tabla tenias 5 filas ahora tendras 500 lo digo por los
temas de rendimiento.
* Si tienes que añadir un campo a una tabla Solo tendras que hacerlo
una vez y no 100 !!!!
* .
Es posible que una solución intermedia sea la mejor , por ejemplo 10 bases
de datos en lugar de 100 o una única.

4) En cuanto a este punto, valora que supone tener parado a tu/s cliente/s,
y una vez valorado decide si tener un backup es suficiente, si necesitas un
cluster, bbdd en standby ... etc. Pero este punto deberias sopesarlo tanto
para una como para 100 base de datos.

Aprovecho y te hago unas preguntillas sencillas:

* ¿Has tenido algun problema que la replicación?

* ¿La consideras estable y fiable?. Yo estoy haciendo pruebas y la verdad es
que me asusta un poco ... (Bueno un mucho ;-)).

Saludos.

Hola,

Por lo que veo no te ha dado "demasiados" problemas ;-)

Nuestra sistema todavia no se ha puesto en marcha, pero la base de datos
ocupa 35 Gigas y cada año seguramente aumentará del orden de 5 a 10Gb. (Ya
estoy dandole vueltas al tema del historico ...).

Mi mayor preocupación con la replicación es tener que retransmitir toda esta
cantidad de datos, uan que tengo la opción de llevar los datos en cd,dvd,
dat, o disquetes ;-) esto supondria varios dias de inactividad en alguna de
las centrales

Otra cosa que me preocupa es el impacto que tendrá la replicación sobre el
sistema, ya que tenemos unas restriciones sobre el tiempo máximo en la
recuperación de datos bastante fuertes.

Saludos y a mejorarse ( que la vuelta siempre es dura !!)




www.metasincro.es
"keko" wrote in message
news:

Primero gracias por contestar y perdon porque he estado enfermo de baja y
no he podido leer las noticias... falta de ganas, la verdad.

1.- En efecto las tareas de mantenimiento dan miedo, pero o cierto es que
las programo con el asisten y programando una vez me hace los
mantenimientos sober todas... de todos modos eso normalmente no recae en
mi persona, aunque ahora si, de momento no tengo demasiados problemas. El
volumen de datos, bien, algunas mas que otras, podría decirte que de media
suelen ser bases de datos de 150megas, aunque ya te digo, de media, y mas
o menos se incrementan de 50 a 100 por año... aunque cada año se vuelve a
empezar de cero. es decir, desde septiembre a septiembre aumentan unos 100
megas.

2.- En efecto tengo los agentes programados en cuatro grupos a distintas
horas... a las 12, a las 2, a las 4, etc.. de ese modo ahora levanto
25agentes en cada franja pero eso si, es un poco cutre porque en cualquier
momento puede ser que tenga que dar de alta un nuevo cliente y es un
trabajo farragoso y delicado he pensado en automatizarlo pero lo de
siempre, no hay tiempo...


3.- La aplicación, en efecto, ya esta implementada y no puedo hacer
cambios drásticos en menos de dos años, pero ya estamos empezando a pensar
en la nueva versión que saldrá, como digo, en dos años, y por eso estoy a
tiempo de pensar en cambiar o no el sistema o que. Respecto al número de
filas por tabla, pensaba que con el filtrado de filas ese podía hacer que
solo se mezclen las filas necesarias en cada cliente, aunque aun asi, la
aplicación web y la de computacion telefonica es posible que se
resintieran al acceder a la base de datos... ufff. Sobre campos a añadir,
si, se me convierte en un problema. De ahi pensar en el cambio, por el
mantenimiento de una sola frente a 100... lo de la solución intermedia no
se me había ocurrido.. es posible que no sea mala idea...

4.- El tema del cluster ya se propuso pero es cierto que vale una pasta,
ahora mismo la empresa me ha comunicado que quizá mas adelante se implante
pero no ahora... el hecho es que si me dan carta blanca eso iria hacia
delante.

-

Respecto a tus preguntas, algunos problemas si he tenido, primero porque
un error en el diseño de la base de datos relacionado con los identity,
cagada, pero bueno, en principio lo tengo solucionado, aunque a veces es
para volverse loco, por otro lado el hecho del poco control que se tiene
sobre la mezcla, no sabes quien ha mezclado que y donde... es decir, no
puedes saber en que tabla que filas... eso me parece una carencia... pero
bueno, a mi en general me va bien salvo alguna que otra incidencia... que
he solucionado con algunas horitas extras por amor al arte :D pero si, me
da bastante miedo en ocasiones. Tambien me crea problemas el hecho de que
nadie en la empresa salvo mi mano derecha y yo parece entender como
funciona la duplicación y a veces nos vemos en conversaciones que asustan
de verdad...

Pero resummiendo, a mi me ha funcionado durante algo mas de dos años... y
como te cuento los problemas que he tenido han sido por los identity y ah!
si, se me olvidaba, en muchas ocasiones el hecho de tener que depender de
internet es un problema (menor) a la hora de los firewalls, de las
continuas caidas de la ADSL del cliente o de increible latencia que pega
unos timeouts de miedo

Por lo demás, bien, de hecho no he perdido datos de ningun cliente.
Incluso cuando me cayó el servidor principal sin tener aun el asociado y
lo cierto es que en 4 horas tenia restauradas y republicadas todas las
bases de datos, eso si, hubo que reinicializar a 50 clientes de entonces
:D

Un saludo, para lo que necesites... aqui estoy.
Un saludo,
KEKO


Oscar wrote:

Hola Keko,

Primero comentarte que yo estoy en una situacion muy parecida a la tuya
pero al reves ;-).
Tengo replicacion por mezcla y una única base de datos con todos los
clientes.

Paso a intentar contestarte tus preguntas:

1) --> A mi personalmente 100 bases de datos me parecen demasiadas , se
te multiplican por 100 las tareas de mantenimiento (backup, indices
), y si además las tienes publicadas ... bufff. ¿Que volumen de datos
tiene cada base de datos?.

2) Si no te he entendido mal se levantan de forma simultanea los 100
agentes ?¿. Y si los pones para que se levante de forma espaciada , uno
cada X tiempo, o varios en grupitos , pero todos a la vez la verdad es
que son muchos.

3) Esta es la opción que estoy implementado yo, si lo haces aparte de los
temas de replicación ten en cuenta que:
* Tendias que modificar tu aplicación
* Si antes en una tabla tenias 5 filas ahora tendras 500 lo digo por
los temas de rendimiento.
* Si tienes que añadir un campo a una tabla Solo tendras que hacerlo
una vez y no 100 !!!!
* .
Es posible que una solución intermedia sea la mejor , por ejemplo 10
bases de datos en lugar de 100 o una única.

4) En cuanto a este punto, valora que supone tener parado a tu/s
cliente/s, y una vez valorado decide si tener un backup es suficiente, si
necesitas un cluster, bbdd en standby ... etc. Pero este punto deberias
sopesarlo tanto para una como para 100 base de datos.

Aprovecho y te hago unas preguntillas sencillas:

* ¿Has tenido algun problema que la replicación?

* ¿La consideras estable y fiable?. Yo estoy haciendo pruebas y la verdad
es que me asusta un poco ... (Bueno un mucho ;-)).

Saludos.

Gracias, intento mejorarme,

En efecto no me ha dado demasiados problemas pero está claro que con
bases de datos mayores yo creo que problemas de conflictos mayores... de
todos modos yo creo que es un sistema bastante fiable.

Suerte, ya me contarás.


Oscar wrote:

Hola,

Por lo que veo no te ha dado "demasiados" problemas ;-)

Nuestra sistema todavia no se ha puesto en marcha, pero la base de datos
ocupa 35 Gigas y cada año seguramente aumentará del orden de 5 a 10Gb. (Ya
estoy dandole vueltas al tema del historico ...).

Mi mayor preocupación con la replicación es tener que retransmitir toda esta
cantidad de datos, uan que tengo la opción de llevar los datos en cd,dvd,
dat, o disquetes ;-) esto supondria varios dias de inactividad en alguna de
las centrales

Otra cosa que me preocupa es el impacto que tendrá la replicación sobre el
sistema, ya que tenemos unas restriciones sobre el tiempo máximo en la
recuperación de datos bastante fuertes.

Saludos y a mejorarse ( que la vuelta siempre es dura !!)