Query de 40 horas?

14/10/2005 - 17:32 por rigoberto | Informe spam
buenos dias:

Mi problema es el siguiente: Tengo una tabla TABLA_BASE de
aproximadamente 42 millones de registros con una clave unica y otra
tabla TABLAAUX con aproximadamente 21 millones de registros con datos
que tengo que actualizar en la primera tabla.

En la primera tabla utilizo el siguiente query para crear los campos.

BEGIN TRAN
ALTER TABLE [TABLA_BASE] ADD [CAMPO_FLAG] [smallint] DEFAULT (0) NOT
NULL
ALTER TABLE [TABLA_BASE] ADD [RGS_FLAG] [smallint] DEFAULT (0) NOT
NULL
ALTER TABLE [TABLA_BASE] ADD [OTRO_FLAG] [smallint] DEFAULT (0) NOT
NULL
ALTER TABLE [TABLA_BASE] ADD [ESTADO] [smallint] DEFAULT (0) NOT NULL

ALTER TABLE [TABLA_BASE] ADD [FECHA] [datetime] DEFAULT ('2002-01-12
00:00:00.000') NOT NULL
ALTER TABLE [TABLA_BASE] ADD [CONTADOR] [smallint] DEFAULT (0) NOT
NULL
COMMIT
GO
Cuando ejecuto el query en pruebas, se demora aproximadamente 40 Horas.
como este procedimiento se ejecutara solo UNA VEZ en produccion, se
puede manejar. pero el inconveniente es en los procesos mensuales en
los cuales actualizo estos campos. El query a utilizar sera este:

BEGIN TRAN
UPDATE TABLA_BASE
SET FECHA = '2005-02-01 00:00:00.000',
CONTADOR = CONTADOR + 1,
CAMPO_FLAG = CASE WHEN P.CAMPO_FLAG < C.VALOR THEN C.VALOR ELSE
P.CAMPO_FLAG END
FROM TABLA_BASE P INNER JOIN TABLAAUX C ON (C.CLAVE = P.CLAVE)
COMMIT
GO

El query anterior en pruebas lleva 60 horas y no ha terminado. Ekl
tiempo maximo permitido en produccion para este procedimiento seria de
20 horas. ya he probado enviandolo desde un procedimiento almacenado
pero el tiempo se reduce muy poco.

Pregunta: esto es normal por la cantidad de registros ha actualizar (21
millones) ó es un problemas al crear los campos con valores por
defecto?.

El problema es que con estos tiempos cada prueba completa se me demora
casi una semana

gracias por cualquier ayuda a disminuir estos tiempos.

Preguntas similare

Leer las respuestas

#1 Franklin Marcano
14/10/2005 - 17:47 | Informe spam
humm, se me ocurre como prueba que realizes una funcion, para que te
devuelva el valor a actualizar, de esa forma solo en ciertos casos hara la
funcion, y no tendrias que armar la consulta, en memoria.

la funcion recibiria como parametro p.clave, y harias un select clave from
tablaaux where clave=p.clave
y devolverias el valor actualizar

la consulta quedaria de la siguiente forma:
UPDATE TABLA_BASE
SET FECHA = '2005-02-01 00:00:00.000',
CONTADOR = CONTADOR + 1,
CAMPO_FLAG = CASE WHEN P.CAMPO_FLAG < C.VALOR THEN funcion(p.clave)
ELSE
P.CAMPO_FLAG END
FROM TABLA_BASE P


"rigoberto" escribió en el mensaje
news:
buenos dias:

Mi problema es el siguiente: Tengo una tabla TABLA_BASE de
aproximadamente 42 millones de registros con una clave unica y otra
tabla TABLAAUX con aproximadamente 21 millones de registros con datos
que tengo que actualizar en la primera tabla.

En la primera tabla utilizo el siguiente query para crear los campos.

BEGIN TRAN
ALTER TABLE [TABLA_BASE] ADD [CAMPO_FLAG] [smallint] DEFAULT (0) NOT
NULL
ALTER TABLE [TABLA_BASE] ADD [RGS_FLAG] [smallint] DEFAULT (0) NOT
NULL
ALTER TABLE [TABLA_BASE] ADD [OTRO_FLAG] [smallint] DEFAULT (0) NOT
NULL
ALTER TABLE [TABLA_BASE] ADD [ESTADO] [smallint] DEFAULT (0) NOT NULL

ALTER TABLE [TABLA_BASE] ADD [FECHA] [datetime] DEFAULT ('2002-01-12
00:00:00.000') NOT NULL
ALTER TABLE [TABLA_BASE] ADD [CONTADOR] [smallint] DEFAULT (0) NOT
NULL
COMMIT
GO
Cuando ejecuto el query en pruebas, se demora aproximadamente 40 Horas.
como este procedimiento se ejecutara solo UNA VEZ en produccion, se
puede manejar. pero el inconveniente es en los procesos mensuales en
los cuales actualizo estos campos. El query a utilizar sera este:

BEGIN TRAN
UPDATE TABLA_BASE
SET FECHA = '2005-02-01 00:00:00.000',
CONTADOR = CONTADOR + 1,
CAMPO_FLAG = CASE WHEN P.CAMPO_FLAG < C.VALOR THEN C.VALOR ELSE
P.CAMPO_FLAG END
FROM TABLA_BASE P INNER JOIN TABLAAUX C ON (C.CLAVE = P.CLAVE)
COMMIT
GO

El query anterior en pruebas lleva 60 horas y no ha terminado. Ekl
tiempo maximo permitido en produccion para este procedimiento seria de
20 horas. ya he probado enviandolo desde un procedimiento almacenado
pero el tiempo se reduce muy poco.

Pregunta: esto es normal por la cantidad de registros ha actualizar (21
millones) ó es un problemas al crear los campos con valores por
defecto?.

El problema es que con estos tiempos cada prueba completa se me demora
casi una semana

gracias por cualquier ayuda a disminuir estos tiempos.
Respuesta Responder a este mensaje
#2 rigoberto
14/10/2005 - 17:55 | Informe spam
Gracias... Voy a probarlo con cierto numero limitado de registro, y le
cuento.
Respuesta Responder a este mensaje
#3 Gustavo Larriera [MVP]
14/10/2005 - 18:10 | Informe spam
Qué indices tienes en las tablas TABLA_BASE y TABLAAUX ?

Gustavo Larriera
Uruguay LatAm
Blog: http://sqljunkies.com/weblog/gux/
MVP profile: http://aspnet2.com/mvp.ashx?GustavoLarriera
Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga ningun
derecho / This posting is provided "AS IS" with no warranties, and confers
no rights.
"rigoberto" wrote in message
news:
buenos dias:

Mi problema es el siguiente: Tengo una tabla TABLA_BASE de
aproximadamente 42 millones de registros con una clave unica y otra
tabla TABLAAUX con aproximadamente 21 millones de registros con datos
que tengo que actualizar en la primera tabla.

En la primera tabla utilizo el siguiente query para crear los campos.

BEGIN TRAN
ALTER TABLE [TABLA_BASE] ADD [CAMPO_FLAG] [smallint] DEFAULT (0) NOT
NULL
ALTER TABLE [TABLA_BASE] ADD [RGS_FLAG] [smallint] DEFAULT (0) NOT
NULL
ALTER TABLE [TABLA_BASE] ADD [OTRO_FLAG] [smallint] DEFAULT (0) NOT
NULL
ALTER TABLE [TABLA_BASE] ADD [ESTADO] [smallint] DEFAULT (0) NOT NULL

ALTER TABLE [TABLA_BASE] ADD [FECHA] [datetime] DEFAULT ('2002-01-12
00:00:00.000') NOT NULL
ALTER TABLE [TABLA_BASE] ADD [CONTADOR] [smallint] DEFAULT (0) NOT
NULL
COMMIT
GO
Cuando ejecuto el query en pruebas, se demora aproximadamente 40 Horas.
como este procedimiento se ejecutara solo UNA VEZ en produccion, se
puede manejar. pero el inconveniente es en los procesos mensuales en
los cuales actualizo estos campos. El query a utilizar sera este:

BEGIN TRAN
UPDATE TABLA_BASE
SET FECHA = '2005-02-01 00:00:00.000',
CONTADOR = CONTADOR + 1,
CAMPO_FLAG = CASE WHEN P.CAMPO_FLAG < C.VALOR THEN C.VALOR ELSE
P.CAMPO_FLAG END
FROM TABLA_BASE P INNER JOIN TABLAAUX C ON (C.CLAVE = P.CLAVE)
COMMIT
GO

El query anterior en pruebas lleva 60 horas y no ha terminado. Ekl
tiempo maximo permitido en produccion para este procedimiento seria de
20 horas. ya he probado enviandolo desde un procedimiento almacenado
pero el tiempo se reduce muy poco.

Pregunta: esto es normal por la cantidad de registros ha actualizar (21
millones) ó es un problemas al crear los campos con valores por
defecto?.

El problema es que con estos tiempos cada prueba completa se me demora
casi una semana

gracias por cualquier ayuda a disminuir estos tiempos.
Respuesta Responder a este mensaje
#4 Alejandro Mesa
14/10/2005 - 18:33 | Informe spam
Rigoberto,

La funcion hara que el query tome mas tiempo, pues ahora tendria que
ejecutar la funcion por cada registro que se actualiza.

- Asegurate tener un indice en [TABLAAUX] por [CLAVE], lo mismo en
[TABLA_BASE], y de ser posible, que el de [tabla_base] sea clustered
- si tienes indices nonclustered por alguna de las columnas que seran
actualizadas, elimina los indices y vuelvelos a recrear despues de la
actualizacion
- 21 mllones de registros se considera una transaccion grande y sql server
va ha necesitar mucho espacio en el log de transacciones, por lo que te
recomiendo lo hagas en batches.

Ejemplo:

declare @clave int

set @clave = (select min(clave) from TABLA_BASE)

while @clave is not null
begin

update
p
SET
FECHA = '20050201',
CONTADOR = CONTADOR + 1,
CAMPO_FLAG = CASE WHEN P.CAMPO_FLAG < C.VALOR THEN C.VALOR
ELSE P.CAMPO_FLAG END
from
TABLA_BASE as p inner join TABLAAUX as c
on c.clave = p.clave
where
clave between @clave and @clave + 100000

set @clave = (select min(clave) from TABLA_BASE where clave > @clave)
end


AMB

"rigoberto" wrote:

Gracias... Voy a probarlo con cierto numero limitado de registro, y le
cuento.


Respuesta Responder a este mensaje
#5 Saul Batista
14/10/2005 - 18:38 | Informe spam
como tienes las opciones de la base de datos (autogrowth, update-statistics,
etc )?



"rigoberto" wrote in message
news:
buenos dias:

Mi problema es el siguiente: Tengo una tabla TABLA_BASE de
aproximadamente 42 millones de registros con una clave unica y otra
tabla TABLAAUX con aproximadamente 21 millones de registros con datos
que tengo que actualizar en la primera tabla.

En la primera tabla utilizo el siguiente query para crear los campos.

BEGIN TRAN
ALTER TABLE [TABLA_BASE] ADD [CAMPO_FLAG] [smallint] DEFAULT (0) NOT
NULL
ALTER TABLE [TABLA_BASE] ADD [RGS_FLAG] [smallint] DEFAULT (0) NOT
NULL
ALTER TABLE [TABLA_BASE] ADD [OTRO_FLAG] [smallint] DEFAULT (0) NOT
NULL
ALTER TABLE [TABLA_BASE] ADD [ESTADO] [smallint] DEFAULT (0) NOT NULL

ALTER TABLE [TABLA_BASE] ADD [FECHA] [datetime] DEFAULT ('2002-01-12
00:00:00.000') NOT NULL
ALTER TABLE [TABLA_BASE] ADD [CONTADOR] [smallint] DEFAULT (0) NOT
NULL
COMMIT
GO
Cuando ejecuto el query en pruebas, se demora aproximadamente 40 Horas.
como este procedimiento se ejecutara solo UNA VEZ en produccion, se
puede manejar. pero el inconveniente es en los procesos mensuales en
los cuales actualizo estos campos. El query a utilizar sera este:

BEGIN TRAN
UPDATE TABLA_BASE
SET FECHA = '2005-02-01 00:00:00.000',
CONTADOR = CONTADOR + 1,
CAMPO_FLAG = CASE WHEN P.CAMPO_FLAG < C.VALOR THEN C.VALOR ELSE
P.CAMPO_FLAG END
FROM TABLA_BASE P INNER JOIN TABLAAUX C ON (C.CLAVE = P.CLAVE)
COMMIT
GO

El query anterior en pruebas lleva 60 horas y no ha terminado. Ekl
tiempo maximo permitido en produccion para este procedimiento seria de
20 horas. ya he probado enviandolo desde un procedimiento almacenado
pero el tiempo se reduce muy poco.

Pregunta: esto es normal por la cantidad de registros ha actualizar (21
millones) ó es un problemas al crear los campos con valores por
defecto?.

El problema es que con estos tiempos cada prueba completa se me demora
casi una semana

gracias por cualquier ayuda a disminuir estos tiempos.
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente Respuesta Tengo una respuesta
Search Busqueda sugerida