Good day.
I have three Standard Edition 11G Release two DB's running on three separate CentOS 64 bit boxes.

DB with sid PROD1 is the primary database. I then have one db as a stdby and then another one at remote site as DR.
Prod1 is running archive log mode.

I have the following backup jobs scheduled on the master database: (scheduled via Enterprise Manager)

Job one - run once per week...This is the definition as seen via Enterprise Manager.

$rman_script="backup incremental level 0 cumulative device type disk tag 'PROD1_BACKUP' database;
backup device type disk tag 'PROD1_BACKUP' archivelog all not backed up;
";
&br_save_agent_env();
&br_prebackup($l_db_connect_string, $l_is_cold_backup, $l_use_rcvcat, $l_db_10_or_higher, $l_backup_strategy, "TRUE");
my $result = &br_backup();
exit($result);



Job 2 - daily - also seen via Enterprise Manager.
$rman_script="backup incremental level 1 cumulative device type disk tag 'PROD1_BACKUP' database;
recover copy of database;
backup device type disk tag 'PROD1_BACKUP' archivelog all not backed up;
";
&br_save_agent_env();
&br_prebackup($l_db_connect_string, $l_is_cold_backup, $l_use_rcvcat, $l_db_10_or_higher, $l_backup_strategy, "TRUE");
my $result = &br_backup();
exit($result);


I tested a couple of recovery scenarios, and it seems to be fine.

For archive logs I have three separate destinations configured:
arc1 - primary db
arc2 - stdby db
arc3 - dr db

I user archive_log_dest_n (with 1,2,3) as archive log destinations.

Then I have shell scripts to move arc2 and arc3 to the stdby db's.
eg #rsync -e ssh -PazvC /u02/app/oracle/flash_recovery_area/PROD1/archivelog/arc2/ oracle@192.168.100.229:/u01/app/oracle/flash_recovery_area/PROD1/archivelog/arc1/
This is a cron entry running every 10 minutes.

The problem I have is that the automated backup commands deletes the archive logs during die weekly hot backup before they can be copied to the stdby servers. This breaks my stdby servers as I now have missing archive files.

I have now set "Archived Redo Log Deletion Policy" to 4 via Availability setting. This seems to be resolving the problem of deleting archive logs before they are copied across.

From the documentation it seems that these archive logs will be deleted only when space is running row.

The one confusing factor here is that the size for the archive log destination cannot be set differently from the flash_recovery area.
My archive logs and flash_recovery_area are on two different disk-packs with vastly different sizes.

So some of the questions:
Can I leave the DB to sort out the "out of space" problems when the archive disk pack runs out of space or will I need to do it myself?

As this is a production box (with no similar test environment due to budget constraints) I'm very scared of leaving it and see what happens!

Is it possible to specify size limitations for the flash recovery area separate from the archive log destinations?


I have now started a separate backup via cron with the following: (run once per day at night)
#
rman target / << EOF
run {
backup device type disk
archivelog like '/u02/app/oracle/flash_recovery_area/PROD1/archivelog/%arc%'
delete all input;
}
EXIT;
EOF
#


This works - but I would like to know how to do it differently. This just doesn't seem like a "clean and elegant" solution and is in need of constant monitoring.

Any pointers will be appreciated..
Regards
Andre

Hi Andre,

>> Can I leave the DB to sort out the "out of space" problems when the archive disk pack runs out of space or will I need to do it myself?

I would set all object with maxextents unlimited and all tablespaces with "autoextend on". That way, all you must monitor is the filesystem . . .

************************************
>> As this is a production box (with no similar test environment due to budget constraints) I'm very scared of leaving it and see what happens!

For $1,400 a month, you cdabn hire experts ro do all the monitoring and reportsing, freeing-up you to do FBA work:

http://www.remote-dba.net

*************************************
>> Is it possible to specify size limitations for the flash recovery area separate from the archive log destinations?

Sure!

I think that redo is separate area from flashback:

Remember:

- Redo log is AFTER images for roll forward

- UNDO logs for BEFORE images, for rollback & flashback

http://www.dba-oracle.com/t_oracle_flash_recovery_area.htm

During creation, the FRA is given a disk location and an upper limit for space allowed for storage of the associated backup and recovery files. The DBA also establishes a retention policy. RMAN then automatically keeps the backups and any archived redo logs needed for complete recovery as are required to satisfy the policy. When files are no longer needed for the established retention policy, they can be deleted as RMAN needs space for new files.

In Oracle 11g R2, the FRA has been renamed from the Flash Recovery Area to the Fast Recovery Area. The description of the two in Oracle's RMAN documentation is unchanged other than the name, so DBA already using or planning to establish an FRA should be comforted that FRA=FRA.

****************************************
>> This just doesn't seem like a "clean and elegant" solution and is in need of constant monitoring.

Why re-invent the wheel? Download the Oracle script collection:

http://www.dba-oracle.com/oracle_scripts.htm