Update vs cursor

Hola aa,

Lastimosamente el uso de set rowcount no es recomendado y además yo
necesitaba procesar todos los registros y el rowcount para al llegar al
numero indicado.

En mi escenario no tenia ningun campo que me permitiera controlar el numero
de registro (no existían pk's ni columnas unique) por lo que la unica
solucion era a través de cursores.

A lo que quiero llegar es que para cada escenario pueden haber diferentes
soluciones y solo haciendo un aálisis correcto se puede determinar cual es
la mejor solución.

Lo que nosostros pensamos que en un caso tiene muy buen performance para
otro caso puede llegar a ser pésimo.

Atte.

Gustavo Gonzalez

"aa" wrote in message
news:
Mostrar la cita

En ese caso tenes que tener un set rowcount 250000
y cada sentencia ejecuta solo sobre 250000 registros.
"Aguardientico" <gusgon1 at nospam dot com> wrote in message
news:%
Mostrar la cita

Hola Cesar,

Te cuento que el hacer un update en base a un select es mucho mejor que
usar un cursor pero.

Te comento que una vez tuve que hacer una migración de datos, eran aprox.
10 millones de registros por tabla.

Traté de hacer algunas actualizaciones basadas en select's pero
lastimosamente generaba mucho log para poder controlar rollbacks, así que
la forma más eficiente que encontré para poder hacerlo fue basado en
cursores para poder hacer commit's cada cierta cantidad de registros.

Gustavo Gonzalez

"AAAAA" wrote in message
news:
Mostrar la cita

Hola amigos,
Estoy haciendo un update de una tabla a otra de forma masiva con un
select en el update, me han comentado que mejor use un cursor qu e es
mas rapido, es eso verdad donde puedo encontrar sustento sobre eso?

Saludos

Cesar


__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4631 (20091123) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Set rowcount lo unico que hace es una especie de "top",no tiene
contraindicaciones.
Igualmente siempre hay mejores maneras hasta con while de controlar flujo de
datos sin pasar por cursores.
"Aguardientico" <gusgon1 at nospam dot com> wrote in message
news:
Mostrar la cita

Hola aa,

Lastimosamente el uso de set rowcount no es recomendado y además yo
necesitaba procesar todos los registros y el rowcount para al llegar al
numero indicado.

En mi escenario no tenia ningun campo que me permitiera controlar el
numero de registro (no existían pk's ni columnas unique) por lo que la
unica solucion era a través de cursores.

A lo que quiero llegar es que para cada escenario pueden haber diferentes
soluciones y solo haciendo un aálisis correcto se puede determinar cual es
la mejor solución.

Lo que nosostros pensamos que en un caso tiene muy buen performance para
otro caso puede llegar a ser pésimo.

Atte.

Gustavo Gonzalez

"aa" wrote in message
news:
Mostrar la cita

En ese caso tenes que tener un set rowcount 250000
y cada sentencia ejecuta solo sobre 250000 registros.
"Aguardientico" <gusgon1 at nospam dot com> wrote in message
news:%
Mostrar la cita

Hola Cesar,

Te cuento que el hacer un update en base a un select es mucho mejor que
usar un cursor pero.

Te comento que una vez tuve que hacer una migración de datos, eran
aprox. 10 millones de registros por tabla.

Traté de hacer algunas actualizaciones basadas en select's pero
lastimosamente generaba mucho log para poder controlar rollbacks, así
que la forma más eficiente que encontré para poder hacerlo fue basado en
cursores para poder hacer commit's cada cierta cantidad de registros.

Gustavo Gonzalez

"AAAAA" wrote in message
news:
Mostrar la cita

Hola amigos,
Estoy haciendo un update de una tabla a otra de forma masiva con un
select en el update, me han comentado que mejor use un cursor qu e es
mas rapido, es eso verdad donde puedo encontrar sustento sobre eso?

Saludos

Cesar


__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4631 (20091123) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

En realidad sí las tiene. Aunque los resultados de TOP(n) y ROWCOUNT son
similares, hay ciertas cosas que hay que tener en cuenta en su uso. En el
apartado "TOP frente a SET ROWCOUNT" del tema "Limitar los conjuntos de
resultados con TOP y PERCENT"
http://msdn.microsoft.com/es-es/lib...87043.aspx de los BOL viene bien
explicado.

Tampoco veo muy bien las ventajas de usar WHILE en vez de un cursor... al
final el procesamiento fila a fila es el mismo en un caso que en el otro.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"aa" wrote in message
news:
Mostrar la cita

Set rowcount lo unico que hace es una especie de "top",no tiene
contraindicaciones.
Igualmente siempre hay mejores maneras hasta con while de controlar flujo
de datos sin pasar por cursores.
"Aguardientico" <gusgon1 at nospam dot com> wrote in message
news:
Mostrar la cita

Hola aa,

Lastimosamente el uso de set rowcount no es recomendado y además yo
necesitaba procesar todos los registros y el rowcount para al llegar al
numero indicado.

En mi escenario no tenia ningun campo que me permitiera controlar el
numero de registro (no existían pk's ni columnas unique) por lo que la
unica solucion era a través de cursores.

A lo que quiero llegar es que para cada escenario pueden haber diferentes
soluciones y solo haciendo un aálisis correcto se puede determinar cual
es la mejor solución.

Lo que nosostros pensamos que en un caso tiene muy buen performance para
otro caso puede llegar a ser pésimo.

Atte.

Gustavo Gonzalez

"aa" wrote in message
news:
Mostrar la cita

En ese caso tenes que tener un set rowcount 250000
y cada sentencia ejecuta solo sobre 250000 registros.
"Aguardientico" <gusgon1 at nospam dot com> wrote in message
news:%
Mostrar la cita

Hola Cesar,

Te cuento que el hacer un update en base a un select es mucho mejor que
usar un cursor pero.

Te comento que una vez tuve que hacer una migración de datos, eran
aprox. 10 millones de registros por tabla.

Traté de hacer algunas actualizaciones basadas en select's pero
lastimosamente generaba mucho log para poder controlar rollbacks, así
que la forma más eficiente que encontré para poder hacerlo fue basado
en cursores para poder hacer commit's cada cierta cantidad de
registros.

Gustavo Gonzalez

"AAAAA" wrote in message
news:
Mostrar la cita

Hola amigos,
Estoy haciendo un update de una tabla a otra de forma masiva con un
select en el update, me han comentado que mejor use un cursor qu e es
mas rapido, es eso verdad donde puedo encontrar sustento sobre eso?

Saludos

Cesar


__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4631 (20091123) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

El cursor trabaja sobre temporales y consume mas recursos,con while se
pueden hacer cosas con los select para limitar que son mas performantes.
"Carlos Sacristan" wrote in message
news:
Mostrar la cita

En realidad sí las tiene. Aunque los resultados de TOP(n) y ROWCOUNT son
similares, hay ciertas cosas que hay que tener en cuenta en su uso. En el
apartado "TOP frente a SET ROWCOUNT" del tema "Limitar los conjuntos de
resultados con TOP y PERCENT"
http://msdn.microsoft.com/es-es/lib...87043.aspx de los BOL viene
bien explicado.

Tampoco veo muy bien las ventajas de usar WHILE en vez de un cursor... al
final el procesamiento fila a fila es el mismo en un caso que en el otro.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"aa" wrote in message
news:
Mostrar la cita

Set rowcount lo unico que hace es una especie de "top",no tiene
contraindicaciones.
Igualmente siempre hay mejores maneras hasta con while de controlar flujo
de datos sin pasar por cursores.
"Aguardientico" <gusgon1 at nospam dot com> wrote in message
news:
Mostrar la cita

Hola aa,

Lastimosamente el uso de set rowcount no es recomendado y además yo
necesitaba procesar todos los registros y el rowcount para al llegar al
numero indicado.

En mi escenario no tenia ningun campo que me permitiera controlar el
numero de registro (no existían pk's ni columnas unique) por lo que la
unica solucion era a través de cursores.

A lo que quiero llegar es que para cada escenario pueden haber
diferentes soluciones y solo haciendo un aálisis correcto se puede
determinar cual es la mejor solución.

Lo que nosostros pensamos que en un caso tiene muy buen performance para
otro caso puede llegar a ser pésimo.

Atte.

Gustavo Gonzalez

"aa" wrote in message
news:
Mostrar la cita

En ese caso tenes que tener un set rowcount 250000
y cada sentencia ejecuta solo sobre 250000 registros.
"Aguardientico" <gusgon1 at nospam dot com> wrote in message
news:%
Mostrar la cita

Hola Cesar,

Te cuento que el hacer un update en base a un select es mucho mejor
que usar un cursor pero.

Te comento que una vez tuve que hacer una migración de datos, eran
aprox. 10 millones de registros por tabla.

Traté de hacer algunas actualizaciones basadas en select's pero
lastimosamente generaba mucho log para poder controlar rollbacks, así
que la forma más eficiente que encontré para poder hacerlo fue basado
en cursores para poder hacer commit's cada cierta cantidad de
registros.

Gustavo Gonzalez

"AAAAA" wrote in message
news:
Mostrar la cita

Hola amigos,
Estoy haciendo un update de una tabla a otra de forma masiva con un
select en el update, me han comentado que mejor use un cursor qu e
es mas rapido, es eso verdad donde puedo encontrar sustento sobre
eso?

Saludos

Cesar


__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4631 (20091123) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Depende del cursor y de cómo esté implementado el bucle WHILE.

De todos modos, a lo que me refería es que ambas soluciones (WHILE o CURSOR)
hacen procesamiento fila a fila, algo que normalmente perjudica el
rendimiento respecto de una solución orientada a conjuntos.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"aa" wrote in message
news:
Mostrar la cita

El cursor trabaja sobre temporales y consume mas recursos,con while se
pueden hacer cosas con los select para limitar que son mas performantes.
"Carlos Sacristan" wrote in message
news:
Mostrar la cita

En realidad sí las tiene. Aunque los resultados de TOP(n) y ROWCOUNT son
similares, hay ciertas cosas que hay que tener en cuenta en su uso. En el
apartado "TOP frente a SET ROWCOUNT" del tema "Limitar los conjuntos de
resultados con TOP y PERCENT"
http://msdn.microsoft.com/es-es/lib...87043.aspx de los BOL viene
bien explicado.

Tampoco veo muy bien las ventajas de usar WHILE en vez de un cursor... al
final el procesamiento fila a fila es el mismo en un caso que en el otro.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"aa" wrote in message
news:
Mostrar la cita

Set rowcount lo unico que hace es una especie de "top",no tiene
contraindicaciones.
Igualmente siempre hay mejores maneras hasta con while de controlar
flujo de datos sin pasar por cursores.
"Aguardientico" <gusgon1 at nospam dot com> wrote in message
news:
Mostrar la cita

Hola aa,

Lastimosamente el uso de set rowcount no es recomendado y además yo
necesitaba procesar todos los registros y el rowcount para al llegar al
numero indicado.

En mi escenario no tenia ningun campo que me permitiera controlar el
numero de registro (no existían pk's ni columnas unique) por lo que la
unica solucion era a través de cursores.

A lo que quiero llegar es que para cada escenario pueden haber
diferentes soluciones y solo haciendo un aálisis correcto se puede
determinar cual es la mejor solución.

Lo que nosostros pensamos que en un caso tiene muy buen performance
para otro caso puede llegar a ser pésimo.

Atte.

Gustavo Gonzalez

"aa" wrote in message
news:
Mostrar la cita

En ese caso tenes que tener un set rowcount 250000
y cada sentencia ejecuta solo sobre 250000 registros.
"Aguardientico" <gusgon1 at nospam dot com> wrote in message
news:%
Mostrar la cita

Hola Cesar,

Te cuento que el hacer un update en base a un select es mucho mejor
que usar un cursor pero.

Te comento que una vez tuve que hacer una migración de datos, eran
aprox. 10 millones de registros por tabla.

Traté de hacer algunas actualizaciones basadas en select's pero
lastimosamente generaba mucho log para poder controlar rollbacks, así
que la forma más eficiente que encontré para poder hacerlo fue basado
en cursores para poder hacer commit's cada cierta cantidad de
registros.

Gustavo Gonzalez

"AAAAA" wrote in message
news:
Mostrar la cita

Hola amigos,
Estoy haciendo un update de una tabla a otra de forma masiva con un
select en el update, me han comentado que mejor use un cursor qu e
es mas rapido, es eso verdad donde puedo encontrar sustento sobre
eso?

Saludos

Cesar


__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4631 (20091123) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4634 (20091124) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com