Bloqueo sobre TempDB en SQL 2000

Hola Juan,

¿Has mirado si la llamada que hace dicha herramienta contra la base de datos
pone el parámetro updateusage a true? Si fuese así, es bien posible que se
demorara largo rato la operación.


Rubén Garrigós
Solid Quality Mentors

"Juan Armani" wrote in message
news:u%

Buenas tardes,
Tengo un servidor SQL 2000 con SP4, desde ayer comenzaron a aparecer
problemas de bloqueos contra la base TempDB, el proceso que bloquea
ejecuta un "SP_SpaceUsed" y no libera la tabla SysIndexes con lo cual
comienzan a encolarse otros procesos y resulta casi imposible trabajar
sobre el motor. Es en el unico server que me esta sucediendo esto.
El proceso que bloquea es llamado a traves de la herramienta System
Center, y bajando el servicio de la msima se soluciona el problema.

El strore procedure sp_spaceused , consulta sysobjects, sysindexes y
sysfiles...es posible que me genere un bloqueo demasiado largo sobre
SysIndexes?

Alguna sugerencia al respecto?
Gracias

Juan Armani

Hola Rubén, te comento que he mirado tambien si estaba utilizando el
parametro pero no lo hace (= false por default), lo que me resulto un poco
confuso fue que me bloquee sysidexes, siendo que sp_spaceused solo consulta
la tabla sysindexes.
Opté por matar el proceso y bajar el servicio de la aplicacion externa que
me estaba generando el conflicto.

Seguramente vuelva a hacer mas pruebas levantando el servicio de esta app y
analizando el codigo de los demas procesos que trabajan con la TempDB en ese
momento.
Gracias de todos modos.
Saludos

Juan Armani


"Rubén Garrigós" escribió en el mensaje
news:

Hola Juan,

¿Has mirado si la llamada que hace dicha herramienta contra la base de
datos pone el parámetro updateusage a true? Si fuese así, es bien posible
que se demorara largo rato la operación.


Rubén Garrigós
Solid Quality Mentors

"Juan Armani" wrote in message
news:u%

Buenas tardes,
Tengo un servidor SQL 2000 con SP4, desde ayer comenzaron a aparecer
problemas de bloqueos contra la base TempDB, el proceso que bloquea
ejecuta un "SP_SpaceUsed" y no libera la tabla SysIndexes con lo cual
comienzan a encolarse otros procesos y resulta casi imposible trabajar
sobre el motor. Es en el unico server que me esta sucediendo esto.
El proceso que bloquea es llamado a traves de la herramienta System
Center, y bajando el servicio de la msima se soluciona el problema.

El strore procedure sp_spaceused , consulta sysobjects, sysindexes y
sysfiles...es posible que me genere un bloqueo demasiado largo sobre
SysIndexes?

Alguna sugerencia al respecto?
Gracias

Juan Armani

Una posible explicación de lo que está pasando es la siguiente:

sp_spaceused crea una tabla temporal, de ahí los bloqueos en sysindexes de
tempdb. Si no los libera es porque sp_spaceused se está ejecutando en una
transacción que dura mucho tiempo, igualmente la conexión permanece abierta
durante mucho tiempo.

Una vez tuve yo un problema similar con una aplicación que usaba ODBC, la
aplicación empezaba una transacción que podía durar horas. ODBC llama al
procedimiento sp_statistics para obtener información de claves en las tablas
y para ello también crea tablas temporales. La contención en tempdb era
enorme hasta el punto que en ciertos momentos había que empezar a matar
conexiones.
La solución fue sustituir el procedimiento sp_statistics por una versión mía
que devolviera el mismo resultado pero que no creara tablas temporales. La
nueva versión de sp_statistics y no provocaba contención en temdb, si
embargo no era tan eficiente como la versión original. Qué le vamos a hacer,
no se puede tener todo en esta vida.


Generalmente no es una buena idea modificar un procedimiento almacenado del
sistema, pero a veces no queda más remedio, sobre todo si no hay manera de
modificar la aplicación para que haga las cosas de otra manera.


En definitiva, una solución a tu problema podría ser sustituir el
procedimiento sp_spaceused por una versión tuya que no creara tablas
temporales y que usara hints NOLOCK para evitar bloqueos.

Saludos:

Jesús López





"Juan Armani" escribió en el mensaje
news:

Hola Rubén, te comento que he mirado tambien si estaba utilizando el
parametro pero no lo hace (= false por default), lo que me resulto un poco
confuso fue que me bloquee sysidexes, siendo que sp_spaceused solo
consulta la tabla sysindexes.
Opté por matar el proceso y bajar el servicio de la aplicacion externa que
me estaba generando el conflicto.

Seguramente vuelva a hacer mas pruebas levantando el servicio de esta app
y analizando el codigo de los demas procesos que trabajan con la TempDB en
ese momento.
Gracias de todos modos.
Saludos

Juan Armani


"Rubén Garrigós" escribió en el mensaje
news:

Hola Juan,

¿Has mirado si la llamada que hace dicha herramienta contra la base de
datos pone el parámetro updateusage a true? Si fuese así, es bien posible
que se demorara largo rato la operación.


