Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: аск фор кодривью :)  [new]
kapelan
Member

Откуда: хутор БольшойБугор
Сообщений: 750
legg
kapelan
пропущено...


     fetch c bulk collect  into ar limit 10000; 
     forall i in 1..ar.count save exceptions

или я чего то не понимаю или выглядит так, что вы сравниваете скорость чтения с диска данных таблицы и скорость перебора массива в оперативной памяти.


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

С мат. вью тоже без большого лока, только быстрее в разы.
24 ноя 21, 17:32    [22400316]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
legg
снапшот ту олд практически гарантирован ведь при прямом апдейте всего сразу?

update никак не может дать snapshot too old, поскольку берет блоки в current режиме.
24 ноя 21, 17:32    [22400317]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
kapelan
Тут надо понимать что ничего таки не изменится

Заблуждаетесь.
24 ноя 21, 17:33    [22400319]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
kapelan
Member

Откуда: хутор БольшойБугор
Сообщений: 750
booby
legg
...
или я чего то не понимаю или выглядит так, что вы сравниваете скорость чтения с диска данных таблицы и скорость перебора массива в оперативной памяти.

Вы делаете тройную работу - два раза читаете блоки данных в буфере данных, и еще перебираете массив.
При этом второе чтение у вас всегда сопровождается проверкой - не надо ли соответствующий блок еще раз прочитать в память.

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

в яблочко
24 ноя 21, 17:37    [22400320]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

Откуда: Москва
Сообщений: 6690
booby
legg
...
или я чего то не понимаю или выглядит так, что вы сравниваете скорость чтения с диска данных таблицы и скорость перебора массива в оперативной памяти.

Вы делаете тройную работу - два раза читаете блоки данных в буфере данных, и еще перебираете массив.
При этом второе чтение у вас всегда сопровождается проверкой - не надо ли соответствующий блок еще раз прочитать в память.

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

я не понимаю (
"два раза читаете блоки данных в буфере данных," - это где?
"с транзакционной точки зрения " - условием where отбираются те записи которые ни при каких обстоятельствах не будут принимать участие ни в каких транзакциях. потому колом поставить не должен). но в общем - верное замечание. только вот неверное условие where если зацепит записи участвующие потенциально в других транзакциях наделает делов куда больше чем поставит базу колом. так что кол в виде блокировок будет не бедой а спасением))
24 ноя 21, 17:39    [22400322]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
kapelan
Member

Откуда: хутор БольшойБугор
Сообщений: 750
andrey_anonymous
kapelan
Тут надо понимать что ничего таки не изменится

Заблуждаетесь.

Нет не заблуждаюсь, да есть бенефиты у лупа но недостатки значительно хуже booby точно написал
24 ноя 21, 17:39    [22400323]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
kapelan
andrey_anonymous
пропущено...
Заблуждаетесь.

Нет не заблуждаюсь, да есть бенефиты у лупа

Не туда смотрите.
24 ноя 21, 17:42    [22400324]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
booby
Member

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

вам пытаются сказать, что ваша идея про матвью сама по себе либо вообще не будет работать,
а если повезет, то будет работать всего на порядок - другой хуже, чем вообще любое другое решение.
В норме и три порядка может наскрестись.
24 ноя 21, 17:56    [22400331]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

Откуда: Москва
Сообщений: 6690
kapelan
legg
пропущено...

или я чего то не понимаю или выглядит так, что вы сравниваете скорость чтения с диска данных таблицы и скорость перебора массива в оперативной памяти.


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

С мат. вью тоже без большого лока, только быстрее в разы.

матвью чем то принципиально отличается простой таблицы? суть вопроса - как проапдейтить большое количество (10000000) записей? считаете что ничего страшного одним апдейтом?
24 ноя 21, 18:00    [22400333]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
booby
Member

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

индекс в этой истории, если вообще смотрится, то функциональный, а скорее и вовсе bitmap,
и насколько это совместимо с общей логикой использования целевой таблицы - издалека не видно.
24 ноя 21, 18:04    [22400334]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 8544
DBMS_PARALLEL_EXECUTE Overview
This package lets you incrementally update table data in parallel, in two high-level steps.

1. Group sets of rows in the table into smaller-sized chunks.
2. Run a user-specified statement on these chunks in parallel, and commit when
finished processing each chunk.

This package introduces the notion of parallel execution task. This task groups the
various steps associated with the parallel execution of a PL/SQL block, which is
typically updating table data.
24 ноя 21, 18:07    [22400336]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
кит северных морей
Member

Откуда: krsk / nyc / krsk
Сообщений: 938
я за вариант с разбивкой по диапазонам rowid. заодно можно и в параллели запустить.
24 ноя 21, 18:08    [22400337]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

Откуда: Москва
Сообщений: 6690
booby
kapelan,

индекс в этой истории, если вообще смотрится, то функциональный, а скорее и вовсе bitmap,
и насколько это совместимо с общей логикой использования целевой таблицы - издалека не видно.


да бог с ним с этим индексом. не из-за него тормоза то. большой апдейт (долгий) это ведь плохо? как минимум ролбэксегменты растут из-за него. могут ведь кончится? или я вообще ахинею несу и можно хоть по 5 миллиардов строк одни выражением апдейтить?
24 ноя 21, 18:09    [22400338]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

Откуда: Москва
Сообщений: 6690
параллели нельзя. потому что. только в самом крайнем случае, через кучу согласований. внутренние наши обычаи такие
24 ноя 21, 18:12    [22400340]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
booby
kapelan,
индекс в этой истории, если вообще смотрится, то функциональный, а скорее и вовсе bitmap

Ммм?
SQL> select 10000000/1000000000*100 || '%' from dual;

