Experience: is what you get soon after you need it.

Experience: is what you get soon after you need it.

Rasul Allah (sal Allahu alaihi wa sallam) said: "Restore the trusts of those who trust you, and deal not falsely with him who deals falsely with you." [Abu Dawud, Tirmidhi]

Search This Blog

Thursday, April 8, 2010

FLASH BACK DATABASE-CONS

Limitations of Flashback Database Because Flashback Database works by undoing
changes to the datafiles that exist at the moment that you run the command, it has the
following limitations:
■ Flashback Database can only undo changes to a datafile made by an Oracle
database. It cannot be used to repair media failures, or to recover from accidental
deletion of datafiles.
■ You cannot use Flashback Database to undo a shrink datafile operation. However,
you can take the shrink file offline, flashback the rest of the database, and then
later restore and recover the shrink datafile
■ You can not use Flashback Database alone to get back a dropped datafile. If you
flashback a database to a time when a dropped datafile existed in the database,
Oracle will only add the datafile entry in the controlfile. You can recover the
dropped datafile by further restoring and recovering the datafile.
■ If the database control file is restored from backup or re-created, all accumulated
flashback log information is discarded. You cannot use FLASHBACK DATABASE
to return to a point in time before the restore or re-creation of a control file
■ When using Flashback Database with a target time at which a NOLOGGING
operation was in progress, block corruption is likely in the database objects and
datafiles affected by the NOLOGGING operation. For example, if you perform a
direct-path INSERT operation in NOLOGGING mode, and that operation runs from
9:00 to 9:15 on April 3, 2005, and you later need to use Flashback Database to
return to the target time 09:07 on that date, the objects and datafiles updated by
the direct-path INSERT may be left with block corruption after the Flashback
Database operation completes.
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.


if "flashback buf free by RVWR" is the top wait event, then you know
that Oracle Database cannot write flashback logs very quickly. In such a case, you may want to tune the file system and storage used by the fast recovery area


The V$FLASHBACK_DATABASE_STAT view shows the bytes of flashback data logged
by the database. Each row in the view shows the statistics accumulated (typically over
the course of an hour). The FLASHBACK_DATA and REDO_DATA columns describe
bytes of flashback data and redo data written respectively during the time interval,
while the DB_DATA column describe bytes of data blocks read and written. The
columns FLASHBACK_DATA and REDO_DATA correspond to sequential writes, while
DB_DATA corresponds to random reads and writes.
Because of the difference between sequential I/O and random I/O, a better indication
of I/O overhead is the number of I/O operations issued for flashback logs

V$SYSSTAT Statistics
Column Name Column Meaning
Physical write I/O request The number of write operations issued for writing data blocks
physical read I/O request The number of read operations issued for reading data blocks
redo writes The number of write operations issued for writing to the redo
flashback log writes The number of write operations issued for writing to flashback
logs.
log.

No comments: