Rendimiento BD

Hola,
después de mirar e investigar por todos lados hasta estar seguro he reducido
el tamaño del archivo de transacciones con tal como ponía en
http://www.helpdna.net/bosqlfaq01.htm
Ahora queda lo demás, ¿algún consejo?
Gracias
Un saludo

Hola Miguel:
Sobre la TempDb, te puedo decir que es la BD del servidor de SQL, o se
un area de trabajo. Normalmente van ahi: Tablas Temporales, Cursores,
Consultas(grandes) ordenadas en sobre columnas sin indice, joins entre
Tablas(Grandes) con columnas sin indice, "Tablas Temporales" para Indexar
(CREATE INDEX) o Reindexar, algunos DBCC's , etc.
Cada vez que reinicias el servidor se reinicia TempDB, pero por supuesto
si estas operaciones se repiten vuelve a crecer la BD. Puedes reducirla sin
necesidad de reiniciar el servidor con un SHRINK desde el administrador
coporativo.
Finalmente te quedan dos alternativas:
a) Solucionar el Problema: Buscando cuales actividades te producen el BD
grande. Facil de decir, dificil de hacer.
b) Minimizando el Problema: Poniendo TempDB en su propio disco o arreglo
de discos (separado del resto de las BD). $$$ :)
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.
Miguel Tubía escribio:

