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

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

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

Мое решение:
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;


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

Сообщение было отредактировано: 24 ноя 21, 11:50
24 ноя 21, 11:48    [22400113]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
AmKad
Member

Откуда:
Сообщений: 5344
ctas [+partitioning] + rename + grants.
24 ноя 21, 11:54    [22400115]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
Stax
Member

Откуда: Ukraine,Lviv
Сообщений: 3281
legg,

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


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

.....
stax

Сообщение было отредактировано: 24 ноя 21, 12:04
24 ноя 21, 12:02    [22400117]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

Откуда: Москва
Сообщений: 6690
AmKad
ctas
- отказался от такого варианта, тк решил что на работающей базе (таблица активно используется другими сессиями) так не прокатит. важное уточнение - забыл сразу дописать
24 ноя 21, 12:05    [22400120]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

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

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

нет
Stax

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

.....
stax

имхо тоже, коллега вцепился зубами в ногу, боится что у записи rowid поменяется в одном случае из стотыщмиллионов. Надеюсь это успокоит
24 ноя 21, 12:16    [22400127]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
Stax
Member

Откуда: Ukraine,Lviv
Сообщений: 3281
legg

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

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

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

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

....
stax
24 ноя 21, 12:52    [22400148]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
AmKad
Member

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

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

Какой в этом профит в сравнении с твоим вариантом - не нужно вычитывать таблицу перед обновлением.
24 ноя 21, 13:16    [22400159]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

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

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

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

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

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

....
stax

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

Сообщение было отредактировано: 24 ноя 21, 13:35
24 ноя 21, 13:30    [22400164]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

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

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

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


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


крутокрутокруто! попробую. сейчас оставлю так, а в след релизе глядишь и эту версию выпущу. на сам деле я чего то подобного и хотел, не знал как реализовать.
24 ноя 21, 13:32    [22400166]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
Stax
Member

Откуда: Ukraine,Lviv
Сообщений: 3281
legg

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


я не про null

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


зы
я так понимаю ето разовая операция,
"оптимизация" займет больше времени чем проапдейтить 10млн
stax

Сообщение было отредактировано: 24 ноя 21, 14:08
24 ноя 21, 14:06    [22400192]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

Откуда: Москва
Сообщений: 6690
[quot Stax#22400192]
legg

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


я не про null

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


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

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

Stax

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

Сообщение было отредактировано: 24 ноя 21, 14:23
24 ноя 21, 14:19    [22400195]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19949
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

Сообщение было отредактировано: 24 ноя 21, 14:36
24 ноя 21, 14:34    [22400208]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

Откуда: Москва
Сообщений: 6690
andrey_anonymous
legg
по полю kolonka идет партиционирование. конечная цель - перенос из исходной таблицы в целевую неактуальных данных (архивировать то есть) на лету, без техперерывов всяких.

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

согласен. через row movement естественно. не я это придумал. но реализовываю -я). а тут грабля на грабле.
24 ноя 21, 14:40    [22400210]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

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


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


первый раз вижу о такой возможности. вечером почитаю. спасибо огромное!
24 ноя 21, 14:46    [22400214]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

Откуда: Москва
Сообщений: 6690
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


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

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

Сообщение было отредактировано: 24 ноя 21, 14:55
24 ноя 21, 14:52    [22400218]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
Stax
Member

Откуда: Ukraine,Lviv
Сообщений: 3281
legg

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


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

.....
stax
24 ноя 21, 14:57    [22400219]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

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

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


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

.....
stax

я там ругаюсь)
24 ноя 21, 14:58    [22400220]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
kapelan
Member

Откуда: хутор БольшойБугор
Сообщений: 750
А зачем вообше такая странная логика:
1. Скопировать втаблицу в память
2. Сканировать таблицу в памяти
3. Апдейтить оригинальную таблицу
Вроде-как по всем книжкам гораздо быстрее работать напрямую
24 ноя 21, 16:14    [22400260]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19949
kapelan
Вроде-как по всем книжкам гораздо быстрее работать напрямую

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

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

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


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

На круг предложенный вариант с разбиением работы на части посредством предварительного анализа таблицы экстентов вполне себе неплох.
24 ноя 21, 16:30    [22400278]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
kapelan
Member

Откуда: хутор БольшойБугор
Сообщений: 750
andrey_anonymous
kapelan
Вроде-как по всем книжкам гораздо быстрее работать напрямую

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

это все понятно, тока переложить большую таблицу в другое место тоже не быстрая операция ... потом сканировать ее в памяти ...
Грубо говоря получаем двойной фулл скан большой таблицы.
Я бы посмотрел в в сторону мат. вью: навесить на него нужные индексы и делать поиск по индексам.
Таким образом получаем поиск по индексу в мат. вью и UPDATE таблицы по PRIMARY KEY
24 ноя 21, 16:40    [22400284]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19949
kapelan
переложить большую таблицу в другое место тоже не быстрая операция ... потом сканировать ее в памяти ...

Это о чем?
24 ноя 21, 16:47    [22400289]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
kapelan
Member

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

Это о чем?


     fetch c bulk collect  into ar limit 10000; 
     forall i in 1..ar.count save exceptions
24 ноя 21, 17:05    [22400298]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

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

Это о чем?


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

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

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

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

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

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

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

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

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

Сообщение было отредактировано: 24 ноя 21, 17:31
24 ноя 21, 17:30    [22400314]     Ответить | Цитировать Сообщить модератору
 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

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

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

Откуда: Москва
Сообщений: 19949
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

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

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

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

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

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

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

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


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

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

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

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

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

Откуда: Россия, Москва
Сообщений: 8549
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

Откуда: Москва
Сообщений: 19949
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

Откуда: Москва
Сообщений: 19949
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

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

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

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

Откуда: Москва
Сообщений: 19949
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

Откуда: Москва
Сообщений: 19949
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]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
booby
Member

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

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

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

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

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

Сообщение было отредактировано: 24 ноя 21, 18:51
24 ноя 21, 18:47    [22400369]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
Elic
Member

Откуда:
Сообщений: 30234
Увидели в коде слово update - вам должно становиться физически больно, как будто вас ошпарили кипятком, или прижгли окурком.
А написали сами такое слово - должны поставить себя в угол на неделю, без допуска к пиву и женщинам.
Каждый имеет право проповедовать свою религию, основанную на вере в хрен знает что. Следовать ей или нет - это зависит уровня разума читающего.
24 ноя 21, 19:51    [22400394]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

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

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

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

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

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

да. я уже наметил себе в планах сравнение delete и row movement. но делетить то все равно кусками надо) выходит делитель с обходом по екстендам - самый оптимальный результат? (вопрос с использованием политик ADO пока в сторону, этим в третью очередь займусь)
24 ноя 21, 19:53    [22400395]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
kapelan
Member

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


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

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

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

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

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

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

Откуда:
Сообщений: 2700
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 потом
(а там разговор за минимально разумную конфигурацию только начинается от миллиона долларов),
значит ты неудачно произвёл выбор субд для своей системы.
Это просто техническая ошибка, достаточно высокой общей стоимости владения.

Сообщение было отредактировано: 24 ноя 21, 22:44
24 ноя 21, 22:36    [22400435]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
Sayan Malakshinov
Member

Откуда: Мск
Сообщений: 5960
Охъ, сколько понаписали, а элементарно посоветовать 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.
25 ноя 21, 02:09    [22400455]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
Sayan Malakshinov
Member

Откуда: Мск
Сообщений: 5960
andrey_anonymous
3. В Вашем сценарии update вообще не нужен, delete-returning-bulk insert будет дешевле.
пробегая быстро по куче сообщений, проглядел эту строчку и увидел только со второго раза - это именно то, что и надо ТС. Безо всяких свистоплясок.
25 ноя 21, 02:15    [22400456]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

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

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

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

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

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

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

"1.000.000 записей одним махом? да легко
100.000.000 записей одним махом? другое дело " - как понять где проходит граница?
кроме того - поделка перед установкой на пром, который наверное сожрет в самом деле такие транзакции, должна пройти еще прокутиться на тестовых стендах и такими транзакциями боюсь таки будет валить их. не рассчитаны они на массовые операции. кроме того, транзакции резко. выбивающиеся из общей картины потребуют от меня кучу объяснений админам и сопровожденцам, хотелось бы максимально этого избежать, если такая возможность есть . при любом инциденте на проме в первую очередь будут кивать на такие вот транзакции, резко выделяющиеся на общем фоне, есть уже опыт. не критично но не желательно
25 ноя 21, 11:33    [22400589]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

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


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

партиционирование специально сделал по этому полю . так и назвал - архивная и активная партиции. поле not null default 0, 0 -активная , все остальное -архивная
25 ноя 21, 11:38    [22400593]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
booby
Member

Откуда:
Сообщений: 2700
значит скан вы должны делать не по всей таблице, а только по активной партиции.
это, по вашему описанию, будет всегда не больно.
Если еще не сделали, создайте над активной партицией представление с удобным именованием, и жизнь сильно наладится.
25 ноя 21, 11:48    [22400603]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19949
legg

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

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

Сообщение было отредактировано: 25 ноя 21, 12:05
25 ноя 21, 12:05    [22400613]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

Откуда: Москва
Сообщений: 6690
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 с обходом по экстендам и сравню
25 ноя 21, 12:05    [22400614]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

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

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

она называется active ) уже удобно
25 ноя 21, 12:07    [22400615]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

Откуда: Москва
Сообщений: 6690
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
думаю в эту сторону посмотреть
25 ноя 21, 12:13    [22400622]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19949
legg
архивная секция почти всегда пустая - она переносится в другую таблицу в итоге

Тогда это вообще жестко.
Почему сразу не нести в другую таблицу, зачем все эти приседания с partitioning?
25 ноя 21, 16:13    [22400790]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
booby
Member

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

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

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

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

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

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

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

Вот это условие, в предположении его его вменяемой простоты, превращается в вычисляемое поле.
И строка сама говорит - меня пора переносить в куда-то.
Как-то так, примерно.
25 ноя 21, 16:35    [22400808]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

Откуда: Москва
Сообщений: 6690
andrey_anonymous
legg
архивная секция почти всегда пустая - она переносится в другую таблицу в итоге

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


насколько понимаю (автор общей идеи не я) - посчитали что такой механизм окажется наиболее щадящим для нагруженной таблицы в которую активно инсертят-апдейтят другие записи в это же время. вместо транзакции делит-инсерт-commit - транзакция апдейт-коммит. ну и на этом этапе дополнительная возможность отладить-проверить все ли ок. я могу только гадать (. ну и склоняюсь к тому чтобы переделать на delete-insert. и проще и надежнее и быстрее. спасибо за подсказку
25 ноя 21, 16:38    [22400812]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19949
booby
И строка сама говорит - меня пора переносить в куда-то.

"...и звезда с звездою говорит", ага..
ТС где-то уже упоминал, что признак "устаревания" записи может определяться не только на основе данных конкретной строки, но как часть более сложного бизнес-процесса.
25 ноя 21, 16:41    [22400814]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19949
legg
насколько понимаю (автор общей идеи не я) - посчитали что такой механизм окажется наиболее щадящим для нагруженной таблицы в которую активно инсертят-апдейтят другие записи в это же время. вместо транзакции делит-инсерт-commit - транзакция апдейт-коммит.

Идея более чем странная, поскольку фактически заменяет
"делит-инсерт<"в другую таблицу">-commit"
на
апдейт[internals: update-delete-insert]-коммит c последующим "делит-инсерт<"в другую таблицу">-commit"
25 ноя 21, 16:45    [22400817]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

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

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

booby

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


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

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

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

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

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


это я понял. я не могу гарантировать вменяемую простоту. условие архивирование хранится в справочник в виде строки (sql выражение), подтянуть его довольно сложно получается
25 ноя 21, 17:00    [22400825]     Ответить | Цитировать Сообщить модератору
 Re: аск фор кодривью :)  [new]
legg
Member

Откуда: Москва
Сообщений: 6690
andrey_anonymous
legg
насколько понимаю (автор общей идеи не я) - посчитали что такой механизм окажется наиболее щадящим для нагруженной таблицы в которую активно инсертят-апдейтят другие записи в это же время. вместо транзакции делит-инсерт-commit - транзакция апдейт-коммит.

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


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

Сообщение было отредактировано: 25 ноя 21, 17:07
25 ноя 21, 17:04    [22400830]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3      [все]
Все форумы / Oracle Ответить