Tablas temporales o virtuales...

Sip, es cierto!! esto hace crecer la Tempdb y podria traer problemas si se
hace un uso abusivo de ellas.


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


"Kno" escribió en el mensaje
news:

¿Es cierto que el uso de tablas virtuales, es decir, aquellas definidas
con
#tabla, pueden afectar la performance del servidor de base de datos?, esto
porque tengo una aplicación que utiliza un procedimiento almacenado que
ocupa
este tipo de tablas (3 especificamente), y el nivel de consulta es alto
(alrededor de 10000 consultas al día).

Atte.
KNO

Las tablas temporales de todas las bases de datos se crean siempre en la
base de datos de sistema TempDb. Por tanto e sun potencial cuello de botella
para tu servidor SQL. Debe evitarse al mínimo el uso de tablas temporales,
intenta sustituirlas por variables de tipo TABLE.

Gustavo Larriera
Uruguay LatAm
Blog: http://sqljunkies.com/weblog/gux/
MVP profile: http://aspnet2.com/mvp.ashx?GustavoLarriera
Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga ningun
derecho / This posting is provided "AS IS" with no warranties, and confers
no rights.

"Kno" wrote in message
news:

¿Es cierto que el uso de tablas virtuales, es decir, aquellas definidas
con
#tabla, pueden afectar la performance del servidor de base de datos?, esto
porque tengo una aplicación que utiliza un procedimiento almacenado que
ocupa
este tipo de tablas (3 especificamente), y el nivel de consulta es alto
(alrededor de 10000 consultas al día).

Atte.
KNO

ya que tocaron este tema Yo tambien estuve probando las Tablas Temporales y las Variables
Tipo Table y me doy con la sorpresa que cuando son mas 1,000 registros las variables tipo
tables son mas lentras que las tablas temporales. alguien sabe del porque sucede esto??

Nota.
Servidor Win2003 Server
Memoria 1gb
Disco duro 80Gb scsi
Sql2000 Std


Gustavo Larriera [MVP] escribió:

Las tablas temporales de todas las bases de datos se crean siempre en la
base de datos de sistema TempDb. Por tanto e sun potencial cuello de botella
para tu servidor SQL. Debe evitarse al mínimo el uso de tablas temporales,
intenta sustituirlas por variables de tipo TABLE.

Posiblemente necesitas más memoria.

Difícil opinar sin conocer los detalles de la aplicación específica que
estás probando, aunque no creo que haya una regla universal del tipo
"después de X registros las variables TABLE tienen peor rendimiento que las
tablas temporales". Depende del escenario de trabajo que tengas.

Gustavo Larriera
Uruguay LatAm
Blog: http://sqljunkies.com/weblog/gux/
MVP profile: http://aspnet2.com/mvp.ashx?GustavoLarriera
Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga ningun
derecho / This posting is provided "AS IS" with no warranties, and confers
no rights.

"Developers" wrote in message
news:

ya que tocaron este tema Yo tambien estuve probando las Tablas Temporales
y las Variables Tipo Table y me doy con la sorpresa que cuando son mas
1,000 registros las variables tipo tables son mas lentras que las tablas
temporales. alguien sabe del porque sucede esto??

Nota.
Servidor Win2003 Server
Memoria 1gb
Disco duro 80Gb scsi
Sql2000 Std


Gustavo Larriera [MVP] escribió:

Las tablas temporales de todas las bases de datos se crean siempre en la
base de datos de sistema TempDb. Por tanto e sun potencial cuello de
botella para tu servidor SQL. Debe evitarse al mínimo el uso de tablas
temporales, intenta sustituirlas por variables de tipo TABLE.

Si las tablas son muy grandes es mejor usar tablas temporales, ya que una
característica de las variables tipo tabla es que no guardan estadísticas
que son necesarias para obtener un plan de ejecución eficiente.

Revisa
INF: Frequently Asked Questions - SQL Server 2000 - Table Variables
http://support.microsoft.com/kb/305977/en-us

Saludos,
Ulises


Kno wrote:

¿Es cierto que el uso de tablas virtuales, es decir, aquellas definidas
con
#tabla, pueden afectar la performance del servidor de base de datos?, esto
porque tengo una aplicación que utiliza un procedimiento almacenado que
ocupa este tipo de tablas (3 especificamente), y el nivel de consulta es
alto (alrededor de 10000 consultas al día).

Atte.
KNO