Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3      [все]
 Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Столкнулся с непонятной ситуацей. Есть простой джойн на три таблички, с индексами и всей хурмой, результаты которого льются в #Tmp.

Размер данных крохотный, ~50 строк на 400кб. При этом вставка длиться примерно полторы минуты ( 32 ядра и дофигалион оперативки) и занимает 80(!) процентов от всего INSERT...SELECT .

Попробовал #Tmp поменять на @Tmp, результат такой же.

Не связано ли эта хурма с неверными оценками?
План запроса показывает, что ожидается для инсерта 80000 строк на 650 мегабайт, а приходит 50 на 400кб.

Куда копать, товарищи?
6 июн 17, 11:33    [20542662]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Вы актуальный план покажите, хватит его пересказывать своими словами.
6 июн 17, 12:18    [20542856]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
AlanDenton
Member [скрыт]

Откуда:
Сообщений: 1004
Скрипт покажите того, что вы пытаетесь вставить во временную таблицу
6 июн 17, 12:22    [20542875]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
o-o
Guest
автор
Размер данных крохотный, ~50 строк на 400кб. При этом вставка длиться примерно полторы минуты

представляете, а у нас вообще одна таблица, даже не 3.
правда она 400Гб, но кому это важно.
мы подсчитываем жалкий count(*) с тучей условий.
так вот, если вставить результат в темповую таблицу, то ожидается всего 1 строка.
и это правильная оценка.
но вставляется полчаса
(или все же читается полчаса, а вставляется моментально, не?)
6 июн 17, 12:34    [20542935]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Я не очень представляю как сюда сунуть именно этот кусок плана запроса.
Но судя по SqlSentry PlanExporer именно вставка весит много.
6 июн 17, 13:36    [20543224]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
AlanDenton,Ну какой вам толк от скрипта с конкретной промбазы?
6 июн 17, 13:36    [20543227]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6802
Cammomile,

автор
Я не очень представляю как сюда сунуть именно этот кусок плана запроса.
Но судя по SqlSentry PlanExporer именно вставка весит много
AlanDenton,Ну какой вам толк от скрипта с конкретной промбазы?

ну что ж, достаём шары и начинаем предсказывать: обновите статистику
6 июн 17, 13:39    [20543240]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Яж не упираюсь, просто вся XML плана весит столько сколько движок форума постить не дает.
6 июн 17, 13:41    [20543248]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
aleks2
Guest
Cammomile
Яж не упираюсь, просто вся XML плана весит столько сколько движок форума постить не дает.


Простенький запрос, да...

Страдалец, план - не нужен.
У тя запрос кривее сабли янычара.
6 июн 17, 13:46    [20543271]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
aleks2, много ехидства. План у меня от хранимки с миллионом запросов, один из них "простенький".
Поскольку лично я в XML планах не ориентируюсь, я и пишу что не понимаю как оттудова достать "значимую" часть.
6 июн 17, 13:48    [20543280]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
aleks2
Guest
Cammomile
aleks2, много ехидства. План у меня от хранимки с миллионом запросов, один из них "простенький".
Поскольку лично я в XML планах не ориентируюсь, я и пишу что не понимаю как оттудова достать "значимую" часть.


101% проблем кривого запроса решается без всяких планов.
Заканчивай жевать сопли и копируй запрос.
6 июн 17, 13:52    [20543295]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
o-o
Guest
Cammomile
Яж не упираюсь, просто вся XML плана весит столько сколько движок форума постить не дает.

