Update vs cursor
AAAAA
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
Carlos Sacristan
forma masiva. T� mismo podr�as hacer la prueba; para hacerlo con un cursor
puedes basarte en las plantillas de Management Studio (men� View/Template
Explorer y seleccionas en esa ventana el archivo "Earlier versions\Using
Cursors\Declare and Use UPDATE Cursor")
--
-----------------------------
"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
"AAAAA" <ces...@hotmail.com> wrote in message
news:eo7eWOLb...@TK2MSFTNGP02.phx.gbl...
aa
Maxi Accotto
con los cursores.
Ejecutalo y fijate ;)
- CURSORES
USE tempdb
GO
CREATE TABLE T1 (C1 INT PRIMARY KEY, C2 INT, C3 CHAR(8000))
GO
DECLARE @I INT
SELECT @I = 0
WHILE (@I < 1000)
BEGIN
INSERT INTO T1 VALUES (@I,@I + 1000,'HOLA')
SET @I = @I + 1
END
-- UPDATE SIMPLE
BEGIN TRAN
UPDATE T1 SET C2 = 1000 + C2
COMMIT TRAN
-- UPDATE USANDO CURSORES
DECLARE MYCURSOR CURSOR FOR
SELECT C2 FROM T1
OPEN MYCURSOR
GO
BEGIN TRAN
FETCH MYCURSOR
WHILE (@@FETCH_STATUS = 0)
BEGIN
UPDATE T1 SET C2 = 1000 + C2 WHERE CURRENT OF MYCURSOR
FETCH MYCURSOR
END
COMMIT TRAN
-- VEMOS LOS TIEMPOS
SELECT TOP 1000
TOTAL_WORKER_TIME/EXECUTION_COUNT AS AVG_CPU_COST,
EXECUTION_COUNT,
(SELECT SUBSTRING(TEXT,STATEMENT_START_OFFSET/2 + 1,
(CASE WHEN STATEMENT_END_OFFSET = -1 THEN
LEN (CONVERT(NVARCHAR(MAX),TEXT)) * 2
ELSE STATEMENT_END_OFFSET END - statement_start_offset) /2)
FROM sys.dm_exec_sql_text(SQL_HANDLE)) AS QUERY_TEXT
FROM sys.dm_exec_query_stats
ORDER BY [AVG_CPU_COST] DESC
--
------------------------------------------------
Maxi Accotto
MVP en SQL Server
http://blog.maxiaccotto.com
--------------------------------------------------
"AAAAA" <ces...@hotmail.com> wrote in message
news:eo7eWOLb...@TK2MSFTNGP02.phx.gbl...
Aguardientico
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" <ces...@hotmail.com> wrote in message
news:eo7eWOLb...@TK2MSFTNGP02.phx.gbl...
> __________ 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.
aa
y cada sentencia ejecuta solo sobre 250000 registros.
"Aguardientico" <gusgon1 at nospam dot com> wrote in message
news:%23O1MHRY...@TK2MSFTNGP06.phx.gbl...
Aguardientico
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" <a...@aa.com> wrote in message
news:eSqRk2ib...@TK2MSFTNGP04.phx.gbl...
aa
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
Carlos Sacristan
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/library/ms187043.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" <a...@aa.com> wrote in message
news:uSXPXYrb...@TK2MSFTNGP02.phx.gbl...
> 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:upB5WAlb...@TK2MSFTNGP06.phx.gbl...
>> 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" <a...@aa.com> wrote in message
>> news:eSqRk2ib...@TK2MSFTNGP04.phx.gbl...
>>> 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:%23O1MHRY...@TK2MSFTNGP06.phx.gbl...
>>>> 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
aa
pueden hacer cosas con los select para limitar que son mas performantes.
"Carlos Sacristan" <nom...@nomail.com> wrote in message
news:eDSzutrb...@TK2MSFTNGP06.phx.gbl...
> En realidad s� las tiene. Aunque los resultados de TOP(n) y ROWCOUNT son
> apartado "TOP frente a SET ROWCOUNT" del tema "Limitar los conjuntos de
> resultados con TOP y PERCENT"
> http://msdn.microsoft.com/es-es/library/ms187043.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
> Edward V. Berard, ingeniero inform�tico
>
>
> "aa" <a...@aa.com> wrote in message
> news:uSXPXYrb...@TK2MSFTNGP02.phx.gbl...
>> 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:upB5WAlb...@TK2MSFTNGP06.phx.gbl...
>>> Hola aa,
>>>
>>> numero indicado.
>>>
>>> En mi escenario no tenia ningun campo que me permitiera controlar el
>>> unica solucion era a trav�s de cursores.
>>>
>>> A lo que quiero llegar es que para cada escenario pueden haber
>>> determinar cual es la mejor soluci�n.
>>>
>>> Lo que nosostros pensamos que en un caso tiene muy buen performance para
>>>
>>> Atte.
>>>
>>> Gustavo Gonzalez
>>>
>>> "aa" <a...@aa.com> wrote in message
>>> news:eSqRk2ib...@TK2MSFTNGP04.phx.gbl...
>>>> 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:%23O1MHRY...@TK2MSFTNGP06.phx.gbl...
>>>>> Hola Cesar,
>>>>>
>>>>> Te cuento que el hacer un update en base a un select es mucho mejor
>>>>> que usar un cursor pero.....
>>>>>
>>>>>
>>>>> lastimosamente generaba mucho log para poder controlar rollbacks, as�
Carlos Sacristan
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" <a...@aa.com> wrote in message
news:O1V3lHub...@TK2MSFTNGP05.phx.gbl...
> 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" <nom...@nomail.com> wrote in message
> news:eDSzutrb...@TK2MSFTNGP06.phx.gbl...
>> 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/library/ms187043.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" <a...@aa.com> wrote in message
>> news:uSXPXYrb...@TK2MSFTNGP02.phx.gbl...
>>> 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:upB5WAlb...@TK2MSFTNGP06.phx.gbl...
>>>> 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" <a...@aa.com> wrote in message
>>>> news:eSqRk2ib...@TK2MSFTNGP04.phx.gbl...
>>>>> 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:%23O1MHRY...@TK2MSFTNGP06.phx.gbl...
>>>>>> 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
aa
referia.news:OgFodF0b...@TK2MSFTNGP02.phx.gbl...
> 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
>
> --
> -----------------------------
> "Caminar sobre el agua y desarrollar software a partir de unas
> Edward V. Berard, ingeniero inform�tico
>
>
> "aa" <a...@aa.com> wrote in message
> news:O1V3lHub...@TK2MSFTNGP05.phx.gbl...
>> 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" <nom...@nomail.com> wrote in message
>> news:eDSzutrb...@TK2MSFTNGP06.phx.gbl...
>>> el apartado "TOP frente a SET ROWCOUNT" del tema "Limitar los conjuntos
>>> de resultados con TOP y PERCENT"
>>> http://msdn.microsoft.com/es-es/library/ms187043.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
>>> Edward V. Berard, ingeniero inform�tico
>>>
>>>
>>> "aa" <a...@aa.com> wrote in message
>>> news:uSXPXYrb...@TK2MSFTNGP02.phx.gbl...
>>>> 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:upB5WAlb...@TK2MSFTNGP06.phx.gbl...
>>>>> Hola aa,
>>>>>
>>>>> al numero indicado.
>>>>>
>>>>> En mi escenario no tenia ningun campo que me permitiera controlar el
>>>>> unica solucion era a trav�s de cursores.
>>>>>
>>>>> A lo que quiero llegar es que para cada escenario pueden haber
>>>>> determinar cual es la mejor soluci�n.
>>>>>
>>>>> Lo que nosostros pensamos que en un caso tiene muy buen performance
>>>>>
>>>>> Atte.
>>>>>
>>>>> Gustavo Gonzalez
>>>>>
>>>>> "aa" <a...@aa.com> wrote in message
>>>>> news:eSqRk2ib...@TK2MSFTNGP04.phx.gbl...
>>>>>> 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:%23O1MHRY...@TK2MSFTNGP06.phx.gbl...
>>>>>>> Hola Cesar,
>>>>>>>
>>>>>>> Te cuento que el hacer un update en base a un select es mucho mejor
>>>>>>> que usar un cursor pero.....
>>>>>>>
>>>>>>>
Aguardientico
Disculpame por responder despues de tanto tiempo pero adjunto un par de url
para demostrar que no en todos los casos es malo usar un cursor.
http://blogs.techrepublic.com.com/datacenter/?p=1741
http://blogs.techrepublic.com.com/datacenter/?p=412&tag=rbxccnbtr1
Esto no es con el proposito de discutir sino para las personas sin un
conocimiento avanzado puedan tomar mejores decisiones de diseño con respecto
a las aplicaciones con bases de datos.
--
Atte.
Gustavo Gonzalez
"aa" wrote:
> 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:upB5WAlb...@TK2MSFTNGP06.phx.gbl...
> > 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" <a...@aa.com> wrote in message
> > news:eSqRk2ib...@TK2MSFTNGP04.phx.gbl...
> >> 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:%23O1MHRY...@TK2MSFTNGP06.phx.gbl...
> >>> 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
> .
>