Diego, si el capo al que hace referencia Leonardo es Maxi o Mariano, yo use
algo que explicaron y dieron ejemplos en alguna charla y que es exactamente
lo que te comentan, funciona muy bien

Saludos
PabloC

-----Mensaje original-----
De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Diego Jancic
Enviado el: Jueves, 03 de Julio de 2008 15:16
Para: pablo.canonico
Asunto: [dbms] Proceso sin bloqueos

Wow!... Lindo tip!..
Vere si es muy complicado de adaptar..

Gracias!

2008/7/3 Leonardo Micheloni <[EMAIL PROTECTED]>:
> Hay una solución más compleja que me contó un capo ;-)
>
> Subís todo a una tabla temporal (una tabla física pero que no se use)
> con el bulk insert
>
> le ponés un trigger para delete (que se ejecuta antes del delete)
>
> con ese trigger hacés el insert/update/delete con una transacción, si
> algo falla no se hace el delete que disparó el trigger
>
> en algún momento (no sé si tenés la posiblidad de hacer ese proceso tipo
batch)
>
> Te tiras un delete top 1000 (sql 2005 soporta TOP en el delete) por
> ejemplo y se te van pasando y borrando los datos automáticamente.
>
> Seguro que quien me mostró esto te lo puede contar mejor, pero es un gran
truco.
>
> Saludos,
>
> 2008/7/3 Diego Jancic <[EMAIL PROTECTED]>:
>> Hola,
>>
>> Leonardo: Creo que corte la explicacion por la mitad, lo que quiero
>> hacer es meter todo dentro de una transaccion, y como la transaccion
>> bloquea la tabla que usa mientras esta activa (la transaccion) me va a
>> bloquear a todos los usuarios que quieran usar esta tabla.
>>
>> Hernan: Parece buena idea, a excepcion de performance. Para hacer lo
>> que decis deberia usar un cursor o algo asi y creo que va a ser medio
>> lento...
>> Igual se me ocurre que podria hacer lo mismo que tengo ahora pero
>> usando un TOP n y corriendolo varias veces (es decir, hacerlo en
>> batches mas pequeños)
>> Creo que de esa forma podria "calibrar" el tiempo que se bloquea, para
>> equilibrar velocidad de import versus tiempo de tabla bloqueada.
>>
>> Gracias!
>> Diego
>>
>> 2008/7/3 Hernán Zaldívar <[EMAIL PROTECTED]>:
>>> Siempre que hagas un bulk va a bloquear todo y es por proteccion... si
le sacas el bloqueo se pueden producir errores no muy buenos...
>>>
>>> Y si actualizas uno a uno en vez de bulk? Uno a uno va bloqueando de a
un registro a la vez y soltandonlo cuando lo termina de usar.. esto es
rapido
>>>
>>> -----Mensaje original-----
>>> De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Leonardo
Micheloni
>>> Enviado el: Jueves, 03 de Julio de 2008 2:13 p.m.
>>> Para: Hernán Zaldívar
>>> Asunto: [dbms] Proceso sin bloqueos
>>>
>>> Hola Diego,
>>>  No entiendo qué querés decir con "bloquear toda la aplicación web"
>>>
>>> On Thu, Jul 3, 2008 at 1:04 PM, Diego Jancic <[EMAIL PROTECTED]> wrote:
>>>> Hola gente!,
>>>> Tengo un problema (posiblemente de diseño), tengo una app web que
>>>> permite importar algunas cosas (usuarios, permisos, etc) desde csv. Ya
>>>> esta funcionando todo en un proceso aparte, lo que se hace es:
>>>> 1 - importar cada linea del csv a una tabla temporal, sin hacer mucho
>>>> procesamiento
>>>> 2 - ejecutar bulk inserts para los nuevos usuarios
>>>> 3 - ejecutar bulk updates para actualizar los usuarios existentes
>>>> 4 - ejecutar bulk inserts para los nuevos permisos
>>>> 5 - ejecutar bulk updates para actualizar los permisos existentes
>>>> 6 - ....
>>>>
>>>> Como puedo hacer para ejecutar los pasos 2, 3, 4, 5, ..., n sin
>>>> bloquear a toda la aplicacion web ?
>>>> Posiblemente tarde poco el import, pero bloquear todo durante algunos
>>>> segundos no es muy bueno que digamos...
>>>>
>>>> Alguna idea?
>>>>
>>>> Gracias,
>>>> Diego
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Leonardo Micheloni.
>>> Ayudando a organizar las primeras jornadas ágiles de Latinoamérica
>>>
>>> http://agiles2008.org/
>>>
>>> Blog Personal
>>>
>>> http://leomicheloni.blogspot.com/
>>>
>>>
>>>
>>
>>
>
>
>
> --
> Leonardo Micheloni.
> Ayudando a organizar las primeras jornadas ágiles de Latinoamérica
>
> http://agiles2008.org/
>
> Blog Personal
>
> http://leomicheloni.blogspot.com/
>
>



Responder a