Replicacion en VLDB

la replicación no tiene porqué funcionar mal en ese entorno, el principal
problema es la sincronización inicial, sobre todo si las lineas no son muy
rápdas. En 2005 se puede comenzar una replicación transaccional mediante un
backup.
¿cuando dices que en forma bidireccioanl te refieres a que las mismas tablas
se modifican en todos los extremos?

Saludos
Miguel Egea
"Jose Nadim" wrote in message
news:
Hola tenemos instalado SQL 2000 nuestra bd importnte está sobre los
180 gb de los cuales necesito encontrar una estrategia de replicacion ,
calculo que las tablas areplicar son aproximadamente 50 tablas, que son
fuertemente actualizables. La idea es correr procesos bastante grandes
en esa bd de replica en forma bidireccional.
Seriá lo adecuado ? (yo consideraria que no ) ; adicionalemnte las 50
tabla suman unos 70gb.
Otra estrategia seria mover esa tablas a filegorups realizar backups
mas pequeños realizar el proceso y luego actualizar (con sus
respectivos controles).
SQl 2005 me ayudaria en replicas ? q opciones de 2005 me
servirian?...
O tomo tomo software de terceros para re alizar tareas de este tipo..
como x ejemplo lite speed (el bkp de 180 gb lo baja a 45 gb y el timepo
tambien).

Gracias

Jose Nadim

Hola Miguel, la idea es correr un proceso de actualizacion de datos que
dura 10 horas y que afecta una gran cantidad de tablas en otro
servidor, luego pasar los datos modificados al server de produccion,
aun no se cual estrategia es mejor si una replicacion en un solo
sentido de server de produccion a server de proceso y luego por diseño
y codigo controlar las actualizaciones realizada; o si replicacion en
ambos sentidos con el fin de actualizar datos en ambas bases de datos.
agradezco sugerencias.

Jose Nadim
Miguel Egea wrote:

la replicación no tiene porqué funcionar mal en ese entorno, el principal
problema es la sincronización inicial, sobre todo si las lineas no son muy
rápdas. En 2005 se puede comenzar una replicación transaccional mediante un
backup.
¿cuando dices que en forma bidireccioanl te refieres a que las mismas tablas
se modifican en todos los extremos?

Saludos
Miguel Egea
"Jose Nadim" wrote in message
news:
Hola tenemos instalado SQL 2000 nuestra bd importnte está sobre los
180 gb de los cuales necesito encontrar una estrategia de replicacion ,
calculo que las tablas areplicar son aproximadamente 50 tablas, que son
fuertemente actualizables. La idea es correr procesos bastante grandes
en esa bd de replica en forma bidireccional.
Seriá lo adecuado ? (yo consideraria que no ) ; adicionalemnte las 50
tabla suman unos 70gb.
Otra estrategia seria mover esa tablas a filegorups realizar backups
mas pequeños realizar el proceso y luego actualizar (con sus
respectivos controles).
SQl 2005 me ayudaria en replicas ? q opciones de 2005 me
servirian?...
O tomo tomo software de terceros para re alizar tareas de este tipo..
como x ejemplo lite speed (el bkp de 180 gb lo baja a 45 gb y el timepo
tambien).

Gracias

Jose Nadim

