Users see your wonderful DataGuard implementation like this:
And yet, you know the actual picture looks more like this:
High-availability – the concept behind it makes every DBA shudder because every time it seems you deal with one element and have it protected, there’s another underlying component that also needs protection and redudancy, or else your solution is still insufficient.
Real Application Clusters (RAC) covers individual database host failures but is sensitive to failure of the storage subsystem or the network interconnections between the hosts.
Recovery Manager (RMAN) is your vital tool to keeping track of what’s backed up and where is it. And its catalog of recovery information could reside locally in copies of the controlfiles, or centrally in another database. Depends on your backup strategies, really. Are you using SAN-based backups (snaps, virtual images, deduplicated block replication) or off-site methods that would have to be shipped back to start recovery?
But the typical first-time setup scenario, is you use the OEM-based jiffy whizbang method to setup your new DataGuard environment at the recommendation of one of the steps int the Maximum Availability Advisor (MAA), and everything’s up and running nicely. You schedule a new weekly full backup, plus daily incremental backup as Oracle recommended practices prescribe, and notice everything’s running smoothly.
Except on your standby database, the archivelogs are piling up and not being deleted automatically. What’s next?
This thread was a basic discussion in the Oracle Community forums of the topic:
https://community.oracle.com/thread/2388130?start=0&tstart=0
This is a typical RMAN-based configuration:
On Primary
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
On Standby ( Depends upon where backup is preformed )
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
Or
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
/* if Standby Where Backups Are Not Performed */
Source:
Data Guard Concepts and Administration 12c
http://docs.oracle.com/database/121/SBYDB/toc.htm
12 Using RMAN to Back Up and Restore FilesRMAN Configurations at the Primary Database
12.3.4 RMAN Configurations at a Standby Where Backups Are Not Performed
The following RMAN configurations are recommended at a standby database where backups are not done:
- Connect RMAN to the standby database as target, and to the recovery catalog.
- Enable automatic deletion of archived logs once they are applied at the standby database (this is also applicable to all terminal databases when the cascading or far sync instance features are in use):
- CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
** However, that doesn’t really take into consideration what might happen if a final archivelog before switchover of roles doesn’t quite make it on the standby (for whatever reason, it gets corrupted during playback or something similar which results in a Database Needs More Recovery error.)
Based upon:
12.3.3 RMAN Configurations at a Standby Database Where Backups are Performed
The following RMAN configurations are recommended at a standby database where backups are done:
- Connect RMAN to the standby database (where backups are performed) as target, and to the recovery catalog.
- Enable automatic backup of the control file and the server parameter file:
3. RMAN > CONFIGURE CONTROLFILE AUTOBACKUP ON;
- Skip backing up data files for which there already exists a valid backup with the same checkpoint:
5. RMAN > CONFIGURE BACKUP OPTIMIZATION ON;
- Configure the tape channels to create backups as required by media management software:
7. RMAN > CONFIGURE CHANNEL DEVICE TYPE SBT PARMS ‘<channel parameters>’;
- Because the archived logs are backed up at the standby database, Oracle recommends that you configure the BACKED UP option for the log deletion policy:
9. RMAN > CONFIGURE ARCHIVELOG DELETION POLICY BACKED UP n TIMES TO [DEVICE TYPE SBT];
I came up with the configuration of:
On Standby ( Depends upon where backup is preformed )
# If no DataGuard is present (single DB host):
# Ensure daily RMAN backup job is being executed in OEM or via cron.
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK;
And setup a 2nd backup set for the Standby Host DB. This puts the backups into the defined Fast Recovery Area and manages both the backups and archivelog retention in the same mountpoint.
Each has its pros and cons depending on the scenario.You need to lay out your entire architecture scheme including backup solutions and play out the various scenarios that you’re required to cover as far as your Quality of Service (QOS) guarantee to your end-user population.
And of course, if you’re using the advanced cross-WAN FarSync DataGuard implementation architecture (wherein there’s a separate Failover Archive Log (FAL) standby database whose sole purpose in life is to cache archivelogs in case the data replication stream is too much for WAN bandwidth to handle in real-time.) this all still applies because the FAL server is basically just another standby target which needs managing just as much as any regular LAN-based full DataGuard standby instance (it’s just missing the big datafiles and handles all the archivelog traffic.) You’ll just have even more servers and services involved in keeping the whole thing running (like your Global Names Service servers and databases, which might also be RAC and DataGuard protected, or your Single-Sign On authentication services, or even the OEM Cloud Control OMS itself orchestrating all of that.)
Thoughts from James H. Lui 
You must be logged in to post a comment.