Replicacion en VLDB

Hola Jose:
10 horas!!!, conozco de procesos que mueven 30 millones de filas en 3
horas, y con procesos complejos, asi que no se que estas haciendo pero yo
trataria de optimizar ese proceso. No estaras usando cursores? Si es asi, te
garantizo que puedes bajarlo a por lo menos 1 hora.
Asumiendo que no es asi, durante las 10 horas que se ejecuta el proceso
asumo que se siguen haciendo cambios?
Si es asi, yo consideraria usar replicacion de mezcla, porque:
a) Te permite escoger las tablas que vas a replicar.
b) Te permite escoger como manejeran los conflictos.
c) Puedes invocar el trabajo de replicacion por demanda, antes de
iniciar el proceso, y luego de terminarlo. Esto te permite controlar el
impacto que tiene la replicacion sobre el otro servidor.
Saludos,

Javier Loria
Costa Rica-MVP
Solid Quality Learning

"Jose Nadim" wrote in message
news:
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
>
>