Lentitud al ejecutar una subconsulta

Hola, ´sin ver los planes de ejecucion es imposible saber la causa. Revfisa
que tengas buenos indices y revisa el plan de ejecucion


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Manuel Candal" <[ mcandal ] @ [ hotmail ] . [ com ]> escribió en el mensaje
news:%236zW%

Tengo un server con sql server 2000 sp4 con dos bases de datos db1, db2.
El equipo es un w2000 con 2gb de ram

En el analizador de consultas observo lo siguiente:

Tarda 12 segundos:
select campo from db2.tablaB where codigo in (select distinct codigo from
db1.tablaA)

Instantáneo:
select distinct codigo from db1.tablaA -> devuelve 12 registros
select campo from db2.tablaB in (12 registros devueltos)


¿Porqué tarda tanto utilizando la subconsulta?

Un saludo

Manuel,

Preferible que uses este patron para ese tipo de consulta.

select
campo
from
db2.tablaB as b
where
exists (
select
*
from
db1.tablaA as a
where
a.codigo = b.codigo
)
go


AMB

"Manuel Candal" wrote:

Tengo un server con sql server 2000 sp4 con dos bases de datos db1, db2.
El equipo es un w2000 con 2gb de ram

En el analizador de consultas observo lo siguiente:

Tarda 12 segundos:
select campo from db2.tablaB where codigo in (select distinct codigo from
db1.tablaA)

Instantáneo:
select distinct codigo from db1.tablaA -> devuelve 12 registros
select campo from db2.tablaB in (12 registros devueltos)


¿Porqué tarda tanto utilizando la subconsulta?

Un saludo

Buenos días, Manuel

Lo primero darte las gracias por exponer aquí tu pregunta: es una pregunta
muy buena.

Por otro lado, no sé si te ayudaré, pero seguro que entre todos los del
grupo lo conseguimos.

En principio, sin conocer el diseño de tus tablas, ni número de registros,
ni planes de ejecución, etc. resulta complicado, en muchos casos, conocer la
situación concreta.

Para intentar reproducir tu escenario, he realizado lo siguiente, partiendo
de la base de datos de Northwind, para que el resto de compañeros puedan
reproducirlo, si les resultara de interés:


USE Northwind
GO

no se nota la diferencia en el rendimiento...
SELECT TOP 500000 A.*
INTO TMP_ORDERS
FROM [ORDER DETAILS] A CROSS JOIN [ORDER DETAILS] B
GO

TMP_ORDERS, con el administrador corporativo (yo soy de esos que no disfrutan
con los comandos...)

set statistics io on
select *
from [ORDER DETAILS]
where orderid in (select distinct orderid from TMP_ORDERS)
set statistics io off


set statistics io on
select distinct orderid from TMP_ORDERS

select *
from [ORDER DETAILS]
where orderid in
(10248,10249,10250,10251,10252,10253,10254,10255,10256,10257,10258,10259,10260,10261,10262,10263,10264,10265,10266,10267,10268,10269,10270,10271,10272,10273,10274,10275,10276,10277,10278,10279,10280,10281,10282,10283,10284,10285,10286,10287,10288,10289,10290,10291,10292,10293,10294,10295,10296,10297,10298,10299,10300,10301,10302,10303,10304,10305,10306,10307,10308,10309,10310,10311,10312,10313,10314,10315,10316,10317,10318,10319,10320,10321,10322,10323,10324,10325,10326,10327,10328,10329,10330,10331,10332,10333,10334,10335)
set statistics io off


set statistics io on
select distinct orderid
into #tmp_prueba
from TMP_ORDERS

