Mark Romeo, December 13, 2017 - 1:16 am UTC
Hey Alastair,
To help manage those archived redo log files I recommend having a "cleanup archived redo log shell script" which can be scheduled by cron every 15 minutes. Make it generic so you just pass in an $ORACLE_SID and then you can use it for all databases. Basic idea:
# Get a list of archive log dests -- is your organisation multiplexing the archived logs?
sqlplus -s / as sysdba << EOF
set heading off
set trimspool on
set feedback off
set newpage none
spool ${ORACLE_SID}_archive_log_dests.txt
select destination from v\$archive_dest where destination is not null;
spool off
exit
EOF
cat ${ORACLE_SID}_archive_log_dests.txt |
while read line
do
v_arch_dest=$line
# gzip the files
find $v_arch_dest -name "*.arc" -mmin +$hc_mins_redo_lag -print -exec gzip {} \; #declare hc_mins_redo_lag
# remove the even older files
find $v_arch_dest -name "*.gz" -mtime +$hc_days_redo_retain -print -exec rm {} \; #declare hc_days_redo_retain as the number of days to retain archived redo
done
I would recommend moving your backups to RMAN for a single reason - ease of recovery. This is why it's called Recovery MANager. Sure it can do backups but honestly the recovery features are awesome. And speaking of recovery, can you please ensure your backups are tested? No point in backing up the DB if you can't restore and recover it.
Cheers,
Mark
December 13, 2017 - 1:54 am UTC
Agreed - no backup regime should NOT be using RMAN nowadays.
Even for storage level snapshot based mechanisms, I'd *still* catalog the backups in RMAN.