Многие пользователи 1С:Предприятие сталкиваются с вопросом о предельном размере файловой базы данных и опасениями, что их текущая база (например, 6,7 ГБ) может вскоре достигнуть критических значений. Мы рассмотрим, какие ограничения существуют для файловых баз 1С, почему они важны и какие шаги можно предпринять для обеспечения стабильной и надежной работы вашей системы.
Наш читатель озаботился размером своей файловой базы в 6,7 ГБ и использовал утилиту tool_1cd.exe, которая показала "максимальный процент" якобы 1,7%. Это вызвало вопрос: действительно ли можно спать спокойно, или это лишь иллюзия безопасности? Давайте разберемся в этом вопросе детально.
Прежде всего, важно понимать, что ограничения файловой базы 1С:Предприятие касаются не общего размера файла .1CD, а размера ее внутренних файлов (таблиц). Файл .1CD представляет собой своего рода внутреннюю файловую систему, состоящую из страниц и внутренних файлов. Каждый из этих внутренних файлов соответствует определенным данным таблицы базы: например, файл записей данных, файл индексов или файл значений неограниченной длины.
Рассмотрим подробнее эти ограничения:
Посмотрим на внутреннее устройство файла .1CD. Он имеет страничный формат, где каждая страница занимает 4096 байт (4 КБ). Номер страницы представлен 4-байтовым целым числом без знака, что позволяет адресовать до 4 294 967 296 страниц. Внутренние файлы состоят из корневой страницы, индексных страниц и страниц данных. Корневая страница содержит служебную информацию о файле и ссылки на индексные страницы, которые, в свою очередь, ссылаются на страницы данных. Таким образом, внутренний файл может содержать не более 1 041 414 страниц данных, что при размере страницы 4 КБ дает максимальный размер около 4,26 ГБ.
Когда одна из внутренних таблиц достигает или превышает свой лимит (4 или 6 ГБ в зависимости от версии платформы), база данных может выдать ошибку "Превышен максимально допустимый размер внутреннего файла 1Cv8.1CD" при запуске, загрузке из файла .dt или во время работы.
Утилита tool_1cd.exe — это инструмент для просмотра структуры и содержимого файловой базы 1Cv8. Показатель "максимальный процент", о котором говорил наш читатель, скорее всего, отражает степень заполнения одного из внутренних файлов до его максимального размера (4 или 6 ГБ). Если этот процент мал, это означает, что ни одна из отдельных таблиц вашей базы не приблизилась к своему пределу. Однако общий размер базы в 6,7 ГБ уже превышает 4 ГБ, что означает, что вы, вероятно, используете платформу с увеличенным размером страницы или же база близка к пределу по сумме всех внутренних файлов, а не по одной таблице.
Размер файловой базы в 6,7 ГБ, а тем более 14 ГБ, как упоминали другие участники дискуссии, является очень значительным для файлового режима работы. Даже если вас устраивает текущая скорость работы и параллельность доступа пользователей, мы должны серьезно озаботиться вопросом сохранности данных.
По нашим многолетним наблюдениям, файловые базы такого размера склонны самопроизвольно рассыпаться по непонятным причинам. Изначально помогает встроенная утилита chdbfl.exe (Тестирование и исправление), входящая в дистрибутив платформы. Однако после нескольких таких случаев chdbfl.exe перестает помогать, и единственным выходом становится поиск и восстановление базы из самой свежей резервной копии.
Причины повреждений могут быть разнообразны:
Фирма "1С" сама рекомендует использовать файловый режим для баз размером до 10 ГБ и не более чем для 5 пользователей, которые не предъявляют особых требований к отказоустойчивости и безопасности. При превышении этих параметров могут возникнуть серьезные проблемы с производительностью, блокировками данных и, самое главное, со стабильностью и целостностью базы.
База на SQL также может разрушиться, но значительно реже и с лучшими инструментами для восстановления. Вероятность повреждения в серверном режиме ниже за счет избыточности хранения и других принципов работы СУБД, а при правильно настроенном плане обслуживания и резервного копирования ее можно приблизить к нулю.
Если вы сталкиваетесь с большой файловой базой или планируете ее рост, мы настоятельно рекомендуем рассмотреть следующие подходы для обеспечения стабильности и надежности:
При росте размера базы данных (особенно свыше 4 ГБ) или увеличении числа одновременно работающих пользователей (более 5), самым надежным и рекомендованным решением является переход на клиент-серверный вариант работы с использованием системы управления базами данных (СУБД). Это значительно повышает стабильность, производительность и отказоустойчивость системы, а также практически снимает ограничения на размер базы.
Мы рекомендуем рассмотреть следующие варианты СУБД:
Для небольших компаний с ограниченным бюджетом отличным решением будет приобретение "1С-сервер МИНИ" (например, на 5 пользователей). Цена вопроса невелика (около 14-15 тысяч рублей), но преимущества в стабильности и сохранности данных колоссальны.
Одним из ключевых преимуществ клиент-серверного режима является возможность выполнять резервное копирование базы данных без необходимости выгонять всех пользователей. Это гарантирует актуальность бэкапов и минимизирует простои в работе.
Даже если переход на серверный режим пока невозможен, существуют способы уменьшить размер файловой базы и предотвратить превышение лимитов внутренних файлов:
Выполнение процедуры "Тестирование и исправление" (ТиИ): Регулярно запускайте эту процедуру в конфигураторе. Особенно важен пункт "Сжатие базы данных". Эта операция убирает пустые области в файле базы данных, которые образуются после удаления данных или изменения структуры, тем самым уменьшая размер внутренних таблиц.
Выгрузка и загрузка информационной базы через файл формата .dt: Это очень эффективный способ сжать данные. Файл .dt, который получается при выгрузке, обычно значительно меньше, чем исходный файл .1CD (например, 1,2 ГБ вместо 7 ГБ). Загрузка базы из .dt файла перестраивает ее структуру, устраняя фрагментацию и пустые места, что может помочь, если какая-либо таблица приблизилась к предельному размеру.
Использование технологии "томов хранения": Если в вашей базе хранится большое количество присоединенных файлов (документы, сканы, изображения), рассмотрите возможность использования технологии томов хранения. Это позволяет вынести большие бинарные данные из основного файла .1CD на диск или в сетевое хранилище, значительно уменьшая размер самой базы.
Анализ размера таблиц: Для диагностики проблем с размерами таблиц мы можем использовать встроенные функции платформы 1С. Они позволяют получить структуру хранения базы данных и размер отдельных таблиц, помогая определить, какие именно таблицы занимают наибольший объем:
// Пример получения структуры хранения базы данных
Структура = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого Таблица Из Структура.Таблицы Цикл
Сообщить("Имя таблицы: " + Таблица.Имя);
// Мы можем получить дополнительную информацию о таблице,
// например, ее идентификатор и количество записей
КонецЦикла;
// Пример получения размера данных конкретной таблицы
// Замените "ИмяТаблицы" на реальное имя таблицы, например, "РегистрБухгалтерии.Хозрасчетный"
Размер = ПолучитьРазмерДанныхБазыДанных("ИмяТаблицы");
Сообщить("Размер таблицы 'ИмяТаблицы': " + Размер + " байт");
// Для удобства, мы можем создать обработку, которая будет выводить
// размеры всех таблиц в удобочитаемом виде:
СтруктураХранения = ПолучитьСтруктуруХраненияБазыДанных();
СписокТаблицИРазмеров = Новый СписокЗначений;
Для Каждого ЭлементСтруктуры Из СтруктураХранения.Таблицы Цикл
ИмяТаблицы = ЭлементСтруктуры.Имя;
Попытка
РазмерТаблицы = ПолучитьРазмерДанныхБазыДанных(ИмяТаблицы);
СписокТаблицИРазмеров.Добавить(РазмерТаблицы, ИмяТаблицы);
Исключение
Сообщить("Не удалось получить размер для таблицы: " + ИмяТаблицы);
КонецПопытки;
КонецЦикла;
СписокТаблицИРазмеров.СортироватьПоПредставлению(НаправлениеСортировки.Убыв);
Сообщить("Размеры таблиц (от наибольшей к наименьшей):");
Для Каждого ЭлементСписка Из СписокТаблицИРазмеров Цикл
Сообщить(ЭлементСписка.Представление + ": " + Формат(ЭлементСписка.Значение / (1024*1024), "ЧДЦ=2") + " МБ");
КонецЦикла;
Публикация файловой базы 1С через веб-сервер (Apache или IIS) позволяет обеспечить доступ к ней через браузер или тонкий клиент, в том числе удаленно. Некоторые пользователи отмечают эмпирическое улучшение стабильности работы файловых баз при таком подходе. Из практики, базы объемом 4-5 ГБ, которые часто "бились", после перевода на работу через Apache работали без нареканий больше года.
Однако важно понимать, что при этом компонент 1С для работы с файловой базой загружается в адресное пространство веб-сервера, и запросы пользователей к базе выстраиваются в очередь. Это может снижать производительность при высокой нагрузке и увеличивать нагрузку на сам веб-сервер. Для многопользовательской работы и больших баз в режиме веб-публикации предпочтительнее использовать клиент-серверный вариант. Также есть сообщения о том, что веб-сервер (Apache) не всегда корректно освобождает память после работы с файловыми базами, что может приводить к ее исчерпанию на сервере.
Независимо от выбранного режима работы, регулярное и надежное резервное копирование является критически важным. При таких размерах базы, как 6,7 ГБ, мы сталкиваемся с проблемами:
Поэтому мы настоятельно рекомендуем разработать и строго соблюдать план резервного копирования. Если вы остаетесь в файловом режиме, необходимо обеспечить регулярную выгрузку базы в .dt файл и его надежное хранение. В серверном режиме задача резервного копирования значительно упрощается благодаря встроенным инструментам СУБД, которые позволяют делать "горячие" бэкапы.
Ваша файловая база в 6,7 ГБ уже находится в зоне повышенного риска. Хотя tool_1cd.exe может показывать низкий процент заполнения для отдельных таблиц, это не отменяет общих рисков стабильности и повреждения данных для больших файловых баз. Мы настоятельно рекомендуем не дожидаться, пока проблемы станут критическими. Примите меры по повышению надежности вашей системы.
Наиболее эффективным и долгосрочным решением является переход на клиент-серверный режим работы с использованием СУБД (например, PostgreSQL) и сервера 1С:Предприятия. Если это временно невозможно, мы советуем регулярно выполнять процедуры оптимизации (ТиИ, выгрузка/загрузка .dt) и рассмотреть возможность публикации базы через веб-сервер для повышения стабильности. И помните, никакие меры не заменят грамотно настроенное и регулярно проверяемое резервное копирование!