Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
Добрый день Пытаюсь впервые разобраться с партицированием. Задача: убедиться по плану запроса, что выбираются данные только из той партиции, в которой лежат нужные данные. Нашел статью коллеги Гладченко тынц где написано следующее: если выполнить Код: sql 1. 2. 3. 4. 5. то в плане выполнения будет |–Table Scan(OBJECT:([t]), WHERE:([t].[a]<(0)) PARTITION ID:((1))) Однако, когда указанное выполняю я, вижу: |--Table Scan(OBJECT:([master].[dbo].[t]), SEEK:([PtnId1001] >= (1) AND [PtnId1001] <= RangePartitionNew(CONVERT_IMPLICIT(int,[@1],0),(0),(0),(10),(100))), WHERE:([master].[dbo].[t].[a]<CONVERT_IMPLICIT(int,[@1],0)) ORDERED FORWARD) Что я делаю не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2019, 15:46 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
Oblom, У вас запрос параметризировался и вы столкнулись с так называемым dynamic partition elimination. если добавить option (recompile) получите что хотите ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2019, 16:10 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
felix_ffOblom, У вас запрос параметризировался и вы столкнулись с так называемым dynamic partition elimination. если добавить option (recompile) получите что хотите Запустил с recompile, получил: |--Table Scan(OBJECT:([master].[dbo].[t]), SEEK:([PtnId1001]=(1)), WHERE:([master].[dbo].[t].[a]<(0)) ORDERED FORWARD) Вроде непохоже на пример из статьи, или это одно и то же, записанное разными словами? И как уйти от dynamic partition elimination не используя RECOMPILE? а то для промышленных решений как-то жестковато. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2019, 16:40 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
OblomИ как уйти от dynamic partition eliminationЗачем? Неэстетично выглядит? Вам вообще для чего секционирование? Веяние моды? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2019, 16:58 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
invmOblomИ как уйти от dynamic partition eliminationЗачем? Неэстетично выглядит? Вам вообще для чего секционирование? Веяние моды? Общая задача: Есть DWH с несколькими таблицами фактов более 100 млн. каждая Есть кубы на этих таблицах секционированных по годам, код партиций в кубе вида "WHERE Date >='20180101' AND Date < '20190101' " Ежедневно пересчитываются партиции последнего года или последних двух лет. Показалось разумным секционировать таблицы фактов синхронно кубам, чтобы ускорить ежедневный пересчет кубов за счет того, что выборка будет не по всей таблице, а по 1-2 последним партициям. Мне теперь надо понять по плану запроса, что моё секционирование решило поставленную задачу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2019, 17:08 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
Oblomчтобы ускорить ежедневный пересчет кубовСекционирование - средство администрирования, а не ускорения. Кластерный индекс справится не хуже. А если на ваших таблицах уже есть индексы, то секционирование еще и добавит головной боли. OblomМне теперь надо понять по плану запроса, что моё секционирование решило поставленную задачу.Не пробовали почитать что такое "dynamic partition elimination"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2019, 17:46 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
Oblom, у Фридмана хорошо описан сам процесс: почитайте https://blogs.msdn.microsoft.com/craigfr/2006/11/27/introduction-to-partitioned-tables/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2019, 17:50 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
OblominvmВам вообще для чего секционирование? Веяние моды?Показалось разумным секционировать таблицы фактов синхронно кубам, чтобы ускорить ежедневный пересчет кубов за счет того, что выборка будет не по всей таблице, а по 1-2 последним партициям.Понятно, веяние моды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2019, 19:49 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
invmНе пробовали почитать что такое "dynamic partition elimination"? Попробовал, почитал и понял. Более того, в моем случае, его таки нет, а если и будет, то не смертельно. Хоть бы раз здесь в моей теме не написали "вам это нафиг не надо", вместо того, чтобы хотя бы кинуть ссыль на документацию, которую надо почитать. Если уж своими словами лениво объяснить, имея опыт. Весь опыт по любой теме всегда сводится к "вам это нафиг не надо". Спасибо всем, вопрос закрыт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2019, 09:34 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
Oblom, кубы обновляют при помощи SSIS и change tracking, если не ошибаюсь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2019, 11:39 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
Oblom, Типы должны быть приведены явно к типу аргумента функции секционирования: Код: sql 1. Если не соблюдать это правило, можете получить просмотр всех секций. В вашем случае просмотрена была только одна. Если "шашечки" важнее, чем "ехать", то проблема, наверное, есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2019, 11:49 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовТипы должны быть приведены явно к типу аргумента функции секционированияСможете объяснить как же тогда работает исключение секций в вышеприведенном примере? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2019, 12:15 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
Oblom Хоть бы раз здесь в моей теме не написали "вам это нафиг не надо", вместо того, чтобы хотя бы кинуть ссыль на документацию, которую надо почитать. Если уж своими словами лениво объяснить, имея опыт. именно это вам своими словами и написали: "Секционирование - средство администрирования, а не ускорения. Кластерный индекс справится не хуже." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2019, 12:16 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
StarikNavy, конечно же это неправда. Секции эффективны при просмотре данных в плане запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2019, 12:22 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
invm, увы, нет, я не настолько детально знаю особенности движка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2019, 12:22 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовСекции эффективны при просмотре данных в плане запроса.Расшифруйте. Владислав Колосовувы, нет, я не настолько детально знаю особенности движка.Тогда на основании чего вы даете такие рекомендации? И почему ваше предложение обязательно для предикатов со столбцом секционирования, а не вообще для всех? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2019, 12:47 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
invm, насколько я видел в планах, использование секций приводит к просмотру меньшего количества данных и, вместо просмотра всех строк таблицы, запрос читает лишь строки секции, попадающую в заданный предикатом диапазон. Обязательно потому, что, как показывает практика, неявное преобразование может привести к просмотру всех секций вместо тех, которые подходят в заданные условия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2019, 14:03 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
Проблему легко увидеть, слегка изменив пример: Код: sql 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2019, 14:15 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
Владислав Колосовнасколько я видел в планах, использование секций приводит к просмотру меньшего количества данных и, вместо просмотра всех строк таблицы, запрос читает лишь строки секции, попадающую в заданный предикатом диапазон.А соответствующий индекс будет работать как-то иначе? Владислав КолосовОбязательно потому, что, как показывает практика, неявное преобразование может привести к просмотру всех секций вместо тех, которые подходят в заданные условия.Ну так почему же ваше правило не обязательно для поиска по индексу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2019, 14:27 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
invm, хорошие вопросы, надо подумать. Вы имеете в виду поиск диапазона в кластерном индексе? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2019, 16:12 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
Владислав Колосов, как по мне плюшки исключения секций в плане сайдэффекта увеличения производительности можно сравнивать только в случае сканирования индекса. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2019, 16:33 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
felix_ff, у меня как раз ситуация с большим количеством ad hoc запросов и достаточно широкой таблицей, по которой все наборы индексов строить не оптимально. Разделение на секции дало многократный рост производительности, поскольку запросы обращаются к относительно небольшим интервалам временнЫх меток данных. Теперь мне интересно проверить - как изменится план и производительность, если я уберу секции и оставлю тот же кластерный индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2019, 16:43 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовВы имеете в виду поиск диапазона в кластерном индексе?В любом, не требующем лукапов. Возможность позиционирования по секции или по индексу определяется саргабельностью предиката. В случае допустимости неявного приведения типов, саргабельность предиката зависит от приоритетов типов левой и правой части предиката. Если тип справа приоритетнее - потребуется явное приведение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2019, 17:38 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
felix_ffкак по мне плюшки исключения секций в плане сайдэффекта увеличения производительности можно сравнивать только в случае сканирования индекса.Ваш пример очень искусственный. И без форсирования сканирования не работает. Но в реальности увеличение производительности при секционировании вполне возможно. Например, когда столбец секционирования не первый в индексе. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2019, 18:30 |
|
||
|
Вступление в партицирование
|
|||
|---|---|---|---|
|
#18+
Владислав Колосовfelix_ff, у меня как раз ситуация с большим количеством ad hoc запросов и достаточно широкой таблицей, по которой все наборы индексов строить не оптимально. Разделение на секции дало многократный рост производительности, поскольку запросы обращаются к относительно небольшим интервалам временнЫх меток данных. Теперь мне интересно проверить - как изменится план и производительность, если я уберу секции и оставлю тот же кластерный индекс. так если вам "помогло" секционирование, то ключ секционирования присутствовал во всех where. значит, дата есть во всех этих таблицах и кластерный по дате вам обеспечил бы ровно такой же выборочный просмотр диапазона ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2019, 19:23 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39782906&tid=1688161]: |
0ms |
get settings: |
10ms |
get forum list: |
21ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
72ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
85ms |
get tp. blocked users: |
2ms |
| others: | 235ms |
| total: | 447ms |

| 0 / 0 |