зипьте.
планы хорошо сжимаются
6 июн 17, 13:55    [20543302]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
INSERT INTO #BaseContactInfo 
 

    SELECT  
      c_regstatus = LTRIM(RTRIM(ABE.c_regstatus))
    , c_abonentId = LTRIM(RTRIM(AB.c_abonentId))  
    , c_HeadName = LTRIM(RTRIM(ABE.c_HeadName)) 
    , c_heademail = LTRIM(RTRIM(ABE.c_heademail))
    , c_headfax = LTRIM(RTRIM(ABE.c_headfax))
    , c_headphone = LTRIM(RTRIM(ABE.c_headphone))
    , c_headposition = LTRIM(RTRIM(ABE.c_headposition))
    , c_contactfio = LTRIM(RTRIM(ABE.c_contactfio))
    , c_contactemail = LTRIM(RTRIM(ABE.c_contactemail))
    , c_contactfax = LTRIM(RTRIM(ABE.c_contactfax))
    , c_contactphone = LTRIM(RTRIM(ABE.c_contactphone))
    , c_contactposition = LTRIM(RTRIM(ABE.c_contactposition))
    , c_inn = LTRIM(RTRIM(ABE.c_inn))
    , c_accountid = ABE.c_accountid 
    , ParentCustomerIdName = LTRIM(RTRIM(ACC.[Name]))

    , HeadFirstName = PARSENAME(REPLACE(LTRIM(RTRIM(ABE.c_HeadName)), ' ', '.'), 2 ) 
    , HeadMiddleName = PARSENAME(REPLACE(LTRIM(RTRIM(ABE.c_HeadName)), ' ', '.'), 1 ) 
    , HeadLastName = PARSENAME(REPLACE(LTRIM(RTRIM(ABE.c_HeadName)), ' ', '.'), 3 ) 
 
    , PrimaryContactFirstName = PARSENAME(REPLACE(LTRIM(RTRIM(ABE.c_contactfio)), ' ', '.'), 2 )   
    , PrimaryContactMiddleName  = PARSENAME(REPLACE(LTRIM(RTRIM(ABE.c_contactfio)), ' ', '.'), 1 ) 
    , PrimaryContactLastName  = PARSENAME(REPLACE(LTRIM(RTRIM(ABE.c_contactfio)), ' ', '.'), 3 ) 

    , VersionNumber  = AB.VersionNumber
   
    FROM 
      MSCRM.dbo.c_abonentBase AB   
      INNER JOIN  MSCRM.dbo.c_abonentExtensionBase ABE ON ABE.c_abonentId = AB.c_abonentId
      INNER JOIN MSCRM.dbo.AccountBase ACC ON ACC.AccountId = ABE.c_accountid 
    WHERE
      1 = 1 
      AND AB.statuscode = 1 
      AND AB.statecode = 0
      AND ABE.c_sTage = @c_stage
      AND ABE.c_type <> @EdoType 
      AND ABE.c_type <> @CashdeskType 
      
      AND Ab.VersionNumber > @LastFixedVersionNumber
      /*DEBUG*/
      /*AND ABE.c_accountid = '97A93EB6-4AAF-4250-AAE4-5521C96A57CF' */
    OPTION (RECOMPILE , MAXDOP 1)
6 июн 17, 13:56    [20543306]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
o-o
Guest
"32 ядра", MAXDOP 1
-----
вы за полторы минуты ожидания не посмотрели что ли?
6 июн 17, 14:00    [20543318]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Очень много ехидства чую я. С параллелизмом оно работает вместо полутора минут 2.5 минуты.

Я ж тут погроммист, а не скульдб админ. Яхз, что на продакшене накручено, если честно. Максдоп поставил эмпирическим путем.
6 июн 17, 14:02    [20543321]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
А главное, повторяю еще раз, план запроса показывает что вот весь этот инсерт весит 96% от хранимки , а из 96% 75% это именно вставка.
6 июн 17, 14:04    [20543330]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Cammomile
А главное, повторяю еще раз, план запроса показывает что вот весь этот инсерт весит 96% от хранимки , а из 96% 75% это именно вставка.
Актуальный план запроса мы увидем сегодня? Не предварительный, где вся процедура, а именно актуальный для этого стейтмента.
6 июн 17, 14:05    [20543337]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
o-o
Guest
Cammomile
Очень много ехидства чую я. С параллелизмом оно работает вместо полутора минут 2.5 минуты.

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

