1 person found this helpful
3. CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
To gurantee you have all backup information in the contol file make sure you have set
CONTROL_FILE_RECORD_KEEP_TIME to desired value default value is 7 days it cannot gurantee will keep backup information more than 7 days old in the controlfile.
I suggest to use recovery catalog in order to secure your backup information.
3) Control file mulitplication
It is highly recommended, hou have to do it with multiple mount points or multiple ASM disk groups.
4) Redo log groups
Ofcourse we need to consider to have multiple member in each redo log group.
With respect to data protection, I recommend to set up a dataguard from your production server to DR.
And if yo have active dataguard or real time sync you will have update to date data available in other site.
1 person found this helpful
The way I see it, if DB Server XYZ dies, I wouldn't be able to restore using RMAN because Control File is not multiplex to Server ABC. Is that accurate? You cannot multiplex controlfiles to multiple servers . You can only multiplex with multiple mount points or multiple ASM disk groups.
For example : Here we are multiplexing controlfile to three different mount points.
CONTROL_FILES = (/u01/oracle/prod/control01.ctl,
1 person found this helpful
Also, to restore to a new server (in total DR situations), I would restore Control File, Full Backup from Server ABC, and recover to the last Archived Logs on Server ABC. Is that accurate? Yes the sequence will be.
1) Startup the database using init file, nomount mode.
2) Restore controlfile, mount the database.
3) Restore full backup and archivelogs until last archivelog
rman> restore database;
rman> recover database;
sql> alter database open resetlogs;
Lastly, if I multiplex Redo Logs to Server ABC as well, I should be able to recover pretty close to the time of disaster. Is that accurate? As controlfile here as well same you cannot multiplex redo logs to multiple servers instead each redo log you can have multiple members which resides on multiple mount points.
1) Archiving to the FRA is best practice, and you can also send archivelogs to other locations if needed.
ARCHIVE_LAG_TARGETforces a log switch after the specified amount of time elapses.
2) Autobackup is also a good idea, as RMAN is able to search for the name of this backup for the purpose of a restore if you don;t know what the name is.
3) The backup retention policy of 7 days, tell RMAN that you may need to recover to up to 7 days in the past.
RMAN will determine which backups are obsolete, but if you want to delete obsolete backup files, then you need to manually do this.
4) You can do backups as you require.
5) You will be able to restore and recover on the other server, if the controlfile backup (or autobackup) is available. This is regardless of whether you multiplexed the controlfiles.
You can't multiplex controlfiles across different servers. So in a DR, you just need to make available all the backup files (including as many archivelogs as possible) from the other server.
Sorry, but there seems to be a misconception about pretty much everything here. If you are designing a DR plan for a production system, I suggest to reconsider and to do your homework first, so to speak.
We could sit here for the rest of the week to discuss your strategy, but just to give you some clues:
1. Archive_lag_target set to 3600 (1 hour): archiving hourly to fast_recovery_area and server ABC
I've not seen the use of ARCHIVE_LAG_TARGET and from what I've read so far, this is mainly used for a standby database. The parameter, if used, is usually 30 min. Rotation and hence archiving of redo logs, by rule of thumb, should be configured to happen every 15 minutes for performance reasons, and depends on transaction volume and size of redo logs.
If you wish to mirror/multiplex archivelogs in FRA and some other, non Oracle managed location, you can do so as explained in https://docs.oracle.com/cd/B28359_01/server.111/b28310/archredo004.htm#ADMIN11338. Be aware, however, that the database will halt when archivelogs in a mandatory location cannot be written, e.g. out of space, network trouble, etc.
2. CONFIGURE CONTROLFILE AUTOBACKUP ON;-- auto backup of control file during RMAN backup.
RMAN will always backup the controlfile and spfile when the backup includes the system tablespace. Autobackup simplifies the restore of the controlfile when you do not have an RMAN catalog database. It also performs a backup of the controlfile when there are structural database changes. You cannot restore a dropped tablespace, without restoring the previous control file first, for example.
3. CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; -- keep on Server ABC for 7 days before being marked obsolete and removed.
The RMAN retention policy does not mark any obsolete backups. When you run RMAN report obsolete, RMAN evaluates what backups are required to accomplish the specified recovery window. RMAN does not delete any data unless you issue the command and a recovery window of 7 days does not mean data older than 7 days will be removed - again it depends what backups are required to accomplish the recovery window. Also pay attention to the control_file_record_keep_time parameter, which only guarantees metadata for the last 7 days by default.
4. RMAN daily backup to Server ABC. Full backup size is about 50gb / day.
Lastly, if I multiplex Redo Logs to Server ABC as well, ...
RMAN does not and cannot backup the online redo logs. If you need to restore the controlfile, you must open the database with open resetlogs, hence creating a new database incarnation and resetting the log sequence number, effectively erasing the redo logs.
There is still much more to explain, but I hope you find the info so far useful and realize the complexity.