ReSQL.ru
     
powered by simpleCommunicator - 2.0.29     © 2024 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Map
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / аск фор кодривью :)
71 сообщений из 71, показаны все 3 страниц
  все  
аск фор кодривью :)
    #40114471
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
Научите уму-разуму, как надо было делать и что плохого в моей реализации.

Постановка задачи:
есть табл tablitchka с количеством записей 1 000 000 000. В таблице нет индексов кроме первичного ключа
Требуется проапдейтить таблицу по условию COND (условие на неиндексированные поля) установив поле kolonka в 1, прогнозируемое количество попадающих под апдейт - 10 000 000.

Мое решение:
Код: 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.
declare
 
   type tp is record (rid rowid, id number);
   type tAr is table of tp;
   ar tar;
   cursor c is
   select t.rowid, t.id from
   tablitchka t
   where /*условие COND*/
    .. and kolonka = 0;               
begin
  open c;
  loop
     fetch c bulk collect  into ar limit 10000; 
     forall i in 1..ar.count save exceptions
     
     update
     tablitchka  --
     SET kolonka = 1 where rowid = ar(i).rid and id = ar(i).id;
     cnt := cnt + sql%rowcount;
     commit;
     exit when c%notfound;
  end loop;
 
  close c; 
 
exception when others then
   null;    
end;



не очень мне нравится, но это единственный вариант который смог извергнуть. Прошу критики и рассказа о правильном подходе
...
Рейтинг: 0 / 0
24.11.2021, 11:48
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114472
Фотография AmKad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AmKad
Участник
ctas [+partitioning] + rename + grants.
...
Рейтинг: 0 / 0
24.11.2021, 11:54
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114474
Фотография Stax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stax
Участник
legg,

если
напр kolonka = 2 проапдейтить надо?


ps
имхо
если есть условие по ровид, то по ид лишнее

.....
stax
...
Рейтинг: 0 / 0
24.11.2021, 12:02
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114475
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
AmKad
ctas
- отказался от такого варианта, тк решил что на работающей базе (таблица активно используется другими сессиями) так не прокатит. важное уточнение - забыл сразу дописать
...
Рейтинг: 0 / 0
24.11.2021, 12:05
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114479
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
Stax
legg,

если
напр kolonka = 2 проапдейтить надо?
stax

нет
Stax

ps
имхо
если есть условие по ровид, то по ид лишнее

.....
stax

имхо тоже, коллега вцепился зубами в ногу, боится что у записи rowid поменяется в одном случае из стотыщмиллионов. Надеюсь это успокоит
...
Рейтинг: 0 / 0
24.11.2021, 12:16
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114489
Фотография Stax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stax
Участник
legg

имхо тоже, коллега вцепился зубами в ногу, боится что у записи rowid поменяется в одном случае из стотыщмиллионов. Надеюсь это успокоит

допустим поменяется ровид и ....

тогда условие rowid = ar(i).rid and id = ar(i).id; не отработает (0 на 1 не поменяется)

ps
есть save exceptions, а обработка за циклом

....
stax
...
Рейтинг: 0 / 0
24.11.2021, 12:52
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114498
Фотография AmKad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AmKad
Участник
legg
отказался от такого варианта, тк решил что на работающей базе (таблица активно используется другими сессиями) так не прокатит. важное уточнение - забыл сразу дописать
Есть вариант похардовее.

1) С учетом того, таблица, как и любой сегмент, состоит из экстентов, в цикле с помощью dbms_rowid получаешь первый и последний rowid для каждого экстента и делаешь update по условию
Код: plsql
1.
where your_fucking_condition and rowid between r_begin and r_end

например, с фиксацией транзакции после каждого или N-го экстента.
2) Делаешь финальный update-скан по всей таблице только для тех записей, что были добавлены или мигрированы с момента старта этапа 1 и для которых выполняется условие
Код: plsql
1.
where your_fucking_condition and lnnvl(kolonka = 1)


Какой в этом профит в сравнении с твоим вариантом - не нужно вычитывать таблицу перед обновлением.
...
Рейтинг: 0 / 0
24.11.2021, 13:16
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114502
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
Stax
legg

имхо тоже, коллега вцепился зубами в ногу, боится что у записи rowid поменяется в одном случае из стотыщмиллионов. Надеюсь это успокоит

допустим поменяется ровид и ....

тогда условие rowid = ar(i).rid and id = ar(i).id; не отработает (0 на 1 не поменяется)

ps
есть save exceptions, а обработка за циклом

....
stax

да, верное замечание. просто долго описывать все нюансы. логика - 'если случилась неведомая фигня - лучше ничего трогать не буду, надо ручками разбирать что там.' - в данном случае так можно. и вместо null в обработчике логирование варнинга идет
...
Рейтинг: 0 / 0
24.11.2021, 13:30
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114503
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
AmKad
legg
отказался от такого варианта, тк решил что на работающей базе (таблица активно используется другими сессиями) так не прокатит. важное уточнение - забыл сразу дописать
Есть вариант похардовее.