нет ну я что ли про ядра пишу, типа 32,
а потом еще и ограничиваю?
это как писать "ваще у меня еще и личный вертолет,
и посадочная площадка на крыше офиса.
но помогите, плиз, советом, до работы добираюсь 3 часа,
то автобус ломается, то в пробке стоит".
---
план-то будете зипить или как?
6 июн 17, 14:05    [20543338]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
o-o
Guest
Cammomile
А главное, повторяю еще раз, план запроса показывает что вот весь этот инсерт весит 96% от хранимки , а из 96% 75% это именно вставка.

ну так посмотрите уже ожидания, может,
прочесть вы вообще не можете, сидите ожидаете окончание чей-то вставки,
и план, и инсерт, вообще тогда никаким боком
----
в оценочном плане все проценты вообще левые могут быть
6 июн 17, 14:08    [20543351]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Ура, я справился с планом.
6 июн 17, 14:10    [20543369]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
http://dropmefiles.com/kv0hL
6 июн 17, 14:12    [20543373]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
o-o
Guest
ну это только вам 93Кб к сообщению не прицепляют.
мы уж подумали, там черт знает что за план, мегабайты xml.
смотрите ожидания
6 июн 17, 14:21    [20543409]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Блин, я счаз полыхну. Как и куда смотреть ожидания?!

Я начал топик с того, что ожидания не такие как реально обработанные строки.

Но я НЕ ЗНАЮ, как это влияет и влияет ли вообще на вставку.

Какие я должен сделать выводы?
6 июн 17, 14:26    [20543428]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Cammomile
План у меня от хранимки с миллионом запросов, один из них "простенький".
...
весь этот инсерт весит 96% от хранимки , а из 96% 75% это именно вставка


Добрый день. Я правильно понимаю, что вы сделали следующее: получили план всей хранимой процедуры, далее, основываясь на процентах, которые отображает студия, выбрали тот где процентов показывается больше всего, а уже в этом запросе выбрали тот оператор на котором опять же больше всего процент?

Если так, то могу сказать, что "проценты", как и стоимость, основываются на оценках и не отражают реальность в случае, если оценки неверные. Такой подход мог бы быть полезным, если бы оценки всех планов в точности соответствовали реальности. Однако, в таких планах, когда оценки нормальные, проблемы как раз наблюдаются не так часто, поэтому, эти проценты больше путают, чем помогают. Если я правильно помню, даже был какой-то Item на Connect что-то с этим сделать или убрать совсем или что-то еще.

Так что прежде всего, если у вас в хранимке много запросов определите точно, на основе реального выполнения (а не стоимости), какой именно запрос тормозит, включите profiler или xEvents и посмотрите на duration-ы реальных запросов. Т.е. установите точно, что проблема именно в том запросе, на который вы смотрите.
6 июн 17, 14:26    [20543429]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Добрый! Да, именно так я и сделал. Выполнил хранимку с кнопкой "Включить действительный план выполнения".

Как проделать эту работу с помощью профайлера? Какие там надо выбрать галочки для отслеживания?
6 июн 17, 14:28    [20543439]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8740
Предполагаемый размер строки свыше 8кб, может из-за этого?
6 июн 17, 14:29    [20543444]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Cammomile
Блин, я счаз полыхну. Как и куда смотреть ожидания?!
Ожидания сессии можно смотреть в sys.dm_os_waiting_tasks
6 июн 17, 14:30    [20543448]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
o-o
Guest
Cammomile
Блин, я счаз полыхну. Как и куда смотреть ожидания?!

Я начал топик с того, что ожидания не такие как реально обработанные строки.

Но я НЕ ЗНАЮ, как это влияет и влияет ли вообще на вставку.

Какие я должен сделать выводы?

выводы такие, что представленный план нормальный,
пусть он и промахнулся маленько,
но где надо, хэш выбрал,
в остальных лупы в самый раз, строк немного.
моментально такое отработает.
и тут одно из двух:
или прав SomewhereSomehow, и не в этом куске кода дело.
или, если именно в этом, то висите вы на чтении,
не можете прочесть нужное, на блокировке висите.
и чтобы не гадать, возьмите и посмотрите, что именно и какой стэйтмент ждет
sys.dm_os_waiting_tasks join sys.dm_exec_sessions
6 июн 17, 14:32    [20543457]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Cammomile,

