INFOSTART EVENT 2018 EDUCATION

Второй тур голосования за доклады.
Окончание 5 сентября.

Алексей Тишков | Заместитель начальника отдела ИТ | ПАО "Амурский судостроительный завод"

«Цифровая трансформация процессов судостроительного предприятия на платформе 1С»

В докладе будет рассмотрен пример построения единого информационного пространства на платформе 1С с использованием комплекса конфигураций: - Управление производственным предприятием; - Документооборот КОРП; - Бухгалтерия предприятия с надстройкой "БИТ:Финанс"; Комплекс конфигураций является фундаментом для внедрения процессного подхода к управлению, системы на платформе 1С используются не только в качестве "учетных", а в качестве среды выполнения формализованных процессов. Таким образом, уровень зрелости и функциональности комплекса перешел от "учетного" к "среде жизненного цикла процессов". Реализованы, в том числе, сквозные процессы между конфигурациями и интегрированными внешними системами (концепция "большие процессы", или "большая единая 1С"), сквозной сбор данных стратегического BI-уровня (контрольные отчеты директора). Используемые технологии: - неквалифицированная цифровая подпись согласно 63-ФЗ (используется для согласования договоров, служебок, исходящих писем, приказов, распоряжений и многих других внутренних документов); - интеграция с внешними системами посредством web-сервисов (интеграция с системой СКУД и управление блокировкой прохода на предприятие из кадровой системы); - интеграция между конфигурациями 1С посредством COM-объектов и web-сервисов; - внешние компоненты; - объекты метаданных Бизнес-процессы и Задачи; На сквозном примере будет рассмотрен общий принцип цифровой трансформации отдельного процесса, выполнение следующего комплекса преобразований: 1. Определение возможного уровня цифровизации, возможности реализации в какой-либо информационной системе весь жизненный цикл процесса (все ли участники процесса присутствуют в информационной системе, могут присутствовать потенциально); 2. Описание и формализация, моделирование текущего состояния процесса, выявление проблемных зон и функций, связанных с вещественной формой передачи информации (на примере модели в нотации EPC); 3. Моделирование трансформированного состояния процесса, определение среды жизненного цикла цифровой формы процесса (подсистемы), измененных форм первичных документов; 4. Закрепление трансформированной формы процесса в системе менеджмента качества (актуализация или создание нормативной базы); 5. Изменение соответствующей информационной подсистемы (архитектура прикладных объектов, кодирование, тестирование); 6. Внедрение и обучение пользователей (участников процесса), постановка на эксплуатацию. Доклад будет интересен практикам внедрения на крупных промышленных предприятиях.

Неоптимальная работа запроса

Администрирование - Оптимизация БД (HighLoad)

117
Шпаргалка к экзамену "Эксперт по технологическим вопросам".

Вряд ли сможете думать о чем-то другом.

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

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

  1. Ошибки в условиях
  2. Ошибки в соединениях
  3. Ошибки сортировки/группировки
  4. Некорректное использование виртуальных таблиц
  5. Прочие ошибки

Теперь подробнее.

 

Ошибки в формулировке условий: Параметры виртуальных таблиц, Соединения (ПО), ГДЕ

 

Проверять условия позже, чем надо

  • Данные передаются в плане запроса от оператора к оператору. Чем раньше удастся отсеять ненужные данные, тем быстрее будет работать запрос. Сначала идет формирование виртуальных таблиц, потом проверяются условия соединения (которые должны быть максимально простыми), позже всего проверяется условие «ГДЕ». Подробнее: //infostart.ru/public/527529/ 

Отсутствие индекса

  • Гораздо лучше, если для запроса есть индекс, который содержит все поля данных и условий. (покрывающий индекс для запроса)

 

