TempDB не будет сокращаться. Нет открытых транзакций

У меня есть TempDB на SQL 2008, который стал очень большим (> 40 ГБ), и я хочу уменьшить его. Я использовал dbcc shrinkdatabase, dbcc shrinkfile и команду shrink через Management Studio.

Я получаю следующую ошибку:

Страница 1: 4573184 не может быть перемещена, потому что это страница рабочего стола.

Мне удалось освободить место, чтобы вытащить меня из опасности, запустив DBCC FREEPROCCACHE и повторно запустив одну из процедур сжатия, но, очевидно, это не идеально и, скорее всего, выиграет мне немного времени.

Я запустил DBCC OpenTran и там ничего не висит.

Все, что я читал в Интернете, сводится к переработке SQL Server ... наверняка должен быть лучший способ ... кто-нибудь?

Спасибо,

Том

Примечание: этот пост тоже может быть полезен:

Проблемы с файлом mDD TempDB постоянно увеличиваются

Если вы не можете выяснить, какой процесс использует эту рабочую таблицу (и может безопасно ее убить), мне придется согласиться с тем, что ваши поиски уже дали: зациклите сервер, и вы сможете уменьшить tempdb.

Другой вопрос касался выяснения этого для таблиц #temp; Я не знаю, может ли он быть адаптирован для рабочих столов:

Найти, какая сессия содержит какую временную таблицу

Я также написал об этом в блоге (опять же, для #temp таблиц):

http://sqlperformance.com/2014/05/t-sql-queries/dude-who-owns-that-temp-table

Я сомневаюсь, что рабочая таблица связана с изоляцией снимков / хранилищем версий, но на всякий случай:

Найти транзакции, которые заполняют хранилище версий

Кроме того, не надейтесь DBCC OPENTRAN;- я наблюдал много сценариев, когда я знаю, что у меня есть активная транзакция, но она там не отображается. И обратите внимание, что контекст базы данных важен; база данных, в которой активна транзакция, не обязательно является tempdb. Что ты здесь видишь? Что-нибудь?

SELECT * FROM sys.dm_tran_active_transactions
  WHERE name = N'worktable';

После того, как вы сократили tempdb

Конечно, это не постоянное решение. Вы собираетесь уменьшить tempdb, а затем он снова будет расти. Это может стать очень скучным и утомительным, чтобы играть в эту игру каждый раз, когда это происходит. И если он снова будет расти, что вы собираетесь делать с этим свободным пространством в это время? Сдать в аренду, а затем выселить людей, когда это понадобится tempdb? Вам нужно либо:

1. Исправьте процесс, который делает tempdb необычно большим в первую очередь.
2. Выделите достаточно места для базы данных tempdb, чтобы ее не нужно было увеличивать, и перестаньте сокращать ее (особенно если только временно; это просто напрасная работа!).

Пара других предложений:

• Не используйте SHRINKDATABASE(который должен называться автофрагментом) или пользовательский интерфейс. Написать конкретные, целевые SHRINKFILEкоманды, чтобы повлиять на отдельные файлы.
• Рассмотрите возможность использования нескольких файлов для базы данных tempdb (которую вы можете распространить в другое хранилище, если / когда это возможно), и рассмотрите флаги трассировки 1117 (при условии, что это поведение также не повлияет на ваши пользовательские базы данных) и 1118.
• Несколько советов по минимизации использования tempdb здесь:
  • Как определить, какой запрос заполняет журнал транзакций tempdb?

Все, что я читал в Интернете, сводится к переработке SQL Server ... наверняка должен быть лучший способ ... кто-нибудь?

Нет, это временное решение. Я предполагаю, что вы опубликовали тот же вопрос, прежде чем вы могли бы сказать, какой общий размер базы данных у вас в вашем экземпляре SQL Server. Размер tempdb зависит от того, насколько ваши запросы его используют. Он не может расти сам по себе, если вы не используете его. Ссылки, предоставленные Aron, могут помочь, но вам нужно настроить запросы, если они интенсивно используют temdbb или могут быть требованием по умолчанию вашей среды. Я видел немного env. где 200 ГБ базы данных tempdb были приемлемы, потому что запросы требовали такого большого количества пространства базы данных tempdb.