StoredProcedure - SP:StmtCompleted, SP:Completed
(можете также включить и Performance - Showplan XML Statistics Profile для сбора действительно плана по стейтментам).

Если вы на сервер не один и там идет активная работа, не забудьте поставить фильтры на колонки, например на ИД процедуры или на hostname, чтобы не разгребать кучу событий и не уронить сервер сбором всего этого добра и отправкой этого вам на клиента, также не забудьте потом остановить трассировку.
6 июн 17, 14:34    [20543468]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Значится посмотрел в профайлер.


Вся хранимка.
ЦПУ: 500 ЧТЕНИЯ:15400 ЗАПИСЬ: 51 ПРОДОЛЖИТЕЛЬНОСТЬ:1121 (запустил на небольшом количестве данных)
Обсуждаемый кусок кода:
ЦПУ: 359 ЧТЕНИЯ:14900 ЗАПИСЬ: 4 ПРОДОЛЖИТЕЛЬНОСТЬ:358

Выходит, что оно просто долго читает и ничего мне с этим не поделать?
6 июн 17, 14:41    [20543506]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Гавриленко Сергей Алексеевич
Cammomile
Блин, я счаз полыхну. Как и куда смотреть ожидания?!
Ожидания сессии можно смотреть в sys.dm_os_waiting_tasks


PAGEIOLATCH_SH
PAGEIOLATCH_EX

Как то тааак...
6 июн 17, 14:44    [20543518]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
aleks2
Guest
Ну, налетели плановые анализаторы!

1. Если у тредстартера воспроизводится 1.5 мин.
2. Какой, в задницу, анализ плана?
3. Пущай select без insert-а запустит и прослезится.
~50 строк студия стерпит.

4. А потом, расскажет нам какая из 2-х таблиц дает меньше всего строк на условия для нее.

Но ежели идти далее...
400кБ на строку * 50 строк = 20 000 кБ = 20 Мб
Запись этой хрени на диск в базу и журнал должна занимать ~2-3 сек.

ЗЫ. Ну и надо завязывать с LTRIM на выборке. Эти пробелы вам дороги как память? Обработайте таблицу раз и навсегда.
6 июн 17, 14:49    [20543538]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
автор
3. Пущай select без insert-а запустит и прослезится.
~50 строк студия стерпит.


Вот тут и загадка, селект без инсерта вообще пулей.

автор
Ну и надо завязывать с LTRIM на выборке. Эти пробелы вам дороги как память? Обработайте таблицу раз и навсегда.
Яб с радостью, только проблема в том, что местные погромисты CRM не могут закодить так, чтоб потом в эту таблицу не попадали пробелы. А спорить с ними у меня нервов нет.
6 июн 17, 14:54    [20543559]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8740
Cammomile,

и все же, если на каждое поле написать left(100), то есть гарантировать размер записи меньше 8000 байт - это даёт результат?
6 июн 17, 15:02    [20543584]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
автор
Вся хранимка. ПРОДОЛЖИТЕЛЬНОСТЬ:1121
Обсуждаемый кусок кода: ПРОДОЛЖИТЕЛЬНОСТЬ:358

Ну вот, вы сами убедились, что это же не 96% хранимки этот запрос? А где-то около 30%...

Посмотрите что там у вас еще есть. Нет ли каких-то мелких запросов, которые запускаются в цикле/курсоре? Что-то же занимает остальные 70% времени. Может быть это и не план вовсе, может быть блокировки, тогда надо ожидания смотреть более конкретно.

Касательно вашего плана, у вас там есть такая строчка:
CONVERT_IMPLICIT(bigint,[MSCRM].[dbo].[c_abonentBase].[VersionNumber] as [AB].[VersionNumber],0) > (2066235780)
Нужно бы либо тип колонки привести в порядок, либо предикат поиска, чтобы они совпадали.