Невозможность применен ия индекса (Преобразования)

  • Использование условия ИЛИ в запросах // Переписать запрос, используя "ОБЪЕДИНИТЬ ВСЕ". Кстати, проверка вхождения в список преобразуется внутри СУБД в условия "ИЛИ". В некоторых случаях оптимизатор может обработать "ИЛИ" правильно, например: "Контрагент.ИНН В &(Список)"
  • Подзапросы в условиях, в том числе неявные, сложные условия // Упрощайте, используйте временные таблицы, внутренние соединения, избегайте оператор проверки вхождения.
  • Преобразования, арифметические выражения над индексированным полем
     

Невозможность применен ия индекса (Принципиально)

  • Использование ПОДОБНО % // Вызывает сканирование таблицы, если процент помещен в начале шаблона.
  • Использование условия на «НЕ РАВНО» или «НЕ» // Если проверяем условие не вхождения в список, лучше использовать левое соединение и проверку IS NULL.
  • Использование поля составного типа примитивных и ссылочных значений // Поля составного типа преобразуются в СУБД в несколько столбцов.
    Источники
    //infostart.ru/public/184361/, http://its.1c.ru/db/metod8dev#content:1828:hdoc

     

Ошибки в соедин ениях

  • Соединение с подзапросами (виртуальными таблицами) // В плане запросов преобразуются в малопривлекательный для больших объемов данных Nested loops.
  • Получение данных через точку от полей составного типа – неявные соединения // Пример полей: Регистратор, Субконто, Последовательность. Происходит левое соединение всех таблиц участвующих типов.
  • Сложные запросы, использующие большое количество соединений // Оказывается, оптимизатор MS SQL плохо обрабатывает запросы, где 6-8 соединений и больше. Соединение - самый тяжелый оператор.
  • Сложный, коррелированный запрос
  • Использование полного соединения для Postgres. Источник http://its.1c.ru/db/metod8dev#content:1556:hdoc

Ошибки сортировки/группировки

  • Использование ОБЪЕДИНИТЬ вместо ОБЪЕДИНИТЬ ВСЕ – лишняя сортировка
  • Повторная группировка виртуальных таблиц. Виртуальные таблицы остатков/оборотов сгруппированы по измерениям, участвующим в запросе
  • Выбрать первые + сортировка. Проблема, если сортировка по неиндексируемому полю, или не первому в индексе
  • Применять операцию "Различные" к выборке, заведомо не содержащей повторений.
     

Некорректное использование виртуальных таблиц

  • Указывать период в виртуальных таблицах вместо использования текущих итогов (Остатки, Срез последних 8.3)
  • Использование таблицы Обороты для периода, меньшего месяца.
  • Неполные условия внутри. // Поиск 1С по составным индексам можно сравнить с поиском адреса проживания. Если знаем город, знаем номер дома но не знаем улицу - поиск будет неприятным. Подходящий индекс содержит все поля, перечисленные в условии, поля в индексе идут подряд и между ними нет "зазоров".
     

Прочие ошибки


Внутри запроса

  • Запросы виды ВЫБРАТЬ * ИЗ … // Если в объекте есть табличные части - звездочка получает их тоже.
  • ДЛЯ ИЗМЕНЕНИЯ в автоматическом режиме, не указывать таблицы для блокировки
  • Конструкции типа Ссылка.Ссылка
     

Снаружи запроса

  • Выполнение запросов в цикле.
  • Выполнение запросов через объектную модель.
  • Неоптимальное использование RLS платформы // Следует делать запрос из привилегированного модуля, НЕ назначать две роли с RLS
  • Расчет остатков/оборотов по таблицам документов и таблицам движений регистров

 

 
 Внутри - первый вариант статьи. Большинство комментариев - по нему.

 

Источники

Е. В. Филиппов, "Настольная книга 1С:ЭКСПЕРТА", изд. 2 страницы 215-232

http://learning1c.blogspot.ru/2015/10/1-4.html

https://its.1c.ru/db/metod8dev#content:5842:hdoc

 https://ausevich.ru/ekspert/tipichnye-oshibki-privodyashchie-k-neoptimalnoj-rabote-zaprosa/#more-413

