ну как бы если говорить про конкретный запрос, да там есть сложности, но раньше он отрабатывал быстро, щас медленно.

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

Как вообще правильно настроить эти области. У нас физически 250GB оперативки на каждой ноде.
pga_aggregate_limit = 32Gb
sga_max_size = 65Gb

это сильно зависит от того, у вас OLTP или DWH тип нагрузки базы. И сколько сессий в среднем висит в БД. И сколько они обычно жрут в сумме PGA

я бы под все отдал 230, pga 10, sga 220 но как ранее сказали надо смотреть что у вас. и вам не pga_aggregate_limit надо, а таргет. лимит на ходу изменить сможете

скорее OLTP, активных сессий до 50, а вот сколько памяти PGA вопрос, в данный момент
pga_used_mem = 2Gb
pga_alloc_mem =  2.5Gb
pga_freeable_mem = 100Mb
Хз может я не так смотрю... Взял от сюда запрос

pga_aggregate_target=32Gb

V$PGASTAT посмотрите сколько максимально юзали и уже от этого отталкивайтесь

Ну
maximum PGA allocated = 26Gb
maximum PGA used for auto workareas=  13Gb
maximum PGA used for manual workareas=  0,03Gb

limit не может быть меньше target. Обычно limit=target*2. Но можно limit вообще в 0 выставить, если у оперативки дофига

а он не меньше он равен target

это не очень хороший вариант. Если дойдете до limit, то oracle начнет пришибать свои собственные процессы - у вас начнут внезапно умирать сессии

А еще memory_target = 0 это значит автоматическое управление?

не, это ручное (через sga_target и pga_aggregate_target). memory_target=0 лучше не трогать...

Если вопрос еще не потрял актуальности.
С багами при бэкап/ресторах не сталкивались. А вот с партицированными таблицами/индексами есть нюанс.
Иногда в параметрах остаются "ссылки" на удаленные ТП.
И при попытках сплита, добавления новых партиций (при автопартицированнии) вылазят артефакты в виде попыток создать партицию в ТП DELETED.
Точной ошибки не помню, но нюанс стоит учитывать и проверять параметры создания партиции.

интересно, спасибо.

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

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

поэтому осознанно пожертвовали производительностью в пользу надежности.

Ну такой подход архивлоги еще дополнительно генерит.
Но если не проблема, то почему нет.
Ну и default tablespace если переименовываешь плюс еще alter user-ам делается неявный

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

🤔
https://hub.docker.com/r/asservio/cx-oracle/

Есть как костыль базовый образ alpine + libc и он размером чуть больше чем чистый alpine. Может там оно