А что непонятного
Был бы бэкап -- удалялись бы логи, которые уже не нужны, в соответствии с политикой
Бэкапа нет -- значит этот лог еще может потребоваться для восстановления с нулевого состояния
Например, потерял ты табличное пространство (или файл), ты можешь восстановить его с нуля только по одним логам (естественно, это не относится к SYSTEM)

Ну, во-первых, ему это нахрен не нужно отслеживать, да и размер контролфайла ограничен (control_file_record_keep_time)
Кстати, ты еще столкнешься с тем, что выполнив удаление архивлогов через RMAN, он удалит только те, о которых он помнит (тот самый keep_time)

А так, запускай по крону удаление либо через RMAN, либо через OS, но не забывай CROSSCHECK после этого

Нахрена тогда ты вообще используешь ARCHIVELOG?

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

Собственно, на мой взгляд, основная фишка FRA для больших БД -- это хранение FLASHBACK-логов (их больше никуда не засунешь), все остальное вполне обходится без FRA

Сергей АрсеньевВячеслав ЛюбомудровСобственно, на мой взгляд, основная фишка FRA
остановиться раньше чем будет засрана вся ФС - мелочь а приятно.Ну да, остановиться, когда FS пустая на самом деле, а у него в мозгах полная
Просто если юзаешь -- то уж не поленись прочитать про нее и работай с ней правильноСергей Арсеньевеще бы трейсы, алертлог и т.п. в нее бы попадали и за давностью затирались.Да в общем-то ADR с 11 именно так и действует (за исключением trace/alert.log, ну так я это например, только приветствую)
Хуже дело обстоит с *.AUD файлами, особенно на стендбаях под управлением EM
И что самое противное, они перестали перезаписывать существующие (тогда бы их количество ограничилось хотя бы 32-64k файлов), а стали, сцуко, всякие суффиксы добавлять
Так что DBA все равно приходится настраивать какие-либо процедуры подчистки ненужных файлов