Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
juwdoks Member Откуда: Сообщений: 144 |
есть вьюха на основе нескольких cte к крупным секционированным таблицам и куче мелких left join секции по датам данные выбираются в файл через dts путём склеивания колонок в один стринг с разделителем "|" и приведением всех полей кастом к варчару переменной длины (весь этот процесс не в моей власти) app получает данные за 2 часа и пишет в файл ( при этом прямой запрос к вьюхе проходит за 10 минут) но проблема вот какая: на новом, более мощном (значительно) железе с точно таким же конфигом sqlserver (различия только по тому, что зависит от железа) - dts не может прогнать запрос вообще (сборка в одну колонку не работает ни через dts ни напрямую в ssms) прямой запрос к вьюхе работает - выполняется 10 минут статистику проверял - всё свежее при maxdop 1 запрос вроде начинает шевелиться, но всё равно вист сутками, копит actual_reads и ничего не выдаёт новый сервер на 2014 sp1 без кумулятивных куда можно ещё посмотреть? может есть какой-то нюанс типа недавно исправленного бага смерти статистики при ребилде индексов на секционированных таблицах? https://support.microsoft.com/en-us/help/3194959/statistics-are-removed-after-rebuilding-a-specific-partition-of-an-partitioned-aligned-index-on-a-partitioned-table-in-sql-server запрос, пришедший из dts висит с вейтом cxpacket и не проявляет признаков жизни, нулевой reads |
21 фев 17, 01:13 [20231301] Ответить | Цитировать Сообщить модератору |
Mr. X
Guest |
juwdoks, Смотреть в строну CU для начала. |
21 фев 17, 06:49 [20231412] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8488 |
https://support.microsoft.com/en-us/help/2413549/using-large-amounts-of-memory-can-result-in-an-inefficient-plan-in-sql-server Попробуйте использовать руководство планов, принудительно прикрепив найденный эффективный план к запросу в представлении. |
21 фев 17, 10:25 [20231867] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
juwdoks, Trace Flag : 9481 пробуйте включить и смотреть. вернёт "старый" cardinality estimator |
21 фев 17, 10:31 [20231901] Ответить | Цитировать Сообщить модератору |
juwdoks Member Откуда: Сообщений: 144 |
спасибо за варианты, буду тестить 2335 пока прав нет особо, а для трейсфлагов нужно sysadmin (( если ничего не изменится - попробую 9481 |
23 фев 17, 17:50 [20240144] Ответить | Цитировать Сообщить модератору |
Ролг Хупин Member Откуда: Чебаркуль Сообщений: 4072 |
[quot juwdoks]спасибо за варианты, буду тестить 2335 пока прав нет особо, а для трейсфлагов нужно sysadmin (( если ничего не изменится - попробую 9481[/quot В названии темы "и старшем sqlserver " видимо надо читать "и младшем sqlserver " |
23 фев 17, 19:48 [20240354] Ответить | Цитировать Сообщить модератору |
juwdoks Member Откуда: Сообщений: 144 |
да, так будет точнее но вроде как понятно, что речь идёт о номере версии ) |
23 фев 17, 20:01 [20240380] Ответить | Цитировать Сообщить модератору |
juwdoks Member Откуда: Сообщений: 144 |
T2335 ситуацию не изменил запрос выполнился за 5 часов на sqlserver 2014: select Column1 from ( select 'col1|col2|...|col110' as Column1 union all select isnull(cast(col1 as varchar(50)),'') + '|' + isnull(cast(col2 as varchar(100)),'') + '|' + isnull(cast(col3 as varchar(1)),'') + '|' + isnull(cast(col4 as varchar(128)),'') + '|' + ... isnull(cast(col110 as varchar(50)),'') from View1 (nolock) where col2=1 ) T выполнился только с option (maxdop 1) аналогичный запрос на 2008r2 выполняется за 20 минут (без указания maxdop) выбор полей обычным рекордсетом без кастов - 10 минут на обоих серверах во что ещё может упираться? T9481 ещё не пробовал, хлчется локализовать проблему/решение более конкретно |
25 фев 17, 20:23 [20243585] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
это же хорошо, что и в студии воспроизводится, покажите оба плана: просто выборки и выборки с конкатенацией |
||
25 фев 17, 21:36 [20243711] Ответить | Цитировать Сообщить модератору |
juwdoks Member Откуда: Сообщений: 144 |
похоже, что T2335 всё-таки помог запрос начал вращаться сторого в рамках ожидаемого расчётного времени почему сразу не получилось - не знаю в субботу висело 5 часов, в воскресенье заработало нормально ещё буду перепроверять, но уже сдвиг позитивный огромное спасибо ещё раз, особенно Владиславу Колосову! |
27 фев 17, 17:02 [20248070] Ответить | Цитировать Сообщить модератору |
o-o
Guest |
видимо, только теоретически хочется. почему было не сравнить эффективный и неэффективный планы? наверное, все же приятнее гадать... "вчера вроде флаг не помог, а сегодня вроде помог", ... Но тут лиса бежала, А может, не бежала, А может, это страус злой, А может, и не злой. А может, это дворник был... |
||
27 фев 17, 17:16 [20248118] Ответить | Цитировать Сообщить модератору |
juwdoks Member Откуда: Сообщений: 144 |
когда получу SentryOne Plan Explorer - сравню сейчас это не очень удобно |
27 фев 17, 17:21 [20248142] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
juwdoks, и вдогонку вашего непонимания что же кардинально изменилось 2014 в 2014 новый механизм оценки, который неожиданно и влияет на ваш параллелизм (выполнился только с option (maxdop 1)) прививание флагом на планы с меньшими ресурсами и тп. я ж говорю отрубите его совсем (TF9481 ) и не мучайтесь, ведь запросы вы оптимизировать не планируете
хоть до sp2 доведите на всякий случай |
||
27 фев 17, 17:23 [20248146] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
мдааааа уж... кстати 2016 SSMS умеет сравнивать, хотя в жизни сравнивал только глазами :( |
||
27 фев 17, 17:25 [20248153] Ответить | Цитировать Сообщить модератору |
juwdoks Member Откуда: Сообщений: 144 |
TaPaK, даже с maxdop 1 запрос не отрабатывал по флагу T2335 от ms разве есть подробное объяснение? на сроки обновления до CU2/3 я не могу повлиять насчёт "хочется локализовать проблему/решение более конкретно" - это я писал в отношении T9481 |
27 фев 17, 17:39 [20248203] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
и вы её локализовали? чем? 2335 смех и грех |
||
27 фев 17, 17:44 [20248211] Ответить | Цитировать Сообщить модератору |
juwdoks Member Откуда: Сообщений: 144 |
послушайте, есть базовый запрос, который выполняется одинаково хорошо на 2008 и на 2014 проблемный запрос тот, который собирает рекордсет в один стринг и по нему не просто плохой план, а запрос тупо висит на cxpacket без активности да, вопрос удалось решить (надеюсь) пока что флагом 2335 - что тут такого криминального? |
27 фев 17, 17:53 [20248236] Ответить | Цитировать Сообщить модератору |
juwdoks Member Откуда: Сообщений: 144 |
sp2 стоит, не знаю зачем я соврал |
27 фев 17, 17:54 [20248241] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
juwdoks,
|
||
27 фев 17, 17:55 [20248245] Ответить | Цитировать Сообщить модератору |
juwdoks Member Откуда: Сообщений: 144 |
у нас разные cost-based версии оценки сути проблем ваша версия новее и круче я подтянусь |
27 фев 17, 18:31 [20248375] Ответить | Цитировать Сообщить модератору |
iap Member Откуда: Москва Сообщений: 47063 |
|
||
27 фев 17, 19:26 [20248494] Ответить | Цитировать Сообщить модератору |
juwdoks Member Откуда: Сообщений: 144 |
этим меня уже попинали |
27 фев 17, 19:33 [20248506] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |