Reference for rman backup policy formulation

Reference for rman backup policy formulation
I. Before formulating the rman backup policy, redo logs should be evaluated. This article follows the suggestions in the official documentation: Recommended: Oracle recommends that you multiplex the online redo log. the loss of log files can be catastrophic if recovery is required. when you multiplex the online redo log, the database must increase the amount of I/O it performs. depending on your system, this additional I/O may impact overall database performance. we recommend that you use multiple redologs (redo01a in oracle. log) to ensure redo redundancy !, And put redundant redolog on different disks (in the figure, redo01a. log is placed in diakA) to reduce I/O overhead! Ii. configuration of archive logs: To archive to multiple destinations, you can choose to archive to two or more locations using theLOG_ARCHIVE_DEST_n initialization parameters, or to archive only to a primary and secondary destination using theLOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST initialization parameters. we recommend that you use log_archive_dest_n in oracle to configure the archivelog placement path! In addition, we still follow the redundancy policy! Note: If you configure a Fast Recovery Area (by setting the DB_RECOVERY_FILE_DEST andDB_RECOVERY_FILE_DEST_SIZEparameters) and do not specify local archive destinations, the database automatically selects the Fast Recovery Area as a local archive destination and setsLOG_ARCHIVE_DEST_1 to USE_DB_RECOVERY_FILE_DEST. if a Fast Recovery Area is specified and no local archiving path is specified. Oracle uses the default quick recovery area as the archive path. You must ensure that there is sufficient disk space at all times for archive log destinations. if the database encounters a disk full error as it attempts to archive a log file, a fatal error occurs and the database stops responding. you can check the alert log for a disk full message. make sure that the specified archiving path has enough space to store archived logs. If oracle finds insufficient space during archiving, it will stop responding (suspended). A message indicating insufficient disk is displayed in the alter file! Iii. Therefore, the dba must estimate the size of the quick recovery zone and then set it! Use of the fast recovery area is strongly recommended. Consider refreshing a fast recovery area as a first step in implementing a backup strategy
Quick recovery zones are strongly recommended for oracle. The first step in creating a backup policy is to configure the quick recovery zone! You enable the fast recovery area by setting two initialization parameters.
These parameters enable the fast recovery area without having to shut down and restart the database instance. to enable fast recovery area, you only need to enable the following two parameters! You do not need to restart instanceYou set the size of the fast recovery area with the parameter DB_RECOVERY_FILE_DEST_SIZE first,
And then you set the physical location of the flash recovery files with the parameterDB_RECOVERY_FILE_DEST. the following describes how to configure the size of the quick recovery zone on The official website: the larger the fast recovery area is, The more useful it becomes. ideally, the fast recovery area shoshould be large enough to contain the files listed in Table 5-2. the rediscovery area shocould be able to contain a copy of all datafiles in the database and the incremental backups used by your chosen backup strategy. if providing this much space is impractical, then it is best to create an area large enough to keep a backup of the most important tablespaces and all the archived logs not yet on tape. at an absolute minimum, the fast recovery area must be large enough to contain the archived redo logs not yet on tape. if the rediscovery area has insufficient space to store new flashback logs and meet other backup retention requirements, then to make room, the rediscovery area may delete older flashback logs. formulas for estimating a useful fast recovery area size depend on whether: Your database has a small or large number of data blocks that change frequentlyYou store backups only on disk, or on disk and tapeYou use a redundancy-based backup retention policy, or a recovery window-based retention policyYou plan to use Flashback Database or a guaranteed restore point as alternatives to point-in-time recovery in response to logical errorsIf you plan to enable flashback logging, then the volume of flashback log generation is approximately the same order of magn1_as redo log generation. for example, if you intend to set DB_FLASHBACK_RETENTION_TARGETto 24 hours, and if the database generates 20 gigabytes of redo in a day, then a general rule of thumb is to allow 20 GB to 30 GB of disk space for the flashback logs. the same rule applies to guaranteed restore points when flashback logging is enabled. for example, if the database generates 20 GB of redo every day, and if the guaranteed restore point is kept for a day, then plan to allocate 20 to 30 GB. suppose that you want to determine the size of a fast recovery area when the backup retention policy is set toREDUNDANCY 1 and you intend to follow Oracle's suggested strategy of using an incrementally updated backup. in this example, you use the following formula to estimate the disk quota, where n is the interval in days between incremental updates and y is the delay in applying the foreign archived redo logs on a logical standby database: Disk Quota =
Size of a copy of database +
Size of an incremental backup +
Size of (n + 1) days of archived redo logs +
Size of (y + 1) days of foreign archived redo logs (for logical standby) +
Size of control file +
Size of an online redo log member * number of log groups +
Size of flashback logs (based on DB_FLASHBACK_RETENTION_TARGET value) is too complicated. The method I used is to estimate the data volume of oracle and allocate a reasonable size. Check the size of the quick recovery area once a day. SELECT * from v $ RECOVERY_FILE_DEST; check the size of the quick recovery area. SELECT * from v $ RECOVERY_AREA_USAGE; check that the files are properly set based on the backup policy! For example, my current backup policy is based on the backup policy of the 30-day time window. Zero-level Incremental backup over the weekend, 1, 2, 3 differential incremental backup, 4 cumulative incremental backup, 5, 6 differential incremental backup! The database is not flashed back, the archived logs are in other directories, and the redo is not in the quick recovery area. The daily data volume is less than 5%. I just made a full backup and occupied the size of the GB fast recovery zone. According to the rman policy, set the size to 10 Gb.