Skip to main content

Backup and Recovery Configuration and Administration Best Practices

This section describes best practices for determining backup frequency, using the RMAN recovery catalog, and for using Oracle database backup options such as Block Change Tracking.

Determine a Backup Frequency and Retention Policy

It is important to determine a backup frequency policy and to perform regular backups. A backup retention policy helps ensure that needed data is not destroyed.
Factors Determining Backup Frequency Frequent backups are essential for any recovery scheme. You should base the frequency and content of backups on the following criteria:
  • Criticality of the data: The Recovery Point Objective (RPO) determines how much data your business can acceptably lose if a failure occurs. The more critical the data, the lower the RPO and the more frequently data should be backed up. If you are going to back up certain tablespaces more often than others, with the goal of getting better RPO for those tablespaces, then you also must plan for doing TSPITR as part of your recovery strategy. This requires considerably more planning and practice than DBPITR, because you must ensure that the tablespaces you plan to TSPITR are self-contained.
  • Estimated repair time: The Recovery Time Objective (RTO) determines the acceptable amount of time needed for recovery. Repair time is dictated by restore time plus recovery time. The lower the RTO, the higher the frequency of backups, that is, backups are more current, thereby reducing recovery time.
  • Volume of changed data: The rate of database change effects how often data is backed up:
    • For read-only data, perform backups frequently enough to adhere to retention policies.
    • For frequently changing data, perform backups more often to reduce the RTO.
To simplify database backup and recovery, the Oracle Suggested Recovery Appliance Backup Strategy for the Enterprise uses RMAN to send incremental database backups and redo using Data Guard transport to the Recovery Appliance, while the Oracle Suggested Backup Strategy uses the fast recovery area, incremental backups, and incrementally updated backup features for a particular database. After the initial image copy backup to the FRA, only the changed blocks are captured in the incremental backups thereafter and subsequently applied to the image copy, thereby updating the copy to the most current incremental backup time (that is, incrementally updating the backup).
See Also:
Establishing a Backup Retention Policy A backup retention policy, which is implemented as a Protection Policy on the Recovery Appliance, is a rule set regarding which backups must be retained, on disk or other backup media, to meet recovery and other requirements. It may be safe to delete a specific backup because it has been superseded by more recent backups or because it has been stored on tape. You may also have to retain a specific backup on disk for other reasons such as archival or regulatory requirements. A backup that is no longer needed to satisfy the backup retention policy is said to be obsolete.
Base your backup retention policy on redundancy or on a recovery window:
  • In a redundancy-based retention policy, specify a number n such that you always keep at least n distinct backups of each file in your database.
  • In a recovery window-based retention policy, specify an earlier time interval, for example, one week or one month, and keep all backups required to let you perform point-in-time recovery to any point during that window.
Keeping Archival Backups Some businesses must retain some backups for much longer than their day-to-day backup retention policy. RMAN allows for this with the Long-term Archival Backup feature. Rather than becoming obsolete according to the database's backup retention policy, archival backups either never become obsolete or become obsolete when their time limit expires.
You can use the RMAN BACKUP command with the KEEP option to retain backups for longer than your ordinary retention policy. This option specifies the backup as an archival backup, which is a self-contained backup that is exempt from the configured retention policy. This allows you to retain certain backups for much longer than usual, when needed for such reasons as satisfying statutory retention requirements. Using the KEEP FOREVER option, a recovery catalog is required because the backup records eventually age out of the control file (otherwise, without a recovery catalog, loss may occur when you retain backups for much longer than usual using the database control file). Only the archived redo log files required to make an archival backup consistent are retained. For more information about the RMAN recovery catalog, see Section 7.2.2, "Use an RMAN Recovery Catalog".

 Use an RMAN Recovery Catalog

