← На главную

Рано или поздно многие компании сталкиваются с ситуацией, когда информационная база 1С, в которой ведется учет по нескольким юридическим лицам, разрастается до огромных размеров. В нашем случае речь идет о базе «Бухгалтерии предприятия» объемом 230 Гб с 25-летней историей учета. Такая база становится медленной, сложной в обслуживании и обновлении. Возникает закономерный вопрос: как грамотно разделить ее на несколько отдельных баз для каждой организации?

Проанализируем основные подходы к решению этой непростой, но типовой задачи, их преимущества, недостатки и подводные камни.

Подготовительный этап: архивация и "свёртка" базы

Прежде чем приступать к любым манипуляциям, необходимо выполнить два критически важных шага:

1. Создание полного архива. Сделайте полную копию исходной базы данных (.dt или бэкап SQL) и сохраните ее в надежном месте. Этот архив станет вашим "историческим срезом", к которому можно будет обратиться при необходимости посмотреть данные за прошлые периоды.
2. Рассмотрение "свёртки". Если сохранение детальной истории за все 25 лет в рабочих базах не требуется, стоит подумать о процедуре свёртки. Свёртка заменяет множество документов за прошлые периоды на единые документы ввода начальных остатков на определенную дату (например, на начало текущего или прошлого года). Это само по себе значительно уменьшит объем базы и упростит дальнейшие операции. Однако в очень больших базах даже свёртка может стать отдельной, нетривиальной задачей.

После того как архив создан, можно приступать к выбору основной стратегии разделения.

Метод 1: Перенос данных в чистую базу (Наиболее рекомендуемый)

Этот подход считается самым правильным и эффективным для старых и "замусоренных" баз. Суть его не в удалении лишнего из старой базы, а в создании новых, чистых баз и переносе в них только нужной информации.

Разберем по шагам:

1. Создание пустых баз. Для каждой организации, которую нужно выделить, создается новая, абсолютно пустая информационная база с той же конфигурацией, что и исходная.
2. Ввод начальных остатков. На выбранную дату "разреза" (например, 01.01.2022) в каждую новую базу вводятся начальные остатки по всем регистрам (остатки товаров, взаиморасчеты, ОС и т.д.). Эти остатки можно сформировать из старой базы и перенести.
3. Перенос справочников. В новые базы переносится вся необходимая нормативно-справочная информация (НСИ): контрагенты, номенклатура, договоры и т.д., относящиеся к конкретной организации.
4. Перенос документов за нужный период. Чтобы сохранить недавнюю историю для оперативной работы (например, для оформления возвратов или анализа продаж), из старой базы выгружаются документы за определенный период (например, за последние 2-3 года) по соответствующей организации.

Инструментарий: Основным штатным инструментом для таких задач является конфигурация «Конвертация данных». Она позволяет гибко настроить правила обмена между исходной и новыми базами, указать, какие объекты, по каким фильтрам (по нашей организации) и за какой период выгружать.

Преимущества этого метода:

• Чистота данных. В новую базу не попадает накопленный за десятилетия "мусор": битые ссылки, некорректные записи, результаты старых ошибок учета.
• Компактность и скорость. Новые базы получаются небольшими по размеру, что положительно сказывается на скорости работы, обновления и резервного копирования.
• Контролируемый процесс. Вы точно контролируете, какая информация переносится, и можете исправить ошибки в процессе переноса.

Сложности и "подводные камни":

• Сложный учет. Как справедливо замечено в обсуждении, перенос данных с партионным учетом (FIFO), комиссионной торговлей, частыми возвратами требует очень тщательной настройки правил в «Конвертации данных». Нужно корректно перенести все движения и остатки партий.
• ЭДО. Подсистема электронного документооборота часто имеет сложную структуру связанных объектов. Перенос документов ЭДО и их статусов может потребовать доработки стандартных правил обмена.

Метод 2: Удаление "лишних" данных из копий базы ("Дедовский способ")

Этот метод интуитивно понятен: делаем несколько копий исходной базы и из каждой удаляем всё, что не относится к "титульной" организации. Несмотря на кажущуюся простоту, для больших баз это очень трудоемкий и рискованный путь.

Процесс выглядит так:

1. Создаются копии исходной базы по числу организаций.
2. В каждой копии запускается процесс удаления данных по "чужим" организациям. Важно соблюдать последовательность: сначала удаляются движения в регистрах, затем — сами документы-регистраторы, и только потом — элементы справочников, которые больше не используются.
3. Процесс повторяется итерационно, пока не будут удалены все лишние данные.

Проблемы стандартного удаления:

Если использовать стандартный механизм пометки на удаление и последующего удаления объектов в 1С, на базе в 230 Гб этот процесс может занять несколько дней или даже недель. Система будет постоянно проверять ссылочную целостность для каждого из миллионов удаляемых объектов, что крайне медленно.

Решение — специализированные обработки:

Существуют инструменты (например, на портале Инфостарт), которые выполняют удаление данных напрямую на уровне SQL-запросов, минуя медленные проверки платформы 1С. Такой подход на порядки быстрее. Обработка сначала генерирует SQL-скрипт для удаления, а затем выполняет его. На базе в сотни гигабайт это может занять несколько часов, а не дней.

Преимущества метода:

• Сохраняется вся история по нужной организации, если это является критическим требованием.

Риски и недостатки:

• Высокий риск повреждения данных. Прямые SQL-запросы к базе — это очень опасно. Одна ошибка в скрипте может безвозвратно повредить базу. Обязательно многократное тестирование на копии.
• Требуется высокая квалификация. Исполнитель должен отлично понимать структуру данных 1С и владеть SQL.
• Проблемы со связанными объектами. Как показывает практика, наибольшие трудности возникают с неочевидными связями, например, в подсистеме ЭДО, где множество регистров и справочников ссылаются друг на друга.

Метод 3: Использование Распределенной Информационной Базы (РИБ)

Это штатный механизм платформы «1С:Предприятие», который позволяет создать дочернюю базу, отфильтрованную по определенному критерию, в нашем случае — по организации.

Рассмотрим процесс по шагам:

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

Преимущества метода:

• Надежность и безопасность. Фильтрация данных выполняется на уровне платформы, что минимизирует риск нарушения целостности данных. Это гораздо безопаснее, чем ручное удаление.
• Автоматизация. Процесс в значительной степени автоматизирован штатными средствами.

Недостатки:

• Перенос всей истории. В отличие от метода 1, РИБ перенесет всю историю данных по выбранной организации. Если база очень старая, то и результирующая база может получиться довольно большой, хотя и меньше исходной.

Итоги и рекомендации

Проанализировав все подходы, можно дать следующие рекомендации для задачи разделения очень большой и старой базы:

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

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