Видалення вторинних файлів даних. DBCC SHRINKFILE: Сторінку неможливо перемістити, оскільки це сторінка робочого столу

У мене занадто багато файлів вторинних даних (.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, менше, ніж ядра CPU, і це не парне число. Це може не спричинити жодних проблем, але просто не здається правильним :).

Нарешті я зміг спорожнити та видалити файл, не перезавантажуючи сервер, встановивши одну з баз даних (на яку я підозрював, що викликала проблему) в єдиний користувальницький режим (негайний відкат). Це спрацювало, але мені пощастило. Те, що я дуже хочу, - це завжди мати можливість відслідковувати сторінку :).

— Адам Лунєвський
джерело

Команда DBCC PAGE невірна, вона повинна бути схожою на сторінку dbcc (2,41920,1). 1,2,3 залежить від того, що ви хочете у виході.

— Шанкі

Якщо вище не працює, можливо, доведеться це зробити апаратно, видаливши файли та перезавантаживши сервер sql, щоб він просто використовував файли, які не були видалені. Ви можете посилатися на це посилання daveturpin.com/2011/07/how-to-drop-a-tempdb-database-file

— Shanky

@Shanky Команда правильна. 0..3 можна передати як 4-й параметр: dbcc page ( {'dbname' | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])Про ваше рішення: воно буде працювати, але я дуже хотів би зробити це, не збиваючи примірник.

— Адам Лунєвський

Добре .. Я розповідав вам простішу форму сторінки dbcc. Зверніть увагу на незадокументовану команду. Ви перевірили посилання, яке я опублікував

— Shanky

Я не думаю, що вирішити цю проблему неможливо без перезавантаження примірника. Очевидно, ви спробували відстежити, що це за робочий стіл (що допоможе визначити, хто йому належить), і це не вдалося. Візьміть удар або живіть із додатковими файлами, поки не зможете перезапустити.

— Аарон Бертран

Відповіді:

Перезавантаження сервера повинно бути достатньо - ці робочі таблиці повинні бути очищені. Але я, мабуть, запустив його в режимі одного користувача (-m), щоб запобігти іншим процесам створювати робочі таблиці, перш ніж успішно видалити ці файли. Потім перегляньте необхідні файли tempdb; можливо, видалення непотрібних файлів, зміна розмірів тощо. Ви також повинні переконатися, що ви маєте парну кількість файлів, що всі вони встановлені на один і той же розмір, і що всі вони мають однакові параметри автоматичного зростання (в МБ, не%). І може бути вдалий час, щоб також розглянути TF 1117 і TF 1118 ( вихідна точка ).

Я б дуже насторожено ставився до пропозиції просто видалити файли з файлової системи перед тим, як знову запустити SQL Server - він може не запуститися зовсім.

(Мені б також цікаво, в чому полягає справжня проблема. Наявність занадто багато файлів насправді не шкодить вам.)

— Аарон Бертран
джерело

@@ Аарон звичайно, вам потрібно бути обережними щодо його видалення, воно повинно бути порожнім, але це документально підтверджено тут msdn.microsoft.com/en-gb/library/ms175574.aspx . Спробували це, і tempdb сервера SQl з’являється в Інтернеті.

— Шанки

@Shanky Я намагався один раз проїхати 138 миль на годину, і мене не потягнуло. Це означає, що я повинен продовжувати це робити, і що немає жодного шансу, що мене завтра потягнуть? Набагато безпечніше спробувати спочатку правильний спосіб, перш ніж запропонувати більш ризикований спосіб. ІМХО. Тим більше, що він не може спорожнити файл зараз - чи вважаєте ви, що можливо, є ще щось, крім робочого столу, на яке скаржиться повідомлення про помилку? Помилка не дає вичерпного списку всіх об'єктів, вона виводить лише перший об'єкт.

— Аарон Бертран

Існує щось, що насправді використовує tempdb, тому воно не дозволяє порожньому файлу важко здогадатися. Може, він використовує оператор сортування - це якийсь запит, який ще потребує tempdb. DMV може допомогти в пошуку sys.dm_db_task_space_usage sys.dm_db_session_space_usage sys.dm_db_file_space_usage

— Shanky

Тут є варіант перезавантаження, але навіть якщо він не випорожнює файл і не намагається видалити файл tempdb, він би сказав, що файл tempdb не може бути скинутий, але в той же час системний каталог оновлюється і після перезавантаження файл не буде втрачено. Це, напевно, поведінка за замовчуванням з tempdb, тому я запропонував і все ще думаю, що видалення файлу даних буде працювати, навіть якщо він використовується. Те саме є за посиланням, яке я розмістив у своєму другому коментарі.

— Шенкі

@Shanky ці DMV можуть повернути тисячі рядків для всіляких речей, які не мають нічого спільного з відповідним файлом - так як ви плануєте його звузити? Крім того, оскільки зі своїм методом вам доведеться також перезапустити, чому б просто не спробувати спочатку простіший спосіб? Я просто не згоден з вами, що "важкий шлях" повинен бути першою пропозицією, вибачте.

— Аарон Бертран

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

Як запропонував Майк на форумі msdn, робочі таблиці в основному пов'язані з кешем плану. Очищення їх також видалить робочий стіл, і тоді ви можете зменшити Tempdb. Це працювало для мене. Це також заощаджує перезапуск сервера. Буде деякий накладні витрати, оскільки SQL-серверу доведеться знову відтворити плани виконання.

— sajeesh
джерело