А то во первых это у вас сильно искажает оценки, и приводит переоценке, отсюда памяти hash join требует аж около 790 мб, а использует около 2 мб. Это может влиять и на общее использование памяти в контексе всего сервера, если запросов несколько одновременно и на конкретно выделение памяти для одного запроса, ожидания типа resource_semaphore.

Во вторых напрашивается индекс по VersionNumber только с правильным типом, чтобы он не делал много чтений, а то у вас возвращается Actual Number Of Rows 318, а читается реально Number of Rows Read 761689. Если бы был индекс и не было неявного преобразования типов, т.е. он мог делать поиск, то читалось бы ровно столько, сколько нужно.

Но я бы начал с поиска того, что еще у вас в процедуре занимает столько времени. Мелких и часто повторяемых запросов например.
6 июн 17, 15:04    [20543588]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
aleks2
Guest
Cammomile
автор
3. Пущай select без insert-а запустит и прослезится.
~50 строк студия стерпит.


Вот тут и загадка, селект без инсерта вообще пулей.

автор
Ну и надо завязывать с LTRIM на выборке. Эти пробелы вам дороги как память? Обработайте таблицу раз и навсегда.
Яб с радостью, только проблема в том, что местные погромисты CRM не могут закодить так, чтоб потом в эту таблицу не попадали пробелы. А спорить с ними у меня нервов нет.


Я давно не верю в дедов морозов.
0. set statistics io on; set statistics time on;
1. Прямо в процедуре (или копии, если корежить основную нельзя) скопировать select из insert. Перед insert-ом.
2. В разумном количестве мест копии понатыкать select getdate(). Ну проблемный селест и инсерт обрамить хоть.
3. Запустить процедуру.
4. Узрить свет истины.
6 июн 17, 15:04    [20543589]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
o-o
Guest
Cammomile
PAGEIOLATCH_SH
PAGEIOLATCH_EX

Как то тааак...

там вообще-то еще указана база и конкретные страницы.
например, вот это вот PAGEIOLATCH_EX, это что, в темпдб что ли?
а у PAGEIOLATCH_SH и вовсе посмотреть, чьи страницы, что за объект.
ненормально запускать мизерные объемы и каждый раз с диска начитывать
-----
ну и кстати о перегруженных дисках темпдб, если все же его PAGEIOLATCH_EX.
не пробовали вместо вставки в темповую в постоянную попробовать?
6 июн 17, 15:15    [20543630]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
AlanDenton
Member [скрыт]

Откуда:
Сообщений: 1004
AND Ab.VersionNumber > @LastFixedVersionNumber

Посмотрите на план и тип переменной может поменяете, то у Вас из-за несоотвествия типов идет индекс скан

Картинка с другого сайта.

+ можно фильтрованный индекс на c_abonentBase добавить.
6 июн 17, 15:22    [20543669]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
SomewhereSomehow,

автор
Касательно вашего плана, у вас там есть такая строчка:
CONVERT_IMPLICIT(bigint,[MSCRM].[dbo].[c_abonentBase].[VersionNumber] as [AB].[VersionNumber],0) > (2066235780)
Нужно бы либо тип колонки привести в порядок, либо предикат поиска, чтобы они совпадали.

А то во первых это у вас сильно искажает оценки, и приводит переоценке, отсюда памяти hash join требует аж около 790 мб, а использует около 2 мб. Это может влиять и на общее использование памяти в контексе всего сервера, если запросов несколько одновременно и на конкретно выделение памяти для одного запроса, ожидания типа resource_semaphore.

БОГ ТЫ МОЙ, вот оно! ВОТ!
Спасибо добрый человек, новый план вообще тютелька-в-тютельку.
После того как обновил статистику 1,5 минуты стали в 25 секунд
После того как убрал этот конверт, 25 секунд превратились в 10.

Всем спасибо, всё это было очень позновательно.
6 июн 17, 15:22    [20543670]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
PS
Раньше не приходилось работать с timestamp и, по скудомию, мне казалось, что timestamp в bigint сервер сам отлично оптимизирует. Оказалось, что нет.
6 июн 17, 15:23    [20543676]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
AlanDenton
AND Ab.VersionNumber > @LastFixedVersionNumber

