TempDB ne rétrécira pas. Aucune transaction ouverte

J'ai un TempDB sur SQL 2008 qui est devenu très volumineux (> 40 Go) et je veux le réduire. J'ai utilisé la base de données dbcc shrinkdatabase, dbcc shrinkfile et la commande shrink via Management Studio.

J'obtiens l'erreur suivante:

Page 1: 4573184 n'a pas pu être déplacé car il s'agit d'une page de table de travail.

J'ai pu récupérer de l'espace pour me mettre hors de danger en exécutant DBCC FREEPROCCACHE et en réexécutant l'une des routines de rétrécissement, mais évidemment ce n'est pas idéal et cela ne fera probablement que me gagner un peu de temps.

J'ai exécuté DBCC OpenTran et il n'y a rien qui traîne là-bas.

Partout où j'ai lu sur Internet se résume au recyclage de SQL Server ... il doit sûrement y avoir une meilleure façon ... n'importe qui?

Merci,

À M

sql-server-2008 tempdb shrink

— user45117
source

Remarque: ce message peut également être utile:

Les problèmes avec le fichier mdf TempDB ne cessent d'augmenter

À moins que vous puissiez comprendre quel processus utilise cette table de travail (et peut le tuer en toute sécurité), je serais d'accord avec ce que vos recherches ont déjà produit: faites un cycle sur le serveur et vous devriez pouvoir réduire tempdb.

Une autre question a trait à la détermination de cela pour les tables #temp; Je ne sais pas s'il peut être adapté aux tables de travail:

Rechercher quelle session contient quelle table temporaire

J'ai également blogué à ce sujet (encore une fois, pour les tables #temp):

http://sqlperformance.com/2014/05/t-sql-queries/dude-who-owns-that-temp-table

Je doute que la table de travail soit liée au magasin d'isolement / version d'instantané, mais juste au cas où:

Rechercher les transactions qui remplissent le magasin de versions

Ne vous fiez pas non plus à DBCC OPENTRAN;- j'ai observé de nombreux scénarios où je sais que j'ai une transaction active mais qu'elle n'apparaît pas là-bas. Et notez que le contexte de la base de données est important; la base de données où la transaction est active n'est pas nécessairement tempdb. Que voyez-vous ici? N'importe quoi?

SELECT * FROM sys.dm_tran_active_transactions
  WHERE name = N'worktable';

Une fois que vous avez réduit tempdb

Bien sûr, ce n'est pas une solution permanente. Vous allez réduire tempdb, puis ça va encore augmenter. Cela peut devenir très ennuyeux et fastidieux de jouer à ce jeu chaque fois que cela se produit. Et si ça va encore grandir, qu'allez-vous faire avec cet espace libre en attendant? Louez-le et puis expulser les gens quand tempdb en a encore besoin? Vous devez soit:

Corrigez le processus qui fait que tempdb grandit anormalement en premier lieu.
Allouez suffisamment d'espace pour tempdb afin qu'il n'ait pas besoin de croître, et arrêtez de le réduire (surtout si ce n'est que temporairement; c'est juste du travail gaspillé!).

Quelques autres suggestions:

N'utilisez pas SHRINKDATABASE(qui devrait être appelé auto-fragment) ou l'interface utilisateur. Écrivez des SHRINKFILEcommandes spécifiques et ciblées pour affecter des fichiers individuels.
Envisagez d'utiliser plusieurs fichiers pour tempdb (que vous pourriez répartir sur un stockage différent si / lorsque cela est possible), et envisagez les indicateurs de trace 1117 (tant que ce comportement n'affectera pas également vos bases de données utilisateur) et 1118.
Quelques conseils pour minimiser l'utilisation de tempdb ici:
- Comment identifier quelle requête remplit le journal des transactions tempdb?

— Aaron Bertrand
source

SELECT * FROM sys.dm_tran_active_transactions WHERE name = N'worktable '; renvoie 6 lignes toutes de la même date (7/10/14). Est-ce que transaction_id représente le SPID?

— user45117

Non, transaction_id n'est pas SPID. Si les transactions sont vraiment actives (et ce ne sont pas des transactions système ), vous devriez être en mesure de les faire correspondre à un session_id dans sys.dm_tran_session_transactions. Dans tous les cas, êtes-vous sûr que c'est le message que vous recevez de DBCC SHRINKFILE? Qu'en est-il de ALTER DATABASE ... MODIFY FILE? Je ne suis pas sûr non plus de comprendre pourquoi l'effacement du cache de procédure vous a évité des ennuis; procédure cache est en mémoire, pas dans tempdb ...

— Aaron Bertrand

Le message est venu de DBCC SHRINKDATABASE. Je n'ai pas essayé la ALTER DATABASE ... MODIFY FILE ... qui sera la prochaine. L'effacement du cache de procédure a permis de réduire la tempdb d'environ 10% et m'a redonné 4 Go d'espace disque. Je n'ai pas pu lier ces transaction_id de sys.dm_tran_active_transactions à quoi que ce soit dans sys.dm_tran_session_transactions

— user45117

Je pense que vider le cache de la procédure était moins lié à "permettre" à tempdb de rétrécir que vous ne le pensez. Les coïncidences se produisent tout le temps.

— Aaron Bertrand

Partout où j'ai lu sur Internet se résume au recyclage de SQL Server ... il doit sûrement y avoir une meilleure façon ... n'importe qui?

Non, c'est une solution temporaire. Je suppose que vous avez posté la même question avant pourriez-vous s'il vous plaît indiquer quelle est la taille totale de la base de données que vous avez dans votre instance SQL Server. La taille de tempdb dépend de la quantité d'utilisation de vos requêtes. Il ne peut croître de lui-même que si vous l'utilisez. Les liens partagés par Aron seraient utiles, mais vous devez régler les requêtes si elles utilisent beaucoup temdbb ou si c'est la condition par défaut de votre environnement. J'ai vu peu d'env. où 200 G de tempdb étaient acceptables car les requêtes nécessitaient autant d'espace tempdb.

— Shanky
source