10000000/1000000000*100||'%'
----------------------------
1%

SQL> 
24 ноя 21, 18:13    [22400342]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
legg
можно хоть по 5 миллиардов строк одни выражением апдейтить?

1. Если update одной транзакцией, то нужен будет большой rollback segment.
2. Statement restart - серьезная проблема для больших update - убедитесь, что не наступите.
3. В Вашем сценарии update вообще не нужен, delete-returning-bulk insert будет дешевле.
Впрочем, повторяюсь.
24 ноя 21, 18:17    [22400344]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
кит северных морей
Member

Откуда: krsk / nyc / krsk
Сообщений: 938
legg
параллели нельзя. потому что. только в самом крайнем случае, через кучу согласований. внутренние наши обычаи такие

уточню - паралелль здесь не в смысле ENABLE_PARALLEL_DML, а в смысле два независимых процесса, обрабатывающих непересекающиеся диапазоны.
24 ноя 21, 18:21    [22400349]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

Откуда: Москва
Сообщений: 6690
andrey_anonymous
3. В Вашем сценарии update вообще не нужен, delete-returning-bulk insert будет дешевле.
Впрочем, повторяюсь.

это я запомнил и записал в специальный файлик ). Попробую. Спасибо. Буду тест кейсы писать - сверять скорость)
andrey_anonymous
1. Если update одной транзакцией, то нужен будет большой rollback segment.

- ну так и возвращаемся, транзакцию со всех сторон крайне желательно бить на куски. собственно вопрос и был как это делается по фэн шум.
andrey_anonymous

2. Statement restart - серьезная проблема для больших update - убедитесь, что не наступите.
- я не могу нагуглить что это(.
24 ноя 21, 18:24    [22400351]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

Откуда: Москва
Сообщений: 6690
кит северных морей
legg
параллели нельзя. потому что. только в самом крайнем случае, через кучу согласований. внутренние наши обычаи такие

уточню - паралелль здесь не в смысле ENABLE_PARALLEL_DML, а в смысле два независимых процесса, обрабатывающих непересекающиеся диапазоны.
по сути
DBMS_PARALLEL_EXECUTE и делает это вроде бы?
теоретически можно, но не особо смысл есть мне кажется. нет жестких требований к времени. главное - не положить систему
24 ноя 21, 18:27    [22400352]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

Откуда: Москва
Сообщений: 6690
legg
кит северных морей
пропущено...

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

надо будет -допишу потом. главное чтоб суть заработала
24 ноя 21, 18:30    [22400356]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
booby
Member

Откуда:
Сообщений: 2678
andrey_anonymous,
ответ такой - в живой ситуации не всякий админ порадуется, когда ему предложат держать стандартный индекс
на толстой таблице, если заранее известно, что использоваться осмысленно он будет на 1%
Кроме того, его clustering фактор непредсказуем, хотя именно эта история может существенно компенсироваться хинтами.

В принципе, можно и настоять, что он нужен, при отсутствии ограничений со стороны вставки.
24 ноя 21, 18:36    [22400360]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
booby
Member

Откуда:
Сообщений: 2678
legg,
про нагуглить:
https://www.sql.ru/forum/afsearch.aspx?s=Statement restart &bid=3
24 ноя 21, 18:38    [22400362]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
legg
я не могу нагуглить что это(.

Это чудный механизм согласования целостности при dml.
Применяется при update, delete, select for update и merge (с древним но непофиксенным багом).
Если утрировать (там деталей миллион), то смысл в следующем: бредет процесс update по блокам таблицы.
По их current версиям.
Строчки перебирает, на предикат тестирует.
И набредает на запись, которая:
- подходила под предикат на момент запуска запроса (на scn согласования)
- была изменена после запуска update конкурирующей транзакцией
- изменение вывело запись из предиката.
Упс! думает процесс, тут такое дело, набор данных-то рассогласован, надо что-то делать!
Ну и откатывает ВСЕ произведенные до той поры изменения, хоть 99999999 из 10000000
После чего начинает всё с начала.
...а юзер ждет у моря погоды.
И чем больше времени прошло от запуска запроса, тем выше вероятность влететь в ситуацию рассогласования и тем больший объем rollback он будет откатывать, а затем закатывать обратно на новый scn.
24 ноя 21, 18:39    [22400365]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
booby
andrey_anonymous,
ответ такой - в живой ситуации не всякий админ порадуется

Против правильного функционального я не возражал.
Но bitmapped тут совсем не при делах.
24 ноя 21, 18:41    [22400366]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

Откуда: Москва
Сообщений: 6690
andrey_anonymous
legg
я не могу нагуглить что это(.

Это чудный механизм согласования целостности при dml.
Применяется при update, delete, select for update и merge (с древним но непофиксенным багом).
Если утрировать (там деталей миллион), то смысл в следующем: бредет процесс update по блокам таблицы.
По их current версиям.
Строчки перебирает, на предикат тестирует.
И набредает на запись, которая:
- подходила под предикат на момент запуска запроса (на scn согласования)
- была изменена после запуска update конкурирующей транзакцией
- изменение вывело запись из предиката.
Упс! думает процесс, тут такое дело, набор данных-то рассогласован, надо что-то делать!
Ну и откатывает ВСЕ произведенные до той поры изменения, хоть 99999999 из 10000000
После чего начинает всё с начала.
...а юзер ждет у моря погоды.
И чем больше времени прошло от запуска запроса, тем выше вероятность влететь в ситуацию рассогласования и тем больший объем rollback он будет откатывать, а затем закатывать обратно на новый scn.

ясно. спасибо! я краем уха слышал, но забыл. )
24 ноя 21, 18:46    [22400368]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Oracle Ответить