2009-07-13 7 views
2

Nous avons un environnement de production SQL Server 2000 où tout à coup (les 3 derniers jours) quelque chose a fait grandir le fichier de données tempdb (45 concerts avec une base de données de seulement 10 concerts). Hier, après que cela soit arrivé à nouveau, nous avons réduit la base de données et avons exécuté les principaux traitements par lots individuellement sans aucun problème. Cependant, ce matin, la base de données était de retour à 45 concerts.Sql Server 2000 - tempdb en croissance très grande

Existe-t-il un moyen simple de savoir ce qui fait que cette base de données prend de l'ampleur? Idéalement, quelque chose qui pourrait être regardé aujourd'hui, mais si ce n'est pas disponible quelque chose qui peut être réglé pour obtenir cette information demain.

BTW: La réduction de la base de données récupère l'espace en quelques secondes.

+2

Cela ressemble à une question de serveur de coffre-fort ... mais vous voudrez peut-être consulter Sql Profiler. –

Répondre

2

D'accord avec Jimmy, vous devez utiliser SQL Profiler pour trouver les objets temporaires créés de manière intensive. Cela peut être des tables temporaires qui utilisent des rapports ou quelque chose comme ça.

+0

Je configurerais des traces de profileur pour exécuter toute la nuit suivi des événements probables: suivre tout ce qui a pris plus de 10 secondes à courir, tout ce qui génère plus de 1M de données, tout ce qui génère plus de 1M d'écritures (ce serait trois traces séparées). C'est difficile à dire, beaucoup dépend de votre environnement et de votre système; Le suivi de ces tâches peut prendre beaucoup de temps (puisque vous ne pouvez courir qu'une nuit et vérifier le jour suivant). Puisque c'est tempdb, c'est probablement une seule grande action, et pas un tas de petits gars (sauf si vous avez déclaré des transactions). –

0

avez-vous un travail en cours d'exécution qui reconstruit l'index? Il est possible qu'il utilise SORT_IN_TEMPDB

ou tout autre grandes questions qui ne pourraient étendre le tri tempdb

0

Cela peut avoir quelque chose à voir avec le modèle de récupération que le TempDB est réglé sur. Il peut être réglé sur FULL au lieu de BULK-LOGGED. La récupération complète augmente la taille du journal des transactions jusqu'à ce qu'une sauvegarde soit effectuée.

Examinez la taille du fichier de données par rapport à la taille du journal des transactions.

0

Je ne suis pas un DBA mais quelques réflexions:

  • Est-il possible qu'il y ait température tables créées, mais pas abandonné? ##tempTable?
  • Est-il possible que existe une grande table temporaire créée (et supprimée) mais l'espace n'est pas récupéré?
  • Effectuez-vous une sorte de chargement en vrac où le système peut utiliser la table temporaire? (Je ne suis pas sûr si vous le pouvez) mais pouvez-vous allumer Auto-Shrink pour le tempdb?
1

Je tenais à remercier tout le monde pour leurs réponses car elles ont définitivement mené à la cause du problème.

Nous avons activé le profileur SQL et une charge en masse importante s'est manifestée. Comme nous travaillons sur un projet pour déplacer le travail "offensant" pour travailler aussi dans mysql nous allons probablement juste regarder les choses pour le moment.

Questions connexes