Backup and Recovery Strategies.docx

1、Backup and Recovery StrategiesBackup and Recovery StrategiesThis chapter offers guidelines and considerations for developing an effective backup and recovery strategy.This section includes the following topics: Data Recovery Strategy Determines Backup Strategy Planning Data Recovery Strategy Plannin

2、g Backup Strategy Validating Your Data Recovery StrategyData Recovery Strategy Determines Backup StrategyTo decide on backup strategies, start with your data recovery requirements and your data recovery strategy. Each type of data recovery will require that you take certain types of backup.Failures

3、can run the gamut from user error, datafile block corruption and media failure to situations like the complete loss of a data center. How quickly you can resume normal operation of your database is a function of what kinds of restore and recovery techniques you include in your planning. Each restore

4、 and recovery technique will impose requirements on your backup strategy, including which features of the Oracle database you use to take, store and manage your backups.When thinking about recovery strategies, ask yourself questions like these: If a disk failed and destroyed some of the database fil

5、es, such as datafiles or redo logs, how would you recover the lost files? As described in Planning a Response to Media Failure: Restore and Media Recovery, you should be able to handle the loss of datafiles, control files, and online redo logs. If a logic error in an application or a user error caus

6、ed the loss of important data from one or several tables or tablespaces, how could you recover that data, and what would happen to database updates since the error? Could you determine the cause of the error, to prevent it from happening again? As described in Planning a Response to User Error: Poin

7、t-in-Time Recovery and Flashback Features, techniques available to you include point-in-time recovery of the whole database or one or more tablespaces, importing data from earlier logical exports with one of the data import utilities, and using the Oracle databases flashback features. If the instanc

8、e alert log indicates that one or more tables contains corrupt blocks, how can you repair the corruption? Does the tablespace have to remain available during the repair? As described in Planning a Response to Datafile Block Corruption: Block Media Recovery, the RMAN BLOCKRECOVER command can help you

9、 in this situation. Also, troubleshoot recovery with the SQL*Plus RECOVER . TEST command. If the entire data center is destroyed, can you perform disaster recovery? Assume that all you have is an archive tape containing backups. How would you recover the database? How long would that recovery take?

10、If you were not available to recover your database, could someone else recover it in your absence? Are your recovery procedures sufficiently automated and documented?With these needs in mind, decide how you can take advantage of features related to backup and recovery, and look at how each feature m

11、eets some requirement of your backup strategy. For example: Using Recovery Manager simplifies most backup and recovery operations compared to user-managed backup and recovery. It automates management of most backup files, including the deletion of backups and archived redo logs from disk or tape whe

12、n no longer needed to meet recovery goals. It provides detailed reporting on backup activities, can verify that your available backups can be used to recover your database. Finally, RMAN makes possible many recovery techniques not available if you are using user-managed backup and recovery, such as

13、incremental backups. Flashback Database will help you restore a database to a previous time much faster than media recovery. However, you must decide in advance to keep flashback logs, and keeping flashback logs requires that you configure a flash recovery area. Block media recovery may be better th

14、an datafile media recovery if availability is critical. While block media recovery is possible even if you do not base your backup and recovery strategy on RMAN, RMAN-based block media recovery can be performed more quickly and with less effort.Once you decide which features to use in your recovery

15、strategy, you can plan your backup strategy, answering the following questions, among others: How and where will you store your recovery-related files? Will you use a flash recovery area? Will you use an ASM disk group? Will you store backups on tape or other offline storage, or only on disk? At wha

16、t intervals will you take scheduled backups? And what form of physical backups will you take in each situation? What situations require you to take a database backup outside of the regular schedule? Sometimes you must take an unscheduled backup to ensure that you can recover your data, such as after

17、 an OPEN RESETLOGS or after changes to your database such as NOLOGGING operations that do not appear in the redo log. You may also have business requirements that require backups for auditing purposes or other reasons not related to database recovery. How can you validate your backups, to ensure tha

18、t you can recover your database when necessary? How do you manage records of your backups? Do you have detailed recovery plans that cover each type of failure? How do your DBAs can execute these plans in a crisis? Can scripts be written to automate execution of these plans in a crisis? Can you apply

19、 Oracle database availability technologies, such as Data Guard or Real Application Clusters, to improve availability during a database failure? How does using these availability technologies affect your backup and recovery strategy?These are of course only a few of the considerations you should take

20、 into account. Available resources (hardware, media, staff, budget, and so on) will also be factors in your decision.Planning Data Recovery StrategyYour data recovery strategy should include responses to any number of database failure scenarios. The key to an effective, efficient strategy is envisio

21、ning failure modes, matching Oracle database recovery techniques and tools to the failure modes in which they are useful, and then making sure you incorporate the necessary backup types to support those recovery techniques.To help match failure modes to recovery techniques that can help resolve them

22、, refer to the following sections: Planning a Response to User Error: Point-in-Time Recovery and Flashback Features Planning a Response to Media Failure: Restore and Media Recovery Planning a Response to Datafile Block Corruption: Block Media RecoveryPlanning a Response to User Error: Point-in-Time

23、Recovery and Flashback FeaturesYour backup and recovery strategy should enable you to handle situations in which a user or application makes unwanted changes to database data, such as deleting the contents of a table or making incorrect updates during a batch run. The goal in such a case will be to

24、restore the affected parts of your database to their state before the user error.Depending on the situation, your appropriate response will be one of the following: If you have performed a logical backup by exporting the contents of the affected tables, sometimes you can import the data back into th

25、e table. This technique presumes that you are regularly exporting logical backups of your data, and that any changes between exports are unimportant. You can perform point-in-time recovery, bringing one tablespace or the whole database back to its state before the time of the error. In either case,

26、you need backups from before the time of the error, plus the redo logs from the time of the backup to the time of the error. Note: Oracles Flashback Technology provides faster and less disruptive alternatives to media recovery in many circumstances. Oracle Flashback Database is a physical-level reco

27、very mechanism similar to media recovery, but generally faster and not requiring the restore of data from backup. Oracle Flashback Table and Oracle Flashback Drop work at the logical level, undoing unwanted changes to tables, including reversing the effects of DROP TABLE statements. Oracle Flashback

28、 Query and Oracle Flashback Version Query are useful in viewing past contents of tables and investigating how and when logical corruptions affected your database.Information about these features is collected in Oracle Database Backup and Recovery Advanced Users Guide. This document will allude to su

29、ch features where they can be helpful and provide pointers for more information. Familiarize yourself with these features before planning your backup and recovery strategy, because you may find that they can be quite valuable and require limited advanced planning.Planning a Response to Media Failure

30、: Restore and Media RecoveryA media failure occurs when a problem external to the database prevents Oracle from reading from or writing to a file during database operations. Typical media failures include physical failures, such as head crashes, and the overwriting, deletion or corruption of a datab

31、ase file. Media failures are less common than user or application errors, but your backup and recovery strategy should prepare for them.The type of media failure determines the recovery technique to use. For example, the strategy you use to recover from a corrupted datafile is different from the str

32、ategy for recovering from the loss of the control file.Example: Online Redo Log RecoveryThe method of recovery from loss of all members of an online log group depends on a number of factors, such as: The state of the database (open, crashed, closed consistently, and so on) Whether the lost redo log group was current Whether the lost redo log group was archivedFor example: If you lose the current group, and the database is not closed consistently (either it is open, or it has crashed), then you will have to restore an