Rubén Garrigós
Solid Quality Mentors

"Juan Armani" wrote in message
news:u%

Buenas tardes,
Tengo un servidor SQL 2000 con SP4, desde ayer comenzaron a aparecer
problemas de bloqueos contra la base TempDB, el proceso que bloquea
ejecuta un "SP_SpaceUsed" y no libera la tabla SysIndexes con lo cual
comienzan a encolarse otros procesos y resulta casi imposible trabajar
sobre el motor. Es en el unico server que me esta sucediendo esto.
El proceso que bloquea es llamado a traves de la herramienta System
Center, y bajando el servicio de la msima se soluciona el problema.

El strore procedure sp_spaceused , consulta sysobjects, sysindexes y
sysfiles...es posible que me genere un bloqueo demasiado largo sobre
SysIndexes?

Alguna sugerencia al respecto?
Gracias

Juan Armani

Una solución que se me ocurre para no modificar demasiado el procedimiento
sp_spaceused, está basado SAVE TRANSACTION:

Mira el siguiente código:

USE Northwind
GO

BEGIN TRANSACTION
EXEC sp_spaceused 'dbo.Order Details'
EXEC sp_lock
COMMIT

Verás que sp_spaceused crear una considerable cantidad de bloqueos
exclusivos en tempdb.

Sin embargo si ejecutamos este código:

BEGIN TRANSACTION
IF @@TRANCOUNT > 0
BEGIN
SAVE TRANSACTION tran1
END
exec sp_spaceused 'dbo.Order Details'
IF @@TRANCOUNT > 0
ROLLBACK TRANSACTION tran1
exec sp_lock
COMMIT

Verás que los bloqueos no están ya que hemos deshecho lo que había hecho
sp_spaceused.

Así que podríamos renombrar sp_spaceused a sp_spaceusedoriginal, y crear un
nuevo sp_spaceused:

CREATE PROCEDURE sp_spaceused <los parametros>
BEGIN
IF @@TRANCOUNT > 0 SAVE TRANSACTION tran1
EXEC sp_spaceusedoriginal <los parametros>
IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION tran1
END

Saludos:


Jesús López
www.soldiq.com




"Jesús López" escribió en el
mensaje news:

Una posible explicación de lo que está pasando es la siguiente:

sp_spaceused crea una tabla temporal, de ahí los bloqueos en sysindexes de
tempdb. Si no los libera es porque sp_spaceused se está ejecutando en una
transacción que dura mucho tiempo, igualmente la conexión permanece
abierta durante mucho tiempo.

Una vez tuve yo un problema similar con una aplicación que usaba ODBC, la
aplicación empezaba una transacción que podía durar horas. ODBC llama al
procedimiento sp_statistics para obtener información de claves en las
tablas y para ello también crea tablas temporales. La contención en tempdb
era enorme hasta el punto que en ciertos momentos había que empezar a
matar conexiones.
La solución fue sustituir el procedimiento sp_statistics por una versión
mía que devolviera el mismo resultado pero que no creara tablas
temporales. La nueva versión de sp_statistics y no provocaba contención en
temdb, si embargo no era tan eficiente como la versión original. Qué le
vamos a hacer, no se puede tener todo en esta vida.


Generalmente no es una buena idea modificar un procedimiento almacenado
del sistema, pero a veces no queda más remedio, sobre todo si no hay
manera de modificar la aplicación para que haga las cosas de otra manera.


En definitiva, una solución a tu problema podría ser sustituir el
procedimiento sp_spaceused por una versión tuya que no creara tablas
temporales y que usara hints NOLOCK para evitar bloqueos.

Saludos:

Jesús López





"Juan Armani" escribió en el mensaje
news:

Hola Rubén, te comento que he mirado tambien si estaba utilizando el
parametro pero no lo hace (= false por default), lo que me resulto un
poco confuso fue que me bloquee sysidexes, siendo que sp_spaceused solo
consulta la tabla sysindexes.
Opté por matar el proceso y bajar el servicio de la aplicacion externa
que me estaba generando el conflicto.

Seguramente vuelva a hacer mas pruebas levantando el servicio de esta app
y analizando el codigo de los demas procesos que trabajan con la TempDB
en ese momento.
Gracias de todos modos.
Saludos

Juan Armani


"Rubén Garrigós" escribió en el mensaje
news:

Hola Juan,

¿Has mirado si la llamada que hace dicha herramienta contra la base de
datos pone el parámetro updateusage a true? Si fuese así, es bien
posible que se demorara largo rato la operación.


Rubén Garrigós
Solid Quality Mentors

"Juan Armani" wrote in message
news:u%

Buenas tardes,
Tengo un servidor SQL 2000 con SP4, desde ayer comenzaron a aparecer
problemas de bloqueos contra la base TempDB, el proceso que bloquea
ejecuta un "SP_SpaceUsed" y no libera la tabla SysIndexes con lo cual
comienzan a encolarse otros procesos y resulta casi imposible trabajar
sobre el motor. Es en el unico server que me esta sucediendo esto.
El proceso que bloquea es llamado a traves de la herramienta System
Center, y bajando el servicio de la msima se soluciona el problema.

