← На главную

При загрузке объемной информационной базы из файла выгрузки .dt в клиент-серверную базу на MS SQL Server администраторы и разработчики нередко сталкиваются с критической ошибкой платформы:

«Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Could not allocate a new page for database 'Agrowest' because of insufficient disk space in filegroup 'PRIMARY'. Create the necessary space by dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup. HRESULT=80004005»

Разберем детально, почему возникает эта ошибка, как быстро локализовать ее причину и какие шаги необходимо предпринять для успешного разворачивания базы данных.

Причина 1. Ограничение бесплатной редакции MS SQL Server Express

Текст ошибки сообщает о невозможности выделить новую страницу данных в основной файловой группе (PRIMARY). В большинстве случаев это происходит не из-за физического переполнения жесткого диска, а из-за использования бесплатной редакции MS SQL Server Express Edition.

Начиная с версии MS SQL Server 2008 R2, для редакции Express действует жесткое архитектурное ограничение: максимальный размер файла данных одной базы (.mdf) не может превышать 10 ГБ (в MS SQL Server 2005/2008 ограничение составляло 4 ГБ).

Проанализируем механику распаковки файла .dt: архив выгрузки платформы 1С сжат внутренними алгоритмами. При распаковке объем данных в реляционных таблицах SQL увеличивается в 3–8 раз, а с учетом перестроения индексов и служебных структур исходный архив объемом 2.7 ГБ легко вырастает в готовую базу размером от 15 до 25 ГБ. Как только размер файла данных в процессе загрузки упирается в отметку 10 ГБ, СУБД блокирует дальнейшее выделение страниц, и загрузка падает с ошибкой.

Диагностика установленной редакции SQL Server

Проверим текущую версию и редакцию СУБД. Для этого подключимся к серверу через SQL Server Management Studio (SSMS) и выполним системный запрос:

SELECT @@VERSION;

Если в ответе сервера содержится строка Express Edition, значит СУБД исчерпала лимит объема базы данных, и штатными средствами расширить ее размер внутри этой редакции невозможно.

Способы решения проблемы

Рассмотрим варианты решения задачи в зависимости от назначения информационной базы.

1. Переход на коммерческую редакцию MS SQL Server (Standard / Enterprise)

   Для рабочей (продуктовой) среды предприятия на 20–25 ГБ и более требуется переход на редакцию Standard Edition или Enterprise Edition. В них отсутствуют ограничения на размер баз данных в 10 ГБ, а также сняты ограничения на используемую оперативную память и количество процессорных сокетов.

2. Использование MS SQL Server Developer Edition для тестов и разработки

   Если база данных разворачивается для разработчика, тестирования обновлений или учебных стендов, отличным решением является бесплатная редакция Developer Edition (доступна для версий 2014, 2016, 2019, 2022). Она обладает полной функциональностью Enterprise Edition, не имеет лимита на размер файла базы данных, но по лицензионному соглашению запрещена к использованию в коммерческом проде.

3. Миграция на PostgreSQL / Postgres Pro

   Если покупка лицензий MS SQL Server не планируется, рассмотрим разворачивание базы на свободно распространяемой СУБД PostgreSQL (с патчами от 1С) или Postgres Pro. Эти СУБД полностью поддерживаются платформой «1С:Предприятие 8» и не имеют искусственных ограничений по размеру базы данных.

Оптимизация параметров базы перед повторной загрузкой .dt

После установки поддерживаемой редакции СУБД настроим параметры базы данных для быстрой и стабильной загрузки объемного файла .dt:

1. Простая модель восстановления (Simple Recovery Model): Создадим пустую базу данных на сервере и в ее свойствах (вкладка Options) изменим параметр Recovery model с Full на Simple. Это предотвратит лавинообразный рост журнала транзакций (файла .ldf) в процессе загрузки таблицы за таблицей.
2. Шаг авторасширения (Autogrowth): В свойствах файлов базы (вкладка Files) зададим фиксированный шаг авторасширения в мегабайтах (например, 256 MB или 512 MB) вместо процентов по умолчанию. Это снизит фрагментацию файлов на диске.
3. Мгновенная инициализация файлов (Instant File Initialization): Предоставим учетной записи службы SQL Server право локальной политики безопасности Windows Выполнение задач по обслуживанию томов (Perform volume maintenance tasks). Это избавит СУБД от необходимости занулять выделяемое дисковое пространство при росте файла данных.

Штатные способы уменьшения размера информационной базы

Если требуется вписаться в ограниченное дисковое пространство или уменьшить объем выгрузки перед формированием .dt, выполним предварительную оптимизацию в исходной базе:

1. Перенос присоединенных файлов в тома: Если в конфигурации включено хранение присоединенных файлов (скан-копии, документы, картинки) непосредственно в базе, настроим их вынос в тома на диске через раздел администрирования. Это может сократить объем базы на десятки гигабайт.
2. Очистка таблиц регистрации изменений: Проверим планы обмена (РИБ или интеграции). Зависшие непереданные изменения по неиспользуемым узлам создают скрытый объем данных в системных таблицах.
3. Сокращение версий объектов: Очистим устаревшие записи в регистре сведений версионирования объектов и настроим регламентное удаление старых версий.
4. Усечение журнала регистрации: Сократим журнал регистрации штатными средствами 1С до определенной даты, выгрузив архивные события во внешний файл.

Важная рекомендация: Механизм выгрузки и загрузки .dt предназначен в первую очередь для миграции между разными типами СУБД (например, переход с файлового режима на SQL). Для регулярного резервного копирования и восстановления баз средних и крупных объемов следует использовать нативные бэкапы СУБД — файлы .bak в MS SQL Server.