Gestion de tablas locales ('#') - TEMPDB

Hola Fernando,

Analicemos tu problema:

01. Tu usuario "Pepe" abrio una conexion y en su sesion creó una tabla
temporal y la alimentó con 10 millones de registros, los cuales se
alojan en la Tempdb, hasta que un drop table o temine la sesion o
conexion.
02. Tu usuario "Pepe" se fue elegante y orondamente dejando su
conexion abierta y la tabla bendita ocupando espacio valioso en tu
Tempdb.
03. Si lo miras de otra perspectiva, lo que tienes es una conexion
inactiva sobre una base de datos, por un periodo de tiempo
controlable, la cual debe ser terminada.

Tengo ese problema, no con la Tempdb, sino con tablas de produccion, y
lo que hago es ejecutar una rutina (un stored procedure invocado desde
un job, cuya ejecucion esta programada para cada hora), y realiza un
kill sobre las conexiones inactivas por un periodo de tiempo que he
determinado y correspondiente para cada base de datos segun sea el
caso.
Pienso que lo mismo puedes aplicar en tu caso.

Si ves que una conexion a la base de datos Tempdb esta inactiva
durante, digamos por ejemplo, una hora (por decir algo), realizas un
kill automaticamente. Con eso terminas la conexion, la tabla temporal
y libera el recurso ocupado en la Tempdb. Quieres saber quien fue el
"culpable"? pues el bendito script te dice quien fue, que estaba
haciendo, la ultima vez que ejecuto algo sobre la base de datos, etc.
interesante, no?

****************************************************************************************************************
SET NOCOUNT ON
USE master