Дисклаймер: шпаргалка не заменит полноценной подготовки.

Буду благодарен за положительные отзывы, за конструктивную критику – благодарен вдвойне. Когда писал статью, сомневался: упоминать ли про регламентные операции (пересчет итогов регистров, реиндекс базы, пересчет статистики). С одной стороны они влияют сильно, с другой - это не метаданные и не код, под вопрос не подходят.

P.S. обратите внимание на файл docs\ru\V8Update.htm в каталоге установки программы. Выполнил отбор информации по теме экзамена. Лично мне интересно: с какого релиза какое новшество началось.

 
 Осторожно, #многобукв

 

117

См. также

Вознаграждение за ответ
Показать полностью
Комментарии
Сортировка: Древо
2. quebracho 23 27.04.18 06:18 Сейчас в теме
Возможно ошибка в тексте публикации.
Прикрепленные файлы:
3. vasilev2015 663 27.04.18 09:13 Сейчас в теме
(2) Здравствуйте !
Группировка в моем понимании связана с вычислением агрегатных функций.
Объединить (без ВСЕ), применяет различные (DISTINCT) в плане запросов - оператор сортировки.
4. vasilev2015 663 27.04.18 09:16 Сейчас в теме
Коллеги,

я знаю что скоро экзамен, поэтому писал статью второпях.
Буду вносить правки.
Сообщайте о своих сомнениях активнее.
Заранее благодарен.
5. melenaspb 208 27.04.18 10:50 Сейчас в теме +0.5 $m
Использование условия на «НЕ РАВНО» или «НЕ» // Если проверяем условие не вхождения в список, лучше использовать внутреннее соединение и проверку IS NOT NULL.


А не ЛЕВОЕ и проверка ЕСТЬ NULL?
6. vasilev2015 663 27.04.18 11:40 Сейчас в теме
(5) Елена, спасибо за внимательность, исправлю.
7. headMade 136 27.04.18 13:03 Сейчас в теме
Для 8.3.12 описание новшеств есть?

Сами сдавали на эксперта или готовитесь?
8. vasilev2015 663 27.04.18 13:13 Сейчас в теме
(7) в статье нет, но можете посмотреть сами в каталоге установки.
нет, не сдавал. Когда сдал - уже шпаргалки писать не нужно.
9. headMade 136 27.04.18 13:17 Сейчас в теме +0.5 $m
я бы еще добавил:
- Невыполнение регламентных операций
- Несоответствие индексов и условий (для каждого условия д.б. подходящий ин-декс: содержит все поля, перечисленнные в условии, поля в индексе идут подряд и между ними нет зазоров.).
у вас указано "Неполное условие на виртуальные таблицы" - на не совсем понятно о чем тут

я бы немного перефразировал:
"При этом неоптимально - получение ДАННЫХ через точку от полей составного типа", а не "Обращение через точку к полям составного типа"
12. vasilev2015 663 27.04.18 14:03 Сейчас в теме
(9) Спасибо за полезное замечание. Когда писал статью сомневался про Регламентные операции. С одной стороны они влияют сильно, с другой - это не метаданные и не код. С остальным согласен.
10. Serg1701 99 27.04.18 13:49 Сейчас в теме
Полезная статья. Спасибо. Приятно, что не забываете о группе КИНО)))
11. vasilev2015 663 27.04.18 13:59 Сейчас в теме
(10) я боялся, что цитату не заметят. Хотел еще пожирнее сделать.
13. nickpugachev 27.04.18 19:36 Сейчас в теме +0.5 $m
В плане запросов преобразуются в малопривлекательный Nested loops

Nested loops самая дешевая операция и в некоторых условиях вполне привлекательная. Это экзаменатор будет уточнять 100% при первой же фразе, что NL плохо
Повторная группировка виртуальных таблиц // Виртуальные таблицы уже сгруппированы по измерениям

