При обслуживании информационных баз 1С:Предприятие специалисты часто сталкиваются с парадоксальной ситуацией: после выполнения штатной процедуры «Тестирование и исправление» (ТиИ) объем файла базы данных существенно увеличивается, а последующая попытка выгрузки данных в формат .dt завершается критической ошибкой ошибка выделения памяти hresult 80004005. Разберем подробно, почему это происходит, как оптимизировать размер базы и как успешно выполнить выгрузку.
Рассмотрим механизмы, которые приводят к увеличению файла .mdf (или файла файловой базы) в процессе тестирования. Многие полагают, что ТиИ должно «чистить» базу, но технически это сложный процесс перестроения структур данных. Выделим основные причины:
Fill Factor), SQL-сервер резервирует значительное пустое пространство в каждой странице данных для будущих записей. В результате физический размер индексов может вырасти в разы.Full, файл лога транзакций (.ldf) будет расти до тех пор, пока не будет сделан бэкап лога. Даже в режиме Simple файл данных может расширяться для обеспечения атомарности крупных операций.Эта ошибка чаще всего возникает в тот момент, когда 1С пытается сформировать файл выгрузки .dt. Разберем ситуацию: процесс выгрузки требует значительных ресурсов оперативной памяти для упаковки данных и построения индексов внутри архива.
Переход на 64-разрядную платформу. Проанализируем основную причину сбоя. 32-битный процесс (даже на 64-битной ОС) ограничен адресным пространством в 2-4 ГБ. При работе с базами объемом более 30-50 ГБ этого объема физически не хватает для сериализации данных в .dt. Единственным надежным решением является использование 64-битного клиента и 64-битного сервера 1С. Выясним по шагам, как это проверить и исправить:
rphost.exe помечены как 32-битные, их необходимо заменить на 64-битные версии.Если переход на 64-битную платформу не помог, рассмотрим дополнительные факторы, которые могут блокировать выгрузку:
Проблема с временными файлами. В процессе формирования .dt система активно пишет данные в системную папку Temp. Проанализируем диск, на котором расположен профиль пользователя или временная папка сервера 1С. Если на диске C: осталось мало места (менее объема самой базы), выгрузка упадет с ошибкой памяти. Рекомендуется перенести временные папки на более емкий диск.
Повреждение бинарных данных. Иногда в таблицах типа ХранилищеЗначения (например, при хранении файлов в базе) появляются «битые» объекты огромного размера. 1С пытается прочитать такой объект в память, что вызывает мгновенное переполнение буфера. В этом случае полезно выполнить проверку физической целостности средствами СУБД, используя команду:
DBCC CHECKDB ('Имя_Вашей_Базы') WITH NO_INFOMSGS, ALL_ERRORMSGS;
Если после тестирования файл базы данных остался неоправданно большим, можно выполнить сжатие (Shrink). Посмотрим, как это сделать правильно:
В среде MS SQL Server Management Studio выберите базу, перейдите в «Задачи» — «Сжать» — «База данных». Однако помните важный нюанс: Shrink вызывает колоссальную фрагментацию индексов. Сразу после сжатия производительность базы может упасть. Правильный алгоритм действий выглядит так:
Shrink) для возврата свободного места операционной системе.Rebuild Index) после сжатия.Разберем важную рекомендацию для системных администраторов: формат .dt не является форматом для бэкапа. Это транспортный формат для переноса данных между разными типами СУБД (например, с MS SQL на PostgreSQL).
Для баз размером более 20-30 ГБ использование .dt становится рискованным и медленным. Рекомендуем полностью перейти на нативные средства СУБД — файлы .bak. Они создаются в разы быстрее, не зависят от ограничений памяти 1С и позволяют восстанавливать базу на конкретный момент времени (Point-in-time recovery) при использовании режима Full.
Подводя итог, можно сказать: рост базы после ТиИ — это часто нормальное явление, связанное с перестроением индексов и логами, а ошибка 80004005 лечится использованием 64-битных версий платформы и контролем свободного места на дисках.