Hola,
sé q este es un tema q se ha tratado mucho últimamente, solo quería
aclarar algunos conceptos. Expongo mi caso. Tengo dos BBDD con los
mismos problemas: la tempdb se dispara de tamaño, los registros de
transacciones ocu`pan en mi entender demasiado y los registros de sql
server, creo q hay demasiados. Ahora bien, ¿cuánto es lo normal que
debería ocupar un registro de transacciones? En una web he leído como
se puede reducir. ¿Se puede hacer sin parar la bd? ¿Es peligroso? ¿Se
pueden perder datos?
Sobre los registros de sql server, los q están en el submenú de
administración, ¿cómo se pueden eliminar o reducir? Lo he limitado a
6, el mínimo, pero aún así considero q ocupan demasiado... Me pone
cifras de 9756569 Bytes, 6451080 Bytes, etc. Creo q es bastante, pero
igual es lo normal... Y sobre la tempdb, q me trae loco Una vez
me dijeron en este foro q se vacía reiniciando la bd. ¿No hay otra
forma? Tb me dijeron q mirara q contiene esa bd para ver de donde
venía el problema. Lo malo q ya la había reiniciado, pero en poco
tiempo se ha vuelto a poner por las nubes. Ahora, ¿dónde puedo mirar?
He echado un ojo pero es un galimatias... ¿Cómo se puede evitar q
crezca tanto? ¿Q conclusiones y de q datos puedo sacar? Creo q pido
mucho... si alguien sabe ayudarme con algo de información le estaré
muy agradecido...
Muchas gracias por todo
un saludo

Hola Javier,
muchas gracias por tu respuesta.
El problema es que se trabaja sobre la BD desde una aplicación a terceros,
en la q usan DAO y apenas unos poco proc. almacenados por si puede influir,
y si en ella hacen una consulta grande, no la puedo cambiar para nada. En
ese caso, ¿cómo lo puedo arreglar? ¿o tengo q aguantarme y chupar del bote,
como dicen?
Muchas gracias por tu ayuda
Un saludo

Te copio un artículo acerca de TempDB como un extra al comentario de
Javier. Está en inglés, pero creo que se entiende bien:

*********************************************************************

* IS YOUR TEMPDB STRESSED OUT?
(contributed by Brian Moran, news editor, )

Most SQL Server customers use tempdb a lot. But you might not realize that
heavy use of tempdb can cause resource-allocation contention and result in
potentially serious performance problems. I recently ran across a Microsoft
Knowledge Base article that describes potential problems with tempdb that I
hadn't been unaware of. Coincidentally, this information has helped some of
my clients in the past several weeks, and it might be relevant to your
environment.

I recently investigated a performance problem that my client and I suspected
was related to creating a large number of objects in tempdb. When the
client's site was busy, it created tens of thousands of tables in tempdb in
a short amount of time. There's nothing inherently wrong with an
architecture that relies heavily on the creation of tables in tempdb, but
the site showed an increasing number of locks and latches while response
time and throughput began to drop. I won't bore you with all the
troubleshooting we did, but we eventually stumbled across a Microsoft
article that proved to be surprisingly helpful, "FIX: Concurrency
Enhancements for the Tempdb Database"
( http://support.microsoft.com/defaul...-us;328551 ).

This article describes how the page-free space, Secondary Global Allocation
Map (SGAM), and Index Allocation Map (IAM) pages can become tempdb hotspots
when you quickly create many objects in tempdb or delete them from tempdb.
Potential problem operations include tempdb activity associated with the
following:
- Repeated creation and dropping of temporary tables (local or global)
- Using table variables that use tempdb for storage
- Using work tables associated with cursors
- Using work tables associated with an ORDER BY clause
- Using work tables associated with a GROUP BY clause
- Using work files associated with hash plans

The article offers three solutions for avoiding this potential tempdb
bottleneck: a hotfix, a trace flag that reduces mixed-extent allocation for
small objects, and a recommendation to increase the number of files in
tempdb. Increasing the number of files in tempdb, even if they're all on the
same disk, helps minimize contention on the SGAM because each tempdb file
has its own SGAM. Microsoft expects to include the hotfix in SQL Server 2000
Service Pack 4 (SP4), but I don't recommend applying it without
experimenting with the trace flag and tempdb file-management changes, which
are less intrusive. (Covering SGAMs, mixed extents, and other issues is
beyond the scope of this commentary. But Kalen Delaney's "Inside SQL Server"
column in SQL Server Magazine is an excellent source for this kind of SQL
Server internals information.)

I suspect that this tempdb bottleneck is more common than Microsoft
realizes. Although I discovered the Microsoft article about the tempdb
problems just recently, I've seen this type of problem affect several
customers and read multiple newsgroup postings that describe similar
symptoms associated with heavy use of tempdb. Without the information in
this Knowledge Base article, many customers might have chalked up most of
their tuning problems to "ghosts in the machine" and would have had a
difficult time troubleshooting--if they could discover the problem at all.
If you think tempdb is slowing down your system, check out this article.

*********************************************************************


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)
MVP SQL Server
Por favor, responder únicamente al foro
Se agradece la inclusión de sentencias DDL


"Javier Loria" escribió en el mensaje
news:#

Hola Miguel:
Sobre la TempDb, te puedo decir que es la BD del servidor de SQL, o se
un area de trabajo. Normalmente van ahi: Tablas Temporales, Cursores,
Consultas(grandes) ordenadas en sobre columnas sin indice, joins entre
Tablas(Grandes) con columnas sin indice, "Tablas Temporales" para Indexar
(CREATE INDEX) o Reindexar, algunos DBCC's , etc.
Cada vez que reinicias el servidor se reinicia TempDB, pero por

supuesto

si estas operaciones se repiten vuelve a crecer la BD. Puedes reducirla

sin

necesidad de reiniciar el servidor con un SHRINK desde el administrador
coporativo.
Finalmente te quedan dos alternativas:
a) Solucionar el Problema: Buscando cuales actividades te producen el

BD

grande. Facil de decir, dificil de hacer.
b) Minimizando el Problema: Poniendo TempDB en su propio disco o

arreglo

de discos (separado del resto de las BD). $$$ :)
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.
Miguel Tubía escribio:
> Hola,
> sé q este es un tema q se ha tratado mucho últimamente, solo quería
> aclarar algunos conceptos. Expongo mi caso. Tengo dos BBDD con los
> mismos problemas: la tempdb se dispara de tamaño, los registros de
> transacciones ocu`pan en mi entender demasiado y los registros de sql
> server, creo q hay demasiados. Ahora bien, ¿cuánto es lo normal que
> debería ocupar un registro de transacciones? En una web he leído como
> se puede reducir. ¿Se puede hacer sin parar la bd? ¿Es peligroso? ¿Se
> pueden perder datos?
> Sobre los registros de sql server, los q están en el submenú de
> administración, ¿cómo se pueden eliminar o reducir? Lo he limitado a
> 6, el mínimo, pero aún así considero q ocupan demasiado... Me pone
> cifras de 9756569 Bytes, 6451080 Bytes, etc. Creo q es bastante, pero
> igual es lo normal... Y sobre la tempdb, q me trae loco Una vez
> me dijeron en este foro q se vacía reiniciando la bd. ¿No hay otra
> forma? Tb me dijeron q mirara q contiene esa bd para ver de donde
> venía el problema. Lo malo q ya la había reiniciado, pero en poco
> tiempo se ha vuelto a poner por las nubes. Ahora, ¿dónde puedo mirar?
> He echado un ojo pero es un galimatias... ¿Cómo se puede evitar q
> crezca tanto? ¿Q conclusiones y de q datos puedo sacar? Creo q pido
> mucho... si alguien sabe ayudarme con algo de información le estaré
> muy agradecido...
> Muchas gracias por todo
> un saludo

Hola Miguel:
Creo que algun Anti-Acido te va a caer bien.
No te veo alternativa, excepto tal vez puedes comprar discos
independientes solo para TempDb; de preferencia varios, no tienen que ser
grandes solo muchos:), si puedes darle algun arrego 0 o 1+0 mejor.
No le recortes el tamano, sino mas bien fijala lo suficientemente grande
como para que no se requieran aumentos. No la fijes en AUTO_SHRINK.
Suerte,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Miguel Tubía escribio:

Hola Javier,
muchas gracias por tu respuesta.
El problema es que se trabaja sobre la BD desde una aplicación a
terceros, en la q usan DAO y apenas unos poco proc. almacenados por
si puede influir, y si en ella hacen una consulta grande, no la puedo
cambiar para nada. En ese caso, ¿cómo lo puedo arreglar? ¿o tengo q
aguantarme y chupar del bote, como dicen?
Muchas gracias por tu ayuda
Un saludo