Группировка зависит от типа регистра. Срез последних у регистра сведений и обороты регистра накоплений по-разному себя будут вести при выборке не всех измерений в запросе, тоже на доп. вопрос экзаменатора попадете
14. vasilev2015 663 27.04.18 20:35 Сейчас в теме
(13) Да, разумеется, Nested Loops малопривлекателен при большом количестве строк.
Подразумевалась повторная группировка остатков/оборотов.

Спасибо за уточнения.
19. nickpugachev 28.04.18 17:14 Сейчас в теме
(14) Опять же, последует вопрос что такое "большое количество строк" :) - до 3 строк в ведущей таблице - хорошо, больше - нет
Для оракла при этом есть нюансы, связанные с расположением данных, не помню их
20. vasilev2015 663 28.04.18 18:26 Сейчас в теме
(19) Если есть примерный список вопросов - присылайте ))
25. nickpugachev 28.04.18 21:29 Сейчас в теме
(20) Это то что на моей сдаче было. Только заикнешься про что-либо - тут же начинают копать насколько ты это знаешь

На самом деле тест первого дня пройти не сложно.
Дальше нужно активничать, хорошо знать поиск и фильтрацию текстовых файлов (логов) из командной строки (grep и т.д.), достаточно быстро писать тестовые сценарии для центра тестирования. Ну и не бояться и выходить показывать свои решения.
16. vasilev2015 663 28.04.18 09:12 Сейчас в теме
Отправил немного SM всем, кто помог сделать статью лучше.
:-))
17. KVG495 28.04.18 14:43 Сейчас в теме
Еще бы добавил: низкая селективность существующего индекса. Например если индексируемое поле - булево.
И еще два момента:
1. Условие в параметрах виртуальной таблицы должно быть простым. Если там начать строить сложные правила фильтрации. Например по реквизитам измерений, то система сформирует соединение с полным сканированием таблицы движений.
2. Хотел уточнить про соединение с виртуальными таблицами. В общем случае запрос к вирт. таб. лучше выносить в отдельный пакетный запрос иначе будет соединение с подзапросом - это все правильно.
Но! Представим след случай. Соединяемся с периодическим РС. Таблицей среза последних (или первых). Если для регистра установлены галки "Разрешить итоги: срез первых (последних)", тогда в платформа созтает дополнительные физические таблицы в БД. И если заведомо известно, что запрос получает актуальные итоги, то можно соединяться с виртуальной таблицей напрямую. Без предварительного создания временных таблиц.
18. vasilev2015 663 28.04.18 16:52 Сейчас в теме
(17) Здравствуйте, Андрей !

Низкая селективность использованного индекса влечет сканирование таблицы. Только это не является ошибкой кода конфигурации или метаданных. Про условие я указывал: Ошибки в условиях Параметрах виртуальных таблиц, Соединения (ПО), ГДЕ >> Невозможность применения индекса (Преобразования) >> Подзапросы в условиях. Может, недостаточно выпукло - уточню. Виртуальные таблицы действительно разные по своей полезности. Остатки и срез на пустую дату обращаются к таблицам итогов. Реализация срез на определенную дату сама содержит соединение с подзапросом. Но тему про виртуальные таблицы в рамках этой статьи развивать не буду.

В любом случае - спасибо.
21. palsergeich 28.04.18 20:33 Сейчас в теме
(17)
Но! Представим след случай. Соединяемся с периодическим РС. Таблицей среза последних (или первых). Если для регистра установлены галки "Разрешить итоги: срез первых (последних)", тогда в платформа созтает дополнительные физические таблицы в БД. И если заведомо известно, что запрос получает актуальные итоги, то можно соединяться с виртуальной таблицей напрямую. Без предварительного создания временных таблиц.

