Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3]      все
 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]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3]      все
Все форумы / Oracle Ответить