Skip to Main Content
  • Questions
  • Removal of Archive Files when using OS to backup offline DB

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Alastair.

Asked: November 06, 2017 - 11:44 am UTC

Last updated: December 13, 2017 - 1:54 am UTC

Version: 9i

Viewed 1000+ times

You Asked

I have been thrown in at the deep end and given an Oracle DB to look after. I have no prior experience of Oracle so everything I am doing is new and a massive learning curve.

The current DB data set is approx 400GB and we are working with the application vendor to reduce this (mainly history of transactions that we no longer need and should have been purged yearly). Our current backup scheme is to safely shutdown Oracle every night, copy all the data files to a network location and restart Oracle on completion.

This works fine but I have noticed that we have lots of ARC files, approx 500GB going back at least 18 months. My understanding is that if we used RMAN to manage the backups then these would be managed and purged as the backups are made only leaving the ones required to restore from the last backup and bring the DB up to date, is this correct?

As we are not using RMAN it looks like nothing is purging these files, is it safe to remove some or all of them prior to the last (nightly) backup? I think I would then need to run some RMAN commands to update its database and purge the history?

The intention is to move to an RMAN based backup next year once we have shrunk the DB to a manageable size.

Thanks
Alastair French

and Connor said...

Based on this statement:

"Our current backup scheme is to safely shutdown Oracle every night, copy all the data files to a network location and restart Oracle on completion."

I'll make three suggestions

1) Make sure you are not copying to the same place each day. Because that would mean that *during* the copy, you have *no* backup. So at the very minimum, you would copy (say) Monday to location 1, Tuesday to location 2, Wednesday to location 1 and so on.

2) Then all you need to do is ensure that you have the archive files from (say) the last few days, so that if one full backup is corrupted, you can go back to the previous one. So you can then implement a rolling archive log deletion scheme. Since you are not using RMAN, you can simply use OS commands to remove them as long as you are sure you have backed them up. I'd recommend 2 copies of each file.

3) Give your users a christmas present and change your backup from

- shutdown
- copy all files
- startup

to

- alter system archive log current;
- alter database begin backup
- copy all files
- alter database end backup;
- alter system archive log current;

and voila, your database stays open during the backup.

But obviously, as you've stated, a move to RMAN is an obvious choice.

Rating

  (1 rating)

Is this answer out of date? If it is, please let us know via a Comment

Comments

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
Connor McDonald
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.

More to Explore

Administration

Need more information on Administration? Check out the Administrators guide for the Oracle Database