Есть не типовой регистр ОстаткиТоваровПоставщиков. Периодический в пределах секунды, независимый. Измерения: Номенклатура (Справочник.НоменклатураПоставщика), Поставщик (Справочник.Партнер), Склад поставщика (не типовой Справочник.СкладыПоставщиков); Ресурсы: Остаток (Число); Реквизиты: ОстатокАктуален (Булево).
Количество записей в регистре превышает 200000. В последствии будет больше.
Конфигурация УТ 11.4.6.230, платформа 8.3.16.1224, MS SQL.
Требуется сделать простейший срез последних на заданную дату:
Запрос отрабатывается более 5 минут.
Перепробовал все, включая различные комбинации индексов для измерений. Результат нулевой. Впервые сталкиваюсь с такой проблемой. Аналогичный регистр (только с регистратором) ЦеныНоменклатуры отрабатывается влёт.
Убедительная просьба, не задавайте мне вопросов "Зачем мне это надо?" - ответ мне это нужно и точка. И не поучайте "попробовать другую платформу" - пробовал, в т.ч. 8.3.15
Количество записей в регистре превышает 200000. В последствии будет больше.
Конфигурация УТ 11.4.6.230, платформа 8.3.16.1224, MS SQL.
Требуется сделать простейший срез последних на заданную дату:
ВЫБРАТЬ ПЕРВЫЕ 100
ОстаткиТоваровПоставщиков.Номенклатура КАК Номенклатура,
ОстаткиТоваровПоставщиков.Поставщик КАК Поставщик,
ОстаткиТоваровПоставщиков.СкладПоставщика КАК СкладПоставщика,
ОстаткиТоваровПоставщиков.Остаток КАК Остаток,
ОстаткиТоваровПоставщиков.ОстатокАктуален КАК ОстатокАктуален
ИЗ
РегистрСведений.ОстаткиТоваровПоставщиков.СрезПоследних(&ДатаСреза, ) КАК ОстаткиТоваровПоставщиков
УПОРЯДОЧИТЬ ПО
Период УБЫВ
ПоказатьЗапрос отрабатывается более 5 минут.
Перепробовал все, включая различные комбинации индексов для измерений. Результат нулевой. Впервые сталкиваюсь с такой проблемой. Аналогичный регистр (только с регистратором) ЦеныНоменклатуры отрабатывается влёт.
Убедительная просьба, не задавайте мне вопросов "Зачем мне это надо?" - ответ мне это нужно и точка. И не поучайте "попробовать другую платформу" - пробовал, в т.ч. 8.3.15
По теме из базы знаний
- Заметки по SQL: Срез последних - аналог запроса
- Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах
- Нестандартные блокировки при работе с OLAP-нагрузкой
- Быстрый фронт в базе размером 6.8 терабайт – наши стандарты при разработке и рефакторинге запросов
- Data science. Скажи мне, брат, трансформер...
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) не уверен на 100%, но припоминается что в виртуальных таблицах ( типа срез последних) можно работать только с измерениями и ресурсами, а реквизиты доступны только у полной таблицы регистра... попробуйте убрать
измениться ли скорость ?
ОстаткиТоваровПоставщиков.ОстатокАктуален КАК ОстатокАктуаленизмениться ли скорость ?
(16)
По-вашему те, кто хочет вам помочь, об этом знает на телепатическом уровне?
Если выборка без доп. условий отрабатывает еще дольше, у вас часом версионный режим работы для БД не включен в MSSQL?
Фрагментация индексов таблицы насколько сильная?
Неужели я не попробовал ВСЕ случаи и варианты, прежде чем обратился за помощью?! Очень прошу, не флудите!!!!
По-вашему те, кто хочет вам помочь, об этом знает на телепатическом уровне?
Если выборка без доп. условий отрабатывает еще дольше, у вас часом версионный режим работы для БД не включен в MSSQL?
Фрагментация индексов таблицы насколько сильная?
(20) Я объяснил выше. Не надо задавать вопросов не по существу. Когда (10) дает реальный совет, я его услышу. А вопросы типа "а ты выводил на экран или делал выборку?" задавайте на "Мисте". Там любят такие вопросы. Я в самом начале сказал, что ПОРОБОВАЛ ВСЁ ЧТо ВЫ МОЖЕТЕ ПРЕДЛОЖИТЬ (индексы, сортировки и пр.). А ВЫБРАТЬ ПЕРВЫЕ 100 И УПОРЯДОЧИТЬ ПО.... мне просто нужны и это не обсуждается.
(35) При READ_COMMITTED_SNAPSHOT ON MSSQL для транзакций предоставляет копию данных = версионирование.
Вроде как СрезПоследних в случае версионника (ORACLE/Postgres/etc) тупит как не в себя.
Поэтому используют соединение таблиц саму с собой.
Ну если дело не в этом, то и проверять не стОит.
Вроде как СрезПоследних в случае версионника (ORACLE/Postgres/etc) тупит как не в себя.
Поэтому используют соединение таблиц саму с собой.
Ну если дело не в этом, то и проверять не стОит.
(37) Это происходит только в тот момент, когда параллельно происходит запись. Сделано для того, что запрос на чтение видел данные которые обработаны в запросе на запись, но еще находятся в трансакции и не "легли" в базу. Это про рид комитед.
Что касается версионирования, то для ms их 4. 1) только первичная запись без возможности последующего изменения, 2) запись и последующее изменение без хранения истории, 3 и 4) варианты версионирования. Что касается всего, что не ms, понятия не имею
Что касается версионирования, то для ms их 4. 1) только первичная запись без возможности последующего изменения, 2) запись и последующее изменение без хранения истории, 3 и 4) варианты версионирования. Что касается всего, что не ms, понятия не имею
Посмотри через профайлер план запроса и сделай индекс подходящий. Может индекс необходимо реорганизовать из-за высокой фрагментации. Сортировка тяжёлая операция, но у тебя она по периоду, а по нему индекс по сути отсортирован.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот