При работе с крупными информационными базами 1С:Предприятие на платформе MS SQL Server системные администраторы часто сталкиваются с ошибкой: «Could not allocate a new page for database 'Имя_Базы' because of insufficient disk space in filegroup 'PRIMARY'». Эта ситуация может поставить в тупик, особенно когда системный монитор показывает наличие свободного места на дисках. В данной статье мы подробно разберем причины возникновения этой проблемы, проанализируем механизмы работы SQL Server при загрузке данных из .dt файла и выработаем пошаговый план оптимизации системы.
Ошибка прямо указывает на невозможность выделения новой страницы данных в основной файловой группе (PRIMARY). Разберем по шагам, на что нужно обратить внимание в первую очередь:
.mdf и .ldf целевой базы данных..dt — это сжатый архив. При загрузке в SQL Server данные разархивируются, а также пересоздаются индексы. Коэффициент расширения может составлять от 1:5 до 1:10. Если ваш .dt весит 30 Гб, итоговая база в SQL может потребовать 200–300 Гб дискового пространства.Properties -> Files. Даже если на диске есть терабайт свободного места, в настройках самого файла базы (MDF) может стоять ограничение на максимальный размер (Restricted Growth). Проанализируем настройки: если установлено «Growth Limited», SQL Server не сможет занять больше места, чем указано в лимите.Во время загрузки .dt файла SQL Server активно использует системную базу tempdb для сортировки данных и построения индексов. Рассмотрим ситуацию, описанную в сообщениях темы, где у пользователя было создано 25 файлов для tempdb.
Рекомендация по количеству файлов: Существует классическое правило — создавать количество файлов tempdb равным числу логических ядер процессора, но не более 8 (если ядер больше). Избыточное количество файлов (как в примере с 25 файлами для базы 90 Гб) может привести к снижению производительности из-за накладных расходов на управление распределением страниц.
Если диск, на котором расположена tempdb, переполняется, вы получите ту же ошибку нехватки места. Чтобы «усечь» tempdb без перезагрузки сервера, можно использовать команду:
USE [tempdb]
GO
DBCC SHRINKFILE (N'tempdev' , 1024) -- где 1024 это целевой размер в Мб
GO
Однако помните, что лучшим способом очистки tempdb остается перезагрузка службы SQL Server, так как эта база пересоздается при каждом запуске.
В сообщении 4 упоминается авторасширение на 10%. Это критическая ошибка для баз большого объема. Проанализируем ситуацию: если база весит 100 Гб, то при очередном расширении SQL Server попытается выделить сразу 10 Гб. В этот момент операционная система начинает «занулять» пространство на диске, SQL Server ждет завершения операции, а 1С:Предприятие может разорвать соединение по таймауту, выдав ошибку о нехватке места.
Как правильно настроить: Установите фиксированный размер приращения (в мегабайтах), а не в процентах. Для баз объемом более 50 Гб оптимальным будет приращение 512 Мб или 1024 Мб. Это обеспечит предсказуемую нагрузку на дисковую подсистему.
Чтобы избежать длительного процесса заполнения нового пространства нулями при расширении файлов mdf и tempdb, необходимо включить мгновенную инициализацию файлов. Рассмотрим, как это сделать:
secpol.msc).Локальные политики -> Назначение прав пользователя.Это позволит SQL Server мгновенно получать место у операционной системы, что критически важно при развертывании больших .dt файлов.
Загрузка данных из .dt — это одна огромная транзакция (или серия крупных транзакций). Если у базы установлена модель восстановления Full, файл лога (.ldf) будет расти со скоростью, сопоставимой с объемом загружаемых данных.
Наш алгоритм действий при загрузке:
.dt.Full (если это необходимо для стратегии бэкапов) и сделать полную резервную копию.Это предотвратит раздувание лога до терабайтных размеров.
В сообщении 14 автор отмечает, что после «усечения» (Shrink) лога база начала сильно «тупить». Проанализируем ситуацию: операция SHRINKDATABASE или SHRINKFILE физически перемещает страницы данных, что приводит к колоссальной фрагментации индексов (до 90–100%).
Что нужно сделать сразу после загрузки базы или выполнения Shrink: Необходимо выполнить регламентное задание по перестроению индексов. В SQL Server Management Studio это можно сделать через Maintenance Plan или вручную, запустив скрипт реиндексации:
USE [Agrowest]
GO
-- Пример для одного индекса
ALTER INDEX ALL ON [Имя_Таблицы] REBUILD;
Именно отсутствие актуальных индексов после загрузки .dt или выполнения операций сжатия часто является причиной низкой производительности, которую пользователи принимают за «повреждение базы».
Разберем основные выводы для стабильной работы:
Backup / Restore средствами самой СУБД. Это быстрее и не требует колоссальных ресурсов tempdb.Соблюдение этих правил позволит вам избежать ошибок при загрузке информационных баз и обеспечит высокую отзывчивость системы для конечных пользователей.