To protect and keep backup metadata for longer retention times than can be accommodated by the control file, you can create a recovery catalog. When using the Recovery Appliance, the Recovery Appliance is the recovery catalog for all databases. When not using a Recovery Appliance, you should create the recovery catalog schema in a dedicated standalone database. Do not locate the recovery catalog with other production data. If you use Oracle Enterprise Manager, you can create the recovery catalog schema in the Oracle Enterprise Manager repository database.
The advantages of using a recovery catalog include:
  • Storing backup information for a longer retention period than what can be feasibly stored in the control file. If the control file is too small to hold additional backup metadata, then existing backup information is overwritten, making it difficult to restore and recover using those backups.
  • Stores metadata for multiple databases.
  • Offloading backups to a physical standby database and using those backups to restore and recover the primary database. Similarly, you can back up a tablespace on a primary database and restore and recover it on a physical standby database. Note that backups of logical standby databases are not usable at the primary database.
See Also:
Oracle Database Backup and Recovery User's Guide for more information about RMAN repository and the recovery catalog

Create Backups in NOCATALOG Mode and Then RESYNC CATALOG When Not Using Recovery Appliance

When creating backups to disk or tape, use the target database control file as the RMAN repository so that the success of the backup does not depend on the availability of the database connection to the recovery catalog. To use the target database control file as the RMAN repository, run RMAN with the NOCATALOG option. Immediately after the backup is complete, the new backup information stored in the target database control file should be synchronized to the recovery catalog using the RESYNC CATALOG command.
See Also:
Oracle Database Backup and Recovery Reference for more information about the RESYNC CATALOG command

 Enable Block Change Tracking for Incremental Backups

Oracle database includes the BLOCK CHANGE TRACKING feature for incremental backups which improves incremental backup performance by keeping track of which database blocks have changed since the previous backup. If BLOCK CHANGE TRACKING is enabled then RMAN uses the block change tracking file to identify which blocks to include in an incremental backup. This avoids the need to scan every block in the data file, reducing the number of disk reads during backup.
Starting with Oracle Database 11g, you can enable BLOCK CHANGE TRACKING on both the primary and physical standby databases. You should enable change tracking for any database where incremental backups are being performed. For example, if backups have been completely offloaded to a physical standby database, then Block Change Tracking should be enabled for that database (this requires Active Data Guard). If backups are being performed on both the primary and physical standby databases, then enable Block Change Tracking for both databases.
See Also:

Enable Autobackup for the Control File and Server Parameter File

You should configure RMAN to automatically back up the control file and the server parameter file (SPFILE) whenever the database structure metadata in the control file changes or when a backup record is added.
The control file autobackup option enables RMAN to recover the database even if the current control file, catalog, and SPFILE are lost. Enable the RMAN autobackup feature with the CONFIGURE CONTROLFILE AUTOBACKUP ON statement.
You should enable autobackup for both the primary and standby databases. For example, after connecting to the primary database, as the target database, and the recovery catalog, issue the following command:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
See Also:

Offload Backups to a Physical Standby Database

In an Oracle Data Guard configuration you can offload the process of backing up control files, data files, and archived redo log files to a physical standby database system, thereby minimizing the effect of performing backups on the primary system. You can use these backups to recover the primary or standby database.
Note:
Backups of logical standby databases are not usable on the primary database.
See Also:
Oracle Data Guard Concepts and Administration for information about using RMAN to back up and restore files

Set UNDO Retention for Flashback Query and Flashback Table Needs

To ensure a database is enabled to use Flashback Query, Flashback Versions Query, and Flashback Transaction Query, implement the following:
  • Set the UNDO_MANAGEMENT initialization parameter to AUTO. This ensures the database is using an undo tablespace.
  • Set the UNDO_RETENTION initialization parameter to a value that allows UNDO to be kept for a length of time that allows success of your longest query back in time or to recover from human errors.
  • Set the RETENTION GUARANTEE clause for the undo tablespace to guarantee that unexpired undo will not be overwritten.