1) С учетом того, таблица, как и любой сегмент, состоит из экстентов, в цикле с помощью dbms_rowid получаешь первый и последний rowid для каждого экстента и делаешь update по условию
Код: plsql
1.
where your_fucking_condition and rowid between r_begin and r_end


например, с фиксацией транзакции после каждого или N-го экстента.
2) Делаешь финальный update-скан по всей таблице только для тех записей, что были добавлены или мигрированы с момента старта этапа 1 и для которых выполняется условие
Код: plsql
1.
where your_fucking_condition and lnnvl(kolonka = 1)



Какой в этом профит в сравнении с твоим вариантом - не нужно вычитывать таблицу перед обновлением.


крутокрутокруто! попробую. сейчас оставлю так, а в след релизе глядишь и эту версию выпущу. на сам деле я чего то подобного и хотел, не знал как реализовать.
...
Рейтинг: 0 / 0
24.11.2021, 13:32
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114518
Фотография Stax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stax
Участник
legg

вместо null в обработчике логирование варнинга идет


я не про null

я про место обработки, следующие 10000 не обработаются если была "ошибка"


зы
я так понимаю ето разовая операция,
"оптимизация" займет больше времени чем проапдейтить 10млн
stax
...
Рейтинг: 0 / 0
24.11.2021, 14:06
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114520
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
[quot Stax#22400192]
legg

вместо null в обработчике логирование варнинга идет


я не про null

я про место обработки, следующие 10000 не обработаются если была "ошибка"


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

попытался связанно объяснить, но не уверен что вышло).

Stax

"зы
я так понимаю ето разовая операция,
"оптимизация" займет больше времени чем проапдейтить 10млн
stax " stax
- нет. ежедневно по паре десятков таблиц. с перспективой увеличения количества как таблиц так и их объемов.
...
Рейтинг: 0 / 0
24.11.2021, 14:19
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114528
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
legg
по полю kolonka идет партиционирование. конечная цель - перенос из исходной таблицы в целевую неактуальных данных (архивировать то есть) на лету, без техперерывов всяких.

Через row movement?
Мсье знает толк в извращениях.

https://docs.oracle.com/en/database/oracle/oracle-database/19/vldbg/manage-data-db-ilm.html#GUID-C53B27F1-7E71-4683-A2A0-3DE194A59C2E
...
Рейтинг: 0 / 0
24.11.2021, 14:34
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114530
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
andrey_anonymous
legg
по полю kolonka идет партиционирование. конечная цель - перенос из исходной таблицы в целевую неактуальных данных (архивировать то есть) на лету, без техперерывов всяких.

Через row movement?
Мсье знает толк в извращениях.

согласен. через row movement естественно. не я это придумал. но реализовываю -я). а тут грабля на грабле.
...
Рейтинг: 0 / 0
24.11.2021, 14:40
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114533
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
andrey_anonymous


https://docs.oracle.com/en/database/oracle/oracle-database/19/vldbg/manage-data-db-ilm.html#GUID-C53B27F1-7E71-4683-A2A0-3DE194A59C2E


первый раз вижу о такой возможности. вечером почитаю. спасибо огромное!
...
Рейтинг: 0 / 0
24.11.2021, 14:46
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114537
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
legg
andrey_anonymous


https://docs.oracle.com/en/database/oracle/oracle-database/19/vldbg/manage-data-db-ilm.html#GUID-C53B27F1-7E71-4683-A2A0-3DE194A59C2E


первый раз вижу о такой возможности. вечером почитаю. спасибо огромное!

толи я не туда смотрю, но только я че та не уверен что тут есть то что надо. архивировать можно записи по довольно сложным условиям. к примеру документы могут архивироваться только после того как закрыт соответствующий счет (и еще ряд условий). такие условия разве можно политиками описать? или я не туда поперся?
кажется то что надо. буду вкуривать.
...
Рейтинг: 0 / 0
24.11.2021, 14:52
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114538
Фотография Stax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stax
Участник
legg

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


имхо
тогда и мало смысла в save exceptions

.....
stax
...
Рейтинг: 0 / 0
24.11.2021, 14:57
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114539
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
Stax
legg

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


имхо
тогда и мало смысла в save exceptions

.....
stax

я там ругаюсь)
...
Рейтинг: 0 / 0
24.11.2021, 14:58
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114571
kapelan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kapelan
Участник
А зачем вообше такая странная логика:
1. Скопировать втаблицу в память
2. Сканировать таблицу в памяти
3. Апдейтить оригинальную таблицу
Вроде-как по всем книжкам гораздо быстрее работать напрямую
...
Рейтинг: 0 / 0
24.11.2021, 16:14
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114587
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
kapelan
Вроде-как по всем книжкам гораздо быстрее работать напрямую

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

Если натравить update на большую меняющуюся таблицу с ограничителем по числу строк (...and rownum < :BatchSize), то FTS будет бегать каждый запуск. При этом конкуренция и statement restart тоже никуда не денутся.

Примечение: В случае ТС если "самопалить", то надо гонять не update, а delete...returning с последующим выходом на forall insert, это будет дешевле update+row_movement.
Впрочем, означенные выше проблемы delete-у тоже свойственны.

Есть вариант распараллелить dml несколько снижая проблемы с конкуренцией, но не уверен что ТС это надо.

На круг предложенный вариант с разбиением работы на части посредством предварительного анализа таблицы экстентов вполне себе неплох.
...
Рейтинг: 0 / 0
24.11.2021, 16:30
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114593
kapelan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kapelan
Участник
andrey_anonymous
kapelan
Вроде-как по всем книжкам гораздо быстрее работать напрямую

Прямая прямой рознь....

это все понятно, тока переложить большую таблицу в другое место тоже не быстрая операция ... потом сканировать ее в памяти ...
Грубо говоря получаем двойной фулл скан большой таблицы.
Я бы посмотрел в в сторону мат. вью: навесить на него нужные индексы и делать поиск по индексам.
Таким образом получаем поиск по индексу в мат. вью и UPDATE таблицы по PRIMARY KEY
...
Рейтинг: 0 / 0
24.11.2021, 16:40
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114598
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
kapelan
переложить большую таблицу в другое место тоже не быстрая операция ... потом сканировать ее в памяти ...

Это о чем?
...
Рейтинг: 0 / 0
24.11.2021, 16:47
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114607
kapelan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kapelan
Участник
andrey_anonymous
kapelan
переложить большую таблицу в другое место тоже не быстрая операция ... потом сканировать ее в памяти ...

Это о чем?


Код: plsql
1.
2.
     fetch c bulk collect  into ar limit 10000; 
     forall i in 1..ar.count save exceptions
...
Рейтинг: 0 / 0
24.11.2021, 17:05
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114611
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
kapelan
andrey_anonymous
пропущено...

Это о чем?


Код: plsql
1.
2.
     fetch c bulk collect  into ar limit 10000; 
     forall i in 1..ar.count save exceptions


или я чего то не понимаю или выглядит так, что вы сравниваете скорость чтения с диска данных таблицы и скорость перебора массива в оперативной памяти.
...
Рейтинг: 0 / 0
24.11.2021, 17:15
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114615
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
kapelan
andrey_anonymous
пропущено...

Прямая прямой рознь....

это все понятно, тока переложить большую таблицу в другое место тоже не быстрая операция ... потом сканировать ее в памяти ...
Грубо говоря получаем двойной фулл скан большой таблицы.
Я бы посмотрел в в сторону мат. вью: навесить на него нужные индексы и делать поиск по индексам.
Таким образом получаем поиск по индексу в мат. вью и UPDATE таблицы по PRIMARY KEY

вопрос в том как одним махом проапдейтить 10 000 000 строк. база не в монопольном доступе, очередные 10000000 записей как раз в таблицу инсертятся в это время. а чуть позже - апдейтятся. даже если конкуренций не случится -снапшот ту олд практически гарантирован ведь при прямом апдейте всего сразу?
...
Рейтинг: 0 / 0
24.11.2021, 17:21
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114620
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
legg
...
или я чего то не понимаю или выглядит так, что вы сравниваете скорость чтения с диска данных таблицы и скорость перебора массива в оперативной памяти.

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

Кроме того, с транзакционной точки зрения, вы совершаете логическую ошибку,
не блокируя прочитанные вашим первым чтением данные.
После исключения логических ошибок ваш код, может быть, просто поставит базу колом на какое-то количество часов.
...
Рейтинг: 0 / 0
24.11.2021, 17:30
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114622
kapelan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kapelan
Участник
legg
kapelan
пропущено...


Код: plsql
1.
2.
     fetch c bulk collect  into ar limit 10000; 
     forall i in 1..ar.count save exceptions


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


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

С мат. вью тоже без большого лока, только быстрее в разы.
...
Рейтинг: 0 / 0
24.11.2021, 17:32
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114623
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
legg
снапшот ту олд практически гарантирован ведь при прямом апдейте всего сразу?

update никак не может дать snapshot too old, поскольку берет блоки в current режиме.
...
Рейтинг: 0 / 0
24.11.2021, 17:32
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114625
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
kapelan
Тут надо понимать что ничего таки не изменится

Заблуждаетесь.
...
Рейтинг: 0 / 0
24.11.2021, 17:33
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114626
kapelan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kapelan
Участник
booby
legg
...
или я чего то не понимаю или выглядит так, что вы сравниваете скорость чтения с диска данных таблицы и скорость перебора массива в оперативной памяти.

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

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

в яблочко
...
Рейтинг: 0 / 0
24.11.2021, 17:37
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114627
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
booby
legg
...
или я чего то не понимаю или выглядит так, что вы сравниваете скорость чтения с диска данных таблицы и скорость перебора массива в оперативной памяти.

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

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