Hola Jose:
Si Miguel me permite, debes considear cual es el objetivo de la replica,
distribuir la carga, tolerancia a fallas, o distribucion geografica de los
datos?; tambien debes considerar no solo el tamaño sino tambien el ancho de
banda entre los servidores.
Si lo que quieres es distribuir la carga entre varios servidores, puedes
usar varias estrategias:
a) Sevidores Federados de Base de Datos: Son tablas que se distribuyen entre
dos o mas servidores, y es transparente para la aplicacion.
b) Replicacion Peer-to-Perr (Compañero a Compañero?): Solo disponible en SQL
2005 permite tener la misma informacion en 2 o mas servidores y que luego
usando el transaction log se repliquen los cambios de uno a los demas. Todas
las BD son de lectura y escritura.
c) Replicacion Transaccional/Log Shipping: Con cualquiera de estas dos, una
BD es solo de escritura y las demas son solo de Lectura, de manera que el
sistema usa una BD para reporteria y otro para transacciones.
Si el objetivo es tolerancia a Fallas, SQL te ofrece Log Shipping y
Database Mirroring entre otros.
Si el objetivo es Distribucion geografica de datos, y los datos se
actualizan en varios sitios Replicacion de Mezcla es la mejor opcion, pero
tambien puedes usar Replicacion Transaccional con actualizaciones
(inmediatas y en cola).
Antes de comprar otro software de tercero yo probaria lo que viene
construido con SQL 2005 en un Laboratorio, y solo si el rendimiento no es
aceptable buscaria otro software.
Saludos,

Javier Loria
"Jose Nadim" wrote in message
news:
Hola Miguel, la idea es correr un proceso de actualizacion de datos que
dura 10 horas y que afecta una gran cantidad de tablas en otro
servidor, luego pasar los datos modificados al server de produccion,
aun no se cual estrategia es mejor si una replicacion en un solo
sentido de server de produccion a server de proceso y luego por diseño
y codigo controlar las actualizaciones realizada; o si replicacion en
ambos sentidos con el fin de actualizar datos en ambas bases de datos.
agradezco sugerencias.

Jose Nadim
Miguel Egea wrote:

la replicación no tiene porqué funcionar mal en ese entorno, el principal
problema es la sincronización inicial, sobre todo si las lineas no son muy
rápdas. En 2005 se puede comenzar una replicación transaccional mediante
un
backup.
¿cuando dices que en forma bidireccioanl te refieres a que las mismas
tablas
se modifican en todos los extremos?

Saludos
Miguel Egea
"Jose Nadim" wrote in message
news:
Hola tenemos instalado SQL 2000 nuestra bd importnte está sobre los
180 gb de los cuales necesito encontrar una estrategia de replicacion ,
calculo que las tablas areplicar son aproximadamente 50 tablas, que son
fuertemente actualizables. La idea es correr procesos bastante grandes
en esa bd de replica en forma bidireccional.
Seriá lo adecuado ? (yo consideraria que no ) ; adicionalemnte las 50
tabla suman unos 70gb.
Otra estrategia seria mover esa tablas a filegorups realizar backups
mas pequeños realizar el proceso y luego actualizar (con sus
respectivos controles).
SQl 2005 me ayudaria en replicas ? q opciones de 2005 me
servirian?...
O tomo tomo software de terceros para re alizar tareas de este tipo..
como x ejemplo lite speed (el bkp de 180 gb lo baja a 45 gb y el timepo
tambien).

Gracias

Jose Nadim

magnifica contestación como siempre javier, Solo añadiría que es posible
publicar procedimientos almacenados y el resultado es que ese SP se ejecute
también en el otro server. El resultado es que si se van a modificar muchos
datos igual es más recomendable.

Saludos
Migue Egea
"Javier Loria" wrote in message
news:

Hola Jose:
Si Miguel me permite, debes considear cual es el objetivo de la
replica, distribuir la carga, tolerancia a fallas, o distribucion
geografica de los datos?; tambien debes considerar no solo el tamaño sino
tambien el ancho de banda entre los servidores.
Si lo que quieres es distribuir la carga entre varios servidores,
puedes usar varias estrategias:
a) Sevidores Federados de Base de Datos: Son tablas que se distribuyen
entre dos o mas servidores, y es transparente para la aplicacion.
b) Replicacion Peer-to-Perr (Compañero a Compañero?): Solo disponible en
SQL 2005 permite tener la misma informacion en 2 o mas servidores y que
luego usando el transaction log se repliquen los cambios de uno a los
demas. Todas las BD son de lectura y escritura.
c) Replicacion Transaccional/Log Shipping: Con cualquiera de estas dos,
una BD es solo de escritura y las demas son solo de Lectura, de manera que
el sistema usa una BD para reporteria y otro para transacciones.
Si el objetivo es tolerancia a Fallas, SQL te ofrece Log Shipping y
Database Mirroring entre otros.
Si el objetivo es Distribucion geografica de datos, y los datos se
actualizan en varios sitios Replicacion de Mezcla es la mejor opcion, pero
tambien puedes usar Replicacion Transaccional con actualizaciones
(inmediatas y en cola).
Antes de comprar otro software de tercero yo probaria lo que viene
construido con SQL 2005 en un Laboratorio, y solo si el rendimiento no es
aceptable buscaria otro software.
Saludos,