The Flashback Table also relies on the undo data to recover the tables. Enabling Automatic Undo Management is recommended and the UNDO_RETENTION parameter must be set to a period for which the Flashback Table is needed. If a given table does not contain the required data after a Flashback Table, it can be flashed back further, flashed forward, or back to its original state, if there is sufficient UNDO data.
See Also:

https://docs.oracle.com/database/121/HABPT/config_backuprec.htm#HABPT5148

Comments

Post a Comment

Popular posts from this blog

Oracle SQL92_SECURITY parameter

The Oracle SQL92_SECURITY parameter must be set to TRUE. The configuration option SQL92_SECURITY specifies whether table-level SELECT privileges are required to execute an update or delete that references table column values. If this option is disabled (set to FALSE), the UPDATE privilege can be used to determine values that should require SELECT privileges. The SQL92_SECURITY setting of TRUE prevents the exploitation of user credentials with only DELETE or UPDATE privileges on a table from being able to derive column values in that table by performing a series of update/delete statements using a where clause, and rolling back the change.  In the following example, with SQL92_SECURITY set to FALSE, a user with only delete privilege on the scott.emp table is able to derive that there is one employee with a salary greater than 3000. With SQL92_SECURITY set to TRUE, that user is prevented from attempting to derive a value.  SQL92_SECURITY = FALSE SQL> delete from s...
Post a Comment
Read more

Ofruesit e sistemeve të menaxhimit të bazës së të dhënave

Ofruesit e sistemeve të menaxhimit të bazës së të dhënave Cila është mënyra më e mirë për të përcaktuar se cili lloj i shërbimit të bazës së të dhënave ose bazës së të dhënave është më e mira për ndërmarrjen tuaj? E gjitha varet nga lloji i rastit të përdorimit që ju nevojitet. Zbuloni më shumë në këtë artikull , dhe artikujt vijues. Sistemi I menaxhimit të të dhenave Në thelb të gjitha informacionet digjitale që përdorim në baza ditore janë në një sistem të menaxhimit të bazës së të dhënave ose një grupi ruajtës diku në botë. Këto mund të shkojnë nga një pajisje e vogël e ruajtjes si një smartphone   ose a aq i madh sa një sistem ruajtje relativisht i pakufizuar i cloud. Më së miri është të zbuloni se cila DBMS është për ndërmarrjen tuaj? A duhet të abonoheni në një shërbim në AWS, Azure, Google ose ofrues tjetër cloud ose duhet të blini magazinimin e qendrës së të dhënave dhe serverat dhe ta ekzekutoni atë vetë? E gjitha varet nga lloji i rastit të përdorimit që ju ...
Post a Comment
Read more

Autentifikimi, Autorizimi dhe Llogaritja (AAA)- Authentication, Authorization, and Accounting (AAA)

Autentifikimi, Autorizimi dhe Llogaritja (AAA)- Authentication, Authorization, and Accounting (AAA) Autentifikimi, autorizimi dhe llogaritja (AAA) është një term për një kornizë për kontrollin inteligjent të qasjes në burimet kompjuterike, zbatimin e politikave, përdorimin e auditimit dhe sigurimin e informacionit të nevojshëm për të faturuar shërbimet. Këto procese të kombinuara konsiderohen të rëndësishme për menaxhimin efektiv të rrjetit dhe sigurinë. Si proces i parë, autentifikimi siguron një mënyrë për identifikimin e një përdoruesi, zakonisht duke i dhënë përdoruesit një emër përdoruesi të vlefshëm dhe një fjalëkalim të vlefshëm përpara se qasja të jepet. Procesi i legalizimit bazohet në secilin përdorues që ka një grup të kritereve unike për të fituar akses. Serveri AAA krahason kredencialet e identifikimit të përdoruesit me kredencialet e tjera të përdoruesit të ruajtura në një bazë të dhënash. Nëse kredencialet përputhen, përdoruesit i jepet aksesi në rrjet. Nëse kre...
Post a Comment
Read more