RMAN, RAC, ASM, FRA and Archive Logs
The topic, as the title suggests, concerns RMAN, RAC, ASM and archive logs. This post is rather different than my prior posts, in that, I want to open up a dialogue concerning the subject matter. So, I’ll start the thread by posing a question: Are any of you that run RAC in your production environments backing up your archive logs to an FRA that resides in an ASM disk group (and of course backing up the archive logs to tape from the FRA)? Managing your free space within your FRA is paramount as are judicious backups of the FRA (actually these really go hand in hand). However, I am very interested in your experience. Have you come across and “gotchas”, bad experiences, positive experiences, more robust alternatives, extended solutions, etc.? Being somewhat of a backup and recovery junky, I am extremely interested in your thoughts. Let the dialogue commence!
Update: 03/26/2008
A colleague of mine has been doing some testing using RMAN, RAC, ASM, FRA for archive log management. Also, he has tested the integration of DataGuard into this configuration. To be more precise, he has tested using an FRA residing in an ASM disk group as the only local archive log destination. In addition to the local destination, each archive log is sent to the standby destination. Based on his testing this approach is rather robust. The archive logs are backed up via the "BACKUP RECOVERY AREA" command with a regular periodicity. This enables the FRA's internal algorithm to remove archive logs that have been backed up, once the space reaches 80% full. No manual intervention is required to remove the archive logs. Moreover, the archive logs in this configuration will only be automatically deleted from the FRA if both of the following are true: 1) the archive log has been backed up satisfying the retention policy and 2) the archive log has been sent to the standby. When there is a gap issue with the standby database, the archive logs are read from the FRA and sent to the standby. It works real nice!
Update: 03/26/2008
A colleague of mine has been doing some testing using RMAN, RAC, ASM, FRA for archive log management. Also, he has tested the integration of DataGuard into this configuration. To be more precise, he has tested using an FRA residing in an ASM disk group as the only local archive log destination. In addition to the local destination, each archive log is sent to the standby destination. Based on his testing this approach is rather robust. The archive logs are backed up via the "BACKUP RECOVERY AREA" command with a regular periodicity. This enables the FRA's internal algorithm to remove archive logs that have been backed up, once the space reaches 80% full. No manual intervention is required to remove the archive logs. Moreover, the archive logs in this configuration will only be automatically deleted from the FRA if both of the following are true: 1) the archive log has been backed up satisfying the retention policy and 2) the archive log has been sent to the standby. When there is a gap issue with the standby database, the archive logs are read from the FRA and sent to the standby. It works real nice!
posted by Eric S. Emrick at 2/17/2008
13 Comments:
Hello Eric,
In our rac production environment (10.2.0.3 linux x86_64 RAC,ASM), we are using FRA only for maintaining copies of online log
/ controlfile.
We offload our backups/archive logs to a ext3 filesystem which in turn is backed up to a tape by data protector (hp). One of the reasons for this approach is that we prefer our database backups to be available/retrievable via the typical O.S. utilities /tools and not have rman/asm as SPOF.
Hi Raj,
That sounds like a reasonable approach. I am a big advocate of BCV/Clone technology and find that approach effective and reliable. Although, you can use RMAN off split mirrors very easily as well. However, when possible, I choose to use RMAN for database backups given the non-intrusive nature of the RMAN backup process: less redo generated, less redo latch contention, block level recovery, reduced tape usage and the potential for a robust incremental backup strategy. Nonetheless, I have always felt more comfortable with OS backups for my archive logs. I have written several utilities that manage the file system space while guaranteeing an AL is backed up prior to being removed from disk. But, I really like what I read about archive log backups directly to the FRA as it, in theory, mimics what my routines do today. That is, if the FRA is backed up in accord with your backup policies the archive logs will automatically be deleted (if needed) without compromising the integrity of your recovery process. I haven't used the FRA expressly for this purpose, but find it to be a very viable choice for archive log management.
Regards,
Eric
I'm more of a spectator than a participant in backups, but we use rman/rac/asm/fra, 10.2.0.2 and 10.2.0.3, raw devices. I just looked at four of our databases, db_file_recover_dest_size was set to 750g, 750g, 850g, 1.6tb. I suspect we are saving more there than archive logs. I have seen some rman jobs backing up datafiles to disk channels. Apparently further backups are done from there to tape but I'm not familiar with many of the details. Apparently certain types of restores are much easier when rman backups are available from disk. I recall seeing the dreaded "block x cannot be read at this time" Linux IO error in the alert log for a busy production database - they had it restored much more quickly than I had expected. I'm not sure exactly how they did it though, didn't know enough at the time to look in the alert logs for the record of what was done. We have rman jobs that run every 30 minutes, back up archive logs and send success/failure mail. Ends up being a lot of mail. All pretty vague, I know, but I thought maybe the size of the FRAs would be interesting.
@anonymous
Is one/all of your archive log destinations in an FRA which resides in an ASM diskgroup?
Thanks
Eric
db_create_file_dest +DATA_AREA
db_create_online_log_dest_1 +DATA_AREA
db_create_online_log_dest_2 +RECOVERY_AREA
db_recovery_file_dest +SATA_RECOVERY_AREA ( 1+ tb )
log_archive_dest_1 LOCATION=+RECOVERY_AREA
I think this means the answer to your question is ALL.
Given your following configuration:
db_recovery_file_dest +SATA_RECOVERY_AREA ( 1+ tb )
log_archive_dest_1 LOCATION=+RECOVERY_AREA
It appears you are not using a Flash Recovery Area for your log_archive_dest_1. Your FRA is in the ASM disk group +SATA_RECOVERY_AREA. The db_recovery_file_dest paramenter defines the location of your FRA. I suspect your +RECOVERY_AREA disk group is just another disk group (from this database's perspective) to service a multi-plexed online redo thread and an archive log destination. Do you have multiple databases sharing disk groups?
Thanks for the interpretation.
Looking at an ASM alert log on a node that supports more than one non-ASM instance, I see 3 familiar disk groups ( DATA_AREA, RECOVERY_AREA, SATA_RECOVERY_AREA ) and another ( RECOVERY_AREA_256 ). Looking at db_recovery_file_dest for two non-ASM instances on that node, I see +SATA_RECOVERY_AREA, which seems to indicate that multiple databases can access the same disk group.
Hi, I'm a dba junior ... In my environment I have to Adminitrate Oracle (Single instance, Rac) and I want to know, first at all, what it's FRA?
sorry for the basic question.
@dba
The FRA is the Flash Recovery Area. See the Oracle documentation set for a complete description of the Flash Recovery Area. Just out of curiosity, why are you using single instance RAC?
Thanks
Eric
jajaja... sorry, my english is very bad... No, We have 2 environments.. One with oracle 9i(Single instance) and other whit Oracle 10g RAC, with 2 servers.
sorry. and thanks for the explanation of FRA.... i feel really dummy ... jejejeje... i supose that i had to change my nick name "dba"... jejejeje
Hello Eric,
I am a storage expert and got into an issue with archived logs on ASM.
When backing up an instance, which resides on ASM using storage snapshots capability, most vendors recommend doing snapshot to data group (with backup mode), then doing snapshot to recovery area group. I find this last snapshot space consuming and want to backup only the specific archived logs I need for recovery. If the archived logs are regular files, then no problem. But if they are in ASM, how do I backup only the ones I need (assuming I can identify them by name)? Is RMAN the only option? Is there some sort of copying them to the filesystem when needed?
Thanks,
Ran.
Hi Eric
I am keen on setting up a similar configuration. I would be interested in knowing if you got ahead in this task over the past year or so. please respond to me with how on where you are writing your archivelogs (ASM diskgroup, ASM FRA and whether on disk), how do you manage the archivelog cleanup. Do you set some parameters to cleanup from prod. How do you ensure that you delete archive logs from primary only after it has been applied to standby? How do you ship and apply them to a single instance physical standby dataguard environment. do you compress them and ship them? How do you take backups through RMAN (primary or preferably standby site. I can be reached at bagga.vikas@gmail.com
Harrah's Cherokee Casino Resort – A Quality Casino Resort
We have a non-smoking poker room, a restaurant, and a casino near Murphy. Come enjoy the atmosphere and our food. Enjoy 10cric a variety of sandwiches 샌즈카지노 and salads dafabet
Post a Comment
<< Home