Обработка показывает неиндексированные измерения регистров сведений, из-за которых случаются блокировки. Для любых баз 1С - на обычных и управляемых формах.
Скачать файл
ВНИМАНИЕ:
Файлы из Базы знаний - это исходный код разработки.
Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы.
Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных.
Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
родилась данная обработка - точнее две - для обычных и управляемых форм.
Тестировались на платформе 1С:Предприятие 8.3 (8.3.14.1854).
Обработка для обычных форм тестировалась на конфигурации "Управление торговлей", ред. 10.3.46.2.
Обработка для управляемых форм тестировалась на конфигурации "Бухгалтерия предприятия", ред. 3.0.74.51.
ОБНОВЛЕНИЕ ОТ 14-01-2020
Добавил Вид регистра - провожу анализ режима записи регистра (Независимый, Подчинен регистратору) и периодичность (Непериодический, Периодический). Поскольку от этого зависит - какие индексы создаст платформа согласно условиям. Более детально смотрите здесь Индексы таблиц базы данных
Скрины обработки для обычных и управляемых форм представлены ниже.
Режим "Ускорить анализ" не проверяет к какому типу относится ссылка - к справочнику, документу, плану обмена и т.д.
Обработка использует только одну процедуру (см. листинг).
Набор инструментов программиста и специалиста 1С для всех конфигураций на управляемых формах.
В состав входят инструменты: Консоль запросов, Консоль СКД, Консоль кода, Редактор объекта, Анализ прав доступа, Метаданные, Поиск ссылок, Сравнение объектов, Все функции, Подписки на события и др.
Редактор запросов и кода с раскраской и контекстной подсказкой. Доработанный конструктор запросов тонкого клиента. Продукт хорошо оптимизирован и обладает самым широким функционалом среди всех инструментов, представленных на рынке.
Инструмент представляет собой обработку для проведения свёртки или обрезки баз данных. Работает на ЛЮБЫХ конфигурациях (УТ, БП, ERP и т.д.). Поддерживаются управляемые и обычные формы. Может выполнять свертку сразу нескольких баз данных и выполнять их автоматически без непосредственного участия пользователя.
Инструмент для написания и отладки кода в режиме «1С:Предприятие». Представляет собой консоль кода с возможностью пошаговой отладки, просмотра значений переменных любых типов, использования процедур и функций, просмотра стека вызовов, вычисления произвольных выражений на встроенном языке в контексте точки останова, синтаксического контроля и остановки по ошибке. В консоли используется удобный редактор кода с подсветкой, контекстной подсказкой, возможностью вызова конструкторов запроса и форматной строки.
Расширение позволяет без изменения кода конфигурации выполнять проверки при вводе данных, скрывать от пользователя недоступные ему данные, выполнять код в обработчиках. Не изменяет данные конфигурации, легко устанавливается практически на любую конфигурацию на управляемых формах.
Инструмент, позволяющий абсолютно по-новому взглянуть на процесс разработки печатных форм. Благодаря конструктору можно значительно снизить затраты времени на разработку печатных форм, повысить качество и "прозрачность" разработки, а также навести порядок в многообразии корпоративных печатных форм.
Обработка создана в обучающих целях по следам просмотра видео-кейса Виктора Богачева.
Вопросы по индексам лучше задавать Виктору Богачеву, который преподаёт курс 1С:Эксперт.
(2) если кратко, то это список ваших потенциальных проблем.
вы смотрели видео-кейс?
в видео-кейсе о чем идет речь: о типовой конфигурации или об адаптированной конфигурации?
в видео-кейсе речь идет о типовом регистре или о нетиповом регистре сведений?
в чем проблема всех подобных доработок (в контексте темы видео-кейса):
первый разработчик создает регистр сведений для хранения информации,
второй разработчик пишет запросы к регистру сведений и другие механизмы обработки сведений.
Третий разработчик находит блокировки.
(2) если кратко, то это список ваших потенциальных проблем.
вы смотрели видео-кейс?
в видео-кейсе о чем идет речь: о типовой конфигурации или об адаптированной конфигурации?
в видео-кейсе речь идет о типовом регистре или о нетиповом регистре сведений?
в чем проблема всех подобных доработок (в контексте темы видео-кейса):
первый разработчик создает регистр сведений для хранения информации,
второй разработчик пишет запросы к регистру сведений и другие механизмы обработки сведений.
Третий разработчик находит блокировки.
Капец. Витя наткнулся случайно на то, что одно из измерений не индексировано. Ему это один раз помешало что-то удалить. Он запостил ролик про то, как он круто проиндексировал измерение. Нашлась куча чудаков, которые стали тулить индексацию во все места, где им стало внезапно не хватать индексов. Еще бы тюнинг адвизор запустили и автоматом нажали потом "создать все".
(10)
1. Давайте сразу оговорим, что я не намерен отдуваться за всю фирму 1С и за всех программистов 1С.
Есть инструмент, никто не предлагает индексировать все измерения во всех регистрах сведений. Это вы сами себе придумали и выдаете за содержание данной статьи.
2. Как думают 1С - я не знаю, и вы знать не можете - каждую конфигурацию разрабатывают своя группа разработчиков. Мы можем только предполагать.
Я просмотрел в БП регистр сведений АналитикаУчетаЗатрат - я полагаю, что измерения не индексировали, поскольку использовать их в запросе напрямую нельзя - эти измерения используются программно алгоритмом, достаточно сложным для восприятия.
Но меня удивило , в УТ не проиндексировано измерение СчетФактура в регистре сведений ЖурналУчетаСчетовФактур...
Я бы рекомендовал индексировать все ссылочные измерения, чтобы не было проблем при обменах и свертках базы. По сути в момент удаления документов.
.
Спросите автора ролика на ютубе, на который Вы ссылаетесь, в комментариях там же на ютубе (он там отвечает, вроде, всем), стоит ли так делать? и почему?
(12) речь о том, чтобы измерения делать или ведущими - чтобы при удалении записи удалялись автоматом, или индексировать - чтобы в запросах быстрее отборы накладывались.
Я подразумевал для Счетов-фактур (не для всех документов!) делать измерения ведущими, поскольку есть обмены и свертки баз.
В конкретном случае, регистр ЖурналУчетаСчетовФактур подчинен регистратору - которых три типа документов - Счет-фактура выданный и полученный, и ВводОстатков, поэтому при удалении СФ, записи автоматом удалятся... Поэтому еще одно одноименное измерение "СчетФактура" излишне делать ведущим...
Вот и все, я свой гештальт закрыл.
Получается, что в каждом конкретном случае нужно понимать для чего вам надо делать измерение "ведущим" или "индексировать".
А про цитату "индексировать все ссылочные измерения" - это я погорячился. А с вами тем более надо выбирать выражения - чтобы вы не цеплялись за слова.
(13) Кластерный индекс независимого регистра сведений состоит из всех измерений, идущих по порядку как заданы в конфигураторе. Автор видимо это упустил. А вообще статья... "фейспам".
(15)не фейспам, а фейспалм. Жаль, что вы не поняли суть статьи. За ссылку спасибо, но про индексы на ИТС очень много написано, можно ещё с десяток привести. Какой в этом смысл?
Мы в школе 15 лет назад проходили, что
palm [pɑːm] - ладонь
даже в таких простых вопросах можно начать спорить.....
слово "Маркетинг" мы произносим с буквой "р", а в англ. транскрипции эту букву мы не произносим. Такова природа англицизмов.
Какой в этом смысл?
Этим и я задавался, увидев статью.
Смысл статьи - обратить внимание на видео-кейс Виктора Богачева, в котором он находит проблему в измерении, которое не является ведущим и не имеет признака "Индексировать"...
Какой смысл вам прикладывать ссылку на статью ИТС, что все измерения индексируются платформой автоматом - когда у Виктора нашлось одно измерение, которое не проиндексировано - тут никто не разберет....
Виктор - вроде ведущий эксперт, и сомневаться в его словах нет смысла.
Я в обучающих целях реализовал список всех таких измерений - которые не являются ведущими, и не имеют признак "Индексировать". На большее не претендую.
НЕ понимаю, о чем мы спорим? Просто посмотрите видео-кейс, выводы делайте сами, можете поделиться своими знаниями и опытом, видением ситуации.
Переписываться в стиле : "вот тебе теория" - " а вот тебе другая теория" - "а вот еще одна теория" - не вижу смысла...
Смысл статьи - обратить внимание на видео-кейс Виктора Богачева, в котором он находит проблему в измерении, которое не является ведущим и не имеет признака "Индексировать"...
У него там частичное использование кластерного индекса, потому что не по всем измерениям отбор установлен был. Но в реальности это совсем не означает, что нужно бежать индексировать его. Заметил, что там строчка кода записи набора РС ссылается на модуль обновления ИБ, полагаю, что скорее всего показанная ситуация воспроизведена чисто для учебного примера, а на практике она вовсе не встретится.
(20) Вообще, по мне, так все просто, что касается, в чем смысл статьи...
сейчас расшифрую....
1) вот отсюда
надо понимать, что
Разработка структуры регистра заключается в создании наборов измерений, ресурсов и реквизитов.
Для управления списком измерений, ресурсов и реквизитов регистра и редактирования их свойств служат управляющие элементы групп Измерения, Ресурсы, Реквизиты окна редактирования Регистр. С точки зрения настройки элементы этих групп одинаковы. Описание порядка использования этих управляющих элементов см. здесь.
5.14.2.4.1. Свойства измерения (ресурса, реквизита) регистра сведений
Свойства измерений, ресурсов и реквизитов редактируются при помощи палитры свойств. В основном они совпадают с общими свойствами объектов конфигурации. Ниже в этом разделе будут описаны уникальные свойства измерений, ресурсов и реквизитов.
Ведущее ‑ установка этого свойства имеет смысл для измерений, тип данных которых ‑ ссылка на объект конфигурации. В этом случае считается, что запись регистра сведений имеет смысл, только пока существует этот объект. При удалении объекта записи по нему будут автоматически удалены из регистра.
Запрет пустых значений ‑ установка этого флажка включает механизм запрета записи регистра с пустым значением измерения.
Индексировать ‑ для измерений свойство доступно для редактирования, если измерение не является ведущим. Для измерений, ресурсов и реквизитов с установленным свойством Индексировать создается отдельный индекс, что увеличивает производительность при работе с регистром. Для ведущих измерений индекс создается всегда.
При просмотре регистра в режиме 1С:Предприятие существует возможность сортировать записи регистра по индексированным измерениям, ресурсам и реквизитам. Необходимое число форм для просмотра и редактирования регистра должно быть создано в процессе разработки конфигурации.
Показать
2) вот здесь
надо понимать , что
Большинство прикладных объектов конфигурации имеют в составе подчиненных объектов группу Реквизиты. В этой группе указываются дополнительные характеристики объектов.
В режиме 1С:Предприятие часто требуется осуществлять отбор данных по значению какого-либо реквизита или сортировать списки данных по реквизитам. Средства «1С:Предприятия» позволяют выполнить подобную задачу, однако если данных достаточно много, такая задача может выполняться долго.
Чтобы ускорить эту работу, следует реквизитам, по которым будет выполняться отбор или сортировка, устанавливать свойство Индексировать. Если свойство установлено (выбрано значение Индексировать или Индексировать с доп. упорядочиванием), то подобные задачи будут выполняться эффективнее. Для примитивных типов реквизитов указание индексирования предоставляет пользователям средство сортировки списка по щелчку мыши в области заголовка колонки.
Наряду с сортировкой по реквизиту или отбором данных по значению какого-либо реквизита часто требуется, чтобы в результирующем списке данные были дополнительно отсортированы по основному представлению (наименованию или коду), т. е. в пределах одного значения реквизита записи были отсортированы по представлению. Добиться правильного результата можно, если выбрано значение индексирования Индексировать, а в условиях сортировки списка указаны реквизит и представление.
3) Выводы. Собственно, список показывает измерения, по которым не задано свойство Ведущее и признак Индексировать. Если вы обслуживаете типовые конфы, то можете проверить эффективность типовых регистров - конечно, нужно ли индексировать или нет - зависит от применяемых запросов и алгоритмов обработки, а это зависит напрямую от целей задачи, для которой регистр был создан...
Если у вас своя разработка - то список покажет вам потенциальные проблемы - локализует регистр и измерение - далее исходя из своих запросов и алгоритмов вы решите , нужно ли индексировать или нет....
Делать ли ведущим измерение - это совершенно другой вопрос, создавать ли дополнительно индекс по реквизиту - это другой вопрос - эти вопросы по сути относятся к разным задачам....
Так получилось, что проиндексировать измерение можно, сделав его ведущим - но насколько это оправдано - это тоже вопрос - может при удалении документа - не надо чтобы удалялись записи?! - Виктор этот вопрос не освещает. Я думаю, что он также в обучающих целях создал пример и продемонстрировал кейс.
4) расшифрую ссылку , которую вы прислали: платформа на некоторые измерения сама создает индексы
Индекс кластерный, если регистр независимый.
,
на другие только при условии
Измерению "ИзмерениеN" задано свойство "Индексировать" или свойство "Ведущее" и при этом это не единственное измерение.
(22) Судя по коду обработки статьи, то она выводит измерения РС (почему только РС?!), по которым отсутствует дополнительный индекс (опираясь на данные встроенной функции получения структуры конфигурации, но на самом деле индекс может быть добавлен в СУБД).
Но вы не учли, что кластерный индекс есть всегда (считаем, что хотя бы одно измерение имеется) и первое измерение в цикле нужно пропустить.
Если НЕ Измерение.Ведущее И Измерение.Индексирование = Метаданные.СвойстваОбъектов.Индексирование.НеИндексировать
И Регистр.Измерения.Индекс(Измерение) > 0 Тогда
А то получается, что он попадёт в "потенциальные"... чего-то там :).
По факту эти полученные данные по измерениям ничего не несут - все зависит от конкретной конфигурации и случая.
По факту эти полученные данные по измерениям ничего не несут
тут спорно - поскольку у каждого своя база, и могут быть допущены ошибки на уровне архитектуры решения - добавлены измерения, которые особенно надо индексировать - опять-таки гипотетически рассуждаю, поскольку анализ остается не за обработкой, а за разработчиком....
(26) Полагаю, что анализ об использовании индексов нужно производить из метрик СУБД (в ms sql это sys.dm_db_missing_index_details), там будет предельно исчерпывающая информация по ним. А эта обработка только вносит путаницу.
(26)
насколько он приемлем в отборах и поисках по конкретному измерению? допустим, что рассматриваем случай РС с двумя измерениями....
Если по первому измерению - то все ок, если по первому и второму - тоже, а если только по второму - то скан.
(28) у многих файловые базы, и конечно чаще бывает что отборы по измерениям независимы, чем зависимы, поиск должен быть как по первому так и по второму измерению одинаково быстрым.
(15) Добавил анализ режима записи регистра (Независимый, Подчинен регистратору) и периодичность (Непериодический, Периодический). Поскольку от этого зависит - какие индексы создаст платформа согласно условиям.
Хоть кластерный индекс и создается всегда для независимого непериодического регистра сведений, непонятно, насколько оптимально он используется при поисках и отборах по конкретному измерению? Я думаю, для оптимальной работы надо создать отдельный индекс по конкретному измерению - а это делается через принудительное указание признаков "Ведущее" или "Индексировать"... Поясните, пож-та, вашу точку зрения.
Обработка создана в обучающих целях по следам просмотра видео-кейса Виктора Богачева.
Вопросы по индексам лучше задавать Виктору Богачеву, который преподаёт курс 1С:Эксперт.
Случайно это не та же проблема что и в регистрах остатков, когда первое измерение товар, второе склад, не оптимально выбирать остатки товаров по складу?
Рауз эту проблему решает радикально, одно общее измерение на всех, но это именно регистр сведений и нагрузка на него большая.
"Обработка показывает неиндексированные измерения регистров сведений, из-за которых случаются блокировки. Для любых баз 1С - на обычных и управляемых формах. "
Как-то непрофессионально написано... блокировки случаются и они не случайны, причем тут вообще с индексация реквизитов.
Этот случай - капля в море проблем с производительностью. Начинается все с ошибок проектирования регистров и непродуманных запросов.
(30) находите запроектированный вами или вашими прогерами регистр, смотрите через глобальный поиск в каких запросах участвует. Далее анализируете все ли оптимально.
а по поводу непрофессионально написано, и капля в море, так я не спорю и не претендую на большее.