Но запись в таблицу итогов среза последних - это тоже затраты, встречал случаи, когда запись в основную таблицу РС шла минимально фиксируемое время, а запись в таблицу итогов РС до секунды в серверной базе без других пользователей, что в общем то было не здорово. Но это был весьма древний релиз, возможно сейчас это не так.
Иногда лучшее враг хорошего.
А по теме - удачи с экзаменом, мне не хватило прямо совсем чуть чуть, даже экзаменатор сокрушался, как же я так в последнюю секунду срезался... Надеюсь Вам повезет больше.
И да категорически рекомендую подтянуть знания по анализу тех журнала, если есть пробелы, достаточно в рамках этой статьи. Доп вопрос из разряда посчитайте количество дедлоков СУБД в логах в этой папке (коряво формулирую) это более чем реально (подсказка важно не то что вы эталонно решите эту задачу, а то что вы знаете как ее решить, если экзаменатор видит что Вы знаете, но просто впали в ступор - поможет).
События тех журнала - тоже знать желательно все, вплоть до релиза платформы, в котором появилось.
Так же в фаворе postgres - но тут вопросы попроще.
На моей аттестации в группе, с которой я сдавал - вопросов и доп вопросов именно по теме статьи было мало и они были не сложные, а вот вопросов по ТЖ и postgress - много.
22. palsergeich 28.04.18 21:01 Сейчас в теме
Сложные запросы, использующие большое количество соединений // Оказывается, оптимизатор MS SQL плохо обрабатывает запросы, где больше 8 соединений. Соединение - самый тяжелый оператор.

Тут есть разночтения в зависимости от источника фигурирует цифра 6-8.
Я на экзамене ответил 6-8 и получил +
Соединение с подзапросами (виртуальными таблицами) // В плане запросов преобразуются в малопривлекательный Nested loops.
это не является ошибкой, на сколько я помню даже в настольной книге эксперта об этом написано, просто данный прием часто ведет к проблемам, но у меня есть примеры - когда именно подазпрос давал самый быстрый результат по времени исполнения.
Расчет остатков/оборотов по таблицам документов и таблицам движений регистров
в части таблицам движений регистров не всегда это так, если период меньше периода итогов (ну например обороты за неделю по высокооборотистому складу), то запрос к реальным таблицам может оказаться существенно быстрее, ибо план запроса, по по запросу написанным программистом, может быть проще плана запроса по автосгенерированному тексту запроса. На обучении приводили пример кстати.
И еще - отсутствие расчитанных итогов - тоже может привести к крайне неоптимальной работе запроса, все о них забывают и на экзамене очень желательно и об этом сказать. Если этого не сказать экзаменатор немножко попытается это вытащить, если не получится то вместо + будет +-
23. vasilev2015 663 28.04.18 21:16 Сейчас в теме
(22) Спасибо, что Вы поделились реальным опытом. Очень важно знать, что идешь в верном направлении.
24. palsergeich 28.04.18 21:27 Сейчас в теме
(23) ну и просто категорически рекомендую пройти очное или заочное подготовку к экзамену Эксперт. Все что там рассказывают могут спросить на экзамене + есть спойлеры. И по большому счету - мне лично кое что очень пригодилось в реальной практике. Если быть активным - то это может аукнутся положительным бонусом на эказмене.
26. vasilev2015 663 28.04.18 22:29 Сейчас в теме
(24) Вы составляли какие-то шпаргалки, пытаясь предугадать вопросы экзамена ?
27. palsergeich 28.04.18 23:42 Сейчас в теме +0.5 $m
(26) Если честно то я не серьезно отнесся к описанию самого экзамена, думал билет 3 вопроса + допы, прорешал все билеты и пошел)))) не обратил внимания на
Письменная часть состоит из теста.