я не понимаю (
"два раза читаете блоки данных в буфере данных," - это где?
"с транзакционной точки зрения " - условием where отбираются те записи которые ни при каких обстоятельствах не будут принимать участие ни в каких транзакциях. потому колом поставить не должен). но в общем - верное замечание. только вот неверное условие where если зацепит записи участвующие потенциально в других транзакциях наделает делов куда больше чем поставит базу колом. так что кол в виде блокировок будет не бедой а спасением))
...
Рейтинг: 0 / 0
24.11.2021, 17:39
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114628
kapelan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kapelan
Участник
andrey_anonymous
kapelan
Тут надо понимать что ничего таки не изменится

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

Нет не заблуждаюсь, да есть бенефиты у лупа но недостатки значительно хуже booby точно написал
...
Рейтинг: 0 / 0
24.11.2021, 17:39
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114629
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
kapelan
andrey_anonymous
пропущено...
Заблуждаетесь.

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

Не туда смотрите.
...
Рейтинг: 0 / 0
24.11.2021, 17:42
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114634
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
kapelan,

вам пытаются сказать, что ваша идея про матвью сама по себе либо вообще не будет работать,
а если повезет, то будет работать всего на порядок - другой хуже, чем вообще любое другое решение.
В норме и три порядка может наскрестись.
...
Рейтинг: 0 / 0
24.11.2021, 17:56
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114636
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
kapelan
legg
пропущено...

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


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

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

матвью чем то принципиально отличается простой таблицы? суть вопроса - как проапдейтить большое количество (10000000) записей? считаете что ничего страшного одним апдейтом?
...
Рейтинг: 0 / 0
24.11.2021, 18:00
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114637
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
kapelan,

индекс в этой истории, если вообще смотрится, то функциональный, а скорее и вовсе bitmap,
и насколько это совместимо с общей логикой использования целевой таблицы - издалека не видно.
...
Рейтинг: 0 / 0
24.11.2021, 18:04
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114639
SQL*Plus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SQL*Plus
Участник
DBMS_PARALLEL_EXECUTE OverviewThis 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.
...
Рейтинг: 0 / 0
24.11.2021, 18:07
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114640
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
кит северных морей
Участник
я за вариант с разбивкой по диапазонам rowid. заодно можно и в параллели запустить.
...
Рейтинг: 0 / 0
24.11.2021, 18:08
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114641
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
booby
kapelan,

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


да бог с ним с этим индексом. не из-за него тормоза то. большой апдейт (долгий) это ведь плохо? как минимум ролбэксегменты растут из-за него. могут ведь кончится? или я вообще ахинею несу и можно хоть по 5 миллиардов строк одни выражением апдейтить?
...
Рейтинг: 0 / 0
24.11.2021, 18:09
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114643
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
параллели нельзя. потому что. только в самом крайнем случае, через кучу согласований. внутренние наши обычаи такие
...
Рейтинг: 0 / 0
24.11.2021, 18:12
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114645
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
booby
kapelan,
индекс в этой истории, если вообще смотрится, то функциональный, а скорее и вовсе bitmap

Ммм?
Код: plsql
1.
2.
3.
4.
5.
6.
7.
SQL> select 10000000/1000000000*100 || '%' from dual;

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

SQL>
...
Рейтинг: 0 / 0
24.11.2021, 18:13
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114647
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
legg
можно хоть по 5 миллиардов строк одни выражением апдейтить?

1. Если update одной транзакцией, то нужен будет большой rollback segment.
2. Statement restart - серьезная проблема для больших update - убедитесь, что не наступите.
3. В Вашем сценарии update вообще не нужен, delete-returning-bulk insert будет дешевле.
Впрочем, повторяюсь.
...
Рейтинг: 0 / 0
24.11.2021, 18:17
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114650
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
кит северных морей
Участник
legg
параллели нельзя. потому что. только в самом крайнем случае, через кучу согласований. внутренние наши обычаи такие

уточню - паралелль здесь не в смысле ENABLE_PARALLEL_DML, а в смысле два независимых процесса, обрабатывающих непересекающиеся диапазоны.
...
Рейтинг: 0 / 0
24.11.2021, 18:21
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114651
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
andrey_anonymous
3. В Вашем сценарии update вообще не нужен, delete-returning-bulk insert будет дешевле.
Впрочем, повторяюсь.

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

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

