Notes of Backup and Recovery Basics (Oracle Online Documents)

Just some casual notes

[Begin]

At the physical level, Oracle Flashback Database provides a more efficient direct alternative to database point-in-time recovery.

 

You need Flashback logs or Guaranteed restore points to support Flashback database.

 

Flashback logs need flash recovery area.

 

Most of the flashback features of Oracle operate at the logical level (except flashback database), viewing and manipulating database objects, as follows:

 

■ Oracle Flashback Query lets you specify a target time and then run queries against your database, viewing results as they would have appeared at that time. To recover from an unwanted change like an erroneous update to a table, a user could choose a target time before the error and run a query to retrieve the contents of lost or changed rows.

 

■ Oracle Flashback Version Query lets you view all the versions of all the rows that ever existed in one or more tables in a specified time interval, as updates were applied to the tables. You can also retrieve metadata about the differing versions of the rows, including start time, end time, operation, and transaction ID of the transaction that created the version. This feature can be used both to recover lost data values and to audit changes to the tables queried.

 

■ Oracle Flashback Transaction Query   lets you view changes made by a single transaction, or by all the transactions during a period of time.

 

■ Oracle Flashback Table returns a table to its state at a previous point in time. You can restore table data while the database is online, undoing changes only to the specified table.

 

前面四种basing on undo data.

 

■     Oracle Flashback Drop reverses the effects of a DROP TABLE statement. Flashback Drop is basing on Recycle Bin.

 

The recycle bin is a logical container for all dropped tables and their dependent objects.

 

Initialization Parameter: RECYCLEBIN. RECYCLEBIN is used to control whether the Flashback Drop capability is turned on or off. If the parameter is set to OFF, then dropped tables do not go into the recycle bin. If this parameter is set to ON, dropped tables go into the recycle bin and can be recovered.

Data dictionary tables: DBA_RECYCLEBIN and USER_RECYCLEBIN which has a synonym RECYCLEBIN, for ease of use.

 

 

Oracle Flashback Technology: Alternatives to Point-in-Time Recovery  需要深入继续学习！！！Need more research!!!

 

第二章的例子要好好看一下！！！

 

The only difference between a level 0 incremental backup and a full backup is that a full backup is never included in an incremental strategy.

 

RMAN's change tracking feature for incremental backups improves incremental backup performance by recording changed blocks in each datafile in a change tracking file.

 

One change tracking file is created for the whole database. By default, the change tracking file is created as an Oracle managed file in DB_CREATE_FILE_DEST. You can also specify the name of the block change tracking file, placing it in any location you choose.

If the backup validation discovers corrupt blocks, then RMAN updates the V$DATABASE_BLOCK_CORRUPTION view with rows describing the corruptions. You can repair corruptions using block media recovery, documented in Oracle Database Backup and Recovery Advanced User's Guide.

 

Proxy copies?

 

You can also use the BACKUP command to generate a proxy copy, which is a backup to a third-party medium in which the entire data transfer is conducted by a media manager. (From Backup and Recovery Reference)

 

This section contains the following topics:

■ About Flashback Database

■ About Normal Restore Points

■ About Guaranteed Restore Points

■ About Logging for Flashback Database and Guaranteed Restore Points

 

Flashback Database can be used to reverse most unwanted changes to a database, as long as the datafiles are intact. This includes returning a database to its state in previous incarnations that is, undoing the effects of an OPEN RESETLOGS operation.

 

Flashback Database uses its own logging mechanism, creating flashback logs which are stored in the flash recovery area.

 

From that time on, at regular intervals, the database copies images of each altered block in every datafile into the flashback logs.

 

If FLASHBACK DATABASE fails because the flashback database window is not long enough, database point-in-time recovery (DBPITR) can be used in most cases to achieve a similar result.

 

Note: Limitations that apply to Flashback Database also apply to guaranteed restore points. For example, shrinking a datafile or dropping a tablespace can prevent flashing back the affected datafiles to the guaranteed restore point.

 

The chief differences between normal flashback logging and logging for guaranteed restore points are related to when blocks are logged and whether the logs can be deleted in response to space pressure in the flash recovery area.

 

If your primary need is to be able to return your database to the specific point in time at which the guaranteed restore point was created, then it is generally more efficient to turn off logging for Flashback Database and use only guaranteed restore points. For example, in a scenario in which you are performing an application upgrade on a production database server over a weekend, you could create a guaranteed restore point at the start of the upgrade process and, if the process failed at the end, reverse the changes using FLASHBACK DATABASE instead of restoring the database from backups.

 

Limitations of Flashback Database

If possible, avoid using Flashback Database with a target time or SCN that coincides with a NOLOGGING operation. Also, perform. a full or incremental backup of the affected datafiles immediately after any NOLOGGING operation to ensure recoverability to points in time after the operation. If you expect to use Flashback Database to return to a point in time during an operation such as a direct-path INSERT, consider performing the operation in LOGGING mode.

 

