web-dev-qa-db-fra.com

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-2008tempdbshrink
9
user45117

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:

Trouver 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

Aussi, ne comptez pas sur 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 de cet espace libre en attendant? Louez-le et puis expulser les gens quand tempdb en a encore besoin? Vous devez soit:

  1. Corrigez le processus qui fait que tempdb grandit anormalement en premier lieu.
  2. 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 commandes SHRINKFILE 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 trop vos bases de données utilisateur) et 1118.
  • Quelques conseils pour minimiser l'utilisation de tempdb ici:
7
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 fortement 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.

0
Shanky