Для специалистов - пока собирал инфу, набрёл на интересный пост по теме:

https://blog.dbi-services.com/archivelog-deletion-policy-for-standby-database-in-oracle-data-guard/

Там автор, помимо прочего, обсуждает механизм работы FRA - если во FRA лежат архивлоги, и они уже не нужны, т.е. политики их удержания от стирания не нарушаются (суть они уже забекаплены и/или применены к Stand-By базе/ам), и при вызове из RMAN команды DELETE ARCHIVELOG...., они будут стёрты - то во вью V$RECOVERY_AREA_USAGE, в строке ARCHIVED LOG, в поле RECLAIMABLE, эти архивлоги будут отражены (их размер, в процентах). И в ситуации, когда во FRA начнётся нехватка места, Oracle сам начнёт стирать эти архивлоги, чтобы освободить место. Тут пока ничего интересного или нового, так все и работает, это всем известно.

Дальше - самое интересное, сама суть, чего я все это пишу (точнее, цитирую блог). Автор расковырял "устройство" вьюшки V$RECOVERY_AREA_USAGE (в смысле, какой запрос её формирует, достал из V$FIXED_VIEW_DEFINITION). И обнаружил, что используется X$-view и поле X$KCCAGF.RECTYPE. И дальше он решил "обогатить" вывод этой вью V$RECOVERY_AREA_USAGE (приджойнив ещё V$ARCHIVED_LOG), и добавить туда вывод списка конкретных архивлогов, которые и формируют значение RECLAIMABLE. Таким образом, вместо сухой цифры типа (просто пример) - "у вас тут архивлогов на 100 ГБ хранится во FRA, из них 50% не нужны и могут быть безопасно стерты (RECLAIMABLE)" - можно увидеть список конкретных архивлогов, файлов, которые формируют эти 50%.

Там потом он отдельный пост ещё сделал, уже только конкретно про этот запрос и про саму view:

https://blog.dbi-services.com/drilling-down-vrecoveryareausage/

От меня: на самом деле, из всех "FRA occupants" (термин этот наверно я сам придумал, по аналогии с "SYSAUX occupants" - на самом деле такого в документации нет) - из 7 типов файлов, что там хранятся - по опыту, архивлоги и flashback-логи - самые популярные, я бы сказал 99%. Так что если развить мысль автора блога - то нужно вью V$RECOVERY_AREA_USAGE ещё бы обогатить выводом конкретных файлов флешбеклогов, кого именно можно стирать, не боясь. Суть по той же логике - которые уже не нужны, но которые ещё на диске. И которые сам Oracle потрёт автоматом, как только возникнет FRA Free Space Pressure.

Если это ко мне вопрос - то "стирать не боясь" я конечно оставляю право базе, руками стараюсь не лезть. Кроме ну совсем уж экстренных случаев. И я согласен, flashback-логами Oracle действительно хорошо управляет, как только изменился FLASHBACK_RETENTION_TARGET (в сторону уменьшения) или стёрли GRP - все ненужные flashback-логи тут же автоматом удаляются.

Вообще, есть костыль или хак, не знаю как назвать правильно, и не знаю, делает ли так кто-то в экстренных ситуациях. Если действительно нужно срочно освободить место, например размер FRA пусть будет 100 ГБ, и через вью V$RECOVERY_AREA_USAGE видно, допустим, что 50% его содержимого помечено как RECLAIMABLE. Тогда уменьшаем на минутку размер FRA на размер RECLAIMABLE объёма файлов :




(точнее 55G, с запасом небольшим, чтоб база не остановилась)
В соседнем окне открыт alert.log - в нем тут же появляется простыня на пару экранов сообщений типа:




И/или:




И как только активность удаления "успокаивается" - обычно секунд 30-60 занимает удаление нескольких десятков файлов (с ASM), каждый по гигабайту или несколько - сразу же возвращаем обратно оригинальное значение:




Таким образом, подитожив: суть "метода" в том, чтобы на пару минут уменьшить размер FRA, как бы помогая базе "выдавить" из FRA файлы, которые можно удалять, как бы искусственно создавая Free Space Pressure ситуацию относительно FRA. При этом во FRA остаётся резерв места (5 ГБ в нашем примере), поэтому за минуту база точно не остановится, даже если запишет пару архивлогов в этот момент.

И все, дело сделано - Oracle сам удалил все что можно было безопасно удалить.