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

Когда том данных SQL01 заканчивается, Accounting перестанет писать (1105) и 1С встанет у всех. До нуля: расширьте диск/LUN, добавьте NDF на другой том, либо освободите мусор (старые backup на том же диске, не пользовательские таблицы 1С). Не SHRINKDATABASE как план ёмкости. Не удаляйте MDF. Не ждите Suspect.

Разделите: кончился data, log (журнал) или tempdb (tempdb).

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

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

  • свободно 0–200 МБ на D:\SQL\Data;
  • autogrowth в ERRORLOG failed;
  • 1С: ошибка СУБД при проведении.

Отличия — по file_id ошибки и physical_name.

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

  1. Рост базы 1С без расширения LUN.
  2. Autogrowth 1% по 80 ГБ файлу — мгновенно съедает остаток и долго растёт.
  3. Backup на том же томе.
  4. Другая база на экземпляре.
  5. Thin provisioning гипервизора (видимый NTFS ещё есть, LUN нет) — пишет ERRORLOG про OS error 112.
  6. MAXSIZE файла упёрся при свободном диске.

Диагностика

SELECT DB_NAME(database_id) AS db, name, type_desc, physical_name,
       size * 8 / 1024 AS size_mb, max_size, growth, is_percent_growth
FROM sys.master_files
WHERE database_id IN (DB_ID(N'Accounting'), DB_ID(N'tempdb'));
Get-Volume
Get-ChildItem D:\SQL\Data, D:\SQL\Log, E:\SQLBackup -ErrorAction SilentlyContinue |
  Sort-Object Length -Descending | Select-Object -First 20 FullName, Length

ERRORLOG: 1105, 112, autogrowth.

SELECT name, state_desc FROM sys.databases WHERE name = N'Accounting';

Решение

Сценарий A. На томе лежат backup

Перенесите .bak на backup-том, не data. Освобождение мгновенное, 1С оживает, если SQL смог писать. Потом политику путей job.

Сценарий B. Расширить диск

Расширьте VHDX/LUN, затем раздел NTFS. SQL сразу видит свободное; при необходимости ALTER DATABASE ... MODIFY FILE увеличить SIZE.

ALTER DATABASE [Accounting]
MODIFY FILE (NAME = Accounting, SIZE = 120000MB, FILEGROWTH = 2048MB);

Цифры — ваши. FILEGROWTH в МБ, не процент.

Сценарий C. Добавить файл на другой том

ALTER DATABASE [Accounting] ADD FILE (
  NAME = Accounting_data2,
  FILENAME = N'F:\SQL\Data\Accounting_data2.ndf',
  SIZE = 8192MB,
  FILEGROWTH = 2048MB
);

1С это переживает. Не кладите NDF на сетевую шару.

Сценарий D. MAXSIZE

Если MAXSIZE упёрся — поднимите его после места на диске, не в бесконечность на C:.

Сценарий E. Thin pool полный

Расширение NTFS не поможет, пока datastore/thin pool не вырастет. Смотрите гипервизор.

Контур 1С: почему база растёт и куда смотреть до нуля

Регистры 1С, журнал регистрации в SQL, версионирование объектов, сброшенные незакрытые периоды — легальный рост. Свертка и чистка — проект консультанта на копии, не «админ почистил таблицы». Ваша работа до остановки записи: том, autogrowth, чужие файлы (bak, dump, tempdb на том же диске).

Посмотрите sys.database_files + NTFS. Если файл не растёт, а диск 0 — виноваты соседи: Accounting.bak, tempdb, другая база, IIS-логи. Если файл упёрся в MAXSIZE при свободном диске — поднимите MAXSIZE. Если autogrowth 1% — смените на МБ, иначе следующий рост съест остаток одним куском и заблокирует сеансы надолго (рост файла — это ожидание).

Instant file initialization (право «Perform volume maintenance tasks» у службы MSSQLSERVER) ускоряет рост data, не log. На время массовой нагрузки полезно. Не путать с «выдать службе локального админа».

Thin VHDX: Windows показывает свободные 50 ГБ, datastore 0. Тогда 1105/112 без понятного «диск C красный». Смотрите гипервизор. Расширение NTFS без datastore не лечит.

Мониторинг: свободные байты томов data/log/tempdb/backup, прогноз по росту Accounting за месяц (size в sys.master_files раз в неделю). Для бухгалтерии конец года — пик; расширяйте диск в декабре, не 31-го вечером.

Не включайте автосжатие (AUTO_SHRINK) на Accounting. Это классика фрагментации и «внезапно тормозит».

Пока диск в красной зоне, не стартуйте обновление конфигурации и не rebuild indexes: оба любят место. Сначала ёмкость, потом регламент.

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

  • Есть запас на томе данных (алерт не 0).
  • Проведение в 1С.
  • Autogrowth проходит в тесте (не обязательно растить сейчас).
  • Job backup не пишет на data-том.

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

  • Сразу снова 0 — кто пишет: backup, tempdb, другая БД, утечка.
  • Suspect — статья suspect, копия файлов.
  • Служба не стартует из-за диска C: — служба.

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

  • Отдельные тома: data, log, tempdb, backup.
  • Алерт 15–20% свободно.
  • FILEGROWTH МБ, ёмкость на год учёта 1С.
  • Не хранить Accounting.bak рядом с MDF.

До нуля байт у вас есть рычаги: найти .bak и дампы на томе данных, сдвинуть backup job, расширить VHDX, добавить NDF. После стабилизации посчитайте рост Accounting за квартал и заложите диск до следующего пика (закрытие года). Не держите tempdb, data, log и backup на одном виртуальном диске «потому что просто». Для 1С конец квартала плюс реструктуризация — худший день для ёмкости; расширяйтесь заранее. Алерт на 20% свободных и на неуспешный autogrowth в ERRORLOG дешевле, чем ночь с 1105. Свертку базы не обещайте как замену диска: это проект консультанта на копии с отдельным окном и отдельным backup.

Если 1105 уже пошёл, сеансы 1С будут сыпать ошибками СУБД. Не reboot SQL01 первым: сначала место (bak, расширение тома, NDF). Рестарт при нуле байт может оставить базу в recovery/suspect. Когда место появилось, проверьте state_desc и проведите тестовый документ. Затем разбор, почему рост не прогнозировали: чужой backup на data-томе, процентный autogrowth, thin pool. Запишите новые пороги алерта и MAXSIZE, чтобы ночной job не привёл к тому же к утру.

FAQ

Shrink вернёт место ОС?

Иногда кусок, ценой фрагментации. Не стратегия. Лучше диск.

Можно ли сжать базу 1С штатно?

Регламент 1С «свертка» — отдельный проект с копией, не NTFS shrink.

Instant file initialization зачем?

Ускоряет рост data-файлов. Включите право у службы SQL. На лог не действует так же.

Пользователи могут почистить «кэш SQL»?

Нет. Это не кэш 1С. Диск сервера.

Добавление NDF требует простоя 1С?

Обычно нет, но I/O в момент создания файла большого SIZE лучше не в пик. Создавайте с разумным SIZE.