Прусаков Никита | Про 1С

Столкнулся на днях с неприятной ситуацией, и связана она была с расширениями.

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

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

На тестовой базе всё прошло штатно. А вот на рабочей в момент реструктуризации неожиданно закончилось место на сервере СУБД. Само по себе это очень и очень страшно, а уж во время реструктуризации — тем более. Место добавили, службу перезапустили — пошёл откат транзакции. И тут появились первые фантомы.

В списке расширений отображается нужное имя, но при попытке открыть его открывается расширение с именем «Расширение1» и синим бочонком — то есть изменения не приняты. Если запустить конфигурацию с включённой галкой «Активно» у этого расширения, вылетает ошибка:

«Невосстановимая ошибка. Ошибка при выполнении запроса POST к ресурсу /e1cib/login: по причине: Ошибка при выполнении операции с информационной базой. Запись не найдена в менеджере имен базы данных».

Если расширение сделать неактивным — всё запускается.

Тогда я попробовал удалить расширение — и тут всплыла вторая проблема: расширение не удаляется. При каждой попытке запускается реструктуризация, а в конце выходит сообщение с предложением принять изменения. Но принять их нельзя: записи регистра сведений стали неуникальными. Самое интересное — при каждой новой попытке это сообщение относится к разным регистрам сведений. Тут я окончательно понял, что без восстановления из резервной копии не обойтись. Соблазн оставить всё как есть (работает же, если расширение сделать неактивным) конечно был, но здравый смысл возобладал.

А вы ловили проблемы при работе с расширениями?

Несколько часов на поиски проблемы, или почему нужно знать базу

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

Добавлять все эти поля непосредственно во «Внутренние документы» не хотелось: для большинства видов документов они никогда не используются.

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

В справочник ВнутренниеДокументы добавляем реквизит:

ПояснительнаяЗаписка, тип СправочникСсылка.ПояснительныеЗаписки

На форму внутреннего документа добавляем реквизит формы:

ПояснительнаяЗапискаОбъект, тип СправочникОбъект.ПояснительныеЗаписки

После этого на форме внутреннего документа можно размещать его поля:

ПояснительнаяЗапискаОбъект.Обоснование и т д.

При создании нового элемента внутреннего документа создаём объект пояснительной записки и заранее формируем для него ссылку:

ПояснительнаяЗапискаОбъект =
Справочники.ПояснительныеЗаписки.СоздатьЭлемент();

ПояснительнаяЗапискаСсылка =
Справочники.ПояснительныеЗаписки.ПолучитьСсылку(
Новый УникальныйИдентификатор());

ПояснительнаяЗапискаОбъект.УстановитьСсылкуНового(
ПояснительнаяЗапискаСсылка);

Объект.ПояснительнаяЗаписка =
ПояснительнаяЗапискаСсылка;

ЗначениеВРеквизитФормы(
ПояснительнаяЗапискаОбъект,
"ПояснительнаяЗапискаОбъект");

Таким образом, во внутреннем документе будет хранится ссылка на будущий элемент справочника, хотя сама пояснительная записка ещё не записана. Перед записью внутреннего документа преобразуем реквизит формы обратно в прикладной объект:

ПояснительнаяЗапискаОбъект =
РеквизитФормыВЗначение(
"ПояснительнаяЗапискаОбъект",
Тип("СправочникОбъект.ПояснительныеЗаписки"));

Затем передаём полученный объект в ПриЗаписиНаСервере через параметры записи:

ПараметрыЗаписи.Вставить(
"ПояснительнаяЗапискаОбъект",
ПояснительнаяЗапискаОбъект);

А в ПриЗаписиНаСервере записываем пояснительную записку:

ПояснительнаяЗапискаОбъект.Записать();

ЗначениеВРеквизитФормы(
ПояснительнаяЗапискаОбъект,
"ПояснительнаяЗапискаОбъект");

Обратное преобразование после записи нужно, чтобы пользователь мог продолжить редактирование и повторно записать карточку.

Далее как раз возникает проблема. После записи оказывается, что в реквизите "Пояснительная записка" внутреннего документа лежит битая ссылка. При этом элемент справочника успешно записан, но ссылка у него почему-то оказалась другая, а не та которую указали в методе:

ПояснительнаяЗапискаОбъект.УстановитьСсылкуНового(ПояснительнаяЗапискаСсылка);

Почему же так произошло ?

Все дело в одной особенности работы платформы, а именно:

При переносе объекта в данные формы платформой, или при вызове методов ЗначениеВДанныеФормы(), ЗначениеВРеквизитФормы(), переносятся только данные объекта. Внутренние состояние объекта в данные формы не переносится. Например, значение ссылки нового, которая установлена в объект методом УстановитьСсылкуНового(), будет утеряна в процессе преобразования объекта в данные формы и обратно.

Упрощённо ПередЗаписьюНаСервере должен выглядеть так:

