Tamaño de tabla

Es que depende de más cosas, decir el número de registros de una tabla es un
dato más a tener en cuenta, pero no es el único ni el más importante.

Habría que saber la configuración del servidor, la concurrencia existente
(puede que existan otras operaciones en ese momento que impidan realizar el
delete), el diseño de la tabla (incluyendo índices, triggers, restricciones,
etc), etc.

También sería interesante saber cuánto de selectivo es ese filtro de
"id=xxx". Echa un vistazo al plan de ejecución y las estadísticas de IO para
saber cómo se ejecuta esa instrucción.

"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


"Ivan" wrote in message
news:

Hola, es normal que trabajar con una tabla de 3 millones de registros sea
lento, incluso haciendo consultas con SLQ Server Management?

Si intento hacer una select: select * from tabla where id=xxx, la consulta
fácilmente tarda 40 segundos. Y si hago un delete from tabla, me salta una
excepción de Valor de tiempo de espera caducado y no borra nada.

Tengo una clave formada por un id (int) y un cod (nvarchar), no sé si esto
último puede influir negativamente en el rendimiento.

gracias
Ivan

Gracias por la respuesta.

La concurrencia en la tabla es máxima. Hay unos 1000 potenciales usuarios
haciendo inserciones, selecciones y updates sobre dicha tabla, a veces más o
menos a la vez, en la tabla sólo hay una clave (conformada por dos campos
-int y varchar-).

Lo que me extraña es que leí que microsoft aseguraba que una consulta sobre
una tabla de hasta 2-3 millones de registros era prácticamente instantánea, y
a mí me dista mucho de serlo
Ivan


"Carlos Sacristan" wrote:

Es que depende de más cosas, decir el número de registros de una tabla es un
dato más a tener en cuenta, pero no es el único ni el más importante.

Habría que saber la configuración del servidor, la concurrencia existente
(puede que existan otras operaciones en ese momento que impidan realizar el
delete), el diseño de la tabla (incluyendo índices, triggers, restricciones,
etc), etc.

También sería interesante saber cuánto de selectivo es ese filtro de
"id=xxx". Echa un vistazo al plan de ejecución y las estadísticas de IO para
saber cómo se ejecuta esa instrucción.

"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


"Ivan" wrote in message
news:
> Hola, es normal que trabajar con una tabla de 3 millones de registros sea
> lento, incluso haciendo consultas con SLQ Server Management?
>
> Si intento hacer una select: select * from tabla where id=xxx, la consulta
> fácilmente tarda 40 segundos. Y si hago un delete from tabla, me salta una
> excepción de Valor de tiempo de espera caducado y no borra nada.
>
> Tengo una clave formada por un id (int) y un cod (nvarchar), no sé si esto
> último puede influir negativamente en el rendimiento.
>
> gracias
> Ivan

El DELETE puede demorar debido a bloqueos si hay mucha concurrencia en la
tabla/indices.

La SELECT debería ser rápida si los indices son los adecuados y tienen sus
estadisticas actualizadas.

Para hacer un análisis apropiado, lo mejor es que usted proporcione:
- CREATE TABLE de la tabla.
- CREATE INDEX de todos los indices de la tabla.
- Plan de ejecución de la consulta lenta.

Para mostrar el plan de ejección ejecute SET SHOWPLAN_TEXT ON, por ejemplo:

USE MiBase
GO
SET SHOWPLAN_TEXT ON;
GO
SELECT *
FROM MiTabla
WHERE . . .
GO
SET SHOWPLAN_TEXT OFF;
GO

Gustavo Larriera Sosa
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"Ivan" wrote:

Hola, es normal que trabajar con una tabla de 3 millones de registros sea
lento, incluso haciendo consultas con SLQ Server Management?

Si intento hacer una select: select * from tabla where id=xxx, la consulta
fácilmente tarda 40 segundos. Y si hago un delete from tabla, me salta una
excepción de Valor de tiempo de espera caducado y no borra nada.

Tengo una clave formada por un id (int) y un cod (nvarchar), no sé si esto
último puede influir negativamente en el rendimiento.