Javier Loria
"Jose Nadim" wrote in message
news:
Hola Miguel, la idea es correr un proceso de actualizacion de datos que
dura 10 horas y que afecta una gran cantidad de tablas en otro
servidor, luego pasar los datos modificados al server de produccion,
aun no se cual estrategia es mejor si una replicacion en un solo
sentido de server de produccion a server de proceso y luego por diseño
y codigo controlar las actualizaciones realizada; o si replicacion en
ambos sentidos con el fin de actualizar datos en ambas bases de datos.
agradezco sugerencias.

Jose Nadim
Miguel Egea wrote:

la replicación no tiene porqué funcionar mal en ese entorno, el principal
problema es la sincronización inicial, sobre todo si las lineas no son
muy
rápdas. En 2005 se puede comenzar una replicación transaccional mediante
un
backup.
¿cuando dices que en forma bidireccioanl te refieres a que las mismas
tablas
se modifican en todos los extremos?

Saludos
Miguel Egea
"Jose Nadim" wrote in message
news:
Hola tenemos instalado SQL 2000 nuestra bd importnte está sobre los
180 gb de los cuales necesito encontrar una estrategia de replicacion ,
calculo que las tablas areplicar son aproximadamente 50 tablas, que son
fuertemente actualizables. La idea es correr procesos bastante grandes
en esa bd de replica en forma bidireccional.
Seriá lo adecuado ? (yo consideraria que no ) ; adicionalemnte las 50
tabla suman unos 70gb.
Otra estrategia seria mover esa tablas a filegorups realizar backups
mas pequeños realizar el proceso y luego actualizar (con sus
respectivos controles).
SQl 2005 me ayudaria en replicas ? q opciones de 2005 me
servirian?...
O tomo tomo software de terceros para re alizar tareas de este tipo..
como x ejemplo lite speed (el bkp de 180 gb lo baja a 45 gb y el timepo
tambien).

Gracias

Jose Nadim

Hola gracias por sus valiosos aportes, les voy a explicar cual es el
caso:
tenemos una serie de procesos que se deben correr 3 veces en el mes y
son bastante largos en tiempo 10 horas o mas, en resumen es com
realizar uncierre de año fiscal con todos los juguetes. Com esto debe
entregarse en un tiempo limite por compromiso contractual a un tercero
, debemos mejorar el rendimiento y entrega de datos en las horas
señaladas.
Nuestra primera solucion es pasar las tablas que intervienen en ese
proceso a otro server y luego de realizado el proceso actualizar las
tablas que se afectaron (al final no son mas de 8 y 200 mil registros
promedio) en produccion por la llave.El server es bastante robusto y
no tiene cerga de usuarios.; ya hemos realizado pruebas y obviamente
por ser solo el server de desarrollo el timepo baja un 30%, el detalle
està en como mantengo sincronizado en el que vamos a realizar el
proceso.Cual estrategia deberia ser, o mejor la estrategia pensada es
aceptable?

Gracias Miguel y Javier.
Un saludo
Jose Nadim.



Miguel Egea ha escrito:

magnifica contestación como siempre javier, Solo añadiría que es posible
publicar procedimientos almacenados y el resultado es que ese SP se ejecute
también en el otro server. El resultado es que si se van a modificar muchos
datos igual es más recomendable.

