Backup and Recovery Strategies1

2.1. Data Recovery strategy determines Backup strategy
You are designing a backup strategy. If the data recovery needs and data recovery strategy starts. Each type of data recovery requires that you take the appropriate backup type.

Failure occurs in user error, data File block corruption, media failure. The speed at which the normal operation of the database starts is the execution process of the type of restore and recovery technology. Each restore and recovery technology imposes a need on the backup strategy. Contains the attributes that the database will use to store and manage your backups.
When you consider a recovery strategy. The questions to ask yourself are:
(1) Assume that the disk failed and damaged some database files. For example, data files and redo logs, how do you want to recover lost files.
Planning a Response to media failure:restore and media Recovery
(2) Suppose that the application logic error or a user error caused the loss of key data in multiple tables or tablespaces, how can you recover those data. What happens when I start a database update from an error? Can you solve the cause of the error and prevent it from happening again?
Planning responses to User error:point-in-time Recovery and Flashback
(3) Suppose the alert log of the instance shows one or more tables including the damaged block, how do you fix the damage? Must the tablespace remain available during the repair?
Planning a Response to datafile Block corruption:block Media Recovery
(4) If the entire data center is damaged, can you complete the disaster recovery? If you only have archive tapes that include backups. How do you recover the database? How long does it need to recover?

(5) If you leave, will anyone else be able to recover the database? Is your recovery process fully self-motivated and documented?

Thinking about these issues determines how you can take advantage of backup and recovery-related features and how each feature meets the need for a backup strategy.

Example:
(1) There are many other operations that simplify backup and restore using Rman than user-managed backup and recovery. It proactively manages very many backup files, such as the deletion of backup and archive logs that are no longer needed for recovery on disk or tape. It provides a specific report of the backup activity that identifies the backup that is available as a recovery database. Rman supports incremental backups, but user-managed backup and recovery does not support incremental backups
(2) The Flashback database helps you restore the database to a previous point in time, which is faster than media recovery.

However you must configure a high-speed flash back zone and save flash logs
(3) Assume that availability is strict. Block media recovery is better than data file media recovery.

Even if the backup policy is not dependent on Rman. Block media recovery is also possible. It is faster and less difficult to recover based on Rman block media.

Once you decide which feature to use in your recovery strategy. You can design a backup strategy and ask yourself questions such as the following:

(1) How and where do you save your backups? Will you use a high-speed flash back area? Will you use an ASM disk group to support redundancy? You will save the backup on disk or other offline storage. Or just a disk?
(2) How often do you schedule backups? In each case, what kind of physical backup composition do you take?
(3) Which situation requires you to take a database backup outside of the prescribed schedule? Sometimes you have to take a non-scheduled backup to make sure you can recover the data. For example, after open resetlogs. Change your database to nologging (the operation will not be in the Redo log now).

You may also have business needs that require a backup of the audit target.
(4) How do you verify your backup so that you can recover your database when needed?
(5) Do you have specific recovery designs for each type of failure? How do you run these plans in times of crisis? Can scripts be written and run on their own initiative in times of crisis?
(6) during a database failure. Can you apply Oracle database high availability technology, such as DG or RAC, to improve availability? How does the use of these high availability technologies affect your backup and recovery strategy?

2.2. Planning Data Recovery Strategy
A data recovery strategy should contain any database failure scenarios. The key to an effective and efficient strategy is to anticipate failure conditions and match the appropriate database recovery techniques and tools in the failure situation. Then confirm that your hybrid backup type supports these recovery techniques.

2.2.1, planning responses to User error:point-in-time Recovery and Flashback Features
A user and application may produce unwanted changes, such as incorrect updates, delete rows, or drop tables. A suitable backup and recovery strategy using a variety of database features allows you to return the database to the desired state, with minimal impact on database availability at the same time. DBAs have the least difficulty.

Depend on the situation you are in. Consider each option that makes up the backup strategy, and then build the database to make these options available.

2.2.1, planning responses to User error:point-in-time Recovery and Flashback Features
A user and application may produce unwanted changes, such as incorrect updates, delete rows. or drop table. A suitable backup and recovery strategy uses a variety of database features to allow you to return the database to the desired state. Minimal availability of database at the same time
Effect. DBAs have the least difficulty. Depend on the situation you are in. Consider each option that makes up the backup strategy, and then build the database to make these options available.