Посмотрите на план и тип переменной может поменяете, то у Вас из-за несоотвествия типов идет индекс скан

Картинка с другого сайта.

+ можно фильтрованный индекс на c_abonentBase добавить.

А что это за тулза вам такой важный ворнинг выдает?
6 июн 17, 15:25    [20543690]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
AlanDenton
Member [скрыт]

Откуда:
Сообщений: 1004
Cammomile, Plan Explorer. Недавно его сделали бесплатным, так что советую.
6 июн 17, 15:27    [20543706]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
ОТ sqlSentry? У меня стоит, там такого ворнинга нет. Да и вообще "всплывашка" совершенно иначе оформлена. Ставил две недели назад.
6 июн 17, 15:28    [20543713]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
AlanDenton
Member [скрыт]

Откуда:
Сообщений: 1004
Cammomile, билд последний. Так что увы не знаю что Вам тут ответить
6 июн 17, 15:29    [20543721]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
o-o
Guest
Cammomile
SomewhereSomehow,

автор
Касательно вашего плана, у вас там есть такая строчка:
CONVERT_IMPLICIT(bigint,[MSCRM].[dbo].[c_abonentBase].[VersionNumber] as [AB].[VersionNumber],0) > (2066235780)
Нужно бы либо тип колонки привести в порядок, либо предикат поиска, чтобы они совпадали.

А то во первых это у вас сильно искажает оценки, и приводит переоценке, отсюда памяти hash join требует аж около 790 мб, а использует около 2 мб. Это может влиять и на общее использование памяти в контексе всего сервера, если запросов несколько одновременно и на конкретно выделение памяти для одного запроса, ожидания типа resource_semaphore.

БОГ ТЫ МОЙ, вот оно! ВОТ!
Спасибо добрый человек, новый план вообще тютелька-в-тютельку.
После того как обновил статистику 1,5 минуты стали в 25 секунд
После того как убрал этот конверт, 25 секунд превратились в 10.

Всем спасибо, всё это было очень позновательно.

прикольно, что без инсерта и с теми же необновленными статистиками тот же скан "летал"
6 июн 17, 15:31    [20543731]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Возникает риторический вопрос. Почему мелгкомягкий оптимизатор не догадывается, что кастануть @Bigint в таймстемп дешевле чем кастить таймстмп в каждой строке к бигинту?
6 июн 17, 15:32    [20543735]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
автор
прикольно, что без инсерта и с теми же необновленными статистиками тот же скан "летал"

Может магия кэшей, может просто попадал в менее нагруженное время?
6 июн 17, 15:33    [20543742]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
o-o
Guest
Cammomile
Возникает риторический вопрос. Почему мелгкомягкий оптимизатор не догадывается, что кастануть @Bigint в таймстемп дешевле чем кастить таймстмп в каждой строке к бигинту?

вы ответьте лучше, как же это при тех же приводимых типах,
но без инсерта "летало"
6 июн 17, 15:35    [20543749]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Cammomile
автор
прикольно, что без инсерта и с теми же необновленными статистиками тот же скан "летал"

Может магия кэшей, может просто попадал в менее нагруженное время?

Боюсь, что на текущий момент уже не могу ответить.
6 июн 17, 15:36    [20543755]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8740
Cammomile,

не бывает чудес.
6 июн 17, 15:39    [20543768]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
o-o
Guest
Cammomile
автор
прикольно, что без инсерта и с теми же необновленными статистиками тот же скан "летал"

Может магия кэшей, может просто попадал в менее нагруженное время?

хорошо все же, что план вы научились выцеплять, прицеплять,
и что тут есть кто-то, кто удосужился его внимательно посмотреть.
а то вот есть любители страдальцев, уверенные на 101% что там ничего нужное нет
6 июн 17, 15:43    [20543788]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
aleks2
Guest
o-o
Cammomile
пропущено...

