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

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

Откуда: Moscow
Сообщений: 36965
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

Откуда:
Сообщений: 7754
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

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

не бывает чудес.
6 июн 17, 15:39    [20543768]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить