Problema con update en linked servers...

Resuelto:


Problemas de tipos de datos. Usando nvarchar en lugar de nchar, se arregló
la lentitud.

El update en cuestion actualizada un campo nchar [5].

Le cambie el tipo de datos a nvarchar[5] y ya actualiza correctamente.


Muchas gracias de todas las maneras...

Daniel,

No creo poderte dar una opinion sin antes ver los planes de ejecucion de la
sentencia desde QA y el del procedimineto almacenado. Tambien seria bueno que
postearas la estructura de la tabla, incluyendo restricciones e indices.

Cuando un procedimiento almacenado se ejecuta por primera vez y su plan de
ejecucion no esta en el cache, este se compila y su plan es puesto en el
cache para uso subsequente del mismo. Si el valor de los parametros usados en
la ejecucion no son representativos, entonces sql server usara ese plan
aunque en ejecuciones posteriores se usen valores representativos y el plan
de ejecucion no sera el adecuado. Este fenomeno se conoce como "parameter
sniffing" y puede ser evadido si el procedimineto es compilado cada vez que
se ejecuta, o si los parametros son reasignados a variables locales las
cuales seran usadas en la sentencia, o tambien usando sql dinamico para que
sql server compila la sentencia o batch al ser esta ejecutada en un nuevo
contexto.

A que me refiero con valores representativos?. Pues te dire que sql server
guarda estadisticas sobre la distribucion de valores en las columnas que
componen la clave de un indice. Estas estadisticas son usadas por el
optimizador de queries de sql server para escojer el plan de ejecucion
adecuado. La selectividad de los valores (para un valor o grupo de valores
dado, sql server seleccionara en la tabla una fila especifica) es muy
importante a la hora de determinar si el indice sera usado o no por sql
server. Si la selectividad es alta (menor numero de filas seran seleccionadas
para un valor) entonces sql server decidira usar el indice, pero si la
selectividad es baja (se selccionaran muchas filas dado un valor) entonces
sql server preferira scanear el indice o, en dependencia del numero de filas
a ser seleccionadas, hara un scan de la tabla o el indice clustered.

parameter sniffin
http://groups.google.com/group/micr...amp;rnum=1

Statistics Used by the Query Optimizer in Microsoft SQL Server 200
http://msdn.microsoft.com/library/d...frame=true


AMB

"Daniel Rodriguez" wrote:

Hola a todos!

A ver si me alumbrais con este problema...

Tengo problemas con un UPDATE muy simple desde un servidor vinculado (sql)
sobre las tablas de otro sql.

Pero la cosa es muy curiosa:

Si desde el analizador, conectado al servidor vinculado, hago esto:

Update servidor1.base.dbo.Tabla T set A=1 where T.Id

no hay problemas, tarda un suspiro.

Ahora, si esa misma sentencia la ejecuto desde un SP en el servidor
vinculado:

CREATE PROCEDURE Procedimiento (@Id [int], @Valor)
Update servidor1.base.dbo.Tabla T set A=@Valor where T.Id=@Id
GO

EXEC Procedimiento 10,1

En ese momento, el proceso tarda 10 segundos.

No hay problemas de permisos de usuarios, tampoco de configuracion de linked
server (hay otras consultas que funcionan bien)

Si ejecuto el update directamente con la sentencia, va bien.
Si uso un procedimiento, se queda

Sabeis qué puede estar pasando?