2.2.1.1, Flashback Database
Just want you to have the log of the flashback database. You do not need to restore the backup to use the Flashback database to return the entire database to its previous state.

You can open flashback logging and agree to return to any SCN. Or you can create guaranteed restore points
For example, before the primary database is updated. It guarantees that the flashback database can be used.

You must configure a high-speed flashback zone for the flashback database and a secure restore point.

2.2.1.2, Creating Normal and guaranteed Restore Points
A secure restore point ensures that you can use the Flashback database to return the database to a previous point in time.

Normal restore points does not provide data protection, but they are a convenience, because creating one, you can avoid logging the database's SCN before you use a point-in-time recovery or flashback table. Or you have to study after deciding on the correct SCN. Although you must design a restore point before the restore point needs to be created. However, using normal restore points does not require a special design.
2.2.1.3, Database point-in-time Recovery
You can finish. Based on point-in-time recovery, bring a tablespace or entire database back to the wrong moment. In either case, you need to back up before the wrong moment.

2.2.1.4, importing Lost Objects from Logical Backup
Let's say you export the affected tables by exporting a logical backup, and you can import the data into the table.

Note: Oracle's flash-back technology provides faster and less damage than media recovery in very many scenarios
(1) The flashback database is a physical-level recovery mechanism that is very similar to media recovery, but generally faster and does not need to be restored from backup
(2) The Flashback table and the flashback drop are the logical level of the recovery mechanism. Rollback table does not want to change. Contains the effect of reversing the drop TABLE statement
(3) Flashback query and flashback version number queries are useful in viewing past contents of a table and studying how and when a logical corruption affects a database.

The features about flashback are collected in Chapter 7, "Performing Flashback and Database point-in-time Recovery".

2.2.2, planning a Response to media failure:restore and media Recovery
When a problem is preventing the database from reading or writing. A media failure occurred. A typical media failure includes a physical failure, such as a file header crash. Overrides, deletion or corruption of data files. Media failures are rare compared to user and application errors, but backup and recovery policies must be ready. The type of media failure determines the technology used for recovery.

For example, the recovery policy for corrupted data files is different from the recovery strategy for controlling file loss.

Example: Redo Log Recovery
All members of a log group are missing a recovery strategy that relies on very many factors. Example:
(1) The State of the database (open, crash. Consistency off)
(2) Whether the missing Redo log Group is current
(3) The lost Redo log Live is archived
Assuming that the current log group is missing, the database does not have a consistent shutdown at the same time (it can be open and can be a crash), then you have to restore an old backup and complete a point-in-time recovery to run open resetlogs. You have lost in
All transactions in the log are lost. Subsequently, after the open resetlogs. You should immediately take a full backup of a database;
Assume that the current log group is missing. Database consistency is closed at the same time. Then you run open resetlogs and no transaction is lost. But. You should immediately take a full backup of a database;
Assume that a non-current log group is missing. Then you can use the ALTER DATABASE clear logfile statement to reconstruct all members of the log group. Without the loss of a transaction, immediately take a full backup of a database.

Suppose the missing log group has been archived. Then you don't have to do whatever you need to do.

2.2.3, planning a Response to datafile Block corruption:block Media Recovery
Assuming that a very small chunk of one or more data files is damaged, you are able to complete the block media recovery instead of the full media recovery of the data file. Rman's blockrecover command can be used to restore and restore a specified block of data, but the database needs to be open at the same time as the corrupted data file needs to be online.
Oracle Database Backup and Recovery Advanced User's Guide describes how to use Rman to complete block media recovery.

2.3. Planning Backup Strategy
A data recovery strategy is the basis for a data backup strategy.

This discussion describes the general guiding Principles. It can help you decide when to make a database backup, what parts of the database you should back up, what tools Oracle provides for backup, how to configure the database to improve robustness, and how to make backup and recovery easier. Of course, your strategy must balance the need for recovery strategies with the costs of problems, resources, manpower, and other factors.

