RE: Rman backup status question

From: Sweetser, Joe <>
Date: Tue, 2 Dec 2008 08:39:14 -0700
Message-ID: <89FD2C8D7D551D4598EF20C7E42FEB4574531C@earthquake.ICAT.COM>

Mystery solved. This is running on an "inherited" system and it turns out there is a job that runs at 3:30am that, among other things, performs a crosscheck. I simply missed that in my initial investigations. Always nice to verify that RMAN is behaving exactly the way it should.

Oh - I also got a call from my proctologist. Turns out my head is ready! :-)


-----Original Message-----

[] On Behalf Of Sweetser, Joe Sent: Monday, December 01, 2008 3:36 PM
To: oracle-l
Subject: Rman backup status question

Greetings listers,

Can't find an answer yet (though I still have a few more tests to run) but figured I'd ask here now. I do a full RMAN backup nightly and then gzip the files on disk. The RMAN script is below. I know that once I gzip the files they are no longer accessible to RMAN. I also back up archive logs hourly and that script includes a "crosscheck archivelog all;" command. I do not do any crosschecks on the database backup. However, the database backups show up as expired. I thought rman only checked for the files on disk if I told/asked it to but perhaps I am wrong about this. I am trying to figure out how/what/when a backup goes from AVAILABLE to EXPIRED outside of issuing a crosscheck command. This is my retention policy: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS; It appears to me that the backups are almost immediately expired (this is where I still need to do some testing). Is RMAN aware of the files "going away" even if I don't issue a crosscheck command? That's fine but I want to understand when/how it checks for those backups. I should point out that restores work fine providing I issue a crosscheck command once the files are gunzipped.

Target database is running on RH Linux 2.1 Recovery catalog is running on RH Linux 4.x

Any/all pointers/links welcome.


RMAN> connect target /

2> connect rcvcat rman/<pw>@rcat
4> run {
5> allocate channel c1 device type disk;
6> sql 'alter system switch logfile';
7> backup
8>   incremental level 0
9>   filesperset 10
10>   format '/u03/oracle_backup/PROD/data/PROD_%U'
11>   tag MON_DB_L0_Dec_01_2008_0110AM
12>   database plus archivelog delete input;
13> sql 'alter database backup controlfile to trace';
14> release channel c1;
15> }


-- Received on Tue Dec 02 2008 - 09:39:14 CST

Original text of this message