if not exists (select * from sysobjects where id = object_id(N'[dbo].
[UsuarioInactivosBDatos]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
Begin
CREATE TABLE [dbo].[UsuarioInactivosBDatos] (
[FechaAcceso] [datetime] NULL ,
[TiempoInactivo] [int] NOT NULL,
[spid] [smallint] NOT NULL ,
[blocked] [smallint] NOT NULL ,
[lastwaittype] [nchar] (32) NOT NULL ,
[cpu] [int] NOT NULL ,
[physical_io] [int] NOT NULL ,
[login_time] [datetime] NOT NULL ,
[last_batch] [datetime] NOT NULL ,
[open_tran] [smallint] NOT NULL ,
[status] [nchar] (30) NOT NULL ,
[hostname] [nchar] (128) NOT NULL ,
[program_name] [nchar] (128) NOT NULL ,
[nt_domain] [nchar] (128) NOT NULL ,
[nt_username] [nchar] (128) NOT NULL ,
[loginame] [nchar] (128) NOT NULL
) ON [PRIMARY]
End


DECLARE @dbname varchar(30),
@spid varchar(10),
@dtLastProc datetime,
@start datetime,
@tiTiempo int,
@tiTiempoMax int,
@btVista bit

SELECT @start = current_timestamp,
@dbname = 'master',
@tiTiempoMax = 45,
@btVista = 1

If @btVista = 1
Begin
PRINT
'*******************************************************************'
PRINT '******ESTE SCRIPTS MOSTRARA LOS USUARIOS QUE ESTAN INACTIVOS'
PRINT '******POR MAS DE ' + CAST (@tiTiempoMax AS VARCHAR(5))
PRINT '******EN LA BASE DE DATOS ' + @dbname
PRINT
'*******************************************************************'
End
Else
Begin
PRINT
'*******************************************************************'
PRINT '*ESTE SCRIPTS ELIMINARA LA CONEXION AL SQL SERVER'
PRINT '*POR MAS DE *' + CAST (@tiTiempoMax AS VARCHAR(5))
PRINT '******EN LA BASE DE DATOS ' + @dbname
PRINT
'*******************************************************************'
End

DECLARE spids CURSOR FOR
SELECT convert(varchar, spid), last_batch
FROM sysprocesses
WHERE dbid = db_id(@dbname)

OPEN spids

FETCH NEXT FROM spids INTO @spid, @dtLastProc

WHILE (@@fetch_status = 0)
BEGIN
SELECT @tiTiempo = DATEDIFF(mi, @dtLastProc, @start)
If @tiTiempo >= @tiTiempoMax
Begin
IF @btVista = 1
Begin
SELECT @start AS FechaAcceso, @tiTiempo AS TiempoInactivoMinutos,
spid, blocked, lastwaittype, cpu, physical_io, login_time, last_batch,
open_tran,
status, hostname, program_name, nt_domain, nt_username, loginame
FROM sysprocesses
WHERE spid = @spid
End
ELSE
Begin
INSERT INTO UsuarioInactivosBDatos
SELECT @start AS FechaAcceso, @tiTiempo AS TiempoInactivo, spid,
blocked, lastwaittype, cpu, physical_io, login_time, last_batch,
open_tran,
status, hostname, program_name, nt_domain, nt_username, loginame
FROM sysprocesses
WHERE spid = @spid
EXEC('KILL ' + @spid)
End
End
FETCH NEXT FROM spids INTO @spid, @dtLastProc
END
DEALLOCATE spids

/*
SELECT *
FROM UsuarioInactivosBDatos
select 992/60
delete UsuarioInactivosBDatos
*/
****************************************************************************************************************

Te recomiendo que lo analices y pruebes primero en el ambiente de
Desarrollo, cuando lo hayas entendido,
aplicalo donde gustes.

Saludos,

Juan Carlos Mendoza
Callao - Peru


On 21 nov, 14:53, "Fernando Mosquera Catarecha"
wrote:

Amigos, no puedo concebir que un DBA no pueda tener control de las tablas
temporales locales..

Retomo las preguntas claves:

Como puedo eliminar una tabla temporal local que creo una conexión aun
activa? (sin hacer el KILL al PID de la conexión).

Como puedo saber que conexión la esta manteniendo? (a fin de hacer KILL al
PID de la conexión).

Como puedo realizarle un SELECT de dicha tabla? (esto no es tan relevante
como las dos anteriores).

Por favor si alguien puede aportar un poco de claridad al asunto,

Muchas gracias a todos!

Saludos cordiales,

Atte.

Fernando.

"Fernando Mosquera Catarecha" wrote in messagenews:OAT$



> Buenos días a todos!

> Se me planteo la siguiente problemática:

> Como es sabido, cuando un usuario crea una tabla temporal local (con el
> signo '#') esta se almacena en el contendor TEMPDB de nuestro motor de
> SQL. Hasta que el usuario no realiza un DROP de la misma o no cierra la
> conexión dicha tabla no es eliminada.

> Ahora bien:

> Como puedo eliminar dicha tabla?

> Como puedo realizarle un SELECT de la misma?

> Como puedo saber que conexión la esta manteniendo?

> Realice toda clase de pruebas / scripts involucrando el object id, name,
> tablas del sistema, etc. y no puede obtener resultados positivo.

> No puedo concebir que siendo sysadmin no pueda tener gestión sobre dichas
> tablas.

> Si alguien ya se planteo esta problemática o tiene una solución que yo
> ignoro le agradecería que conteste el Post.

> Saludos Cordiales,

> Atte.

> Fernando.- Ocultar texto de la cita -

- Mostrar texto de la cita -

Hola,

las nuevas DMVs de SQL 2005, te permiten ver los objetos temporales creados
por una sesión; tirando un poco del hilo puedes más o menos identificar el
usuario que ha creado esa tabla gigantesca:

select session.session_id, host_name,
program_name, login_name, nt_domain, nt_user_name,
reads, writes, logical_reads
, user_objects_alloc_page_count
, user_objects_dealloc_page_count
, internal_objects_alloc_page_count
, internal_objects_dealloc_page_count
from
sys.dm_exec_sessions session
join sys.dm_db_session_space_usage space_usage
on session.session_id = space_usage.session_id
where
user_objects_alloc_page_count <> 0
or user_objects_dealloc_page_count <> 0
or internal_objects_alloc_page_count <> 0
or internal_objects_dealloc_page_count <> 0

hasta donde yo se, en la versión 2000, esa infromación no se podía obtener.
También se en que Sybase, a cada objeto temporal, se le añadía el spid de la
conexión que lo había creado -- creo que estás buscando esta aproximación.


ya nos contarás si te sirve esta DMV,

Saludos,

Eladio Rincón,
SQL Server MVP
http://blogs.solidq.com/es/elrincondeldba

"Fernando Mosquera Catarecha" wrote in message
news:

Gente, ante todo muchas gracias por sus respuestas.



Técnicamente sus comentarios son correctos pero no estaría aplicando a mi
consulta. Les doy un caso práctico a fin de aportar claridad.



El usuario 'Pepe' se conecta al SQL con un "Query Analyzer", crea una
tabla temporal local (con el signo '#') y la alimenta con 10 millones de
registros (char (200)).

Termina el horario laborar y el usuario 'Pepe' se va a su casa dejando la
PC "bloqueada" con el "Query Analyzer" abierto (obviamente manteniendo la
conexión PID X con su respectiva tabla temporal de 10 millones de
registros).



Yo administrador del SQL visualizo que el contenedor TEMPDB creció
desmesuradamente y me pongo a analizar el porque.

Rápidamente encuentro una tabla llamada
'#TmpPepe____________________XXXXXX' la cual me esta llenando el
contenedor.

Ahora bien, la quiero borrar (DROP) y no puedo, la quiero consultar y
tampoco puedo. Alternativa: Tendría que identificar la conexión que la
mantiene y realizar un simple KILL al PID para que la misma sea eliminada
automáticamente por el SQL pero no tengo forma de ver cual es ese PID.



Con las tablas del sistema no pude precisar nada.



Lindo problema, no?



Es más común de lo que parece cuando se trabaja en ambientes de
desarrollo.



Agradezco sus colaboraciones,

Saludos Cordiales,

Atte.

Fernando.



"Fernando Mosquera Catarecha" wrote in message
news:OAT$

Buenos días a todos!



Se me planteo la siguiente problemática:



Como es sabido, cuando un usuario crea una tabla temporal local (con el
signo '#') esta se almacena en el contendor TEMPDB de nuestro motor de
SQL. Hasta que el usuario no realiza un DROP de la misma o no cierra la
conexión dicha tabla no es eliminada.



Ahora bien:



Como puedo eliminar dicha tabla?

Como puedo realizarle un SELECT de la misma?

Como puedo saber que conexión la esta manteniendo?



Realice toda clase de pruebas / scripts involucrando el object id, name,
tablas del sistema, etc. y no puede obtener resultados positivo.



No puedo concebir que siendo sysadmin no pueda tener gestión sobre dichas
tablas.



Si alguien ya se planteo esta problemática o tiene una solución que yo
ignoro le agradecería que conteste el Post.



Saludos Cordiales,

Atte.

Fernando.

Estimado Eladio Rincón,



Muchas gracias por tu respuesta, es mas que interesante el script que
adjuntas, particularmente el dato que devuelve la columan
"user_objects_alloc_page_count" y "user_objects_dealloc_page_count".

No hay forma de obtener el objeto o el contenedor en el cual realizo el
alloc & dealloc?



Actualmente estas eventualidades se me producen en SQL 2000, alguna idea
para esta versión?



Saludos Cordiales,

Atte.

Fernando.





"Eladio Rincón" wrote in message
news:

Hola,

las nuevas DMVs de SQL 2005, te permiten ver los objetos temporales
creados por una sesión; tirando un poco del hilo puedes más o menos
identificar el usuario que ha creado esa tabla gigantesca:

select session.session_id, host_name,
program_name, login_name, nt_domain, nt_user_name,
reads, writes, logical_reads
, user_objects_alloc_page_count
, user_objects_dealloc_page_count
, internal_objects_alloc_page_count
, internal_objects_dealloc_page_count
from
sys.dm_exec_sessions session
join sys.dm_db_session_space_usage space_usage
on session.session_id = space_usage.session_id
where
user_objects_alloc_page_count <> 0
or user_objects_dealloc_page_count <> 0
or internal_objects_alloc_page_count <> 0
or internal_objects_dealloc_page_count <> 0

hasta donde yo se, en la versión 2000, esa infromación no se podía
obtener. También se en que Sybase, a cada objeto temporal, se le añadía el
spid de la conexión que lo había creado -- creo que estás buscando esta
aproximación.


ya nos contarás si te sirve esta DMV,

Saludos,

Eladio Rincón,
SQL Server MVP
http://blogs.solidq.com/es/elrincondeldba

"Fernando Mosquera Catarecha" wrote in message
news:

Gente, ante todo muchas gracias por sus respuestas.



Técnicamente sus comentarios son correctos pero no estaría aplicando a mi
consulta. Les doy un caso práctico a fin de aportar claridad.



El usuario 'Pepe' se conecta al SQL con un "Query Analyzer", crea una
tabla temporal local (con el signo '#') y la alimenta con 10 millones de
registros (char (200)).

Termina el horario laborar y el usuario 'Pepe' se va a su casa dejando la
PC "bloqueada" con el "Query Analyzer" abierto (obviamente manteniendo la
conexión PID X con su respectiva tabla temporal de 10 millones de
registros).



Yo administrador del SQL visualizo que el contenedor TEMPDB creció
desmesuradamente y me pongo a analizar el porque.

Rápidamente encuentro una tabla llamada
'#TmpPepe____________________XXXXXX' la cual me esta llenando el
contenedor.

Ahora bien, la quiero borrar (DROP) y no puedo, la quiero consultar y
tampoco puedo. Alternativa: Tendría que identificar la conexión que la
mantiene y realizar un simple KILL al PID para que la misma sea eliminada
automáticamente por el SQL pero no tengo forma de ver cual es ese PID.



Con las tablas del sistema no pude precisar nada.



Lindo problema, no?



Es más común de lo que parece cuando se trabaja en ambientes de
desarrollo.



Agradezco sus colaboraciones,

Saludos Cordiales,

Atte.

Fernando.



"Fernando Mosquera Catarecha" wrote in message
news:OAT$

Buenos días a todos!



Se me planteo la siguiente problemática:



Como es sabido, cuando un usuario crea una tabla temporal local (con el
signo '#') esta se almacena en el contendor TEMPDB de nuestro motor de
SQL. Hasta que el usuario no realiza un DROP de la misma o no cierra la
conexión dicha tabla no es eliminada.



Ahora bien:



Como puedo eliminar dicha tabla?

Como puedo realizarle un SELECT de la misma?

Como puedo saber que conexión la esta manteniendo?



Realice toda clase de pruebas / scripts involucrando el object id, name,
tablas del sistema, etc. y no puede obtener resultados positivo.



No puedo concebir que siendo sysadmin no pueda tener gestión sobre
dichas tablas.



Si alguien ya se planteo esta problemática o tiene una solución que yo
ignoro le agradecería que conteste el Post.



Saludos Cordiales,

Atte.

Fernando.

Amigo Juan Carlos, agradezco tu alternativa, en mi caso no seria valida ya
que por ser entorno de desarrollo las conexiones podrían estar inactivas 2
minutos como 8 hs o días quizás y seguir siendo consumidas, eventualmente,
por un desarrollador.



Me alegra escuchar que alguien se planteo la problemática y encontró una
alternativa aunque no la solución..



Alguien más tuvo y/o tiene esta problemática tan básica pero a su vez tan
mística?



Sigo sin entender que mi amado SQL no me permita gestionar este tipo de
tablas, aguardo toda clase de alternativa / solución.



Muchas gracias a todos!



Saludos Cordiales,

Atte.

Fernando.





"Juan Carlos Mendoza" wrote in message
news:
Hola Fernando,

Analicemos tu problema:

01. Tu usuario "Pepe" abrio una conexion y en su sesion creó una tabla
temporal y la alimentó con 10 millones de registros, los cuales se
alojan en la Tempdb, hasta que un drop table o temine la sesion o
conexion.
02. Tu usuario "Pepe" se fue elegante y orondamente dejando su
conexion abierta y la tabla bendita ocupando espacio valioso en tu
Tempdb.
03. Si lo miras de otra perspectiva, lo que tienes es una conexion
inactiva sobre una base de datos, por un periodo de tiempo
controlable, la cual debe ser terminada.

Tengo ese problema, no con la Tempdb, sino con tablas de produccion, y
lo que hago es ejecutar una rutina (un stored procedure invocado desde
un job, cuya ejecucion esta programada para cada hora), y realiza un
kill sobre las conexiones inactivas por un periodo de tiempo que he
determinado y correspondiente para cada base de datos segun sea el
caso.
Pienso que lo mismo puedes aplicar en tu caso.

Si ves que una conexion a la base de datos Tempdb esta inactiva
durante, digamos por ejemplo, una hora (por decir algo), realizas un
kill automaticamente. Con eso terminas la conexion, la tabla temporal
y libera el recurso ocupado en la Tempdb. Quieres saber quien fue el
"culpable"? pues el bendito script te dice quien fue, que estaba
haciendo, la ultima vez que ejecuto algo sobre la base de datos, etc.
interesante, no?

****************************************************************************************************************
SET NOCOUNT ON
USE master

if not exists (select * from sysobjects where id = object_id(N'[dbo].
[UsuarioInactivosBDatos]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
Begin
CREATE TABLE [dbo].[UsuarioInactivosBDatos] (
[FechaAcceso] [datetime] NULL ,
[TiempoInactivo] [int] NOT NULL,
[spid] [smallint] NOT NULL ,
[blocked] [smallint] NOT NULL ,
[lastwaittype] [nchar] (32) NOT NULL ,
[cpu] [int] NOT NULL ,
[physical_io] [int] NOT NULL ,
[login_time] [datetime] NOT NULL ,
[last_batch] [datetime] NOT NULL ,
[open_tran] [smallint] NOT NULL ,
[status] [nchar] (30) NOT NULL ,
[hostname] [nchar] (128) NOT NULL ,
[program_name] [nchar] (128) NOT NULL ,
[nt_domain] [nchar] (128) NOT NULL ,
[nt_username] [nchar] (128) NOT NULL ,
[loginame] [nchar] (128) NOT NULL
) ON [PRIMARY]
End


DECLARE @dbname varchar(30),
@spid varchar(10),
@dtLastProc datetime,
@start datetime,
@tiTiempo int,
@tiTiempoMax int,
@btVista bit

SELECT @start = current_timestamp,
@dbname = 'master',
@tiTiempoMax = 45,
@btVista = 1

If @btVista = 1
Begin
PRINT
'*******************************************************************'
PRINT '******ESTE SCRIPTS MOSTRARA LOS USUARIOS QUE ESTAN INACTIVOS'
PRINT '******POR MAS DE ' + CAST (@tiTiempoMax AS VARCHAR(5))
PRINT '******EN LA BASE DE DATOS ' + @dbname
PRINT
'*******************************************************************'
End
Else
Begin
PRINT
'*******************************************************************'
PRINT '*ESTE SCRIPTS ELIMINARA LA CONEXION AL SQL SERVER'
PRINT '*POR MAS DE *' + CAST (@tiTiempoMax AS VARCHAR(5))
PRINT '******EN LA BASE DE DATOS ' + @dbname
PRINT
'*******************************************************************'
End

DECLARE spids CURSOR FOR
SELECT convert(varchar, spid), last_batch
FROM sysprocesses
WHERE dbid = db_id(@dbname)

OPEN spids

FETCH NEXT FROM spids INTO @spid, @dtLastProc

WHILE (@@fetch_status = 0)
BEGIN
SELECT @tiTiempo = DATEDIFF(mi, @dtLastProc, @start)
If @tiTiempo >= @tiTiempoMax
Begin
IF @btVista = 1
Begin
SELECT @start AS FechaAcceso, @tiTiempo AS TiempoInactivoMinutos,
spid, blocked, lastwaittype, cpu, physical_io, login_time, last_batch,
open_tran,
status, hostname, program_name, nt_domain, nt_username, loginame
FROM sysprocesses
WHERE spid = @spid
End
ELSE
Begin
INSERT INTO UsuarioInactivosBDatos
SELECT @start AS FechaAcceso, @tiTiempo AS TiempoInactivo, spid,
blocked, lastwaittype, cpu, physical_io, login_time, last_batch,
open_tran,
status, hostname, program_name, nt_domain, nt_username, loginame
FROM sysprocesses
WHERE spid = @spid
EXEC('KILL ' + @spid)
End
End
FETCH NEXT FROM spids INTO @spid, @dtLastProc
END
DEALLOCATE spids

/*
SELECT *
FROM UsuarioInactivosBDatos
select 992/60
delete UsuarioInactivosBDatos
*/
****************************************************************************************************************

Te recomiendo que lo analices y pruebes primero en el ambiente de
Desarrollo, cuando lo hayas entendido,
aplicalo donde gustes.

Saludos,

Juan Carlos Mendoza
Callao - Peru


On 21 nov, 14:53, "Fernando Mosquera Catarecha"
wrote:

Amigos, no puedo concebir que un DBA no pueda tener control de las tablas
temporales locales..

Retomo las preguntas claves:

Como puedo eliminar una tabla temporal local que creo una conexión aun
activa? (sin hacer el KILL al PID de la conexión).

Como puedo saber que conexión la esta manteniendo? (a fin de hacer KILL al
PID de la conexión).

Como puedo realizarle un SELECT de dicha tabla? (esto no es tan relevante
como las dos anteriores).

Por favor si alguien puede aportar un poco de claridad al asunto,

Muchas gracias a todos!

Saludos cordiales,

Atte.

Fernando.

"Fernando Mosquera Catarecha" wrote in
messagenews:OAT$



> Buenos días a todos!

> Se me planteo la siguiente problemática:

> Como es sabido, cuando un usuario crea una tabla temporal local (con el
> signo '#') esta se almacena en el contendor TEMPDB de nuestro motor de
> SQL. Hasta que el usuario no realiza un DROP de la misma o no cierra la
> conexión dicha tabla no es eliminada.

> Ahora bien:

> Como puedo eliminar dicha tabla?

> Como puedo realizarle un SELECT de la misma?

> Como puedo saber que conexión la esta manteniendo?

> Realice toda clase de pruebas / scripts involucrando el object id, name,
> tablas del sistema, etc. y no puede obtener resultados positivo.

> No puedo concebir que siendo sysadmin no pueda tener gestión sobre
> dichas
> tablas.

> Si alguien ya se planteo esta problemática o tiene una solución que yo
> ignoro le agradecería que conteste el Post.

> Saludos Cordiales,

> Atte.

> Fernando.- Ocultar texto de la cita -

- Mostrar texto de la cita -

hola Fernando,

En la consulta anterior, tienes reads, y writes que te podría dar una pista;
en tablas temporales del tamaño que estas hablando, el valor de writes sería
alto.
En la versión 2000 tienes la siguiente consulta:

select spid, physical_io, memusage
from master..sysprocesses

donde physical_io será indicador de que esa conexión está realizando mucha
actividad...

No hay información más concreta que esa; sin embargo, en sysprocesses puedes
filtrar por application name que sería query analizer, por IP probablemente,
etc.etc.

a la pregunta de si en 2005, hay información del objeto, hasta donde yo se,
la respuesta es que no. ¿te imaginas la barbaridad de recursos que se
necesitarían para registrar cada objeto temporal creado? sin conocer el
código del producto, me atrevería a decir que es muy complicado y costoso...

por cierto, la dmv sys.dm_db_session_space_usage, no actualiza su contenido
mientras se esté ejecutando el batch, se actualice según vaya finalizando;
lo he comprobado con el siguiente batch:

while (1=1)
begin
insert #t default values
waitfor delay '00:00:01'
end

hasta que no he parado el batch, la información en cuanto a objetos creados
permanecía a cero, mientras que en sysprocesses si se iba actualizando :)



Saludos,

Eladio Rincón,
SQL Server MVP
http://blogs.solidq.com/es/elrincondeldba

"Fernando Mosquera Catarecha" wrote in message
news:

Estimado Eladio Rincón,



Muchas gracias por tu respuesta, es mas que interesante el script que
adjuntas, particularmente el dato que devuelve la columan
"user_objects_alloc_page_count" y "user_objects_dealloc_page_count".

No hay forma de obtener el objeto o el contenedor en el cual realizo el
alloc & dealloc?



Actualmente estas eventualidades se me producen en SQL 2000, alguna idea
para esta versión?



Saludos Cordiales,

Atte.

Fernando.





"Eladio Rincón" wrote in message
news:

Hola,

las nuevas DMVs de SQL 2005, te permiten ver los objetos temporales
creados por una sesión; tirando un poco del hilo puedes más o menos
identificar el usuario que ha creado esa tabla gigantesca:

select session.session_id, host_name,
program_name, login_name, nt_domain, nt_user_name,
reads, writes, logical_reads
, user_objects_alloc_page_count
, user_objects_dealloc_page_count
, internal_objects_alloc_page_count
, internal_objects_dealloc_page_count
from
sys.dm_exec_sessions session
join sys.dm_db_session_space_usage space_usage
on session.session_id = space_usage.session_id
where
user_objects_alloc_page_count <> 0
or user_objects_dealloc_page_count <> 0
or internal_objects_alloc_page_count <> 0
or internal_objects_dealloc_page_count <> 0

hasta donde yo se, en la versión 2000, esa infromación no se podía
obtener. También se en que Sybase, a cada objeto temporal, se le añadía
el spid de la conexión que lo había creado -- creo que estás buscando
esta aproximación.


ya nos contarás si te sirve esta DMV,

Saludos,

Eladio Rincón,
SQL Server MVP
http://blogs.solidq.com/es/elrincondeldba

"Fernando Mosquera Catarecha" wrote in message
news:

Gente, ante todo muchas gracias por sus respuestas.



Técnicamente sus comentarios son correctos pero no estaría aplicando a
mi consulta. Les doy un caso práctico a fin de aportar claridad.



El usuario 'Pepe' se conecta al SQL con un "Query Analyzer", crea una
tabla temporal local (con el signo '#') y la alimenta con 10 millones de
registros (char (200)).

Termina el horario laborar y el usuario 'Pepe' se va a su casa dejando
la PC "bloqueada" con el "Query Analyzer" abierto (obviamente
manteniendo la conexión PID X con su respectiva tabla temporal de 10
millones de registros).



Yo administrador del SQL visualizo que el contenedor TEMPDB creció
desmesuradamente y me pongo a analizar el porque.

Rápidamente encuentro una tabla llamada
'#TmpPepe____________________XXXXXX' la cual me esta llenando el
contenedor.

Ahora bien, la quiero borrar (DROP) y no puedo, la quiero consultar y
tampoco puedo. Alternativa: Tendría que identificar la conexión que la
mantiene y realizar un simple KILL al PID para que la misma sea
eliminada automáticamente por el SQL pero no tengo forma de ver cual es
ese PID.



Con las tablas del sistema no pude precisar nada.



Lindo problema, no?



Es más común de lo que parece cuando se trabaja en ambientes de
desarrollo.



Agradezco sus colaboraciones,

Saludos Cordiales,

Atte.

Fernando.



"Fernando Mosquera Catarecha" wrote in message
news:OAT$

Buenos días a todos!



Se me planteo la siguiente problemática:



Como es sabido, cuando un usuario crea una tabla temporal local (con el
signo '#') esta se almacena en el contendor TEMPDB de nuestro motor de
SQL. Hasta que el usuario no realiza un DROP de la misma o no cierra la
conexión dicha tabla no es eliminada.



Ahora bien:



Como puedo eliminar dicha tabla?

Como puedo realizarle un SELECT de la misma?

Como puedo saber que conexión la esta manteniendo?



Realice toda clase de pruebas / scripts involucrando el object id,
name, tablas del sistema, etc. y no puede obtener resultados positivo.



No puedo concebir que siendo sysadmin no pueda tener gestión sobre
dichas tablas.



Si alguien ya se planteo esta problemática o tiene una solución que yo
ignoro le agradecería que conteste el Post.



Saludos Cordiales,

Atte.

Fernando.