2.3.1, protecting Your redundancy set--databases are backed up on a separate disk, control files, data files using techniques such as RAID to achieve redundancy, redo logs for archiving and use of multiplexing
A data file, a control file, or a redo log, regardless of a failure. The set of files that recover a database is called a redundancy set. Redundant sets (backup sets) should include:
(1) Recent backup of control files and all data files
(2) All archived logs generated after a recent backup
(3) Copy of current control file and redo log generated by Oracle Multi-channel replication
(4) A copy of the configuration file, for example, the server parameter file. Tnsnames.ora. Listener.ora
Note: Do not save the redundancy set to the data file. Redo the log and control files on the disk. Otherwise, the disk becomes a single point of failure. Assuming this disk fails, you lose the committed transaction.

A minimum production level database requires at least two disks: one to save the redundancy set and one to save the database file.

Ideal. Use every possible method: cut the volume, cut the file system, cut the raid device to save the redundancy set.

The simplest way to manage redundancy sets is to use a high-speed flash-back zone. It is placed on a device separate from the database file. However. Whether or not you use a high-speed flash-back zone, Oracle recommends the following conventions for example:
(1) Multi-copy online redo log files and control files at the database level (the configuration database writes redo logs to two or more locations.) Then each write is a separate operation). Assuming a multi-path replication at the database level, an I/O failure or loss write will only damage one copy.

Ideally. Multiple copy files should be placed on different disks of different disk controllers. The high-speed recovery area is a good location for storing copies. You can also copy redo logs and control files at the operating system level or at the hardware level. But it is not an alternative to multi-channel replication.

(2) Assume that the database executes in archive mode. Archive redo logs to different disks. Suppose you use the high-speed recovery area as one of the archive locations.
(3) database-level multiplexing, all copies of the control file must always be available, or the instance crashes. Operating system or hardware-level mirroring, the database can continue to execute, even if a copy of the disk failure control file is unavailable.
(4) Assume that it is possible to use an operating system or hardware-level mirror to avoid media recovery for a simple disk failure
(5) Assuming that the target database is stored on a RAID device, the redundancy set should be placed on a disk different from the RAID device

2.3.2, deciding Whether to use a Flash Recovery area
It is strongly recommended that you save as many backup and recovery files as possible using the high-speed flash-back zone.
Some of the backup and recovery features of Oracle databases, such as Oracle Flashback database and secure restore point, require the use of high-speed flash-back zones. However, the high-speed flashback zone does not force you to save all recovery-related files.

Even if you do not have to use the high speed flash zone. But. High-speed flash-back zones offer a lot of advantages. Backups that have been copied from the high-speed flashback zone to tape remain on the disk until other files require space, resulting in fewer backups being restored from tape. At the same time, files that no longer match the backup target expiration are deleted appropriately. DBAs do not have to manually delete old backups.
on page 3-13: Setting up a Flash Recovery area for RMAN. Provides a lot of other information about the use and profitability of high-speed flash-back zones

2.3.3, deciding between ARCHIVELOG and Noarchivelog Mode
The redo log records all changes to the data files of the database (some exceptions. For example, direct path loads).

The database is capable of performing in two modes: Archivelog mode and Noarchivelog mode. In archive mode, the used redo log group again
Must be copied to one or more archive locations before use. Non-archive mode. When a log member is used again. Redo log groups are rewritten.

2.3.3.1, implications of Running in Noarchivelog Mode
The database is executed in non-archive mode. Backup and recovery policies are restricted:
(1) cannot complete the online backup of the database. The database must be closed consistently before the backup.

(2) You cannot use any data recovery technology that requires archiving of logs. These technologies include full and point-in-time media recovery, and more advanced recovery techniques such as point-in-time recovery and flashback databases for a single table space
To perform in non-archive mode, you must recover from disk failure at the same time, and you have two important options:
(1) Delete all the objects in the affected data file, the rest of the database is intact, but all the data in the affected file is lost.
(2) Restore the entire database to a recent backup, losing all changes from the beginning of the backup

2.3.3.2, implications of Running in ARCHIVELOG Mode
For very many applications, it is better to perform in non-archival mode. There are many other flexible recovery options after data loss, such as point-in-time recovery of databases and tablespaces.

However, execution has a related cost in the archive mode:
(1) Set the space for the archive location.

