У меня слишком много вторичных файлов данных (.ndf), созданных для tempdb. Чтобы удалить лишние файлы, мне нужно очистить файл (содержимое будет перемещено в другие файлы):
DBCC SHRINKFILE('tempdbfile8', EMPTYFILE);а затем удалите файл:
ALTER DATABASE tempdb REMOVE FILE tempdbfile8;Но EMPTYFILEкоманда возвращает ошибку:
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.
Не волнуйтесь, мне просто нужно найти объект, который использует эту страницу, чтобы что-то с этим сделать:
DBCC TRACEON (3604)
DBCC PAGE(2,8,41920) --dbid=2, fileid=8, pageid=41920
Команда возвращает много информации, в том числе object_id. Но:
Metadata: ObjectId = 0 Я понятия не имею, что с этим делать. Какая кошка мешает перемещению этой страницы? Как найти этот объект, процесс, сессию или что-то еще? Любая помощь будет принята с благодарностью, но, пожалуйста, обратите внимание, что оставить все как есть или удалить другой файл вместо этого не является правильным решением этой проблемы;).
РЕДАКТИРОВАТЬ:
Я удаляю файлы, потому что мы следовали «лучшей практике» создания одного файла на ядро процессора (тот же начальный размер, та же скорость роста). Но, насколько мне известно, до тех пор, пока вы не столкнетесь с проблемами конкуренции, нет смысла создавать дополнительные файлы tempdb на одном устройстве. В нашем случае это имеет смысл, потому что у нас включен MPIO , и устройство хранения может обрабатывать 4 пути. Но произошла ошибка, и мы получили всего 5 файлов с 6-ядерным процессором. Это больше, чем пути MPIO, меньше, чем ядра процессора, и это не четное число. Это может не вызывать никаких проблем, но просто не кажется правильным :).
Я наконец смог очистить и удалить файл без перезапуска сервера, установив одну из баз данных (которую я подозревал в возникновении проблемы) в однопользовательский режим (немедленный откат). Это сработало, но мне повезло. Что я действительно хочу, так это всегда быть в состоянии отследить страницу :).
источник
dbcc page ( {'dbname' | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])О вашем решении: оно будет работать, но я бы очень хотел сделать это, не останавливая экземпляр.Ответы:
Перезапуска сервера должно быть достаточно - эти рабочие столы должны очиститься. Но я бы, вероятно, запустил его в однопользовательском режиме (-m), чтобы другие процессы не могли создавать рабочие таблицы до того, как вы успешно удалите эти файлы. Затем переопределите файлы, необходимые для
tempdb; возможно удаление ненужных файлов, изменение размеров и т. д. Вы также должны убедиться, что у вас есть четное количество файлов, что все они имеют одинаковый размер и имеют одинаковые параметры автоматического роста (в МБ, а не в%). И это может быть хорошее время для рассмотрения TF 1117 и TF 1118 ( отправная точка ).Я бы очень осторожно отнесся к предложению просто удалить файлы из файловой системы перед повторным запуском SQL Server - он может вообще не запуститься.
(Мне также было бы любопытно узнать, в чем проблема на самом деле. На самом деле, слишком много файлов не повредит вам.)
источник
https://social.msdn.microsoft.com/Forums/en-US/2a00c314-f35e-4900-babb-f42dcde1944b/dbcc-shrinkfile-page-411283400-could-not-be-moved-because-it-is- а-рабочий стол-страница? форум = sqldatabaseengine
Как предложил Майк на форуме msdn, рабочие таблицы в основном связаны с кэшем плана. Очистка их также приведет к удалению рабочего стола, а затем вы можете уменьшить Tempdb. Это сработало для меня. И это спасает вас от перезагрузки сервера. Это приведет к некоторым накладным расходам, поскольку SQL-серверу придется заново создавать планы выполнения.
источник