TempDB на SQL01 съел том: найти сеанс, не удалять файлы tempdb.exe-мышкой

Короткий ответ

Когда tempdb на SQL01 забивает том, 1С к Accounting сыплет ошибками записи «внезапно у всех». Не удаляйте tempdb.mdf в проводнике и не снимайте диск с VM. Найдите, кто занимает: сортировки, хэши, version store (долгие транзакции / snapshot), временные таблицы. Остановите виновный сеанс штатно, освободите место, затем ограничьте MAXSIZE/вынесите tempdb на том с потолком и несколькими файлами.

Экземпляр MSSQLSERVER. Кластер SRV-1C тут вторичен: он просто перестаёт писать.

Симптомы и как отличить

Типичная картина:

• том T: (или C:) 0 байт, файлы tempdev/templog гигантские;
• ошибки 1105 filegroup PRIMARY базы tempdb;
• одновременно «медленно» и «не проводится».

Отличия:

Возможные причины

1. Отчёт/СКД с гигантской сортировкой в tempdb.
2. Долгая открытая транзакция, version store (RCSI, если включён).
3. Autogrowth без MAXSIZE на маленьком томе.
4. Один файл tempdb на всех ядрах, spill адский.
5. Регламент 1С ночью + index rebuild с сортировкой в tempdb.
6. Утечка временных объектов в цикле обработки.

Диагностика

1. Размер и сессии

USE tempdb;
SELECT name, type_desc, physical_name, size * 8 / 1024 AS size_mb
FROM sys.database_files;

SELECT TOP 20 tsu.session_id,
       tsu.user_objects_alloc_page_count,
       tsu.internal_objects_alloc_page_count,
       s.login_name, s.host_name, s.program_name, s.open_transaction_count
FROM sys.dm_db_session_space_usage tsu
JOIN sys.dm_exec_sessions s ON s.session_id = tsu.session_id
ORDER BY (tsu.user_objects_alloc_page_count + tsu.internal_objects_alloc_page_count) DESC;

2. Version store и долгие trx

SELECT * FROM sys.dm_tran_active_snapshot_database_transactions;
SELECT session_id, transaction_begin_time, elapsed_time_seconds =
  DATEDIFF(SECOND, transaction_begin_time, GETDATE())
FROM sys.dm_tran_active_transactions t
JOIN sys.dm_tran_session_transactions st ON t.transaction_id = st.transaction_id;

Сопоставьте session_id с сеансом 1С на SRV-1C.

3. Запросы

SELECT r.session_id, r.wait_type, r.granted_query_memory, t.text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.database_id = DB_ID(N'tempdb') OR r.database_id = DB_ID(N'Accounting');

Полный разбор планов — медленные запросы.

Решение

Сценарий A. Виновный сеанс известен

Сохраните текст запроса. Снимите сеанс 1С, не весь кластер. Дождитесь освобождения пространства (иногда не мгновенно).

Сценарий B. Том полный, сеансы надо спасти местом

Добавить файл tempdb на другой том с MAXSIZE, если SQL ещё принимает DDL:

ALTER DATABASE tempdb ADD FILE (
  NAME = tempdev2,
  FILENAME = N'U:\SQLTemp\tempdev2.ndf',
  SIZE = 2048MB,
  MAXSIZE = 8192MB,
  FILEGROWTH = 512MB
);

Это аварийный клапан, не архитектура.

Сценарий C. Нужен рестарт экземпляра

Если DDL не проходит и диск мёртв: окно, стоп 1С, restart MSSQLSERVER — tempdb создаётся заново. Сначала сохраните вывод DMV, иначе утром не найдёте отчёт. Предупредите, что все сеансы Accounting упадут.

Сценарий D. Постоянная конфигурация

Несколько файлов tempdb равного размера (ориентир — число ядер, без фанатизма 64 файлов), отдельный том, FILEGROWTH в МБ, MAXSIZE чтобы не убить ОС на C:. SQL 2019/2022: учитывайте рекомендации по числу файлов, не копируйте блог «по одному на ядро» слепо на 32 ядрах без теста.

После рестарта файлы tempdb на старте принимают размер из model/последнего ALTER. Зафиксируйте размер, чтобы утро не начиналось с autogrowth на 1 МБ.

Контур 1С: какие операции надувают TempDB

Типичные виновники на Accounting: отчёты СКД с детализацией «по регистратору» без периода, выгрузка универсальным отчётом, RL-ограничения с тяжёлыми соединениями, обмен РИБ, индекс maintenance с SORT_IN_TEMPDB. Сопоставьте время роста файлов tempdb с журналом регламентных заданий 1С и с Job Agent Rebuild Index.

Если включён Read Committed Snapshot на базе 1С (так делают не все, но встречается), version store живёт в tempdb. Долгий сеанс с открытой транзакцией (конструктор запроса, отладка на проде) держит версии. Запрет отладки на прод-кластере снимает целый класс инцидентов.

Несколько файлов tempdb: сделайте их одинакового размера, иначе SQL всё равно перекосит в один. После аварии, когда один файл раздуло до 200 ГБ, а остальные по 1 ГБ, выровняйте через ALTER + рестарт в окно, не shrink одного файла в прайм.

Том tempdb не должен быть тем же, что LDF Accounting и backup. Иначе один отчёт одновременно душит проведение и РК. Для VM: отдельный VHDX, не thin на 100% заполненном datastore — «диск ещё виден в Windows», а рост файла падает с OS error 112.

SELECT name, size * 8 / 1024 AS size_mb, max_size, growth
FROM tempdb.sys.database_files;

Зафиксируйте MAXSIZE так, чтобы ОС и ERRORLOG не остались без места на том же диске. Алерт 80% тома tempdb важнее, чем «когда 1С уже не проводится».

Как проверить, что проблема устранена

• Том tempdb имеет запас.
• 1С проводит документы.
• Повтор того же отчёта на копии/в окне — без роста до 0.
• MAXSIZE/алерт на % тома.

Если не помогло

• Сразу снова рост — тот же регламент, включите замер (производительность 1С).
• Version store при RCSI — ищите долгие writer/reader, не «выключить RCSI в прайм» без плана.
• Лог tempdb (templog) — отдельный рост, тоже MAXSIZE и не на C:.

Профилактика

• Tempdb не на системном диске.
• Алерт по свободному месту тома и 1105.
• Тяжёлые отчёты — не в час пик склада, иногда отдельная копия SQL.
• Не включать все события ТЖ навсегда вместе с тяжёлым XEvents — сами заполнят диск.

FAQ

После рестарта tempdb маленький, это победа?

Это сброс, не исправление запроса. Найдите отчёт.

Можно ли shrink tempdb без рестарта?

Иногда DBCC SHRINKFILE, но при активных сеансах часто бесполезно и фрагментирует. Лучше устранить нагрузку; размер сброса — рестарт в окно.

Нужен ли TF 1118 на SQL 2019?

Начиная с 2016 поведение uniform extents для tempdb уже другое; не тащите старые TF «потому что 1С». Смотрите документ вашей версии.

1С виновата или SQL?

Обычно запрос конфигурации/отчёт. SQL лишь отдал spill на диск. Лечить только «больше RAM» без запроса — до следующего отчёта.

Убийство rphost очистит tempdb?

Грубо и с побочными эффектами. Сначала сеанс 1С и SPID.