ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / update. простой. медленно работает
25 сообщений из 26, страница 1 из 2
  1  все
update. простой. медленно работает
    #39970992
Shut-Up
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shut-Up
Участник
Всем привет


простой 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, 16:25
| Ответить | Цитировать | Написать  
update. простой. медленно работает
    #39971012
felix_ff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
felix_ff
Участник
Shut-Up,

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

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

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

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



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


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

У меня есть план в plan explorer данного запроса. прикладываю.
...
Рейтинг: 0 / 0
19.06.2020, 17:19
| Ответить | Цитировать | Написать  
update. простой. медленно работает
    #39971023
Shut-Up
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shut-Up
Участник
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:25
| Ответить | Цитировать | Написать  
update. простой. медленно работает
    #39971024
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_voronin
Участник
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:27
| Ответить | Цитировать | Написать  
update. простой. медленно работает
    #39971025
Shut-Up
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shut-Up
Участник
a_voronin, привет

попробую
...
Рейтинг: 0 / 0
19.06.2020, 17:29
| Ответить | Цитировать | Написать  
update. простой. медленно работает
    #39971026
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_voronin
Участник
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:29
| Ответить | Цитировать | Написать  
update. простой. медленно работает
    #39971031
msLex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
msLex
Участник
a_voronin
Слово Columnstore вам знакомо?

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


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

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



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

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

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

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

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

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

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

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


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

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


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


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

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


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

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

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

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

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

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


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

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


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

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

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



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

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


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

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

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




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

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


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

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

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

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

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

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

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

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

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

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

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


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