Может магия кэшей, может просто попадал в менее нагруженное время?

хорошо все же, что план вы научились выцеплять, прицеплять,
и что тут есть кто-то, кто удосужился его внимательно посмотреть.
а то вот есть любители страдальцев, уверенные на 101% что там ничего нужное нет


Ты мне щас расскажешь, что для обновления статистики и согласования типа переменной с полем фильтра - надо планы изучать?
Бред.
Запросы надо писать подумавши, а не "бери больше - кидай дальше".
6 июн 17, 19:05    [20544587]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
o-o
Guest
aleks2,
Ну ты-то всегда проверяшь типы соединяемого, верно? А как часто, вот прям каждый день или только у новых незнакомых таблиц? А никогда тебе не ресториди базу, где 5 лет подряд в таблице был ключ инт, а сегодня вдруг стал bigint?
И написанное ранее внезапно стало тормозить?
Или когда такое случается, план посмотреть это уголовно наказуемо?
6 июн 17, 19:26    [20544638]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
aleks2
Guest
o-o
aleks2,
Ну ты-то всегда проверяшь типы соединяемого, верно? А как часто, вот прям каждый день или только у новых незнакомых таблиц? А никогда тебе не ресториди базу, где 5 лет подряд в таблице был ключ инт, а сегодня вдруг стал bigint?
И написанное ранее внезапно стало тормозить?
Или когда такое случается, план посмотреть это уголовно наказуемо?


Да, я не ленюсь заглянуть в определение таблицы, шоп правильно написать тип фильтра.
И тебе советую.

Не, не ресторили.

Не припомню, шоб "тормозило".

Планы я смотрю тока от скуки - редко помогает.
В простых запросах - и так фсе ясно.
А в сложных - эффективнее переписать попроще, чем "статистику обновлять".
6 июн 17, 19:51    [20544685]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Ну вот тут у меня был такой простой запрос, что и в голову не пришло, что индусы из МС вместо того чтоб кастить переменную к полю, делают ровно наоборот.
6 июн 17, 21:52    [20544923]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
o-o
Guest
aleks2,
еще раз.
вот тебе ресторят базу каждый божий день (т.е. ночь)
а твои прескарасно написанные запросы, лазящие в ту базу, все правильные.
но в один прекрасный день тип в одной из таблиц поменялся, и тебе об этом не сказали.
и полетели твои планы, но ты об этом не ведаешь, ибо в планы не смотришь.
нехорошо получается, барин
----
у нас это вообще нормальная такая практика.
то колонка вдруг стала nullable,
то тип поменялся
(особенно прикольно это во вьюхах нерефрешенных наблюдать,
они в ОЕ показывают старый тип)
то они таблицу закомпрессят и планы снова летят, уже и типы все те же,
но план летит
6 июн 17, 22:41    [20545048]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
o-o
Guest
Cammomile
индусы из МС вместо того чтоб кастить переменную к полю, делают ровно наоборот.

при чем тут индусы-то,
есть же Data Type Precedence (Transact-SQL), побеждает тот тип, что в таблице "выше":
автор
When an operator combines two expressions of different data types,
the rules for data type precedence specify that the data type with the lower precedence is converted to the data type with the higher precedence.
If the conversion is not a supported implicit conversion, an error is returned.
When both operand expressions have the same data type, the result of the operation has that data type

select 1 +'1' что даст?
вроде из числа в строку всегда можно откастить, а вот строку в число нет.
но "побеждает" число.
но виновен не жираф индус, а тот, кто криво написал и понадеялся не пойми на что
6 июн 17, 22:55    [20545072]     Ответить | Цитировать Сообщить модератору
 Re: Долгий insert в #TempTable и странные эстимейшены  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8740
Надо не восклицать о, статистика! о, приведение типов! А сравнить планы тот, что был прислан ранее и тот, что получился сейчас и понять - на что же повлияло приведение типов. Потому что следствия этого могут привести в действия совершенно другой механизм.
7 июн 17, 10:48    [20545844]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3      [все]
Все форумы / Microsoft SQL Server Ответить