← На главную

При обновлении конфигурации 1С на больших базах данных (более 100 Гб) можно столкнуться с неприятной ситуацией: процесс реструктуризации идет несколько часов и в конце аварийно завершается. Часто это сопровождается ошибкой APPCRASH в системном журнале, указывающей на сбой в модуле MSVCR110.dll. Давайте разберемся, почему это происходит и как решить эту проблему.

Проанализируем типичный сценарий: у вас большая база 1С:Бухгалтерия 3.0, сервер 1С работает в 32-битном режиме. При попытке обновиться на новый релиз конфигуратор долго выполняет реструктуризацию, а затем падает, чаще всего на "тяжелых" объектах, таких как РегистрБухгалтерии.Хозрасчетный или ПланСчетов.Хозрасчетный. Тестирование базы средствами 1С и SQL (DBCC) при этом не показывает ошибок.

Выясняем причину проблемы: ограничения 32-битной платформы

Основная причина таких сбоев кроется в архитектурных ограничениях 32-разрядных приложений. Рассмотрим это подробнее.

Рабочий процесс сервера 1С (rphost.exe) или клиентское приложение в файловом режиме (1cv8.exe), если они 32-битные, могут использовать ограниченный объем оперативной памяти. В Windows для одного процесса этот лимит составляет около 2 ГБ адресного пространства. Во время реструктуризации таблиц базы данных, особенно таких больших, как регистр бухгалтерии с миллионами проводок, 1С создает в оперативной памяти временные структуры для обработки данных. Объем этих структур может легко превысить доступный лимит в 2 ГБ.

Важный момент: даже если вы в диспетчере задач видите, что процесс потребляет "всего" 1.2-1.5 ГБ, это уже критическая зона. Попытка выделить следующий крупный блок памяти для обработки данных приводит к тому, что операционная система не может предоставить запрашиваемое адресное пространство, и приложение аварийно завершается. Ошибка APPCRASH с кодом исключения 40000015 как раз и указывает на сбой, связанный с нехваткой ресурсов памяти.

Таким образом, проблема не в ошибках данных, а в том, что 32-битный процесс "задыхается" от объема информации, которую ему нужно обработать единовременно.

Решение 1. Переход на 64-битный сервер 1С

Это основной, самый правильный и надежный способ решения проблемы. Он устраняет первопричину сбоя.

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

Порядок действий:

1. Сделайте резервную копию базы данных.
2. Установите на сервере 64-битную версию технологической платформы 1С:Предприятие.
3. Перезапустите службу агента сервера 1С. Убедитесь, что рабочие процессы rphost.exe запускаются как 64-битные (в диспетчере задач у них не будет пометки *32).
4. Запустите конфигуратор и выполните обновление.

В большинстве случаев после перехода на x64 реструктуризация проходит успешно. Однако стоит отметить, что для очень сложных обновлений (например, кардинальное изменение структуры Плана счетов) даже 64-битная версия может столкнуться с таймаутами на уровне СУБД, но это уже проблема другого порядка, не связанная с падением процесса.

Решение 2. Частичное обновление конфигурации

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

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

1. Сначала методом проб определите, на каких именно объектах конфигурации происходит сбой. В рассматриваемом примере это были ПланыВидовХарактеристик.ВидыСубконтоХозрасчетные и ПланыСчетов.Хозрасчетный.
2. Запустите процесс обновления: Конфигурация -> Поддержка -> Обновить конфигурацию.
3. На шаге сравнения и объединения снимите флажки с проблемных объектов, которые вызывают падение. Оставьте все остальные изменения.
4. Сохраните конфигурацию и позвольте 1С выполнить реструктуризацию. Так как "тяжелые" объекты исключены, этот этап должен пройти быстро и без ошибок.
5. Критически важно: после завершения этой реструктуризации не запускайте базу в режиме Предприятия. Это необходимо, чтобы не запустились обработчики обновления данных, которые рассчитаны на полную версию новой конфигурации.
6. Снова зайдите в конфигуратор и повторите процесс обновления (сравнение и объединение с конфигурацией поставщика).
7. Теперь, наоборот, снимите все флажки, кроме тех, что стоят на пропущенных ранее проблемных объектах.
8. Сохраните конфигурацию и запустите реструктуризацию. Теперь она будет применяться только к этим "тяжелым" объектам.

Этот метод позволяет изолировать ресурсоемкие операции. Для большей надежности можно между шагами 5 и 6 перезапустить службу агента сервера 1С, чтобы полностью очистить память, занятую рабочими процессами.

Решение 3. Исключение проблемного объекта из обновления (радикальный метод)

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

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

Как это сделать:

1. В конфигураторе найдите проблемный объект (например, ПланСчетов.Хозрасчетный).
2. Включите возможность изменения для него, сняв его с полной поддержки.
3. При выполнении обновления конфигурации просто не принимайте изменения для этого объекта (снимите с него флажок).

Предупреждение: Используйте этот метод с большой осторожностью! Если вы пропустите важное изменение в ключевом объекте, это может привести к серьезным ошибкам в работе программы в будущем. Прибегайте к этому способу, только если вы на 100% уверены, что функционал обновляемого объекта не затрагивает ваши бизнес-процессы.

Решение 4. Современные методы для платформ 8.3.10 и выше

В более новых версиях платформы 1С появился эффективный механизм, который помогает решать подобные проблемы кардинально. Речь идет о реструктуризации на стороне СУБД.

Для его включения необходимо в файле настроек кластера серверов 1С (conf.cfg) добавить параметр:

UpdateDBCfg=v2

Этот параметр переключает механизм реструктуризации. Вместо того чтобы создавать временные таблицы и переливать в них данные силами платформы 1С (что и съедает память), 1С начинает отдавать СУБД прямые команды на изменение структуры таблиц (например, ALTER TABLE). SQL Server выполняет такие операции гораздо эффективнее и с меньшим потреблением ресурсов на стороне сервера 1С.

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