bdd2


Speshilov Alexander

872
Рейтинг

Alexander Speshilov
speshuric



  •   Регистрация: 26.10.2010 (6 лет назад)

  •   Был(а) на сайте: 20.01.2017


Группы

Профессиональный разработчик

Рейтинг 872

Публикации

Готовый и эффективный скрипт для регулярного обслуживания индексов и статистик.


Небольшая обработка для отладки WQL запросов WMI.


Некоторые особенности и неочевидные моменты использования символов в 1С.


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


В этой статье описано самое обычное резервное копирование ИБ 1С при помощи инструментов MS SQL Server 2008 R2, объяснено почему следует делать именно так, а не иначе, и развеяно несколько мифов.


Комментарии

AdminВсем нужен эксперт#79 11.01.17 14:04
(77) 8.3 - обязательно. В (33) ссылка почему 8.2 и 8.1 не подойдут. SQL можно и 2008, но начиная с 2014 появился новый cardinality estimator и может случиться так, что вы просто докажете, что пора переходить на свежий SQL.
AdminВсем нужен эксперт#78 11.01.17 14:01
(75) А что такое "тратится"? На ВТ возможен ровно один индекс, причем кластеризированный (КИ). Причем ВТ всегда на начало заполнения - пустая (это, кстати - предпосылка к неполному протоколированию вставки). Если параллельных планов нет, и планы выполнения "похожи", то скорее всего у вас будет одно из двух ограничений - либо получение данных запросом (но у нас же планы похожи), либо скорость вставки. Скорость вставки в кучу "типа" выше, пока мы не вспомнили про RID (которых может не быть в КИ, если значения уникальны). Так, если речь идет о ВТ со списком уникальных ссылок на один объект метаданных, разница в размере может быть почти в 1,5 раза в пользу кластеризованного индекса.

Если планы похожи, но в случае КИ есть сортировка, а в случае кучи - нет и на этом разница производительности больше 20% для запроса заполнения ВТ, то у вас очень большая ВТ. Не забываем, что это обычно лишь маленький этап большого пакета. Насколько оправданно создание такой ВТ в принципе? Насколько она полезна без индекса?

Если планы разные, то сложно вообще говорить в терминах "тратится". Просто один запрос с эффективным планом, а второй - нет. Я представляю, как заставить SQL свалиться в эту ситуацию, но а) я знаю как с этим бороться б) мне сложно придумать практическое применение результатам такого запроса. Именно поэтому я и прошу воспроизводимую ситуацию.
AdminВсем нужен эксперт#74 11.01.17 13:31
(73)
Цитата
понятно что какое-то время тратится
Непонятно. Пруф с предложенными ограничениями есть? Сколько именно потрачено лишнего внемени и IO?
AdminВсем нужен эксперт#72 11.01.17 12:57
(71) Забыл еще случай, когда в ВТ куча дублирующихся строк, но это частный случай п.3. И так тоже не надо делать (или взять другие поля для кластеризованного индекса)
AdminВсем нужен эксперт#71 11.01.17 12:52
(68) А можно конкретный пример? Сколько тратится времени? Как я уже писал выше - в 8.3 в ВТ создаётся кластеризованный индекс до вставки строк. При этом на самом деле разницу между вставкой в кучу и в КИ не так-то просто заметить.
Заметная разница в пользу кучи может быть если:

1. Один план параллельный, другой нет. Но если у вас параллельные планы при заполнении ВТ, то у меня для вас плохие новости: либо у вас ВТ огромная , либо вам надо что-то делать с запросом или структурой БД вне зависимости от ВТ.
2. Одна операция минимально протоколируемая, другая - нет. Да, вставка в пустую кучу будет "чаще" минимально протоколируемой. Только если у вас узкое место - журнал транзакций на заполнении ВТ, то опять же - это значит, что она огромная и у вас проблема гораздо глубже.
3. Вы выбрали очень неудачный индекс и для сортировки по кластеризованному индексу сгенерирован "плохой" план. Ну так возьмите более удачный индекс.

Поэтому, те кто утверждает, что на индексирование тратится время: пруф в студию. Только а) на свежих 8.3 и MS SQL 2012-2016 (лучше на 2016 с новым cardinality estimator), б) воспроизводимый, в) без параллельных планов, г) с планом запросов и с заметной (т.е. более 20%) разницей на writes в tempdb и duration д) временная таблица, конечно, не с миллионами-миллиардами строк. Эта задача выполнима, но те кто её могут выполнить, уже точно не нуждаются в рекомендациях, как писать запросы.
AdminВсем нужен эксперт#59 10.01.17 19:56
(56) Необходимость индексов в этом запросе сильно зависит от того, как используется Т1 во втором запросе ("ВЫБРАТЬ ... ПОМЕСТИТЬ Т2" - нигде не сказано, что Т1 в нем не используется :) )
AdminВсем нужен эксперт#33 10.01.17 1:07
(32) Дискуссия комментарии примерно 70-80. Да, в 8.1 и 8.2 индексирование было сделано неэффективно. В 8.3 сделали разумно. Если смотреть планы и трассу, то на самом деле ускорение достаточно частое даже на банальном "В (Выбрать)". Особенно, если эта ВТ используется в нескольких фильтрах в запросе.

Тут еще 3 момента важны
1. Это часто проявляется не на простых запросах, а когда уже 1С-ных объектов в запросе давно считается десятками, а план запросов уже и в студии смотреть некомфортно. Тогда оптимизатор уже не строит из себя умника и его приходится водить за ручку.
2. Замерять время запроса в тестовой базе 1С - это хреновая метрика. Когда всё прокешировано - ограничением будет CPU, а когда эти запросы в бою потребуют IO, то CPU станет несущественным.
3. Какой попало индекс, конечно, не поможет.
AdminВсем нужен эксперт#31 10.01.17 0:38
(27) А я, кстати, не видел. Интересно, как он этого добился? У меня на 2016 на моём примере выдаёт один query_hash. Хотя с другой стороны - я помню как где-то "select ... from config where ..." с кучей разных гуидов в dm_exec_query_stats были (прямо по количетву объектов).
AdminВсем нужен эксперт#26 09.01.17 23:49
(0) Кроме скриптов Брента Озара, я бы рекомендовал еще посмотреть на скрипты Гленна Берри. Пока Брент жмотил свои скрипты и давал ссылку только после регистрации - у Гленна уже они были доступны "по клику". Сейчас-то Брент выложил на github, но у меня осадочек остался.
Плюс у Гленна не создаётся ничего, голые селекты, а у Брента всё в ХП.
Ну и, конечно, у каждого набора скриптов есть свои нюансы, так что, по-хорошему, у DBA оба должны быть под рукой.
AdminВсем нужен эксперт#24 09.01.17 23:27
(22)
В современных версиях 1С (т.е. 8.3), если СУБД MS SQL (мы же про нее сейчас?), то платформа при создании индексированной ВТ достаточно разумно сначала создаёт кластеризованный индекс, а потом наполняет её данными. Если отсечь пограничные глупые случаи (типа "положи мне в ВТ всю базу" и "2 ГБ памяти на сервере и tempdb на самом медленном диске"), то заметить затраты на один единственный кластеризованный индекс вы не сможете.
Если у вас нет ни одного индекса на ВТ, а записей больше 2000, то мало того, что у вас единственная операция "просканируй меня", так еще и статистика начинает уплывать. Если сразу указать удачный индекс на ВТ, то SQL Server может его применить в соединениях, например. Так что рекомендация достаточно разумная: хуже чем куча вряд ли будет, а лучше - при минимальном здравом смысле - будет.