Гость
Войти | Профиль | Очистить
Действия ...
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / update. простой. медленно работает / 25 сообщений из 26, страница 1 из 2
  1  все
19.06.2020, 16:25
    #39970992
Shut-Up
Shut-Up
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
Всем привет


простой update выполняется в процедуре, которая запускается из очереди сервис брокера.
Процедура работает почти постоянно от 3 до 20 секунд.
Периодически этот простой update выполняется очень медленно

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
IF OBJECT_ID('tempdb..#A') IS NOT NULL DROP TABLE #A
CREATE TABLE #A
(
  <...>
  [A]    Numeric(28,12)      NULL
, [B]    Numeric(38,12)      NULL
, [C]    Numeric(38,12)      NULL
, [D]    Numeric(38,12)      NULL
  [A1]   Numeric(28,12)      NULL
, [B2]   Numeric(38,12)      NULL
, [C3]   Numeric(38,12)      NULL
, [D4]   Numeric(38,12)      NULL
  <...>
)

<...>

UPDATE #A
SET [A1] = [A] 
  , [B2] = [B] 
  , [C3] = [C] 
  , [D4] = [D] ;



Когда все плохо план не радует, прикрепил снимком.

На текущий момент добавил полное обновление статистики временной таблицы перед апдейтом с FULLSCAN, ALL. Стало получше, но всеравно плохо - 10к записей - update 20-40 секунд.

Microsoft SQL Server 2016 (SP2-CU12) (KB4536648) - 13.0.5698.0 (X64)

Возможно есть мысли?

Всю голову сломал уже.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2020, 17:06
    #39971012
felix_ff
felix_ff
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
Shut-Up,

Покажите актуальный план запроса в формате .sqlplan

И у вас изменение строк во временной таблице источником данных является она же? или какая то другая таблица?

интересует именно что у вас написано во

Код: sql
1.
2.
3.
update #A
...
FROM <= вот тут



и не плохо бы показать предикаты соединения/фильтрации
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2020, 17:19
    #39971020
Shut-Up
Shut-Up
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
felix_ff, привет


update выглядит именно так, как в исходном письме без инструкции FROM.

У меня есть план в plan explorer данного запроса. прикладываю.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2020, 17:25
    #39971023