select *
from [ORDER DETAILS]
where orderid in (select distinct orderid from #tmp_prueba)
set statistics io off

Pruébalo y nos comentas... y si además nos pudieras dar más información de
tu diseño... pues genial...

Tengo que salir de la oficina...

Saludos,
Guillermo Roldán

"Manuel Candal" wrote:

Tengo un server con sql server 2000 sp4 con dos bases de datos db1, db2.
El equipo es un w2000 con 2gb de ram

En el analizador de consultas observo lo siguiente:

Tarda 12 segundos:
select campo from db2.tablaB where codigo in (select distinct codigo from
db1.tablaA)

Instantáneo:
select distinct codigo from db1.tablaA -> devuelve 12 registros
select campo from db2.tablaB in (12 registros devueltos)


¿Porqué tarda tanto utilizando la subconsulta?

Un saludo

Antes de nada precisar que no llevo la gestión de la base de datos y por lo
tanto tengo
conocimientos muy limitados al respecto.

Una de las bases de datos es un sistema de gestión documental, donde los
documentos se
guardan en un campo binario.

la base de datos db1 guarda un sistema de gestión documental con los
documentos guardados
en la propia base de datos.
Esta base de datos ocupa por si sólo 30 Gb de disco y el número de
documentos guardados
ronda los 300.000. Estos documentos están referenciados en la tablaA.
En db1.tablaA, codigo es un campo con un índice agrupado, no único, con
factor de relleno
de 90.

La base de datos db2 es más pequeña y es la que lleva ciertas gestiones de
la empresa.
Con 500 Mb de máximo de disco. En db2.tablaB, codigo es un campo con un
índice
agrupado, no único, con factor de relleno de 90.

Ya había pensado hacer un procedimiento como indica Guillermo con tablas
temporales,
pero al final opté por llevarlo a nivel de código.

No se gestionaban las estadísticas y por lo que he visto esto puede afectar
a la tabla grande.
Acabo de repasar los índices y las estadísticas y he reducido el tiempo de
12 a 2-4 segundos.

Por lo que leo en http://www.sql-server-performance.com lo recomendable es
crear
varias tareas de mantenimiento para reorganizar índices y actualizar
estadísticas en las tablas que
tienen mucho movimiento y que son grandes. (Me falta el tiempo :) )

Muchas gracias a todos por la información.



"Guillermo Roldan" escribió en
el mensaje news:

Buenos días, Manuel

Lo primero darte las gracias por exponer aquí tu pregunta: es una pregunta
muy buena.

Por otro lado, no sé si te ayudaré, pero seguro que entre todos los del
grupo lo conseguimos.

En principio, sin conocer el diseño de tus tablas, ni número de registros,
ni planes de ejecución, etc. resulta complicado, en muchos casos, conocer
la
situación concreta.

Para intentar reproducir tu escenario, he realizado lo siguiente,
partiendo
de la base de datos de Northwind, para que el resto de compañeros puedan
reproducirlo, si les resultara de interés:


USE Northwind
GO

sino,
no se nota la diferencia en el rendimiento...
SELECT TOP 500000 A.*
INTO TMP_ORDERS
FROM [ORDER DETAILS] A CROSS JOIN [ORDER DETAILS] B
GO

TMP_ORDERS, con el administrador corporativo (yo soy de esos que no
disfrutan
con los comandos...)

set statistics io on
select *
from [ORDER DETAILS]
where orderid in (select distinct orderid from TMP_ORDERS)
set statistics io off


set statistics io on
select distinct orderid from TMP_ORDERS

select *
from [ORDER DETAILS]
where orderid in
(10248,10249,10250,10251,10252,10253,10254,10255,10256,10257,10258,10259,10260,10261,10262,10263,10264,10265,10266,10267,10268,10269,10270,10271,10272,10273,10274,10275,10276,10277,10278,10279,10280,10281,10282,10283,10284,10285,10286,10287,10288,10289,10290,10291,10292,10293,10294,10295,10296,10297,10298,10299,10300,10301,10302,10303,10304,10305,10306,10307,10308,10309,10310,10311,10312,10313,10314,10315,10316,10317,10318,10319,10320,10321,10322,10323,10324,10325,10326,10327,10328,10329,10330,10331,10332,10333,10334,10335)
set statistics io off


claro.
set statistics io on
select distinct orderid
into #tmp_prueba
from TMP_ORDERS

select *
from [ORDER DETAILS]
where orderid in (select distinct orderid from #tmp_prueba)
set statistics io off

Pruébalo y nos comentas... y si además nos pudieras dar más información de
tu diseño... pues genial...

Tengo que salir de la oficina...

Saludos,
Guillermo Roldán

"Manuel Candal" wrote:

Tengo un server con sql server 2000 sp4 con dos bases de datos db1, db2.
El equipo es un w2000 con 2gb de ram

En el analizador de consultas observo lo siguiente:

Tarda 12 segundos:
select campo from db2.tablaB where codigo in (select distinct codigo from
db1.tablaA)

Instantáneo:
select distinct codigo from db1.tablaA -> devuelve 12 registros
select campo from db2.tablaB in (12 registros devueltos)


¿Porqué tarda tanto utilizando la subconsulta?

Un saludo