ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Операция update, сравнение производительности.
15 сообщений из 15, страница 1 из 1
Операция update, сравнение производительности.
    #39636312
NTDim
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NTDim
Участник
Добрый день!
По логике приложения каждый час проходит порядка 500 000 операций UPDATE по одной строке в транзакции.

Вопрос - на сколько сильно утяжеляет UPDATE каждое дополнительное поле ?
Скажем был UPDATE одного поля, стало два в одном запросе. Желательно более менее аргументированный ответ ...
...
Рейтинг: 0 / 0
25.04.2018, 18:58
| Ответить | Цитировать | Написать  
Операция update, сравнение производительности.
    #39636325
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
Проблема в нелинейности процессов и сложности (в смысле - комплексности) адекватного ответа.
Это будет большая-большая статья со ссылками на источники и с общим смыслом - "разбирайтесь сами".

Из очевидного и "на пальцах" объяснимого влияния: возрастет объем Redo и потребность в Undo. Конкретная цифирь - зависит от конкретной нагрузки на сервер и его конфигурации :)
Если рассматривать в пределах одной отдельно взятой операции, то это + размер нового значения в redo, + размер старого (заменяемого) значения в undo + размер старого (заменяемого) значения в Redo, поскольку сегменты отката тоже защищены redo + оверхед.

Это если в связи с нововведением не поменялись структуры данных.
Если же структура поменялась (к примеру, добавили поле) - то помимо объемов хранения потенциально возможен рост потребностей в буферном кэше, временном табличном пространстве (соединения-сортировки-группировки-структуры PL/SQL) и т.д.
Если обновляемое поле проиндексировано - то плюс расходы на index maintenance, в т.ч. redo+undo+redo.
Если обновляемое поле еще и FK или FK ссылается на это поле, то плюс потенциальные проблемы с (взаимо)блокировками.
Если это поле - ключ секционирования, то плюс расходы на row movement.
Конкретные цифры и критичность, опять-таки, зависят от конкретной системы.

Плюс сетевые взаимодействия.

А еще есть не вполне тривиальная тема "write consistency" с ее "миниоткатами" на уровне statement...

Это только то, что на поверхности.

На круг - вероятность получить серьезные проблемы сопоставима с вероятностью встретить динозавра на улице (1/2).

Как поступить правильно: постройте тест и играйте боевую нагрузку, сравнивайте.
...
Рейтинг: 0 / 0
25.04.2018, 19:16
| Ответить | Цитировать | Написать  
Операция update, сравнение производительности.
    #39636408
Ярослав Батозский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ярослав Батозский
Участник
andrey_anonymous,

Андрей, по моему человек спрашивал не об этом. Он спросил чем отличаются варианты
UPDATE tab SET F1 = F1 + 1
и
UPDATE tab SET F1 = F1 + 1, F2 = F2 + 1

Автор не сказал, но можно предположить, что вопрос "при прочих равных...", т.е. FK не вовлекаются, констрейнты не проверяются, LOB'ов нет, IOT OVERLFOW нет

Предлагаю ответить на вопрос в такой формулировке, а потом автор её может быть расширит
КТо знает, chаnge vector в этих двух случаях будут отличны или нет?
...
Рейтинг: 0 / 0
25.04.2018, 22:22
| Ответить | Цитировать | Написать  
Операция update, сравнение производительности.
    #39636436
Фотография Fogel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Fogel
Участник
Ярослав Батозскийandrey_anonymous,

Андрей, по моему человек спрашивал не об этом. Он спросил чем отличаются варианты
UPDATE tab SET F1 = F1 + 1
и
UPDATE tab SET F1 = F1 + 1, F2 = F2 + 1

Автор не сказал, но можно предположить, что вопрос "при прочих равных...", т.е. FK не вовлекаются, констрейнты не проверяются, LOB'ов нет, IOT OVERLFOW нет

Предлагаю ответить на вопрос в такой формулировке, а потом автор её может быть расширит
КТо знает, chаnge vector в этих двух случаях будут отличны или нет?
я вот тоже так протелепатил, что автор имеет в виду, но остановил своих "внутренних тараканов", которые у меня послушные и митингов не устраивают.
и Андрей здесь абсолютно прав в оценке всего горизонта событий, потому что
если "ответить на вопрос в вашей формулировке" (а ТС про широту подхода, обрисованную Андреем, даже и помыслить не мечтал), то хоть 1 поле, хоть все.
при апдейте обрабатывается вся строка целиком, все блоки, связанные с ней, меняются/двигаются.
undo, redo и прочее выделяются не под отдельно взятое поле, а под всю строку.
и это как бы азы оракловой механики...
...
Рейтинг: 0 / 0
25.04.2018, 23:53
| Ответить | Цитировать | Написать  
Операция update, сравнение производительности.
    #39636459
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
Ярослав БатозскийАндрей, по моему человек спрашивал не об этом. Он спросил чем отличаются варианты
UPDATE tab SET F1 = F1 + 1
и
UPDATE tab SET F1 = F1 + 1, F2 = F2 + 1он про это и отвечал...

Ярослав БатозскийКТо знает, chаnge vector в этих двух случаях будут отличны или нет?ну как они могут быть одинаковыми? Читайте: http://www.juliandyke.com/Internals/Redo/Redo.php

Fogelundo, redo и прочее выделяются не под отдельно взятое поле, а под всю строку.ну Андрей же уже все описал и гораздо точнее:

andrey_anonymousЕсли рассматривать в пределах одной отдельно взятой операции, то это + размер нового значения в redo, + размер старого (заменяемого) значения в undo + размер старого (заменяемого) значения в Redo, поскольку сегменты отката тоже защищены redo + оверхед.

