Database Backup and Recovery BASICS2

1.6. Automatic disk-based Backup and recovery:the Flash Recovery area
Components that create different backup and recovery files have no knowledge of the size of each file system. With automatic disk-based backup and Recovery, you can create a flashback recovery area that automates the management of backup files. Select a location on disk, provide a larger boundary for storage space, and set up a backup strategy, then the database in that space manages the storage, archive logs, and other recovery-related files that are used for backup. Oracle recommends that you turn on a flashback recovery area to simplify your backup management

1.7. Oracle Flashback technology:alternatives to Point-in-time Recovery
Oracle Flashback Technology offers a range of features that provide practical choices, such as viewing the past state of the data, rolling back the data (you do not need to restore most databases from a backup or complete a point-in-time recovery). Oracle's flashback features are more efficient and less damaging in many situations than media recovery.
Many of Oracle's flashback features operate at the logical level to view and manipulate database objects, as follows:
(1) Oracle Flash back Query
It lets you specify a target time, and then runs forward to check the results. To recover from an unwanted change (such as a user error updating a table), a user can select a target time before the error, and then run the query to recover the contents of the missing or changed rows.
(2) Oracle Flash back version query
Just as updates are applied to a table, it lets you see all the versions of all the rows that appear in one or more tables for a specified period of time. You can also restore metadata about different versions of a row, including the start time, end time, operation, and transaction ID. This feature can be used to recover lost data values and to change the table audit to the query.
(3) Oracle Flash back transaction query
It lets you see the changes that have been made to a single transaction or multiple transactions over a period of time.
(4) Oracle Flash back table
Returns a table to the state of a previous point in time. During the database online, you can restore the table data.
(5) Oracle Flash-Back Drop
Reverses the effect of the drop TABLE statement.

Flashback Query,flashback version query,flashback transaction Query,flashback table relies on rollback data, and the rollback data is the data affected by any one update. Flashback drop is based on a mechanism called Recycle Bin that Oracle manages the deleted database objects with the Recycle Bin.

Note: The flashback attribute at the logical level is not dependent on Rman; it is available regardless of whether Rman is part of the backup strategy.

At the physical level, Oracle Flashback database provides a more efficient, straightforward alternative to point-in-time recovery. If your data file has only unwanted changes, then you can use flashback database to cause the current data file to transition to past content. The final product is much like the result of a point-in-time recovery, but is generally faster than media recovery because it does not need to restore the data files from the backup, requiring only a few log applications. The flashback database uses flashback logs and archived redo log to access past versions of the data block. Flashback database requires you to configure a flashback recovery area because flashback logs can only be stored there. Flashback logging is not turned on by default. The database automatically manages the space used for flashback logs,

Flashback database can be seen as an alternative to incomplete recovery, but it also has some limitations:
(1) Flashback Database cannot resolve media Failure, this error Rman recovery is still the only option.
(2) If you delete a data file or use shrink technology to reduce the size of the data file, you can not use Flashback database technology back to the state before the change, you must first use Rman to delete before or after the reduction of the file backup restore, Then use flashback Database to execute the remaining flashback datbase.
(3) If the control file is recovered from the backup, or is a rebuilt control file, you cannot use flashback Database.
(4) The earliest SCN that can be recovered by using flashback database depends on the earliest SCN recorded in flashback log.

About Restore Points:
The Oracle database also supports restore points that are backed up with the flashback database and restore and restore features. An ordinary restore point is an alias equivalent to the SCN. Point-in-time recovery, flashback table and Flashback database operations are simple because you don't have to explore and record targets
Scn. Create a guaranteed checkpoint (guaranteed restore point) to ensure that you can use the Flashback database to return your database to the restore point time
-"Using normal and guaranteed Restore Points" on page 5-6 for more information about the use of Normal and guaranteed rest Ore points
-chapter 7, "performing Flashback and Database point-in-time Recovery" For more information on the use of the Flashback Features of Oracle in a data recovery context
-oracle Database Concepts and Oracle database Administrator ' s Guide for more information on undo data and automatic undo M Anagement
-oracle Database application Developer ' s guide-fundamentals for more information on Flashback Query, Flashback transacti On query and Flashback Version Query

1.8. Matching failures to Backup and Recovery techniques
In planning your database backup and recovery strategy, you must try to participate in the origin of the error. Although there are many types of problems that can stop the operation of a database or affect database I/O operations, only two typically require DBA intervention and media recovery: Media failure and user error. Instance failures, network failures, failure of the Oracle database background process, and failure of an SQL statement to execute, or even a db instance, but they generally do not cause data loss or restore from backup.

1.8.1, responding to media failure--tell about media recovery

After the online redo log file or the media that controls the file fails, the database operation relies on whether to redo the log file or the control file through multi-copy protection. But the Redo log files or control files are duplicated, and copies of the multiple copy files are saved in the system. Multiple copies of files should be saved on different disks.

If a media failure destroys a disk that contains a copy of a multiplexed redo log file, the database often continues to run when there is no significant damage. A corrupted redo log file that does not have multiple copies causes the database to be stopped and can cause permanent loss of data.

destroys any control file, whether it is multi-copy or not, and immediately stops the database when the database attempts to read or write corrupted control files (often, such as every checkpoint and log switch). Media failure can be either a read error or a write error. In a read error, the instance cannot read a control file and an operating system error returned by the application, such as an error indicating that the file cannot be found, cannot be opened, and is unreadable. The database continues to run until a read or write error is returned. The impact of a data file write error depends on which table space the data file is in. If an instance cannot write to a data file in the system tablespace/rollback tablespace/A table space containing the active rollback segment, the database displays an error while shutting down the instance. All data files for the system tablespace and all data files that contain rollback segments must be online, in order for the database to run properly. If the reason the instance cannot write to the data file differs from the previous listing, the result depends on whether the database is running in Archivelog mode. In Archivelog mode, the database logs the error to the trace file and then the affected data file offline (the other data files in this tablespace are still online). You can then correct the potential problems and restore and restore the table space that is affected. In non-archivelog mode, the database dbwn process fails, and the instance fails, and the cause of the problem determines the desired response. If the problem is temporary (the disk controller is out of power), then use the Redo log file to complete the crash recovery. In this case, the media recovery instance does not need to be able to start. However, if the data file is corrupted, you must restore a consistent backup of the entire database.

1.8.2, responding to User Error
Typically, a user error such as a drop table or delete row requires the following response:
(1) If an available export file exists or the object exists in the standby database, re-import the deleted object
(2) Complete the TSPITR (tablespace point-in-time recovery) of one or more table spaces
(3) If the table record is present, re-insert the missing data
(4) Use database Point-in-time recovery to return the databases to their past state
(5) Using the Flashback feature to restore the object to a past state
The available recovery options are a process for the backup strategy. For example, if the database is running in Noarchivelog mode then you have fewer point-in-time recovery options.

See Also:
-oracle Database Backup and Recovery Advanced User's Guide to learn-perform point-in-time Recovery for an entire DA Tabase
-oracle Database Backup and Recovery Advanced User's Guide to learn what to perform tablespace point-in-time Recovery
-oracle Database Backup and Recovery Advanced User's Guide to learn-use the flashback features of the Oracle Databa Se

1.9. System Requirements for Backup and Recovery Methods
When you select a backup and recovery scenario, you want to see if it is appropriate for your database environment. For example, database 8.0 or higher, you can use Rman to manage backup and recovery. Under 8.0, you must use a scenario other than Rman.

1.10. Feature Comparison of Backup Methods