После проведения планового обновления конфигурации 1С:Бухгалтерия предприятия, редакция 3.0 и сопутствующего обновления технологической платформы 1С:Предприятие 8.3 многие технические специалисты и системные администраторы сталкиваются со следующей проблемой: при попытке войти в информационную базу программа зависает на стартовой заставке. Ожидание может длиться от 10 до 30 минут, после чего конфигурация всё же запускается и работает в штатном режиме. Однако при повторном запуске ситуация полностью повторяется — система снова уходит в глухой «завис».
Стандартные регламентные операции, такие как очистка локального и серверного кэша метаданных, тестирование физической целостности базы данных утилитой chdbfl.exe, реиндексация таблиц в режиме Конфигуратора, а также выгрузка и загрузка информационной базы через файл .dt, в данном случае не приносят абсолютно никакого результата. В этой статье мы подробно разберем истинные причины такого поведения платформы, проанализируем логи технологического журнала, изучим официальный баг фирмы «1С» и предоставим несколько готовых вариантов решения проблемы, включая программное отключение проблемных процедур.
Для того чтобы понять, чем именно занята платформа в момент многоминутного простоя на заставке, необходимо проанализировать логи. Если настроить сбор событий технологического журнала (ТЖ) на сбор исключений и транзакций, мы сможем увидеть детальную картину происходящего. В логах в момент зависания часто фиксируются множественные системные ошибки и исключения вида:
51:03.417003-0,EXCP,2,process=1cv8c,OSThread=6188,Exception=9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3,Descr="src\backbas\src\clientstorageimpl.cpp(499):
9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3: Ошибка доступа к файлу 'C:\ProgramData\1C\1cv8\1cv8connN.pfl'. 5(0x00000005): Отказано в доступе.
...
53:09.847047-0,EXCP,0,process=1cv8c,OSThread=8148,Exception=DatabaseException8,Descr="Не удалось заблокировать запись. Действие (изменение, удаление или блокировка записи) не выполнено 'ACTIVEUSERS'"
...
53:11.641012-0,EXCP,0,process=1cv8c,OSThread=8148,Usr=DefUser,Exception=DatabaseException8,Descr="Не удалось заблокировать запись. Действие (изменение, удаление или блокировка записи) не выполнено 'DATAZONEOBJECTLOCKS'"
На первый взгляд может показаться, что проблема кроется в сетевых правах доступа, блокировках файлов кэша или системных таблиц блокировок ACTIVEUSERS и DATAZONEOBJECTLOCKS. На самом деле эти ошибки являются лишь следствием того, что один из сеансов монопольно захватил критические ресурсы базы данных и выполняет крайне ресурсоемкую операцию в основном потоке. Другие сеансы при этом пытаются получить доступ к общим файлам конфигурации и уходят в бесконечное ожидание блокировок.
Начиная с релиза конфигурации «Бухгалтерия предприятия» 3.0.70 разработчики внедрили механизм обязательной фоновой проверки реквизитов платежных поручений. Фирмой «1С» зарегистрирована официальная ошибка с кодом 10209520, описание которой гласит: «Увеличивается время запуска программы пропорционально количеству документов "Платежное поручение", записанных в ИБ».
Давайте выясним, что происходит в коде системы при старте. При запуске под пользователем с полными правами в модуле управляемого приложения срабатывает событие ПриНачалеРаботыСистемы. В цепочке вызовов активируется метод общего модуля или обработка:
Обработки.ПроверкаРеквизитовПлатежныхПоручений.ПроверитьНаличиеНекорректныхПлатежей()
Эта процедура инициирует масштабный опрос базы данных, анализируя абсолютно все документы типа ДокументСсылка.ПлатежноеПоручение за последние 3 года работы предприятия. Если ваша организация ведет активную финансовую деятельность и в базе накоплены десятки тысяч платежек, этот запрос полностью парализует работу платформы на этапе инициализации интерфейса. Платформа визуально «висит» на заставке, пока полностью не завершится перебор всей таблицы документов.
Фирма «1С» в качестве временного обхода проблемы рекомендовала пользователям открыть обработку «Проверка реквизитов платежных поручений» через раздел Администрирование и установить в ее форме флаг «Не проверять при начале работы».
Однако здесь специалисты сталкиваются с логическим тупиком («замкнутым кругом»):
Таким образом, штатным интерактивным способом отключить зависание в крупных базах становится невозможно. Нам необходимо применить методы программной записи настроек напрямую в системное хранилище конфигурации.
Для того чтобы обойти зависание и принудительно прописать признак отключения стартовой проверки в системные настройки текущего пользователя, мы можем использовать механизм общей настройки платформы. Информация о необходимости выполнения проверки хранится в системной таблице базы данных и управляется через объект ХранилищеОбщихНастроек.
Рассмотрим пример создания простой внешней обработки. Нам понадобится создать внешнюю обработку с одной кнопкой на форме. В модуле формы обработки пропишем следующий программный код:
&НаКлиенте
Процедура КомандаВыполнить(Команда)
УстановкаНастройкиНаСервере();
ПоказатьПредупреждение(, "Настройка успешно записана! Перезапустите программу.");
КонецПроцедуры
&НаСервере
Процедура УстановкаНастройкиНаСервере()
// Записываем значение Истина в параметр "НеПроверятьПриНачалеРаботы"
// для объекта настроек "ПроверкаРеквизитовПлатежныхПоручений"
ХранилищеОбщихНастроек.Сохранить(
"ПроверкаРеквизитовПлатежныхПоручений",
"НеПроверятьПриНачалеРаботы",
Истина
);
КонецПроцедуры
При запуске данной обработки под учетной записью администратора в хранилище настроек немедленно вносится флаг Истина. При следующем старте система увидит это значение и пропустит ресурсоемкий шаг анализа платежных документов, обеспечив моментальный запуск конфигурации.
После применения первого решения вы можете обнаружить, что под пользователем с правами администратора база запускается мгновенно, но у остальных рядовых пользователей (бухгалтеров, операторов) задержка при старте сохраняется. Это связано с тем, что ХранилищеОбщихНастроек по умолчанию записывает параметры только для текущего авторизованного сеанса.
Чтобы решить эту проблему глобально для всех учетных записей, зарегистрированных в информационной базе, нам необходимо программно перебрать всех пользователей и записать настройку для каждого из них. Проанализируем синтаксис метода сохранения настроек:
ХранилищеОбщихНастроек.Сохранить(<КлючОбъекта>, <КлючНастроек>, <Настройки>, <ОписаниеНастроек>, <ИмяПользователя>)
Обратите внимание на последний необязательный параметр <ИмяПользователя>. Именно он позволяет администратору записывать параметры в профили других сотрудников без необходимости заходить под их учетными записями. Модернизируем код нашей серверной процедуры:
&НаСервере
Процедура ОтключитьПроверкуДляВсехПользователейНаСервере()
// Получаем список всех зарегистрированных пользователей информационной базы
МассивПользователейИнформационнойБазы = ПользователиИнформационнойБазы.ПолучитьПользователей();
Для Каждого ТекущийПользователь Из МассивПользователейИнформационнойБазы Цикл
ИмяПользователяИБ = ТекущийПользователь.Имя;
Попытка
// Записываем настройку для конкретного пользователя базы данных
ХранилищеОбщихНастроек.Сохранить(
"ПроверкаРеквизитовПлатежныхПоручений",
"НеПроверятьПриНачалеРаботы",
Истина,
,
ИмяПользователяИБ
);
Исключение
ЗаписьЖурналаРегистрации(
"ИзменениеНастроекПользователей",
УровеньЖурналаРегистрации.Ошибка,
,
,
"Не удалось записать настройку для пользователя: " + ИмяПользователяИБ
);
КонецПопытки
КонецЦикла;
КонецПроцедуры
Запуск этого кода под учетной записью с полными правами мгновенно решит проблему для всего штата сотрудников вашей организации. Обратите внимание, что пользователям, под которыми выполняется данная процедура, нет необходимости иметь права на запуск внешних обработок в штатном режиме, администратор выполняет это действие централизованно.
Если вы не хотите запускать внешние обработки или в базу регулярно добавляются новые пользователи, для которых настройку пришлось бы прописывать повторно, наиболее элегантным решением будет использование механизма расширения конфигурации. Это позволит полностью заблокировать выполнение процедуры проверки на уровне платформы.
Разберем по шагам, как это сделать:
Обработка.ПроверкаРеквизитовПлатежныхПоручений).ПроверитьНаличиеНекорректныхПлатежей в расширение и примените аннотацию &Вместо, полностью очистив тело заменяемой процедуры.Пример кода в расширении будет выглядеть следующим образом:
&Вместо("ПроверитьНаличиеНекорректныхПлатежей")
Процедура Расш_ПроверитьНаличиеНекорректныхПлатежей()
// Полностью блокируем выполнение тяжелого запроса к базе данных.
// Проверка платежных поручений выполняться при старте не будет.
Возврат;
КонецПроцедуры
Этот способ гарантирует стабильную и быструю загрузку системы независимо от релиза платформы, количества пользователей в базе данных и объема накопленных исторических документов.
Описанная проблема была полностью признана разработчиками и исправлена в последующих официальных обновлениях конфигурации 1С:Бухгалтерия предприятия (начиная с релиза 3.0.71, а также в оперативно выпущенных патчах для релиза 3.0.70).
В обновленных версиях алгоритм работы претерпел следующие изменения:
Если у вас нет возможности оперативно обновиться на актуальные релизы конфигурации, настоятельно рекомендуем воспользоваться Решением 2 (создание обработки для принудительного заполнения хранилища общих настроек для всех пользователей) или Решением 3 (использование временного расширения конфигурации).