2. Statement restart - серьезная проблема для больших update - убедитесь, что не наступите.
- я не могу нагуглить что это(.
...
Рейтинг: 0 / 0
24.11.2021, 18:24
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114652
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
кит северных морей
legg
параллели нельзя. потому что. только в самом крайнем случае, через кучу согласований. внутренние наши обычаи такие

уточню - паралелль здесь не в смысле ENABLE_PARALLEL_DML, а в смысле два независимых процесса, обрабатывающих непересекающиеся диапазоны.
по сути
DBMS_PARALLEL_EXECUTE и делает это вроде бы?
теоретически можно, но не особо смысл есть мне кажется. нет жестких требований к времени. главное - не положить систему
...
Рейтинг: 0 / 0
24.11.2021, 18:27
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114654
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
legg
кит северных морей
пропущено...

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

надо будет -допишу потом. главное чтоб суть заработала
...
Рейтинг: 0 / 0
24.11.2021, 18:30
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114658
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
andrey_anonymous,
ответ такой - в живой ситуации не всякий админ порадуется, когда ему предложат держать стандартный индекс
на толстой таблице, если заранее известно, что использоваться осмысленно он будет на 1%
Кроме того, его clustering фактор непредсказуем, хотя именно эта история может существенно компенсироваться хинтами.

В принципе, можно и настоять, что он нужен, при отсутствии ограничений со стороны вставки.
...
Рейтинг: 0 / 0
24.11.2021, 18:36
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114659
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
legg,
про нагуглить:
https://www.sql.ru/forum/afsearch.aspx?s=Statement restart &bid=3
...
Рейтинг: 0 / 0
24.11.2021, 18:38
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114660
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
legg
я не могу нагуглить что это(.

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

Против правильного функционального я не возражал.
Но bitmapped тут совсем не при делах.
...
Рейтинг: 0 / 0
24.11.2021, 18:41
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114662
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
andrey_anonymous
legg
я не могу нагуглить что это(.

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

ясно. спасибо! я краем уха слышал, но забыл. )
...
Рейтинг: 0 / 0
24.11.2021, 18:46
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114663
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
legg,

причитайтесь к тому,что пишет andrey_anonymous.

В качестве правила большого пальца, предлагаю развить в себе рефлекс отторжения update-а.

Увидели в коде слово update - вам должно становиться физически больно, как будто вас ошпарили кипятком, или прижгли окурком.
А написали сами такое слово - должны поставить себя в угол на неделю, без допуска к пиву и женщинам.

Это все при том всём, что у Oracle одна из лучших, если не точно и строго самая лучшая реализация update,
среди всех на сей момент существующих dbms, как-то опирающихся на mvcc.
...
Рейтинг: 0 / 0
24.11.2021, 18:47
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114682
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Elic
Участник
Увидели в коде слово update - вам должно становиться физически больно, как будто вас ошпарили кипятком, или прижгли окурком.
А написали сами такое слово - должны поставить себя в угол на неделю, без допуска к пиву и женщинам.Каждый имеет право проповедовать свою религию, основанную на вере в хрен знает что. Следовать ей или нет - это зависит уровня разума читающего.
...
Рейтинг: 0 / 0
24.11.2021, 19:51
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114683
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
booby
legg,

причитайтесь к тому,что пишет andrey_anonymous.

В качестве правила большого пальца, предлагаю развить в себе рефлекс отторжения update-а.

Увидели в коде слово update - вам должно становиться физически больно, как будто вас ошпарили кипятком, или прижгли окурком.
А написали сами такое слово - должны поставить себя в угол на неделю, без допуска к пиву и женщинам.

Это все при том всём, что у Oracle одна из лучших, если не точно и строго самая лучшая реализация update,
среди всех на сей момент существующих dbms, как-то опирающихся на mvcc.

да. я уже наметил себе в планах сравнение delete и row movement. но делетить то все равно кусками надо) выходит делитель с обходом по екстендам - самый оптимальный результат? (вопрос с использованием политик ADO пока в сторону, этим в третью очередь займусь)
...
Рейтинг: 0 / 0
24.11.2021, 19:53
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114702
kapelan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kapelan
Участник
legg
kapelan
пропущено...


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

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

матвью чем то принципиально отличается простой таблицы? суть вопроса - как проапдейтить большое количество (10000000) записей? считаете что ничего страшного одним апдейтом?

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

PS:
1.000.000 записей одним махом? да легко
100.000.000 записей одним махом? другое дело
...
Рейтинг: 0 / 0
24.11.2021, 21:35
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114710
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
legg

... я уже наметил себе в планах сравнение delete и row movement. но делетить то все равно кусками надо) выходит делитель с обходом по екстендам - самый оптимальный результат? (вопрос с использованием политик ADO пока в сторону, этим в третью очередь займусь)

Прежде всего, следует заметить, что для Oracle ваш миллиард записей, это если уже не совсем маленькая,
но еще вовсе не такая большая таблица.
Далее,
1. Никакого row movement у вас не будет, если а) партицирование таблицы функционально не зависит от изменяемого поля,
б) поле not null, и физически необходимое место для нового значения совпадает с требовавшимся для предыдущего.

2. Если Update производится именно для того, чтобы перенести запись из одной партиции в другую, то тот или иной вариант физического перемещения так или иначе состоится.
Выписанный вами update - построчный, с небольшим преимуществом против обычного построчного, заключающегося в отсутствии переключения контекста между pl/sql и sql машинами. Но объем redo при этом сформируется примерно одинаково неприемлемый.
Именно в этих конкретных обстоятельствах delete bulk collect + forall insert может оказаться, и, скорее всего, окажется предпочтительней.
Для этой конкретной задачи хорошо смотрелся бы Merge с удалением данных на источнике. Но именно такого у Oracle нет.

