Suppression des fichiers de données secondaires. DBCC SHRINKFILE: la page n'a pas pu être déplacée car il s'agit d'une page de table de travail

J'ai trop de fichiers de données secondaires (.ndf) créés pour tempdb. Pour supprimer les fichiers excédentaires, je dois vider le fichier (le contenu sera déplacé vers d'autres fichiers):

DBCC SHRINKFILE('tempdbfile8', EMPTYFILE);

puis supprimez le fichier:

ALTER DATABASE tempdb REMOVE FILE tempdbfile8;

Mais la EMPTYFILEcommande renvoie l'erreur:

DBCC SHRINKFILE: Page 8:41920 could not be moved because it is a work table page.
Msg 2555, Level 16, State 1, Line 2
Cannot move all contents of file "tempdbfile8" to other places to complete the emptyfile operation.

Ne vous inquiétez pas, il me suffit de localiser l'objet qui utilise cette page pour y remédier:

DBCC TRACEON (3604)
DBCC PAGE(2,8,41920) --dbid=2, fileid=8, pageid=41920

La commande renvoie de nombreuses informations, parmi lesquelles object_id. Mais:

Metadata: ObjectId = 0

Je ne sais pas quoi faire à ce sujet. Quel chat empêche cette page d'être déplacée? Comment localiser cet objet, ce processus, cette session ou quoi que ce soit? Toute aide sera appréciée, mais veuillez noter que tout laisser tel quel ou supprimer un autre fichier à la place n'est pas une solution valide à ce problème;).

ÉDITER:

Je supprime les fichiers, car nous avions l'habitude de suivre la "meilleure pratique" de création d'un fichier par cœur de processeur (même taille initiale, même taux de croissance). Mais pour autant que je sache, tant que vous ne rencontrez pas de problèmes de contention, il est inutile de créer des fichiers tempdb supplémentaires sur le même appareil. Dans notre cas, cela a du sens, car nous avons MPIO activé et le périphérique de stockage peut gérer 4 chemins. Mais il y a eu une erreur et nous nous sommes retrouvés avec un total de 5 fichiers avec un processeur à 6 cœurs. C'est plus que des chemins MPIO, moins que des cœurs de CPU, et ce n'est pas un nombre pair. Cela peut ne causer aucun problème, mais ne semble pas correct :).

J'ai finalement pu vider et supprimer le fichier sans redémarrer le serveur en définissant l'une des bases de données (que je soupçonnais de provoquer le problème) en mode mono-utilisateur (restauration immédiate). Cela a fonctionné, mais j'ai eu de la chance. Ce que je veux vraiment, c'est être toujours en mesure de retrouver la page :).

— Adam Luniewski
source

La commande DBCC PAGE n'est pas correcte, elle devrait ressembler à la page dbcc (2,41920,1). 1,2,3 dépend de ce que vous voulez en sortie.

— Shanky

Si ci-dessus ne fonctionne pas, vous devrez peut-être le faire dans le matériel en supprimant les fichiers, puis en redémarrant le serveur SQL afin qu'il utilise uniquement les fichiers qui n'ont pas été supprimés. Pouvez - vous référer à ce lien daveturpin.com/2011/07/how-to-drop-a-tempdb-database-file

— Shanky

@Shanky La commande est correcte. 0..3 peut être passé comme 4ème paramètre: A dbcc page ( {'dbname' | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])propos de votre solution: cela fonctionnerait, mais j'aimerais vraiment le faire sans arrêter l'instance.

— Adam Luniewski

Ok. Je vous disais une forme plus simple de page dbcc. Veuillez noter qu'il s'agit d'une commande non documentée. Avez-vous vérifié le lien que j'ai publié

— Shanky

Je ne pense pas qu'il soit possible de résoudre ce problème sans redémarrer l'instance. De toute évidence, vous avez essayé de retrouver ce qu'est cette table de travail (ce qui aiderait à déterminer à qui elle appartient), et cela a échoué. Prenez le coup, ou vivez avec les fichiers supplémentaires jusqu'à ce que vous puissiez redémarrer.

— Aaron Bertrand