There are a large number of update logs in the database
(2) You must manage saved archive logs. To limit disk space, archived logs can be copied to tape and no longer match the recovery target old logs should be deleted. (Rman is able to proactively manage the archive log, which records the contents of all archived logs and makes it easier to copy archived logs to tape.) Same time identify and delete old logs that no longer match the recovery target)
(3) Background process arc0 to ARCN. Copy redo log to archive location

2.3.4, deciding Whether to use Oracle Flashback Features and Restore Points
When you fix the impact of an unwanted database change. Use the Flashback feature to increase the availability of the database.

The logic level of the Flashback feature agrees that no affected objects are still available, and the physical level of the flashback database is faster than a point-in-time recovery. Assuming you want to take full advantage of the logic-level flashback feature, you must consider how the database manages rollback data. Oracle Database Concepts and Oracle Database Administrator's Guide provides a number of other information about rollback data and your own proactive rollback management.

2.3.5, choosing a Backup Retention Policy
A backup retention policy is a rule that you set to save the backup matching recovery and other requirements. Backup retention policies are based on redundancy or a recovery form. In a redundancy-based retention policy, you specify a number n so you have at least n backups for each file. A retention policy that is based on a recovery form. You specify a time period in the past. Save all the backups you need, and you'll be able to finish whatever time-based recovery is between that form.

2.3.5.1, implementing Backup Retention Policy with RMAN
Rman makes the implementation of a backup retention policy self-active and can use such commands as the following:
(1) CONFIGURE RETENTION Policy command sets the retention policies applied to all data files. It as the default setting
(2) The report obsolete command lists the backups that have expired in the backup policy
(3) Delete obsolete command to remove expired files listed by report obsolete
(4) Change ... Keep sets a separate retention policy for the specified backup, such as saving long-term backups for the target of the archive.

Ability to specify that a backup must be saved to a future time. Even the specified backup is permanently saved. Change ... Nokeep to apply a change to the backup retention policy ... Keep the previous operation.
Assuming that backups are saved using a high-speed recovery area, the database will have to take the initiative to delete outdated backups, archive logs, and other files as new backups are needed.

2.3.6, archiving older Backups
Save the backup of the old data file and archive log for the following reasons:
(1) Old backup completed point-in-time recovery before the latest backup is required
(2) Assume that a recent backup is damaged. You can use the old backup to recover the database
(3) For archival purposes, you may want to save a copy of the database
In order to complete a point-in-time recovery to a target time, it is slightly earlier than the time of the recent backup, so the old backup and the old backup are at the point in time to the full archive log at the target point in time.

2.3.7, determining Backup Frequency
Backups that are frequent for whatever recovery plan are the most important. The frequency of backups is based on the frequency or speed of database changes, for example:
(1) Table additions and deletions
(2) Addition and deletion of rows
(3) Update data
The more frequently the database is updated, the more frequently the database backups are completed. Backup Scripts when Blocks change frequently the scene in page A-5 every one weeks back up the database fully prepared.
Assuming that the database is being updated relatively infrequently, the database is fully prepared to be relatively infrequent, supplemented with incremental backups. Backup Scripts when Few Data Blocks changed "on page A-8 The scene description describes how to design a development strategy based on a fully prepared.

2.3.8, performing Backups before and after your make Structural changes
Sometimes, you need to take a backup of the database outside of a regular backup schedule.

Assume that a backup of the appropriate part of the database is completed before the following structural changes are generated:
(1) Create or delete a table space
(2) Add or rename a data file
(3) Add, rename or delete a redo log group or member
Assume that in a non-archive mode, the database must be closed and the consistency is complete; if it is an archive mode, you must back up a control file. Use the Rman Backup Controlfile command or the ALTER DATABASE backup Controlfile command.

2.3.9, scheduling Backups for frequently-updated tablespaces
Executes in archive mode. The ability to back up a single table space or a single data file. A very small number of database updates are limited to a fraction of the table space.

Assuming that every Sunday is fully prepared, the frequently updated tablespace will have to apply a large amount of redo when media failure occurs in Friday. Daily backups of the table spaces that are often updated reduce the application of redo logs.

2.3.10, backing up after nologging Operations
When the direct path load operation is complete, no redo logs are logged for these database changes. Using media recovery does not restore these changes.