&НаСервере
Процедура ПередЗаписьюНаСервере(
Отказ,
ТекущийОбъект,
ПараметрыЗаписи)

ПояснительнаяЗапискаОбъект =
РеквизитФормыВЗначение(
"ПояснительнаяЗапискаОбъект",
Тип("СправочникОбъект.ПояснительныеЗаписки"));

Если ПояснительнаяЗапискаОбъект.ЭтоНовый() Тогда

ПояснительнаяЗапискаОбъект.УстановитьСсылкуНового(
ТекущийОбъект.ПояснительнаяЗаписка);

КонецЕсли;

ПараметрыЗаписи.Вставить(
"ПояснительнаяЗапискаОбъект",
ПояснительнаяЗапискаОбъект);

КонецПроцедуры

Такие особенности платформы нередко встречаются в процессе разработки. А с какими особенностями при разработке сталкивались вы? Поделитесь своими примерами в комментариях.

Статистика может устаревать.

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

- Вручную, когда выполняем команду UPDATE STATISTICS. Может быть как FULLSCAN, так и SAMPLE (частично)
- Второй вариант – делаем перестроение индекса (REBUILD). Вместе с этим соответствующая статистика помечается как устаревшая, и затем обновляется.
- Чтобы сделать жизнь проще, в MS SQL добавили настройку под названием AUTO_UPDATE_STATISTICS. А чтобы жизнь стала совсем сладкой, также добавили параметр AUTO_UPDATE_STATISTICS_ASYNC, т.е обновление статистики асинхронно. SQL Server отслеживает количество изменений строк (вставок, удалений, обновлений) с момента последнего обновления статистики и сравнивает его с порогом. Когда порог превышен, статистика помечается как устаревшая. Далее запускается процесс асинхронного пересчета статистики.

На практике это выглядит так: запустили запрос - система увидела, что статистика устарела, запустила процесс обновления статистики по таблице, при этом запрос продолжает выполняться.

И как раз тут мы попадаем в ловушку ожидания на таком типе блокировки как LCK_M_SCH_M / LCK_M_SCH_S, связанные с попыткой получить блокировки модификации схемы Sch-M / Sch-S.

LCK_M_SCH_M - Будет возникать у служебной сессии ms sql, которая запустила пересчет статистики. Запрос компилируется и выполняется с существующей, возможно устаревшей статистикой, а обновление статистики уходит в фоновую сессию. Эта сессия будет пересчитывать статистику, и затем обновлять сам объект статистики, чтобы другие запросы могли пользоваться обновленной статистикой. Но, блокировка на этот объект статистики будет держаться до тех пор, пока не закончится выполняться наш основной запрос (тот самый неоптимальный и долгий). И только после того как долгий и неоптимальный запрос выполнится, объект статистики подменится на новый, и блокировка будет снята.

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

Весьма непрозрачная история. Отчет, который выполняется без транзакции с NOLOCK, все равно может вызвать ожидания. Этот сценарий характерен именно для включенного AUTO_UPDATE_STATISTICS_ASYNC. При синхронном обновлении статистики проблема проявляется иначе: запрос ждёт обновления статистики перед компиляцией и выполнением, компиляция запроса не начнется, пока не завершится обновление статистики. Только после этого запустится компиляция запроса.

А вы ловили такие ожидания у себя в практике ?

Когда я готовился к экзамену «1С:Эксперт», меня сильно пугали тем, что на экзамене могут не просто спросить знаешь ли я регулярные выражения, но и попросить прямо на бумаге написать хотя бы простое выражение, которое выберет к примеру все EXCP. Поэтому я достаточно серьёзно подошёл к этой теме: прочитал книгу Бена Форта о регулярных выражениях, подробно разобрал статьи по анализу технологического журнала и подготовил для себя набор типовых шаблонов. Часть этих шаблонов я использую до сих пор.

При этом важно было не просто выучить регулярки, а понимать, чем отличаются инструменты: где удобнее использовать grep, где awk, где sed, а где лучше подключить perl.

Но сейчас речь не совсем об этом.

Сегодня написать практически любое регулярное выражение стало гораздо проще. С помощью ChatGPT, Cursor и других ИИ-инструментов можно быстро получить рабочий скрипт под любую задачу. Но знать основы всё равно важно, потому что нужно понимать, а что собственно смотреть то нужно?

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

Задача была такая: сгруппировать события по контексту и пользователю, а затем вывести основные метрики:

- суммарное время выполнения;
- среднее время выполнения;
- максимальную длительность события;
- количество вызовов;
- расход памяти;
- пиковое потребление памяти;
- процессорное время;
- объём входящих и исходящих данных;

В итоге получился набор скриптов для анализа тех. журнала. Они позволяют быстро собрать статистику по длительным запросам, серверным вызовам , а также быстрее получить первичную картину по проблемным операциям в ТЖ.

Если такие скрипты пригодятся — напишите в личку скину.

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

И уже потом запускать скрипты по сбору аналитик.