gracias
Ivan

Bueno, lo de "concurrencia máxima" es relativo, además de que no es
cuantificable... Lo que para tí es "máxima" para otro sistema puede ser
"mínima". En fin, a lo que voy es que lo suyo es que habría que ver las
operaciones concurrentes que se hacen sobre esa tabla.

Por otro lado, el hecho de que existan 1000 usuarios haciendo operaciones
sobre la tabla no debería afectar si no son concurrentes. E incluso siendo
concurrentes, dependiendo del tipo de operación puede que tampoco afectaran
al rendimiento.

¿Podrías poner el enlace al documento de Microsoft donde dice eso? Me
extraña que realmente haya un sitio oficial que comente algo así, ya que un
SQL Server no es sólo el motor, depende de cómo esté configurado, del
hardware del sistema, de la concurrencia del mismo, del diseño de la base de
datos, de... son muchas cosas como para asegurar algo así. Vamos a ver, en
un sistema normal, esa cantidad de registros no es mucho, pero no es el
valor a cuantificar para decidir si el sistema es lento o rápido. No el
único, al menos.

Como te decía en la respuesta anterior, necesitamos conocer el diseño de la
tabla, los índices, restricciones, triggers que pueda tener, así como la
configuración del sistema (ram, subsistema de disco), si el servidor se
dedica a otras tareas (tiene otros servicios instalados), si esa latencia te
ocurre con otras peticiones, etc

Y, también, el plan de ejecución y las estadísticas IO sería interesante
conocerlas.

"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


"Ivan" wrote in message
news:

Gracias por la respuesta.

La concurrencia en la tabla es máxima. Hay unos 1000 potenciales usuarios
haciendo inserciones, selecciones y updates sobre dicha tabla, a veces más
o
menos a la vez, en la tabla sólo hay una clave (conformada por dos campos
-int y varchar-).

Lo que me extraña es que leí que microsoft aseguraba que una consulta
sobre
una tabla de hasta 2-3 millones de registros era prácticamente
instantánea, y
a mí me dista mucho de serlo
Ivan


"Carlos Sacristan" wrote:

Es que depende de más cosas, decir el número de registros de una tabla es
un
dato más a tener en cuenta, pero no es el único ni el más importante.

Habría que saber la configuración del servidor, la concurrencia existente
(puede que existan otras operaciones en ese momento que impidan realizar
el
delete), el diseño de la tabla (incluyendo índices, triggers,
restricciones,
etc), etc.

También sería interesante saber cuánto de selectivo es ese filtro de
"id=xxx". Echa un vistazo al plan de ejecución y las estadísticas de IO
para
saber cómo se ejecuta esa instrucción.

"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


"Ivan" wrote in message
news:
> Hola, es normal que trabajar con una tabla de 3 millones de registros
> sea
> lento, incluso haciendo consultas con SLQ Server Management?
>
> Si intento hacer una select: select * from tabla where id=xxx, la
> consulta
> fácilmente tarda 40 segundos. Y si hago un delete from tabla, me salta
> una
> excepción de Valor de tiempo de espera caducado y no borra nada.
>
> Tengo una clave formada por un id (int) y un cod (nvarchar), no sé si
> esto
> último puede influir negativamente en el rendimiento.
>
> gracias
> Ivan

Hola, yo tengo un problema similar al de ivan cuando hago un update
masivo en una tabla grande que tiene un trigger asociado, el cual
modifica los datos de otra tabla en otra bbdd en el mismo servidor, el
plan de ejecucion es el siguiente:

|--Clustered Index Update(OBJECT:([skidreams_desarrollo].[dbo].
[xxxGesClientes].[PK__xxxGesClientes__319832C2]), SET:
([xxxGesClientes].[pais]=Convert([@1])), DEFINE:([ConstExpr1006]
=Convert([@1])), WHERE:([xxxGesClientes].[CodCliente] < Convert
([@2])))

y caduca e tiempo... si me pueden decir algo estaria eternamente
agradecido ;)