зы. было очень лениво и добавить к ответу Андрея уже нечего, но таки не смог удержаться...
...
Рейтинг: 0 / 0
26.04.2018, 01:37
| Ответить | Цитировать | Написать  
Операция update, сравнение производительности.
    #39636460
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
NTDimкаждый час проходит порядка 500 000 операций UPDATE по одной строкеодну и ту же строку? в разных сессиях? если - да, то неплохое такое бутылочное горлышко придумали - 140 раз в секунду одну и ту же строку обновлять
...
Рейтинг: 0 / 0
26.04.2018, 01:41
| Ответить | Цитировать | Написать  
Операция update, сравнение производительности.
    #39636517
NTDim
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NTDim
Участник
xtenderNTDimкаждый час проходит порядка 500 000 операций UPDATE по одной строкеодну и ту же строку? в разных сессиях? если - да, то неплохое такое бутылочное горлышко придумали - 140 раз в секунду одну и ту же строку обновлять

Строки разные, имелось ввиду в одном запросе обновляется одна строка за раз, согласен, не совсем точно сформулировал.
Индексы по обновляемом поле отсутствуют.
...
Рейтинг: 0 / 0
26.04.2018, 08:17
| Ответить | Цитировать | Написать  
Операция update, сравнение производительности.
    #39636522
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Elic
Участник
NTDimне совсем точно сформулировал.совсем не
...
Рейтинг: 0 / 0
26.04.2018, 08:23
| Ответить | Цитировать | Написать  
Операция update, сравнение производительности.
    #39636575
NTDim
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NTDim
Участник
Elic, спасибо за флуд, если нечего сказать по теме, прошу не флудить.
...
Рейтинг: 0 / 0
26.04.2018, 09:30
| Ответить | Цитировать | Написать  
Операция update, сравнение производительности.
    #39636600
Фотография Stax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stax
Участник
NTDim,

я б еще отметил два мометна
1) update t set a=a -оракля счітает как изменение а
конечно если меняется одно поле и два поля то с тч редо нагрузка больше (надо сохранять старые и новые значения )
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
SQL> update t set n1=n1;

1 row updated.

       4352  redo size

SQL> update t set n1=n1,n2=n2,n3=n3,n4=n4;

1 row updated.

      16616  redo size



ps
к к-ву изменяемих полей ето не относится,
но бывает что важно в разных ли блоках находятся изменяемые записи

зыы
частые коммиты (140в сек) тож как-бы влияют на журналы

....
stax
...
Рейтинг: 0 / 0
26.04.2018, 10:20
| Ответить | Цитировать | Написать  
Операция update, сравнение производительности.
    #39636607
NTDim
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NTDim
Участник
Спасибо! Погоняем тесты, покурим документацию ...
...
Рейтинг: 0 / 0
26.04.2018, 10:30
| Ответить | Цитировать | Написать  
Операция update, сравнение производительности.
    #39636788
wurdu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
wurdu
Участник
StaxNTDim,

я б еще отметил два мометна
1) update t set a=a -оракля счітает как изменение а

....
staxВ 12.2, кстати, пофиксили.

12.1
Код: plsql
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.
SQL> create table tst as select rownum || lpad('a', 1000, 'a') name from dual connect by level <= 10000;

Table created.
...
SQL> select name, value from v$mystat a, v$statname b where a.statistic# = b.statistic# and name = 'redo size';

NAME			  VALUE
-------------------- ----------
redo size		      0

SQL> update tst set name = name;

10000 rows updated.

SQL> select name, value from v$mystat a, v$statname b where a.statistic# = b.statistic# and name = 'redo size';

NAME			  VALUE
-------------------- ----------
redo size	       27931220

SQL> update tst set name = name;

10000 rows updated.

SQL> select name, value from v$mystat a, v$statname b where a.statistic# = b.statistic# and name = 'redo size';

NAME			  VALUE
-------------------- ----------
redo size	       49646888


12.2
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
SQL> update tst set name = name;

10000 rows updated.

SQL> select name, value from v$mystat a, v$statname b where a.statistic# = b.statistic# and name = 'redo size';

NAME								      VALUE
---------------------------------------------------------------- ----------
redo size							    2245996

SQL> update tst set name = name;

10000 rows updated.

SQL> select name, value from v$mystat a, v$statname b where a.statistic# = b.statistic# and name = 'redo size';

NAME								      VALUE
---------------------------------------------------------------- ----------
redo size							    2245996
...
Рейтинг: 0 / 0
26.04.2018, 14:37
| Ответить | Цитировать | Написать  
Операция update, сравнение производительности.
    #39636789
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
wurdu,

http://orasql.org/2017/11/19/triggers-and-redo-changes-on-12-2/
...
Рейтинг: 0 / 0
26.04.2018, 14:41
| Ответить | Цитировать | Написать  
Операция update, сравнение производительности.
    #39637677
oragraf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oragraf
Участник
NTDimПо логике приложения каждый час проходит порядка 500 000 операций UPDATE по одной строке в транзакции.Сиквенс изобретаете?
...
Рейтинг: 0 / 0
27.04.2018, 18:06
| Ответить | Цитировать | Написать  
Операция update, сравнение производительности.
    #39637678
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Elic
Участник
oragrafСиквенс изобретаете? 21369850
...
Рейтинг: 0 / 0
27.04.2018, 18:09
| Ответить | Цитировать | Написать  
15 сообщений из 15, страница 1 из 1
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Операция update, сравнение производительности.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&gotonew=1&tid=1884070]:
 0ms
get settings:
 8ms
get forum list:
 16ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 192ms
get topic data:
 10ms
get first new msg:
 6ms
get forum data:
 2ms
get page messages:
 51ms
get tp. blocked users:
 1ms
others: 217ms
total:  509ms
созд. / загр.: 509ms
x
x
Закрыть


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