В итоге эти 3 вопросы - чистая формальность. их по диагонали посмотрели + + +- какие то доп вопросы задали чисто формальные, не помню, уровень новичок, реально, у меня даже как таковых доп вопросов по этой части не было (ибо сами вопросы в текущих реалиях слабо актуальны)
Тестирование - 20 вопросов. Разные.
От. Что значит настройка техжуранла DBMSSQL, до вопросов в 5-6 строк, которые с первой попытки и не прочитаешь. Именно по ним и идут доп вопросы. Именно они то и важны, как оказалось). Вот именно тут и оказалась засада. Пример. Как определить были ли deadlock на уровне СУБД по тех журналу. Ответ: будет событие, дай бог памяти EXCP с текстом "Lock request time out period exceeded". (могу ошибаться, не пинайте), на что экзаменатор вам может дать ноутбук и сказать посчитайте количество этих событий вон в этой папочке. Шпаргалки тут бесполезны
34. AlX0id 06.06.18 08:08 Сейчас в теме
(27)
Lock request time out period exceeded

(27)
посчитайте количество этих событий

Это еще из самых простых задач, я бы сказал )) Мне досталась задача - в 27 гигах логов найти таймауты на блокировках и объяснить их причину (!)
29. Andrefan 05.05.18 12:55 Сейчас в теме +0.5 $m
Добрый день.
Я бы ещё вынес четвертым разделом "Остальные причины" и добавил бы туда
- Невыполнение регламентных операций. Симптом - количество ожидаемых строк сильно отличается от фактических. (коллега уже писал в комментариях, видел)
- Использование Полного внешнего соединения. В случае с Postgres особо критично.
- Выбрать первые + сортировка. Проблема, если сортировка по неиндексируемому полю, или не первому в индексе.
- Коррелированный запрос
- Фильтр по периоду в параметрах виртуальной таблицы Остатки без необходимости (без фильтра будут использовать только текущие итоги)
30. vasilev2015 663 05.05.18 17:05 Сейчас в теме
(29) есть рациональное зерно.
31. Dach 100 04.06.18 17:59 Сейчас в теме
"Сначала идет формирование виртуальных таблиц, потом проверяются условия соединения (которые должны быть максимально простыми), позже всего проверяется условие «ГДЕ»"

Извините, но это не всегда так. В общем случае да, но в частном нет. Запрос вида

ВЫБРАТЬ
ДоговорыКонтрагентов.Ссылка КАК Ссылка
ИЗ
Справочник.ДоговорыКонтрагентов КАК ДоговорыКонтрагентов
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты
ПО ДоговорыКонтрагентов.Владелец = Контрагенты.Ссылка
ГДЕ
ДоговорыКонтрагентов.Ссылка = &Ссылка

выполнится так:

Сначала выполнится поиск конкретной строки в таблицы договоров, потом к ней будет выполнен джойн таблицы контрагентов. Оптимизатор запросов в общем и целом "не дурак" и он не будет сначала ко всей огромной таблице договоров приклеивать огромную таблицу контрагентов и после выполнять отбор. Говоря языком T-SQL, иными словами, операция INDEX RANGE SEEK более привлекательная и приоритетная, чем INDEX RANGE SCAN и еще более чем FULL SCAN и оптимизатор всегда старается использовать сначала ее. В этом легко убедиться, если посмотреть план запроса. Мало того, если в секции "ГДЕ" заменить отбор на любой неиндексированный реквизит (например "Номер") - все равно сначала выполнится отбор и потом только джойн. То есть оптимизатор каким-то образом прогнозирует затраты на выполнение запроса при компиляции плана. Подозреваю, что не последнюю роль тут играет свежая статистика таблиц.

Даже знаете, вот если логично рассуждать. Вы на форме списка открываете документ с 25 табличными частями. Запрос платформой будет сформирован с условием WHERE. И документ у вас быстро откроется, хотя табличные части - это на минуточку - совершенно другие таблицы БД.

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

И добавить: "при написании запроса нужно стараться руководствоваться принципом максимальной нормализации и минимизации выборки в ведущей таблице перед выполнением к ней каких-либо соединений"
32. vasilev2015 663 04.06.18 21:06 Сейчас в теме
(31) Да, по поводу порядка выполнения были знатные холивары.
Здесь имел ввиду логический порядок (без учета оптимизатора).
Оставьте свое сообщение