Рассмотрим достаточно распространенную и критичную ситуацию, с которой сталкиваются специалисты при обновлении баз 1С:Бухгалтерия. При попытке перевести типовую конфигурацию с редакции 2.0 на редакцию 3.0 процесс обновления прерывается. Конфигуратор внезапно закрывается с сообщением о записи дампа памяти, причем происходит это чаще всего на этапе реструктуризации справочника Контрагенты. Тестирование и исправление, чистка кеша, а также смена формата базы с файлового на клиент-серверный (SQL) не дают результата. Разберем по шагам, почему возникает эта ошибка и как мы можем ее успешно устранить.
Проанализируем ситуацию: если конфигуратор закрывается без явного текста ошибки, оставляя лишь окно «Запись дампа», это свидетельствует о критическом сбое в ядре самой платформы 1С (например, нарушение доступа к памяти на уровне кода C++). При переходе на БП 3.0 структура метаданных меняется кардинально, и некоторые старые или промежуточные релизы платформ (например, 8.3.9, 8.3.10 или 8.3.11) не справляются с такой нагрузкой из-за внутренних ошибок реструктуризатора.
Что нужно сделать: Обновите платформу 1С до более актуальной и стабильной версии. Для БП 3.0 настоятельно рекомендуется использовать релизы не ниже 8.3.12, а в идеале — 8.3.15 и выше. В подавляющем большинстве случаев (как и в исходной ситуации) установка свежей версии платформы позволяет системе корректно проглотить тяжелую реструктуризацию и успешно завершить обновление базы.
Посмотрим на альтернативный вариант. В платформе 1С реализован обновленный, оптимизированный механизм реструктуризации базы данных. По умолчанию может использоваться старый механизм (v1). Версия v2 потребляет меньше оперативной памяти и работает стабильнее на сложных таблицах.
Чтобы его включить, нам необходимо отредактировать конфигурационный файл платформы conf.cfg (обычно он находится в папке C:\Program Files\1cv8\conf\). Добавим в него следующий параметр:
UpdateDBCfg=v2
Это заставит платформу использовать новый механизм реструктуризации при следующем запуске конфигуратора.
Если наша база работает в клиент-серверном варианте на базе MS SQL Server, зависания и падения при реструктуризации объемных таблиц часто связаны с внутренними блокировками при параллельном выполнении запросов. Выясним причину: SQL-сервер пытается распараллелить тяжелый запрос на несколько потоков, что иногда приводит к конфликтам и падению рабочего процесса сервера 1С.
Решение: Временно ограничим параллелизм на уровне СУБД. В свойствах сервера SQL (раздел Advanced) изменим параметр max degree of parallelism (он же maxdop), установив ему значение 1. Это заставит сервер выполнять реструктуризацию строго в один поток. После успешного обновления базы не забудьте вернуть этот параметр к исходному значению (обычно 0).
Поскольку крах стабильно происходит на справочнике Контрагенты, проанализируем сами данные. Переход с редакции 2.0 на 3.0 сильно меняет структуру этого справочника. Платформа может упасть, если наткнется на логические аномалии, которые не выявляются стандартным Тестированием и исправлением (ТиИ):
Перед обновлением запустите обработку поиска и удаления битых ссылок, а также произведите полное удаление помеченных на удаление объектов.
Разберем еще один критический момент: в процессе реструктуризации платформа активно использует временные файлы (папку Temp). Размеры этих файлов могут достигать десятков гигабайт. Если место на системном диске внезапно закончится, конфигуратор закроется с дампом.
Для клиент-серверной базы временные файлы создаются в профиле пользователя ОС, от имени которого запущена служба сервера 1С (чаще всего это USR1CV8). Убедитесь, что на диске C: достаточно свободного места (желательно иметь запас от 50 до 100 ГБ), и полностью очистите папку Temp перед запуском обновления.
Если после очередного вылета база перестала запускаться и конфигуратор выдает сообщение «Внимание! Ошибка исключительной блокировки... Необходимо завершить операцию сохранения конфигурации», это значит, что служебные таблицы зависли.
Мы можем разблокировать базу средствами SQL-запроса, очистив таблицу ConfigSave и удалив запись о коммите из таблицы Config. Выполните следующий запрос в SQL Server Management Studio:
DELETE FROM ConfigSave;
DELETE FROM Config WHERE FileName = 'commit';
После выполнения этого запроса конфигуратор снова запустится, и мы сможем повторить попытку реструктуризации уже на обновленной платформе 1С.