Shut-Up
Shut-Up
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
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.
  IF OBJECT_ID('tempdb..[#A]') IS NOT NULL DROP TABLE [#A]
  CREATE TABLE [#A]
  (
    [U]                     Int             NOT NULL Identity(1, 1)
  , [K1]                    Int             NOT NULL
  , [K2]                    Int             NOT NULL
  , [K3]                    Int             NOT NULL Default(0)
  , [K4]                    SmallInt        NOT NULL
  , [K5]                    Int             NOT NULL
  , [K6]                    Int             NOT NULL Default(0)
  , [Else]                  Int             NOT NULL Default(0)
  , [K7]                    Int             NOT NULL
  , [K8]                    Int             NOT NULL
  , [K9]                    Int             NOT NULL
  , [K10]                   Int             NOT NULL
  , [A]                     Numeric(28,12)      NULL
  , [A1]                    Numeric(28,12)      NULL Default(0)
  , [Else1]                 Bit             NOT NULL Default(0)
  , [B]                     Numeric(38,12)      NULL
  , [C]                     Numeric(38,12)      NULL
  , [D]                     Numeric(38,12)      NULL
  , [Else2]                 Numeric(38,12)      NULL
  , [Else3]                 Numeric(38,12)      NULL
  , [B2]                    Numeric(38,12)      NULL
  , [C3]                    Numeric(38,12)      NULL
  , [C4]                    Numeric(38,12)      NULL
    PRIMARY KEY CLUSTERED ([K1], [K2], [K3], [K4], [K5], [K6], [K7], [K8], [K9], [K10])
  , UNIQUE ([U])
  )
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2020, 17:27
    #39971024
a_voronin
a_voronin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
Shut-Up,

добавьте проверку и будет вам счастье

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
UPDATE #A
SET [A1] = [A] 
  , [B2] = [B] 
  , [C3] = [C] 
  , [D4] = [D] 
WHERE 
   ( [A1] <> [A]  OR ([A1] is null and [A] IS NOT NULL) or ([A1] is NOT null and [A] IS NULL) ) or 
-- ... BCD аналогично 
;
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2020, 17:29
    #39971025
Shut-Up
Shut-Up
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
a_voronin, привет

попробую
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2020, 17:29
    #39971026
a_voronin
a_voronin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
Shut-Up
felix_ff,

таблица, в обезличенном виде, имеет следующее объявление

Код: sql
1.
    PRIMARY KEY CLUSTERED ([K1], [K2], [K3], [K4], [K5], [K6], [K7], [K8], [K9], [K10])



о-о!!! вы знаете толк в извращениях способах сделать обновление максимально медленным.

Слово Columnstore вам знакомо?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2020, 17:37
    #39971031
msLex
msLex
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
a_voronin
Слово Columnstore вам знакомо?

опять вы про колумнсторе в update?
забудьте это слово от вас оно уже звучит как ругательство


как размер ключа кластерного индекс влияет на скорость апдейта? В плане все равно скан и ни одно из полей входящих в ключ не апдейтится.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2020, 17:42
    #39971035
a_voronin
a_voronin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
msLex
a_voronin
Слово Columnstore вам знакомо?

опять вы про колумнсторе в update?
забудьте это слово от вас оно уже звучит как ругательство



Не могу забыть, я на вертике работаю, а там не-колумнсторов нет. А с переходом в облака и в mssql не будет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2020, 19:03
    #39971054
alexeyvg
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
a_voronin
msLex
пропущено...

опять вы про колумнсторе в update?
забудьте это слово от вас оно уже звучит как ругательство

Не могу забыть, я на вертике работаю, а там не-колумнсторов нет. А с переходом в облака и в mssql не будет.
В MSSQL переход в облака состоялся, и что то там от индексов не отказывались.

Вертика - не универсальная СУБД, она другие не заменит, даже одну из тысячи, она для очень узкой, специальной области применения.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2020, 20:50
    #39971089
komrad
komrad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
a_voronin

Не могу забыть, я на вертике работаю, а там не-колумнсторов нет. А с переходом в облака и в mssql не будет.

в облаках mssql колумнсторы тоже есть
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2020, 21:03
    #39971093
alexeyvg
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
komrad
a_voronin

Не могу забыть, я на вертике работаю, а там не-колумнсторов нет. А с переходом в облака и в mssql не будет.

в облаках mssql колумнсторы тоже есть
Имеется в виду, что в новой версии уберут индексы.
Поиска не будет, будет только сканирование колумнсторов.
Это, в смысле, не заявление MS, это прогноз a_voronin :-)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2020, 22:20
    #39971110
felix_ff
felix_ff
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
Shut-Up
felix_ff, привет


update выглядит именно так, как в исходном письме без инструкции FROM.

У меня есть план в plan explorer данного запроса. прикладываю.


сорри, просмотрел что у вас update на ";" заканчивается, беглым глазом подумал что продолжение Вам влом писать было.


Имхо в таком случае у ТС мало шансов что либо подкрутить что бы было быстрее, ибо там всегда будет скан всего индекса.

Причем для апдейта строки сиквелу потребуется зафетчить помимо значений [A1], [A], [B2], [B], [C3], [C], [D4], [D] еще колонки первичного ключа, а он не маленький, вполне возможно имело бы смысл сделать кластерный индекс с ключем только по полю [U]
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2020, 22:34
    #39971112
msLex
msLex
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
felix_ff
Причем для апдейта строки сиквелу потребуется зафетчить помимо значений [A1], [A], [B2], [B], [C3], [C], [D4], [D] еще колонки первичного ключа,


Вы так говорите, будто значения полей, входящих в ключя, находятся где-то отдельно от остальных полей.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2020, 22:42
    #39971115
felix_ff
felix_ff
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
msLex,

нет, я к тому что был бы ключ меньше сервер оперировал несколько меньшим объемом данных
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2020, 23:10
    #39971125
msLex
msLex
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
felix_ff
msLex,

нет, я к тому что был бы ключ меньше сервер оперировал несколько меньшим объемом данных

За счёт чего? На листовом, а при скане читается только он, лежат одни и те же данные в не зависимости от размера ключа.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2020, 23:15
    #39971127
Shut-Up
Shut-Up
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
друзья, проблема в том, что я не понимаю физической сущности этого явления. может кто-нибудь прольет свет?

в принципе в крайнем случае я могу избавиться от данного апдейта путем перелопачивания кода.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.06.2020, 23:23
    #39971132
msLex
msLex
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
Shut-Up
друзья, проблема в том, что я не понимаю физической сущности этого явления. может кто-нибудь прольет свет?

в принципе в крайнем случае я могу избавиться от данного апдейта путем перелопачивания кода.


Так чем хороший план отличается от плохого?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.06.2020, 00:17
    #39971141
Shut-Up
Shut-Up
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
msLex
Shut-Up
друзья, проблема в том, что я не понимаю физической сущности этого явления. может кто-нибудь прольет свет?

в принципе в крайнем случае я могу избавиться от данного апдейта путем перелопачивания кода.


Так чем хороший план отличается от плохого?
я не пойму в чем проблема. есть таблица с кластерным индексом. есть 4 поля которые обновляются значениями из этой же таблицы, их соседних полей тех же типов. изи кейс же для компилятора. в 99% случаев этот запрос работает 0 сек. я грешу на tempdb. но толку от этого мало. проблема плавающая. ежедневная очистка кэша tempdb тоже не принесла результатов.

на текущий момент единственный результат принесла операция

Код: sql
1.
UPDATE STATISTICS [#A] WITH FULLSCAN, ALL



но полностью проблема не ушла. в пиковые минуты проблем время выполнения сократилось в три раза. но это далеко не моментально.

поэтому вопрос чем плохой план отличается от хорошего, не приближает меня к ответу. почему он стал плохим?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.06.2020, 00:24
    #39971142
msLex
msLex
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
Shut-Up
msLex
пропущено...


Так чем хороший план отличается от плохого?
я не пойму в чем проблема. есть таблица с кластерным индексом. есть 4 поля которые обновляются значениями из этой же таблицы, их соседних полей тех же типов. изи кейс же для компилятора. в 99% случаев этот запрос работает 0 сек. я грешу на tempdb. но толку от этого мало. проблема плавающая. ежедневная очистка кэша tempdb тоже не принесла результатов.

на текущий момент единственный результат принесла операция

Код: sql
1.
UPDATE STATISTICS [#A] WITH FULLSCAN, ALL




но полностью проблема не ушла. в пиковые минуты проблем время выполнения сократилось в три раза. но это далеко не моментально.

поэтому вопрос чем плохой план отличается от хорошего, не приближает меня к ответу. почему он стал плохим?


Что бы понять, почему план стал плохим, нужно увидеть отличия между плохим и хорошим планом.
Вы привели только 1 план (это, кстати, "хороший" или "плохой"? ). Если планы запросов не отличаются, то проблемы условно внешние: нагрузка на темпдб, её лог, загрузка cpu, нехватка памяти и т.д.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.06.2020, 00:29
    #39971143
felix_ff
felix_ff
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
Shut-Up
msLex
пропущено...


Так чем хороший план отличается от плохого?
я не пойму в чем проблема. есть таблица с кластерным индексом. есть 4 поля которые обновляются значениями из этой же таблицы, их соседних полей тех же типов. изи кейс же для компилятора. в 99% случаев этот запрос работает 0 сек. я грешу на tempdb. но толку от этого мало. проблема плавающая. ежедневная очистка кэша tempdb тоже не принесла результатов.

на текущий момент единственный результат принесла операция

Код: sql
1.
UPDATE STATISTICS [#A] WITH FULLSCAN, ALL



но полностью проблема не ушла. в пиковые минуты проблем время выполнения сократилось в три раза. но это далеко не моментально.

поэтому вопрос чем плохой план отличается от хорошего, не приближает меня к ответу. почему он стал плохим?


по идее у Вас не может быть "плохого" и "хорошего" планов.
в любом случае у вас план запроса при вашем варианте написания запроса всегда будет clustered index scan => clustered index update;

даже если предположить условие что вкорячив update statics вы каждый раз выстраиваете актуальную гистограмму распределения + вектор, я не вижу почему она может принести профит в запрос. там нет операторов сортировки или выделения явного выдения памяти на которые могло бы повлиять предположение оптимизатора каким количеством строк он будет оперировать.

при этом фактор блокировок на таблице имхо тоже не стоит рассматривать, поскольку у вас всегда будет получение X => на таблицу + SchS


add: у Вас на скриншоте превалирует ожидание по SOS_SCHEDULER_YIELD, я так полагаю вам просто не везет в некоторые моменты нарваться что бы ваш запрос ушел на наиболее загруженный worker
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.06.2020, 00:55
    #39971146
Shut-Up
Shut-Up
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
msLex,

планы одинаковые за исключение Actual и Estimated Rows.
я с таким сталкиваюсь впервые.

неужели сложно обновить 4 столбца типа намерик у 10к записей в разрезе одной кластерной таблицы? видимо бывают ситуации когда это становится сложно. фрагментация tempdb? вот не думаю.

с процом и памятью все ок. грешил на память сделали х2. грешил на проц увеличили - сейчас пик CPU это 50%.

в итоге сошлись с ДБА на том, что добавим в запрос хинт QUERY_PLAN_PROFILE и наберем больше статистики.

msLex, доброй ночи. спасибо
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.06.2020, 01:02
    #39971147
Shut-Up
Shut-Up
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
felix_ff

add: у Вас на скриншоте превалирует ожидание по SOS_SCHEDULER_YIELD, я так полагаю вам просто не везет в некоторые моменты нарваться что бы ваш запрос ушел на наиболее загруженный worker
вот в этом месте можешь меня ткнуть носом куда копать? возможно есть изи кейс как избежать этого невезения?

доброй ночи, я на сегодня афк.

спасибо вам всем друзья за помощь!
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.06.2020, 02:32
    #39971153
felix_ff
felix_ff
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
Shut-Up
felix_ff

add: у Вас на скриншоте превалирует ожидание по SOS_SCHEDULER_YIELD, я так полагаю вам просто не везет в некоторые моменты нарваться что бы ваш запрос ушел на наиболее загруженный worker
вот в этом месте можешь меня ткнуть носом куда копать? возможно есть изи кейс как избежать этого невезения?

доброй ночи, я на сегодня афк.

спасибо вам всем друзья за помощь!


Ваша проблема это сверических конь в вакууме.
Я не могу со 100% гарантией утверждать что либо, мои высказывания - это просто предположение.

Копать в сторону улучшения если брокеру действительно не везет попадая на загруженные workerы - это попробовать использовать для него resource governor.
Но прежде чем констатировать факт в чем либо Вам нужно проанализировать счетчики производительности на наличие каких либо отклонений от средних значений, что бы понимать что именно в момент когда ваш запрос "подвисает" вызывает проблемы.

Основное направление это Access Methods, Memory Manager, Memory Broker Clerks, IO Reads/Writes, Latches.

Может более знающие люди внесут ясности, но пока Вы предоставили данных столько что можно только гадать что там у Вас происходит.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
20.06.2020, 11:47
    #39971189
invm
invm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
update. простой. медленно работает
Shut-Up,

1. Обновление статистики не может влиять на время выполнения. Оно влияет на построение плана. И, в данном случае, даже на план не влияет, ибо он будет с уровнем оптимизации TRIVIAL, т.к. другого плана быть не может.

2. В самом запросе тормозить нечему, так что а) проверьте не относится ли процедура активации к какой-нибудь группе рабочей нагрузки с урезанными ресурсами и б) коллекционируйте актуальные планы и анализируйте в них статистику ожиданий.
Например, в стартовом посте у вас имеет место ожидание CPU на почти 5 сек - SOS_SCHEDULER_YIELD ( https://www.sqlskills.com/help/waits/sos_scheduler_yield/)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / update. простой. медленно работает / 25 сообщений из 26, страница 1 из 2
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 157ms
Закрыть
start [/forum/topic.php?fid=46&mobile=1&tid=1685970]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 46ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 50ms
get tp. blocked users:
 2ms
others: 16ms
total:  157ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]