Flashback database needs Archivelog mode and flash recovery area.

 

V$FLASHBACK_DATABASE_LOG and V$FLASHBACK_DATABASE_STAT – two dynamic views related to Flashback database.

 

When flashback is enabled or when there are guaranteed restore points, the background process RVWR writes flashback data to flashback database logs in the flash recovery area.

 

 

Case study 3 main parts:

■     Chapter 6 -- Performing Complete Restore and Recovery of Databases (全库、单个文件或者表空间、spfile、controlfile、archivelog等，其实案例1-4已经涵盖此类情况)

■     Chapter 7, "Performing Flashback and Database Point-in-Time Recovery" for details on database point-in-time recovery (DBPITR) and Flashback Database

■     Oracle Database Backup and Recovery Advanced User's Guide for details on tablespace point-in-time recovery (TSPITR)

以上三点结合chapter 2中的例子描述，做case study练习。

 

Database Restore and Recovery Procedure: Outline

The basic procedure for performing restore and recovery with RMAN is as follows:

1. Determine which database files must be restored from backup, and which backups (which specific tapes, or specific backup sets or image copies on disk) to use for the restore operation. The files to be restored may include the control file, SPFILE, archived redo log files, and datafiles.

 

2. Place the database in the state appropriate for the type of recovery that you are performing. For example, if you are recovering a single tablespace or datafile, then you can keep the database open and take the tablespace or datafile offline. If you are restoring all datafiles, then you must shut down the database and then mount it before you can perform. the restore.

 

3. Restore lost database files from backup with the RESTORE command. You may restore files to their original locations, or you may have to restore them to other locations if, for instace, a disk has failed. You may also have to update the SPFILE if you have changed the control file locations, or the control file if you have changed the locations of datafiles or redo logs.

 

4. Perform. media recovery on restored datafiles, if any, with the RECOVER command.

 

5. Perform. any final steps required to make the database available for users again. For example, re-open the database if necessary, as happens when restoring lost control files, or bring offline tablespaces online if restoring and recovering individual tablespaces.

 

This outline is intended to encompass a wide range of different scenarios. Depending upon your situation, some of the steps described may not apply. (For example, you do not need to perform. media recovery if the only file restored from backup is the SPFILE.) You will have to devise your final recovery plan based on your situation.

 

Determining Which Database Files to Restore or Recover

Recognizing a Lost Control File

It is generally obvious when the control file of your database must be restored. The database shuts down immediately if any of the control file copies becomes inaccessible and reports an error if you try to start it without a valid control file at each location specified in the CONTROL_FILES initialization parameter.

 

Identifying Datafiles Requiring Media Recovery

Query V$DATAFILE_HEADER and V$RECOVER_FILE.

 

 

Limitations When Using a Backup Control File

After you restore your database using a backup control file, you must run RECOVER DATABASE and perform. an OPEN RESETLOGS on the database.

For more details on restrictions on using RESTORE CONTROLFILE in different scenarios (such as when using a recovery catalog, or restoring from a specific backup), see the discussion of RESTORE CONTROLFILE in Oracle Database Backup and Recovery Reference.

 

Restoring Datafiles from Backup to a New Location

RUN

{

SQL 'ALTER TABLESPACE users OFFLINE IMMEDIATE';

SQL 'ALTER TABLESPACE tools OFFLINE IMMEDIATE';

# specify the new location for each datafile

SET NEWNAME FOR DATAFILE '/olddisk/users01.dbf' TO

'/newdisk/users01.dbf';

SET NEWNAME FOR DATAFILE '/olddisk/tools01.dbf' TO

'/newdisk/tools01.dbf';

# to restore to an ASM disk group named dgroup, use:

# SET NEWNAME FOR DATAFILE '/olddisk/trgt/tools01.dbf'

# TO '+dgroup';

RESTORE TABLESPACE users, tools;

SWITCH DATAFILE ALL; # update control file with new filenames

RECOVER TABLESPACE users, tools;

}

 

============================================================================

 

Point-in-Time Recovery -- Restore from backup à Apply incremental backup and archive logs to the point in time (Recover until ***)à done.

 

Flashback – Copy old images from flashback logs à maybe need apply a little bit redo logs à then done! Faster and higher availability. (Don’t need to restore.) On table level, much simpler!!

 

The recycle bin is a logical container for all dropped tables and their dependent objects.

 

There is no fixed amount of space pre-allocated for the recycle bin. Therefore, there is no guaranteed minimum amount of time during which a dropped object will remain in the recycle bin.

 

[The End]

 

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9765498/viewspace-257098/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/9765498/viewspace-257098/