3. Пока ваша таблица маленькая, (а не шибко большой, в предположении, что записи в ней не слишком широкие, она будет оставаться миллиардов до 10 записей или несколько дольше),
ни о каких альтернативах прямому проходу по блокам таблицы, с разделением на подмножества, можно не шибко задумываться.
И такую маленькую таблицу почти всё равно, на каком железе "крутить".

А дальше надо принять в расчёт, что любая инсталляция умеренно современного Oracle на любую железную конструкцию, отличную от Oracle Exadata, является всего лишь на соплях собранную демонстрационную модель, показывающую - что такое
Oracle вообще, и собираемую для предоставления возможности первичного и приблизительного ознакомления с инструментом.


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

Если на "обычном" железе Oracle это обычный, такой же, как и прочие, "High End", то на Exadata - это "Super High End" из другой звёздной системы.
Если Exadata нет и не предвидится, то, может быть, придется когда-то что-то мутить на индексах.
Но это плохо, в некотором отношении.

Если продолжать бросаться "правилами большого пальца", то можно сформулировать такую максиму:
Если ты установил себе Oracle сейчас, но не готов заплатить за Exadata потом
(а там разговор за минимально разумную конфигурацию только начинается от миллиона долларов),
значит ты неудачно произвёл выбор субд для своей системы.
Это просто техническая ошибка, достаточно высокой общей стоимости владения.
...
Рейтинг: 0 / 0
24.11.2021, 22:36
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114721
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
Охъ, сколько понаписали, а элементарно посоветовать virtual calculated column забыли...
Ведь в оригинальном вопросе проще всего было бы добавить скрытое вычисляемое поле на условие и не париться с изменением данных.

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

legg
есть табл tablitchka с количеством записей 1 000 000 000...
Требуется проапдейтить таблицу по условию COND ... установив поле kolonka в 1, прогнозируемое количество попадающих под апдейт - 10 000 000.

а сколько всего под архивацию попадает? секционирование уже есст или только планируете? Каково вообще распределение значений этих "kolonka"? Там только 0 и 1? По сколько их? Смысл менять на 1 только для того, чтобы удалить из этой таблицы?

Из ответов получается что вообще ни апдейт, ни секционирование тут не нужны, а просто нужен insert select bulk collect + delete.
...
Рейтинг: 0 / 0
25.11.2021, 02:09
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114722
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
andrey_anonymous
3. В Вашем сценарии update вообще не нужен, delete-returning-bulk insert будет дешевле.
пробегая быстро по куче сообщений, проглядел эту строчку и увидел только со второго раза - это именно то, что и надо ТС. Безо всяких свистоплясок.
...
Рейтинг: 0 / 0
25.11.2021, 02:15
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114790
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
kapelan
legg
пропущено...

матвью чем то принципиально отличается простой таблицы? суть вопроса - как проапдейтить большое количество (10000000) записей? считаете что ничего страшного одним апдейтом?

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

PS:
1.000.000 записей одним махом? да легко
100.000.000 записей одним махом? другое дело

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

анализировать sqlусловие и по результатам анализа создавать правильные индексы- можно попробовать но как то уж чрезмерно сложно, пока что обойдусь фулсканом. кстати а создание и заливка-обновление данных матвью не ведет разве к тому же фулскану?

"1.000.000 записей одним махом? да легко
100.000.000 записей одним махом? другое дело " - как понять где проходит граница?
кроме того - поделка перед установкой на пром, который наверное сожрет в самом деле такие транзакции, должна пройти еще прокутиться на тестовых стендах и такими транзакциями боюсь таки будет валить их. не рассчитаны они на массовые операции. кроме того, транзакции резко. выбивающиеся из общей картины потребуют от меня кучу объяснений админам и сопровожденцам, хотелось бы максимально этого избежать, если такая возможность есть . при любом инциденте на проме в первую очередь будут кивать на такие вот транзакции, резко выделяющиеся на общем фоне, есть уже опыт. не критично но не желательно
...
Рейтинг: 0 / 0
25.11.2021, 11:33
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114792
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
booby


1. Никакого row movement у вас не будет, если а) партицирование таблицы функционально не зависит от изменяемого поля,
б) поле not null, и физически необходимое место для нового значения совпадает с требовавшимся для предыдущего.

партиционирование специально сделал по этому полю . так и назвал - архивная и активная партиции. поле not null default 0, 0 -активная , все остальное -архивная
...
Рейтинг: 0 / 0
25.11.2021, 11:38
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114799
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
значит скан вы должны делать не по всей таблице, а только по активной партиции.
это, по вашему описанию, будет всегда не больно.
Если еще не сделали, создайте над активной партицией представление с удобным именованием, и жизнь сильно наладится.
...
Рейтинг: 0 / 0
25.11.2021, 11:48
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114805
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
legg

партиционирование специально сделал по этому полю . так и назвал - архивная и активная партиции. поле not null default 0, 0 -активная , все остальное -архивная