Similarly, tables and indexes created with Nologging do not record their changes.

After you run an operation that does not redo the log record. You should back up your data files.

You can use both full-provisioning and incremental backups. Whichever will catch all the changed blocks.
Oracle Database SQL provides options for non-recoverable, such as Create TABLE ... As SELECT statement

2.3.11, exporting Data for Added Protection and flexibility
The ORACL database Import and Export tool can be used to export database objects (tables, stored procedures), and then import objects again.

An export provides a snapshot of the logical level of the exported object. It is a binary file that can then be imported into the source database or other database. Exporting is not an all-in-all alternative, but it's practical. Export does not provide a consistent recovery advantage for physical level backups. Example. You cannot apply an archive to a logical backup. Oracle Database Utilities provides export and import for logical backups.

2.3.12, preventing the Backup of Online Redo Logs
Redo logs should never be backed up. The most important necessity associated with the backup redo log is to accidentally restore a meaningless backup. Corrupt the database.
Backups of redo logs are not particularly useful for the following reasons:
(1) Database execution in the archive mode, the archive process has its own initiative to archive all redo logs, not necessarily
(2) database execution in non-archive mode. The only physical backup type is off, consistent, fully prepared, redo logs do not play any role
The best way to protect the redo logs from media failure is to multiplex replication, replicating all log members of each group on different disks on different disk controllers
Note: Rman does not agree to the backup redo log. Before you do a regular backup, you must use a command to archive a redo log that is not archived

2.3.13, keeping Records of the Hardware and software Configuration of the Server
In a recovery scenario, it is important that you have all the information in the process of disposition.

When you meet a problem you don't understand. You need to contact Oracle support. You need to have the following documentation about your hardware configuration:
(1) Version number and patch of the operating system
(2) Number of disk and disk controllers
(3) Name of all data files
(4) Name and version number of the media management software (assuming the use of third-party media management)
You need to have the following documentation about the software configuration:
(1) Name of the DB instance
(2) Database identifiers
(3) version number and patch of database
(4) version number and patch of network software
(5) Database backup strategy (Rman or user-managed) and frequency
(6) Strategies for restore and recovery
You should also keep the information in electronic and photocopy versions. For example, you save the above information to a text or an email. When the entire system is down. You are not able to access this data. It is important to save dbid.

Suppose you have to restore and recover a database that includes SPFile and Controlfile lost. During the recovery process. You will need to dbid. Basic Database Restore and Recovery Scenarios on page 6-3 provide information about how to use dbid during recovery.

2.4. Validating Your Data Recovery Strategy
Contact backup and recovery technology in a test environment before migrating to a production system. This way, we can estimate the totality of the strategy and minimize the problem. The test recovery is guaranteed to be archived regularly. The process of backup and recovery is valid.

Assume that Rman is used. Execute the duplicate command to create a test database using a backup of the production database. Assuming you're finished user-managed backup and recovery, you can also create a new database, a standby database or a copy of an existing database to test your backups.
Oracle Database Backup and Recovery Advanced User's Guide provides information about the Rman test method, troubleshooting Sql*plus recovery. Block media recovery and rman disaster recovery

2.4.1, Using BACKUP ... VALIDATE
Use Rman using BACKUP ... The validate command calls Rman to read all the specified database files entered for a specific backup task, without actually generating any backup as output. For example, backup DATABASE validate calls Rman to read all the files needed to be backed up to ensure they are intact and undamaged. All data blocks in the input file are verified, exactly as if an actual backup occurred. This process provides a practical, complete check.

2.4.2, Validating RMAN backups:validate and RESTORE VALIDATE
The Validate and restore validate command for Rman should be part of the recovery design test. Validate calls Rman to read into a specific backup. Report whether they are correct and available.

RESTORE ... Validate calls Rman to check whether the available backups satisfy the restoration of a particular database object. For example, restore Tablespace tbs_1 VALIDATE

2.4.3, testing Your Database Restore and Recovery procedures
Test your backups by a consistent test of the restore and recovery strategy over different hardware.

Ideal ground, using one as close as possible to the testing of hardware and software configurations and production environments.

Copyright notice: This article blog original article. Blogs, without consent, may not be reproduced.

Backup and Recovery Strategies1