Saludos
Migue Egea
"Javier Loria" wrote in message
news:
> Hola Jose:
> Si Miguel me permite, debes considear cual es el objetivo de la
> replica, distribuir la carga, tolerancia a fallas, o distribucion
> geografica de los datos?; tambien debes considerar no solo el tamaño sino
> tambien el ancho de banda entre los servidores.
> Si lo que quieres es distribuir la carga entre varios servidores,
> puedes usar varias estrategias:
> a) Sevidores Federados de Base de Datos: Son tablas que se distribuyen
> entre dos o mas servidores, y es transparente para la aplicacion.
> b) Replicacion Peer-to-Perr (Compañero a Compañero?): Solo disponible en
> SQL 2005 permite tener la misma informacion en 2 o mas servidores y que
> luego usando el transaction log se repliquen los cambios de uno a los
> demas. Todas las BD son de lectura y escritura.
> c) Replicacion Transaccional/Log Shipping: Con cualquiera de estas dos,
> una BD es solo de escritura y las demas son solo de Lectura, de manera que
> el sistema usa una BD para reporteria y otro para transacciones.
> Si el objetivo es tolerancia a Fallas, SQL te ofrece Log Shipping y
> Database Mirroring entre otros.
> Si el objetivo es Distribucion geografica de datos, y los datos se
> actualizan en varios sitios Replicacion de Mezcla es la mejor opcion, pero
> tambien puedes usar Replicacion Transaccional con actualizaciones
> (inmediatas y en cola).
> Antes de comprar otro software de tercero yo probaria lo que viene
> construido con SQL 2005 en un Laboratorio, y solo si el rendimiento no es
> aceptable buscaria otro software.
> Saludos,
>
> Javier Loria
> "Jose Nadim" wrote in message
> news:
> Hola Miguel, la idea es correr un proceso de actualizacion de datos que
> dura 10 horas y que afecta una gran cantidad de tablas en otro
> servidor, luego pasar los datos modificados al server de produccion,
> aun no se cual estrategia es mejor si una replicacion en un solo
> sentido de server de produccion a server de proceso y luego por diseño
> y codigo controlar las actualizaciones realizada; o si replicacion en
> ambos sentidos con el fin de actualizar datos en ambas bases de datos.
> agradezco sugerencias.
>
> Jose Nadim
> Miguel Egea wrote:
>> la replicación no tiene porqué funcionar mal en ese entorno, el principal
>> problema es la sincronización inicial, sobre todo si las lineas no son
>> muy
>> rápdas. En 2005 se puede comenzar una replicación transaccional mediante
>> un
>> backup.
>> ¿cuando dices que en forma bidireccioanl te refieres a que las mismas
>> tablas
>> se modifican en todos los extremos?
>>
>> Saludos
>> Miguel Egea
>> "Jose Nadim" wrote in message
>> news:
>> Hola tenemos instalado SQL 2000 nuestra bd importnte está sobre los
>> 180 gb de los cuales necesito encontrar una estrategia de replicacion ,
>> calculo que las tablas areplicar son aproximadamente 50 tablas, que son
>> fuertemente actualizables. La idea es correr procesos bastante grandes
>> en esa bd de replica en forma bidireccional.
>> Seriá lo adecuado ? (yo consideraria que no ) ; adicionalemnte las 50
>> tabla suman unos 70gb.
>> Otra estrategia seria mover esa tablas a filegorups realizar backups
>> mas pequeños realizar el proceso y luego actualizar (con sus
>> respectivos controles).
>> SQl 2005 me ayudaria en replicas ? q opciones de 2005 me
>> servirian?...
>> O tomo tomo software de terceros para re alizar tareas de este tipo..
>> como x ejemplo lite speed (el bkp de 180 gb lo baja a 45 gb y el timepo
>> tambien).
>>
>> Gracias
>>
>> Jose Nadim
>
>