Хм... Так это Ваша разработка, а не доработки в живой системе...
Тогда, возможно, вообще зайти с другой стороны - пересмотреть схему секционирования?
...
Рейтинг: 0 / 0
25.11.2021, 12:05
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114806
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
Sayan Malakshinov
Охъ, сколько понаписали, а элементарно посоветовать virtual calculated column забыли...
Ведь в оригинальном вопросе проще всего было бы добавить скрытое вычисляемое поле на условие и не париться с изменением данных.

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

Sayan Malakshinov

а сколько всего под архивацию попадает? секционирование уже есст или только планируете? Каково вообще распределение значений этих "kolonka"? Там только 0 и 1? По сколько их? Смысл менять на 1 только для того, чтобы удалить из этой таблицы?

Из ответов получается что вообще ни апдейт, ни секционирование тут не нужны, а просто нужен insert select bulk collect + delete.


в наиболее тяжелых случаях на сегодняшний момент - при первом запуске под архивацию попадет около 150 млн из 800 млн. далее - около 10 млн в день пока что. в дальнейшем (через годик) вполне может вырасти на порядок.
у меня вообще есть сомнения что подход в корне не верен и рано или поздно никакая оптимизации не поможет, надо будет какими нибудь etl средствами а ля Data stage оперировать.
секционирование есть но можно пока вернуть все взад ). распределение значений kolonka ориентировочно 1% ежедневно. только 0 и 1. количество зависит от таблицы. к миллиарду максимальная приближается пока что.
смысл меня на 1 - логика такая (насколько понимаю, изначально не мое решение, я реализовываю и могу перерешить если сочту нужным) - меняя на 1 мы переносим запись в другую партицию и любые манипуляции с этими данными в дальнейшем не будут влиять не текущие бизнес-процессы, на манипуляции других сессий с данными в этой таблице. кроме того будет возможность отладить , проверить-перепроверить результат в процессе тестирования. если что пошло не так , перенесли что то лишнее-ничего не поломается пока что.
вторым шагом данные копируются (insert) в транзитную таблицу
третьим шагом из транзитной реплэйс партишн в архивную.

в реузлтате - да, реализую вариант с delete-returning-bulk insert с обходом по экстендам и сравню
...
Рейтинг: 0 / 0
25.11.2021, 12:05
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114807
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
booby
значит скан вы должны делать не по всей таблице, а только по активной партиции.
это, по вашему описанию, будет всегда не больно.
Если еще не сделали, создайте над активной партицией представление с удобным именованием, и жизнь сильно наладится.

да, скан делаю по секции, но архивная секция почти всегда пустая - она переносится в другую таблицу в итоге

она называется active ) уже удобно
...
Рейтинг: 0 / 0
25.11.2021, 12:07
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114812
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
andrey_anonymous
legg

партиционирование специально сделал по этому полю . так и назвал - архивная и активная партиции. поле not null default 0, 0 -активная , все остальное -архивная

Хм... Так это Ваша разработка, а не доработки в живой системе...
Тогда, возможно, вообще зайти с другой стороны - пересмотреть схему секционирования?

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

- пересмотреть схему секционирования - прям ща считаю нецелесообразным - почти все работает уже. но переделать все заново по феншую готов. вторым этапом. мне вот тут политик ado насоветовали в теме. (если я правильно понял совет) вы по моему и посоветовали) https://docs.oracle.com/en/database/oracle/oracle-database/19/vldbg/ilm-strategy-heatmap-ado.html#GUID-811423E6-3F43-4B95-AF9E-119AC71FB0D0
думаю в эту сторону посмотреть
...
Рейтинг: 0 / 0
25.11.2021, 12:13
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114923
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
legg
архивная секция почти всегда пустая - она переносится в другую таблицу в итоге

Тогда это вообще жестко.
Почему сразу не нести в другую таблицу, зачем все эти приседания с partitioning?
...
Рейтинг: 0 / 0
25.11.2021, 16:13
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114937
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
booby
Участник
legg
booby
значит скан вы должны делать не по всей таблице, а только по активной партиции.
это, по вашему описанию, будет всегда не больно.
Если еще не сделали, создайте над активной партицией представление с удобным именованием, и жизнь сильно наладится.

да, скан делаю по секции, но архивная секция почти всегда пустая - она переносится в другую таблицу в итоге

она называется active ) уже удобно

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

так же не понял, какой точно смысл вкладывается в

автор...мы переносим запись в другую партицию и любые манипуляции с этими данными в дальнейшем не будут влиять не текущие бизнес-процессы, на манипуляции других сессий с данными в этой таблице. кроме того будет возможность отладить , проверить-перепроверить результат в процессе тестирования. если что пошло не так , перенесли что то лишнее-ничего не поломается пока что...
за что точно идет идет борьба - за высоту индекса, за размер таблицы в tablespace
кто кому и как именно "мешает".
Кроме того, при массовых процессах такого рода, в зависимости от характера переносимых из текущей партиции данных,
могут, а в вашем сценарии скорее должны разыгрываться истории про коалеск индекса и/или move таблицы.
Процесс такого рода носит явно административный характер, и выполнять его надо в явное время оффтайм, если такое есть, или хотя бы во время минимальной нагрузки, такое в большинстве случаев так или иначе проявляется.
---------------------------
Про вычисляемый столбец вам говорят вот о чем:
Вы же изначально собирались именно update-ить поле на 1, а чтобы понять, с кем именно это сделать,
у вас есть некое условие отбора записей.

