Databases Reference
In-Depth Information
After you enable Flashback Database, you can view the flashback logs in your FRA with this query:
select name, log#, thread#, sequence#, bytes
from v$flashback_database_logfile;
The range of time in which you can flash back is determined by the
DB_FLASHBACK_RETENTION_TARGET
parameter.
This specifies the upper limit, in minutes, of how far your database can be flashed back.
You can view the oldest SCN and time you can flash back your database to by running the following SQL:
select
oldest_flashback_scn
,to_char(oldest_flashback_time,'dd-mon-yy hh24:mi:ss')
from v$flashback_database_log;
If, for any reason, you need to disable Flashback Database, you can turn it off, as follows:
SQL> alter database flashback off;
You can use either RMAN or SQL*Plus to flash back a database. You can specify a point in time in the past, using
one of the following:
•
SCN
•
Timestamp
•
Restore point
RESETLOGS
operation (works from RMAN only)
•
Last
This example creates a restore point:
SQL> create restore point flash_1;
Next, the application performs some testing, after which the database is flashed back to the restore point so that a
new round of testing can begin:
SQL> shutdown immediate;
SQL> startup mount;
SQL> flashback database to restore point flash_1;
SQL> alter database open resetlogs;
At this point, your database should be transactionally consistent with how it was at the SCN associated with the
restore point.
Restoring and Recovering to Different Server
When you think about architecting your backup strategy, as part of the process, you must also consider how you're
going to restore and recover. Your backups are only as good as the last time you tested a restore and recovery. A backup
strategy can be rendered worthless without a good restore-and-recovery strategy. The last thing you want to happen
is to have a media failure, go to restore your database, and then find out you're missing critical pieces, you don't have
enough space to restore, something is corrupt, and so on.
