Which three statements are true about Flashback Database?

Which three statements are true about Flashback Database?

Which three statements are true about Flashback Database?

A.
Flashback logs are written sequentially, and are archived.

B.
Flashback Database uses a restored control file to recover a database.

C.
The Oracle database automatically creates, deletes, and resides flashback logs in the Fast
Recovery Area.

D.
Flashback Database can recover a database to the state that it was in before a reset logs
operation.

E.
Flashback Database can recover a data file that was dropped during the span of time of the
flashback.

F.
Flashback logs are used to restore to the blocks’ before images, and then the redo data may be
used to roll forward to the desired flashback time.

Explanation:
* Flashback Database uses its own logging mechanism, creating flashback logs and
storing them in the fast recovery area (C). You can only use Flashback Database if flashback logs
are available. To take advantage of this feature, you must set up your database in advance to
create flashback logs.
* To enable Flashback Database, you configure a fast recovery area and set a flashback retention
target. This retention target specifies how far back you can rewind a database with Flashback
Database.
From that time onwards, at regular intervals, the database copies images of each altered block in
every data file into the flashback logs. These block images can later be reused to reconstruct the
data file contents for any moment at which logs were captured. (F)
Incorrect:
Not E: You cannot use Flashback Database alone to retrieve a dropped data file. If you flash back
a database to a time when a dropped data file existed in the database, only the data file entry is
added to the control file. You can only recover the dropped data file by using RMAN to fully restore
and recover the data file.
Oracle Database Backup and Recovery User’s Guide 12c R



Leave a Reply 4

Your email address will not be published. Required fields are marked *


Piotr

Piotr

F) ->
http://docs.oracle.com/database/121/BRADV/flashdb.htm#BRADV582

From that time onwards, at regular intervals, the database copies images of each altered block in every data file into the flashback logs. These block images can later be reused to reconstruct the data file contents for any moment at which logs were captured.

When you use Flashback Database to rewind a database to a past target time, the command determines which blocks changed after the target time and restores them from the flashback logs. The database restores the version of each block that is immediately before the target time. The database then uses redo logs to reapply changes that were made after these blocks were written to the flashback logs.

Redo logs on disk or tape must be available for the entire time period spanned by the flashback logs. For example, if the flashback retention target is 1 week, then you must ensure that online and archived redo logs that contain all changes for the past week are accessible. In practice, redo logs are typically needed much longer than the flashback retention target to support point-in-time recovery.

D) ->
You can use Flashback Database to reverse most unwanted changes to a database if the data files are intact. You can return a database to its state in a previous incarnation, and undo the effects of an ALTER DATABASE OPEN RESETLOGS statement

C) ->
Flashback Database uses its own logging mechanism, creating flashback logs and storing them in the fast recovery area. You can only use Flashback Database if flashback logs are available. To take advantage of this feature, you must set up your database in advance to create flashback logs.

kurdishdba

kurdishdba

CDF

Flashback Database

Flashback Database is similar to conventional point-in-time recovery in its effects. It enables you to return a database to its state at a time in the recent past. Flashback Database is much faster than point-in-time recovery because it does not require restoring data files from backup and requires applying fewer changes from the archived redo logs.

You can use Flashback Database to reverse most unwanted changes to a database if the data files are intact. You can return a database to its state in a previous incarnation, and undo the effects of an ALTER DATABASE OPEN RESETLOGS statement. “Rewinding a Database with Flashback Database” explains how to use the FLASHBACK DATABASE command to reverse database changes.

Flashback Database uses its own logging mechanism, creating flashback logs and storing them in the fast recovery area. You can only use Flashback Database if flashback logs are available. To take advantage of this feature, you must set up your database in advance to create flashback logs.

To enable Flashback Database, you configure a fast recovery area and set a flashback retention target. This retention target specifies how far back you can rewind a database with Flashback Database.

From that time onwards, at regular intervals, the database copies images of each altered block in every data file into the flashback logs. These block images can later be reused to reconstruct the data file contents for any moment at which logs were captured.

When you use Flashback Database to rewind a database to a past target time, the command determines which blocks changed after the target time and restores them from the flashback logs. The database restores the version of each block that is immediately before the target time. The database then uses redo logs to reapply changes that were made after these blocks were written to the flashback logs.

Redo logs on disk or tape must be available for the entire time period spanned by the flashback logs. For example, if the flashback retention target is 1 week, then you must ensure that online and archived redo logs that contain all changes for the past week are accessible. In practice, redo logs are typically needed much longer than the flashback retention target to support point-in-time recovery.