При работе с информационными системами на базе 1С:Предприятия, особенно с крупными конфигурациями, такими как 1С:ERP, системная база данных SQL Server под названием tempdb часто становится объектом пристального внимания системных администраторов. Ее размер может стремительно увеличиваться, занимая значительные объемы дискового пространства. В данном материале мы рассмотрим, почему это происходит, как можно автоматизировать уменьшение tempdb, и что более важно — как предотвратить ее неконтролируемый рост, вместо того чтобы постоянно бороться с его последствиями.
Прежде чем говорить об уменьшении, давайте разберемся, что такое tempdb и какова ее роль. tempdb – это системная база данных SQL Server, которая служит для хранения временных объектов и промежуточных результатов операций. Она используется как самим SQL Server, так и пользовательскими приложениями для различных целей:
ORDER BY), группировки (GROUP BY), агрегации, создания и перестроения индексов, а также для обработки сложных запросов с операторами UNION, DISTINCT, хеш-операций.tempdb. Любые виртуальные таблицы, например, таблицы остатков регистров, срезов последних или срезов первых, формируются с использованием tempdb. Передача больших массивов данных в качестве параметров запроса в 1С также неявно задействует tempdb.Основная причина увеличения размера tempdb кроется в том, что SQL Server автоматически расширяет ее файлы, если не хватает места для завершения текущих активных транзакций. Это может происходить из-за:
tempdb. Например, запрос к бухгалтерским остаткам с субконто без отборов способен занять значительное пространство.tempdb, не позволяя его повторно использовать.Важно понимать, что tempdb по своей природе должна расти. Полностью исключить рост невозможно, так как это база данных для временных операций. Вопрос в том, насколько контролируемо и оправданно происходит этот рост.
Многие эксперты сходятся во мне мнении, что постоянная борьба с ростом tempdb и ее периодическое уменьшение (shrink) является не лучшей практикой. Нередко такое поведение расценивается как "нонсенс и ужасающая некомпетентность". Почему так?
tempdb спроектирована для роста: Это ее естественное поведение. Если базе данных требуется место для выполнения операций, она должна его получить.tempdb есть свободное место, SQL Server будет использовать его повторно. Сжатие базы данных, а затем ее повторный рост приводят к бессмысленным операциям, дополнительной нагрузке на дисковую подсистему и процессор, а также к фрагментации файлов.tempdb часто является симптомом других, более глубоких проблем, таких как неоптимизированные запросы в 1С или недостаточная производительность дисковой подсистемы. Если мы просто уменьшаем tempdb, не устраняя коренную причину, проблема будет постоянно возвращаться.Как показывают примеры из практики, при "закрытии месяца" в 1С:ERP размер tempdb может достигать 500 ГБ, что является серьезным показателем. Однако для многих систем нормальным считается рост с 16 ГБ до 32 ГБ во время пиковых нагрузок. Если ваша tempdb постоянно превышает разумные пределы, например, 500 ГБ на диске 750 ГБ, это повод для беспокойства, но в первую очередь следует искать причину такого разрастания.
Несмотря на рекомендации не бороться с ростом, иногда может возникнуть острая необходимость уменьшить tempdb. Например, если диск действительно почти заполнен, и нужно высвободить место. Мы рассмотрим несколько методов:
Самый простой и радикальный способ, упомянутый в начале обсуждения. При каждом перезапуске SQL Server база данных tempdb пересоздается с нуля, и ее размер сбрасывается к начальным настроенным значениям. Этот метод эффективен, но требует остановки работы сервера, что не всегда приемлемо, особенно в производственной среде. Если вы не устанавливали начальные размеры файлов tempdb вручную, она будет создана с параметрами базы данных model.
DBCC SHRINKDATABASE (tempdb).
Это одна из команд, которая позволяет сжать базу данных целиком. Она попытается уменьшить размер файлов tempdb. В обсуждении предлагается использовать ее в составе Job'а (задания SQL Server Agent) для автоматизации, особенно если вы ожидаете покупки нового диска или ищете временное решение. Пример использования:
DBCC SHRINKDATABASE (tempdb);
-- Можно указать процент свободного места, который нужно оставить после сжатия
-- DBCC SHRINKDATABASE (tempdb, 10); -- Оставить 10% свободного места
Однако у этой команды есть ограничения: она не может уменьшить размер файлов меньше их первоначального размера или последнего явно заданного размера. Более того, успешность операции сильно зависит от наличия активных транзакций. Если имеются долгие или активные транзакции, использующие tempdb, сжатие может не произойти или произойти лишь частично.
DBCC SHRINKFILE.
Эта команда предоставляет большую гибкость, поскольку позволяет сжимать отдельные файлы данных (.mdf) и журналов (.ldf) tempdb. Мы можем указать желаемый размер файла в мегабайтах. В отличие от DBCC SHRINKDATABASE, DBCC SHRINKFILE может уменьшить файл до размера, меньшего его первоначального, но не меньше размера базы данных model.
USE tempdb;
GO
DBCC SHRINKFILE (tempdev, 1024); -- Сжать файл данных tempdev до 1024 МБ
GO
DBCC SHRINKFILE (templog, 512); -- Сжать файл журнала templog до 512 МБ
GO
Для успешного сжатия рекомендуется выполнять эти операции, когда нагрузка на сервер минимальна. Мы можем использовать графический интерфейс SQL Server Management Studio (SSMS) для выполнения этих команд, что эквивалентно их ручному вводу.
В некоторых случаях, если сжатие не приводит к желаемому результату, может помочь очистка различных кэшей SQL Server перед повторной попыткой сжатия. Это может освободить ресурсы, которые удерживаются в памяти. Однако мы должны быть осторожны, так как это может временно негативно сказаться на производительности, поскольку кэши будут пересоздаваться. Используются команды:
DBCC FREEPROCCACHE; -- Очищает кэш планов запросов
DBCC FREESYSTEMCACHE ('ALL'); -- Очищает кэш различных системных компонентов
DBCC FREESESSIONCACHE; -- Очищает кэш сессий
Важно отметить, что включение опции автоматического сжатия (AutoShrink) для tempdb крайне не рекомендуется. Эта функция может постоянно вызывать фрагментацию файлов и значительно снижать общую производительность системы.
Вместо того чтобы постоянно уменьшать tempdb, гораздо эффективнее применять комплексный подход, направленный на предотвращение ее неконтролируемого роста и повышение производительности. Давайте рассмотрим основные рекомендации:
Это одна из самых важных рекомендаций. tempdb должна располагаться на отдельном, максимально быстром диске. В идеале, это должен быть NVMe SSD. Размещение tempdb на том же диске, что и другие базы данных или системные файлы, может создать узкое место производительности. Отдельный диск гарантирует, что операции с временными данными не будут конкурировать за ресурсы с другими критически важными операциями ввода-вывода.
Как уже говорилось, "кривые" или "тяжелые" запросы являются основной причиной разрастания tempdb. Мы должны регулярно выявлять и оптимизировать такие запросы. Для этого используем динамические представления (DMV) SQL Server:
sys.dm_db_file_space_usage: Для мониторинга использования дискового пространства файлами tempdb.sys.dm_db_session_space_usage: Для отслеживания использования пространства tempdb каждой сессией.sys.dm_db_task_space_usage: Для детализации использования пространства каждой задачей.sp_whoisactive: Мощная хранимая процедура для быстрого анализа текущих активных сессий и их влияния на систему, включая использование tempdb.Особое внимание уделяем запросам, формирующим сложные отчеты, работающим с большими объемами данных (например, закрытие месяца, расчет себестоимости) или использующим виртуальные таблицы 1С с множеством соединений и отборов. Оптимизация таких запросов может включать изменение их логики, создание недостающих индексов или пересмотр настроек 1С.
tempdb.
Правильная настройка файлов tempdb критична для стабильной работы:
tempdb, исходя из пиковых нагрузок вашей системы. Это предотвратит частые операции расширения файлов. Например, если во время пика tempdb достигает 32 ГБ, установите начальный размер в 32 ГБ или чуть больше.tempdb создается с одним файлом данных. Рекомендуется создавать несколько файлов данных для tempdb (до количества логических ядер процессора, но не более 8-16), чтобы уменьшить конкуренцию за страничные блокировки (PAGELATCH_EX, PAGELATCH_SH) и улучшить параллелизм. Все файлы должны быть одного размера, и иметь одинаковые параметры автоприроста.Помните, что периодическое сжатие tempdb может быть контрпродуктивным. Если мы постоянно сжимаем базу данных, а затем позволяем ей снова расти, мы создаем цикл "высокая фрагментация -> потребность в большом месте -> сжатие -> высокая фрагментация", который негативно сказывается на производительности и сроке службы дисков.
MEMORY_OPTIMIZED_TEMPDB_METADATA (SQL Server 2019+).
В SQL Server 2019 появилась новая функция MEMORY_OPTIMIZED_TEMPDB_METADATA, которая позволяет хранить метаданные tempdb в памяти. Это может значительно снизить ожидания на блокировки метаданных (PageLatсh_ХХ) и ускорить операции, особенно в системах с очень высокой нагрузкой на tempdb. Однако ее использование требует тщательного тестирования и оценки, так как есть риск, что вся доступная память может быть занята метаданными tempdb.
tempdb.
В особо высоконагруженных системах или при специфических задачах (например, закрытие месяца в ERP с колоссальными объемами временных данных) возможно рассмотреть перенос tempdb на RAM-диск. Это может обеспечить феноменальную скорость доступа, но требует значительных объемов оперативной памяти и внимательного мониторинга, так как при росте tempdb за пределы RAM-диска она будет расширяться на медленные физические диски.
Подводя итог, мы можем констатировать, что задача "уменьшения размера tempdb" — это чаще всего нецелесообразная борьба с симптомами, а не с причиной. Гораздо более эффективным подходом является:
tempdb как естественное явление, если он находится в разумных пределах и дискового пространства достаточно.tempdb.tempdb, а также их количество.Помните, что производительность и стабильность работы системы 1С:Предприятия на SQL Server зависят от гармоничной настройки всех ее компонентов. Если tempdb постоянно растет до критических значений, это является ясным сигналом к проведению глубокого аудита и оптимизации, а не к бесконечному "сжатию" базы данных.