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 commande EMPTYFILE 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, j'ai juste besoin 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 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 pas causer de problèmes, mais ne semble pas correct :).
J'ai finalement pu vider et supprimer le fichier sans redémarrer le serveur en mettant 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 :).
Le redémarrage du serveur devrait être suffisant - ces tables de travail devraient disparaître. Mais je voudrais probablement le démarrer 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 également TF 1117 et TF 1118 ( 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.)
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.