El strore procedure sp_spaceused , consulta sysobjects, sysindexes y
sysfiles...es posible que me genere un bloqueo demasiado largo sobre
SysIndexes?

Alguna sugerencia al respecto?
Gracias

Juan Armani

Por cierto,

Para hacer que el nuevo sp_spaceused sea realmente un procedimiento
almacenado del sistema tendrás que ejecutar:

use master
go
exec sp_MS_marksystemobject 'dbo.sp_spaceused'



"Jesús López" escribió en el
mensaje news:

Una solución que se me ocurre para no modificar demasiado el procedimiento
sp_spaceused, está basado SAVE TRANSACTION:

Mira el siguiente código:

USE Northwind
GO

BEGIN TRANSACTION
EXEC sp_spaceused 'dbo.Order Details'
EXEC sp_lock
COMMIT

Verás que sp_spaceused crear una considerable cantidad de bloqueos
exclusivos en tempdb.

Sin embargo si ejecutamos este código:

BEGIN TRANSACTION
IF @@TRANCOUNT > 0
BEGIN
SAVE TRANSACTION tran1
END
exec sp_spaceused 'dbo.Order Details'
IF @@TRANCOUNT > 0
ROLLBACK TRANSACTION tran1
exec sp_lock
COMMIT

Verás que los bloqueos no están ya que hemos deshecho lo que había hecho
sp_spaceused.

Así que podríamos renombrar sp_spaceused a sp_spaceusedoriginal, y crear
un nuevo sp_spaceused:

CREATE PROCEDURE sp_spaceused <los parametros>
BEGIN
IF @@TRANCOUNT > 0 SAVE TRANSACTION tran1
EXEC sp_spaceusedoriginal <los parametros>
IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION tran1
END

Saludos:


Jesús López
www.soldiq.com




"Jesús López" escribió en el
mensaje news:

Una posible explicación de lo que está pasando es la siguiente:

sp_spaceused crea una tabla temporal, de ahí los bloqueos en sysindexes
de tempdb. Si no los libera es porque sp_spaceused se está ejecutando en
una transacción que dura mucho tiempo, igualmente la conexión permanece
abierta durante mucho tiempo.

Una vez tuve yo un problema similar con una aplicación que usaba ODBC, la
aplicación empezaba una transacción que podía durar horas. ODBC llama al
procedimiento sp_statistics para obtener información de claves en las
tablas y para ello también crea tablas temporales. La contención en
tempdb era enorme hasta el punto que en ciertos momentos había que
empezar a matar conexiones.
La solución fue sustituir el procedimiento sp_statistics por una versión
mía que devolviera el mismo resultado pero que no creara tablas
temporales. La nueva versión de sp_statistics y no provocaba contención
en temdb, si embargo no era tan eficiente como la versión original. Qué
le vamos a hacer, no se puede tener todo en esta vida.


Generalmente no es una buena idea modificar un procedimiento almacenado
del sistema, pero a veces no queda más remedio, sobre todo si no hay
manera de modificar la aplicación para que haga las cosas de otra manera.


En definitiva, una solución a tu problema podría ser sustituir el
procedimiento sp_spaceused por una versión tuya que no creara tablas
temporales y que usara hints NOLOCK para evitar bloqueos.

Saludos:

Jesús López





"Juan Armani" escribió en el mensaje
news:

Hola Rubén, te comento que he mirado tambien si estaba utilizando el
parametro pero no lo hace (= false por default), lo que me resulto un
poco confuso fue que me bloquee sysidexes, siendo que sp_spaceused solo
consulta la tabla sysindexes.
Opté por matar el proceso y bajar el servicio de la aplicacion externa
que me estaba generando el conflicto.

Seguramente vuelva a hacer mas pruebas levantando el servicio de esta
app y analizando el codigo de los demas procesos que trabajan con la
TempDB en ese momento.
Gracias de todos modos.
Saludos

Juan Armani


"Rubén Garrigós" escribió en el mensaje
news:

Hola Juan,

¿Has mirado si la llamada que hace dicha herramienta contra la base de
datos pone el parámetro updateusage a true? Si fuese así, es bien
posible que se demorara largo rato la operación.


Rubén Garrigós
Solid Quality Mentors

"Juan Armani" wrote in message
news:u%

Buenas tardes,
Tengo un servidor SQL 2000 con SP4, desde ayer comenzaron a aparecer
problemas de bloqueos contra la base TempDB, el proceso que bloquea
ejecuta un "SP_SpaceUsed" y no libera la tabla SysIndexes con lo cual
comienzan a encolarse otros procesos y resulta casi imposible trabajar
sobre el motor. Es en el unico server que me esta sucediendo esto.
El proceso que bloquea es llamado a traves de la herramienta System
Center, y bajando el servicio de la msima se soluciona el problema.

El strore procedure sp_spaceused , consulta sysobjects, sysindexes y
sysfiles...es posible que me genere un bloqueo demasiado largo sobre
SysIndexes?

Alguna sugerencia al respecto?
Gracias

Juan Armani