Performance
observations
As you
have to write to the flashback logs when the database is in flashback mode, you
usually have around 5% performance impact especially for OLTP transactions. The
impact for large inserts (e.g. batch inserts) or direct loads operations goes
from 5% to 40%, this is especially true for 10g, in 11g Oracle introduced
“block-new optimization” which significantly relieves that situation.
Best Practices
1. - Set the DB_FLASHBACK_RETENTION_TARGET to a value equal
to the farthest time in the past that you wish to be able to recover to.
2.- size the flashback recovery area (FRA), ensure that there
is sufficient space allocated to accommodate the flashback database, the
flashback logs for the target retention
size and for peak batch rates. A general rule of thumb is that flashback logs
get generated approximately at the same rate as redo log.
3. - Configure sufficient I/O bandwidth for FRA, failure to
do that will result in high “FLASBACK BUF FREE BY RVWR” wait event and
“FLASBACK LOG WRITE” latency of more than 30ms. The easiest way to accomplish
this is by placing the flashback logs in the outer portion of the disks or
LUNS.
4. - Set the LOG_BUFFER to at least 8MB in order to give the
flashback database more buffer space in memory. For large databases consider a
range between 32-64 MB.
5. – Set _DB_FLASBACK_LOG_MIN =
(11.2.0.3 and above only).
6. - Monitor closely your “Recovery area free space (%).
7. - In Oracle 11.2 onward, you can enable flashback database
while the database is open.
8. - It is highly recommended that you use Guarantee Restore
Point (GRP) before your deployment.
9. - Enable database flashback when needed and disable it
after you are sure the deployment was successful. Please note that every single
time you enable or disable flashback database a reset log operation occurs
therefor you have a different incarnation of the database, once you get the
database out of flashback mode there is no way to move back or forth in time.
Posts
No comments:
Post a Comment