Вот это условие, в предположении его его вменяемой простоты, превращается в вычисляемое поле.
И строка сама говорит - меня пора переносить в куда-то.
Как-то так, примерно.
...
Рейтинг: 0 / 0
25.11.2021, 16:35
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114940
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
andrey_anonymous
legg
архивная секция почти всегда пустая - она переносится в другую таблицу в итоге

Тогда это вообще жестко.
Почему сразу не нести в другую таблицу, зачем все эти приседания с partitioning?


насколько понимаю (автор общей идеи не я) - посчитали что такой механизм окажется наиболее щадящим для нагруженной таблицы в которую активно инсертят-апдейтят другие записи в это же время. вместо транзакции делит-инсерт-commit - транзакция апдейт-коммит. ну и на этом этапе дополнительная возможность отладить-проверить все ли ок. я могу только гадать (. ну и склоняюсь к тому чтобы переделать на delete-insert. и проще и надежнее и быстрее. спасибо за подсказку
...
Рейтинг: 0 / 0
25.11.2021, 16:38
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114942
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
booby
И строка сама говорит - меня пора переносить в куда-то.

"...и звезда с звездою говорит", ага..
ТС где-то уже упоминал, что признак "устаревания" записи может определяться не только на основе данных конкретной строки, но как часть более сложного бизнес-процесса.
...
Рейтинг: 0 / 0
25.11.2021, 16:41
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114945
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
legg
насколько понимаю (автор общей идеи не я) - посчитали что такой механизм окажется наиболее щадящим для нагруженной таблицы в которую активно инсертят-апдейтят другие записи в это же время. вместо транзакции делит-инсерт-commit - транзакция апдейт-коммит.

Идея более чем странная, поскольку фактически заменяет
"делит-инсерт<"в другую таблицу">-commit"
на
апдейт[internals: update-delete-insert]-коммит c последующим "делит-инсерт<"в другую таблицу">-commit"
...
Рейтинг: 0 / 0
25.11.2021, 16:45
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114951
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
booby

ни почему архивная секция всегда пустая, ни почему она удобно называется active.
архивная секция после заполнения (после апдейта который провоцирует row movement) переносится в другую таблицу, нерабочую. и в перспективе данные оттуда будут переносится в облако, из базы вообще удаляться.
ну и когда я работаю (апдейчу) с данными в процессе переноса - я явным образом прописываю секции в самом апдейте

booby

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


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

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

есть сильный соблазн (и уже были предложения) так и делать. но вдруг у меня получится?)))
---------------------------
booby

Про вычисляемый столбец вам говорят вот о чем:
Вы же изначально собирались именно update-ить поле на 1, а чтобы понять, с кем именно это сделать,
у вас есть некое условие отбора записей.

Вот это условие, в предположении его его вменяемой простоты, превращается в вычисляемое поле.
И строка сама говорит - меня пора переносить в куда-то.
Как-то так, примерно.


это я понял. я не могу гарантировать вменяемую простоту. условие архивирование хранится в справочник в виде строки (sql выражение), подтянуть его довольно сложно получается
...
Рейтинг: 0 / 0
25.11.2021, 17:00
| Ответить | Цитировать | Написать  
аск фор кодривью :)
    #40114955
legg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
legg
Участник
andrey_anonymous
legg
насколько понимаю (автор общей идеи не я) - посчитали что такой механизм окажется наиболее щадящим для нагруженной таблицы в которую активно инсертят-апдейтят другие записи в это же время. вместо транзакции делит-инсерт-commit - транзакция апдейт-коммит.

Идея более чем странная, поскольку фактически заменяет
"делит-инсерт<"в другую таблицу">-commit"
на
апдейт[internals: update-delete-insert]-коммит c последующим "делит-инсерт<"в другую таблицу">-commit"


угу. печально что я сразу об этом не задумался, а начал реализовывать что написано. дошло это до меня только в середине этой темы). так что переписывать на дельте-инсерт-коммит придется
зы несложно и сейчас переписать , но я уже сборку отдаю. на ифт стенде при небольшой нагрузке работает. интересно что нт покажет
...
Рейтинг: 0 / 0
25.11.2021, 17:04
| Ответить | Цитировать | Написать  
71 сообщений из 71, показаны все 3 страниц
  все  
Форумы / Oracle [игнор отключен] [закрыт для гостей] / аск фор кодривью :)
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru, Чат Кролика       Пашэ: Рисунки, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=52&tid=1879734]:
 0ms
get settings:
 24ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 51ms
get topic data:
 8ms
get forum data:
 3ms
get page messages:
 1159ms
get tp. blocked users:
 2ms
others: 380ms
total:  1649ms
созд. / загр.: 1649ms
x
x
Закрыть


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