RE: Deleting old archive log files.

> the most portable and sanest route is to use RMAN
Agreed. Go RMAN... Gorman... Hmmm... :-)

> Being able to issue only two commands (i.e. "RESTORE DATABASE" and
"RECOVER
> DATABASE") over dialup from home after being roused at 2:30am and having
> RMAN do all the thinking for you is sublime.
If you do a RESTORE/RECOVER DATABASE doesn't RMAN retrieve and restore ALL datafiles from tape? Wouldn't this unnecessarily increase the mean time to recovery if you just need to recover one datafile?

Orrman for RMAN,
Steve Orr
Bozeman, MT

-----Original Message-----
Sent: Thursday, April 04, 2002 7:19 AM
To: Multiple recipients of list ORACLE-L

If you are not using RMAN, the best, safest, and most portable approach whether deleting archived redo log files on UNIX, VMS, or Windows is the technique of "SQL-generating-OScmd". Query the V$ARCHIVED_LOG view to retrieve the file's NAME where COMPLETION_TIME < whatever-you-want and ARCHIVED='Y'. The query should be written to spool the OS-specific "remove" command along with the file-name, and the spool output can be run as a ".bat" script in Windows, a shell script in UNIX, or DCL script in OpenVMS.

However, the most portable and sanest route is to use RMAN for backups and deletion of archived redo log files (and datafiles, of course), as all of RMAN's actions are recorded and are viewable through V$ARCHIVED_LOG and other views. RMAN not only handles archived redo log files according to the rules you specify, it can backup the log files multiple times before deleting them, keeping track of everything. If you have a bad tape, look for the archived redo log file on an older tape. RMAN also validates the redo log files during the backup to verify that it is not corrupted, an invaluable service.

Yes, RMAN is tough to set up, but it's very name indicates it's focus. It's not called "backup manager" or BMAN for a reason.

Being able to issue only two commands (i.e. "RESTORE DATABASE" and "RECOVER DATABASE") over dialup from home after being roused at 2:30am and having RMAN do all the thinking for you is sublime. Every DBA who has been around for a couple years has their own "backup scripts" that they love and trust (myself included), but how many have bothered to automate restore and recovery? Those who have are certainly aware of the shortcomings of their own efforts and probably use their restore/recovery scripts very sparingly, if they are wise, as the most common cause of failed recoveries by far is not tape failure, but human error or (worse yet) semi-automated human error.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Orr, Steve
  INET: sorr_at_rightnow.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).