Réponses:

Le redémarrage du serveur devrait être suffisant - ces tables de travail devraient disparaître. Mais je le lancerais probablement en mode mono-utilisateur (-m) pour empêcher d'autres processus de créer des tables de travail avant de supprimer correctement ces fichiers. Redéfinissez ensuite les fichiers requis pour tempdb; peut-être la suppression de fichiers inutiles, la modification des tailles, etc. Vous devez également vous assurer que vous disposez d'un nombre pair de fichiers, qu'ils sont tous définis à la même taille et qu'ils ont tous les mêmes paramètres de croissance automatique (en Mo, pas en%). Et ce pourrait être un bon moment pour considérer TF 1117 et TF 1118 également ( point de départ ).

Je serais très méfiant à propos de la suggestion de simplement supprimer les fichiers du système de fichiers avant de redémarrer SQL Server - cela pourrait ne pas démarrer du tout.

(Je serais également curieux de savoir quel est le problème réel, cependant. Avoir trop de fichiers ne vous fait pas vraiment de mal.)

— Aaron Bertrand
source

@@ Aaron ofcourse, vous devez être prudent quant à sa suppression doit être vide, mais cela est documenté ici msdn.microsoft.com/en-gb/library/ms175574.aspx . Je l'ai essayé et SQl Server tempdb est en ligne.

— Shanky

@Shanky, j'ai essayé de rouler 138 milles à l'heure une fois, et je n'ai pas été arrêté. Est-ce à dire que je devrais continuer à le faire et qu'il n'y a aucune chance que je me fasse arrêter demain? Il est beaucoup plus sûr d'essayer d' abord correctement , avant de suggérer un moyen plus risqué. A MON HUMBLE AVIS. D'autant plus qu'il ne peut pas vider le fichier maintenant - pensez-vous qu'il est possible qu'il y ait autre chose en dehors de la table de travail dont le message d'erreur se plaint? L'erreur ne produit pas une liste exhaustive de tous les objets, elle ne produit que le premier objet.

— Aaron Bertrand

Il y a quelque chose qui utilise réellement tempdb, donc il ne lui permet pas de vider le fichier, c'est difficile à deviner. Qu'il utilise l'opérateur de tri est une requête qui a encore besoin de tempdb. DMV peut vous aider à trouver sys.dm_db_task_space_usage sys.dm_db_session_space_usage sys.dm_db_file_space_usage

— Shanky

Le redémarrage est une option ici, mais même s'il ne vide pas le fichier et n'essaie pas de supprimer le fichier tempdb, il dirait que le fichier tempdb ne peut pas être supprimé mais en même temps le catalogue système est mis à jour et après redémarrage, le fichier disparaîtra. Ceci est, je suppose, un comportement par défaut avec tempdb, j'ai donc suggéré et pense toujours que la suppression du fichier de données fonctionnerait même s'il est utilisé. La même chose est là dans le lien que j'ai posté dans mon deuxième commentaire.

— Shanky

@Shanky, ces DMV pourraient renvoyer des milliers de lignes pour toutes sortes de choses qui n'ont rien à voir avec le fichier en question - alors comment prévoyez-vous de le réduire? De plus, avec votre méthode, vous devez également redémarrer, pourquoi ne pas d'abord essayer la méthode la plus simple? Je ne suis tout simplement pas d'accord avec vous que "la voie difficile" devrait être la première suggestion, désolé.

— Aaron Bertrand

https://social.msdn.microsoft.com/Forums/en-US/2a00c314-f35e-4900-babb-f42dcde1944b/dbcc-shrinkfile-page-411283400-could-not-be-moved-because-it-is- une-table-de-travail-page? forum = sqldatabaseengine

Comme proposé par Mike dans le forum msdn, les tables de travail sont principalement associées au cache de plan. Les effacer supprimerait également la table de travail et vous pourriez alors réduire Tempdb. Cela a fonctionné pour moi. Et cela vous évite également un redémarrage du serveur. Il y aura des frais généraux car le serveur SQL devra recréer des plans d'exécution à nouveau.

— sajeesh
source