Заказы на доработку 1С (сервис удаленной работы)

Хранилище

База знаний
Неназначенных незавершенных заказов: 1
Бесплатные отчеты, обработки, конфигурации, внешние компоненты для 1С Статьи, описание работы, методики по работе с 1С

Здравствуйте, гость ( Вход | Зарегистрироваться )



> После перехода с 8.2 на 8.3 зависает запрос к регистру сведений          
Vidocq05 Подменю пользователя
сообщение 08.02.19, 16:20
Сообщение #1

Завсегдатай
Иконка группы
Группа: Местный
Сообщений: 214
Из: Сумы
Спасибо сказали: 38 раз
Рейтинг: 0

УТП 1.2.49.1

Предыстория.
Где-то полгода назад обновил платформу с 8.2.19.130 на 8.3.8.2442. Сразу же на следующий день во многих пользователей и очень часто посыпались ошибки на превышение времени ожидания блокировки. Тогда я причину не выявил, т.к. не особо располагал временем, а пользователи очень сильно жаловались. Я даже здесь тему создавал, но и это не помогло. В общем, откатил платформу обратно на 8.2 и проблема исчезла.

Теперь же опять обновил платформу, но уже на 8.3.10.2650 и проблема опять возникла.
Что я выяснил.

В 4 утра запускается регламентное задание, которое запускает обработку, которая формирует и проводит в цыкле документы "Отчет о розничных продажах". Документов всегда должно быть 37 (равно количеству складов), строк в документе в среднем 250. После перехода на 8.3 регламентное задание стало зависать, а точнее после проведения нескольких документов следующий зависает. Это мог быть по счету 5 или 7 или 10 - какой-то закономерности не выявил. Если потом запустить его проведение - проводится без проблем. При выполнении этого регламентного задания ни пользователи ни другие регламентные задания в базе не работают.

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

    Запрос = Новый Запрос;
    Запрос.УстановитьПараметр("Дата", ДатаЦен);
    Запрос.УстановитьПараметр("СписокСкладов", СписокСкладов);
    Запрос.УстановитьПараметр("СписокНоменклатуры", СписокНоменклатуры);

    ТекстЗапроса = "
    |ВЫБРАТЬ
    |    ЦеныПродажные.Склад КАК Склад,
    |    ЦеныПродажные.Номенклатура КАК Номенклатура,
    |    ЦеныПродажные.ХарактеристикаНоменклатуры КАК ХарактеристикаНоменклатуры,
    |    ЦеныПродажные.Цена КАК Цена
    |ИЗ
    |    РегистрСведений.ЦеныАТТ.СрезПоследних(&Дата, Склад В (&СписокСкладов)
    |       И Номенклатура В (&СписокНоменклатуры)) КАК ЦеныПродажные
    |";

    Запрос.Текст = ТекстЗапроса;

    Возврат Запрос.Выполнить();

КонецФункции // СформироватьЗапросПоПродажнымЦенам()

Обычно запрос выполняется в течении 10 сек. Но бывает что выполнение запроса зависает и может висеть бесконечно, пока не удалишь сеанс. Мало того, что регламентное задание не завершается, так из-за того что зависло выполнение запроса то записи регистра сведений заблокированы (возможно что даже все) и другие пользователи становятся жертвами блокировки и практически не могут работать.
Запускал обработку вручную от имени других пользователей - результат тот же.

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

Проблема вроде как ушла, во всяком случае несколько дней "полет нормальный".
Но мне может кто-то объяснить, что это было?
Я понимаю,что в регистре записей довольно много, и складов довольно много (37), и в массиве один и тот же склад повторялся 250 раз потом передавался в запрос как параметр. Но все же...?
Причем на 8.2 все работало без проблем.

andr_andrey Подменю пользователя
сообщение 11.02.19, 9:42
Сообщение #2

Почти ветеран
Иконка группы
Группа: Местный
Сообщений: 626
Спасибо сказали: 166 раз
Рейтинг: 130.8

Vidocq05 @ 08.02.19, 16:20 * ,
По-разному отрабатывает преобразование запроса из текста запроса на 1С. Надо смотреть в профайлере и план запроса.

П.С. Помню MySQL в молодые годы тормозил при встрече с конструкцией "IN", но MSSQL нормально отрабатывал. Странное что-то.

Сообщение отредактировал andr_andrey - 11.02.19, 9:45


Signature
#define private public
enum BOOL { FALSE, TRUE, FILENOTFOUND } is made my day

Спасибо сказали: Vidocq05,

Vofka Подменю пользователя
сообщение 11.02.19, 10:03
Сообщение #3

У нас здесь своя атмосфера...
***********
Группа: Основатель
Сообщений: 13955
Из: Киев
Спасибо сказали: 4519 раз
Рейтинг: 3641.2

Цитата(Vidocq05 @ 08.02.19, 16:20) *
Почему разработчик так написал код мне непонятно.

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

Сообщение отредактировал Vofka - 11.02.19, 10:04

Vidocq05 Подменю пользователя
сообщение 11.02.19, 12:26
Сообщение #4

Завсегдатай
Иконка группы
Группа: Местный
Сообщений: 214
Из: Сумы
Спасибо сказали: 38 раз
Рейтинг: 0

Цитата(andr_andrey @ 11.02.19, 9:42) *
По-разному отрабатывает преобразование запроса из текста запроса на 1С. Надо смотреть в профайлере и план запроса.

К сожалению в этом я не специалист.

Не нашли ответа на свой вопрос?
Зарегистрируйтесь и задайте новый вопрос.


Ответить Новая тема
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 

RSS Текстовая версия Сейчас: 16.04.24, 17:28
1С Предприятие 8.3, 1С Предприятие 8.2, 1С Предприятие 8.1, 1С Предприятие 8.0, 1С Предприятие 7.7, Литература 1С, Общие вопросы по администрированию 1С, Методическая поддержка 1С - всё в одном месте: на Украинском 1С форуме!