RE: Flashback database

One of the reasons flashback is not implemented here is our storage device is slow (#1) -- deduplicates, compresses etc. The deduped databases we find mission critical have a destination on the other side of the country, and the bandwidth is not available to send any more data (#2).

Oracle likes the flashback logs to be available during restore, (there is a way around it), so I'd want them around.

Generally I'd say that the flashback logs will be the same size as the archive logs, so that much more disk space.

Good luck,

Joel Patterson
Database Administrator
904 727-2546

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Hameed, Amir Sent: Tuesday, February 05, 2013 10:27 AM To: oracle-l
Subject: Flashback database

Folks,
I am in the process of researching whether to use the Oracle flashback database feature in 11.2.0.3 DB for re-instantiating the primary database in a DG setup as opposed to restoring it from the nightly backup and then rolling it forward. The system under consideration is a really busy mission critical Oracle ERP environment which generates an average of 300GB worth of archive log files on daily basis with occasional spikes of up to 400GB. There is obviously a temptation to get the DB up and running as fast as possible but I want to make sure that there are no performance related implications when using the flashback feature. Note "Flashback Database Best Practices & Performance [ID 565535.1]" has the following performance related guidelines/cautions:

After adopting the configuration and operational best practices below and recommended patches, Oracle has observed the following performance observations when enabling flashback database on the primary or standby database.

• Impact on OLTP performance on the primary is usually less than 5 percent.
• Impact of large insert (e.g. batch inserts) or direct load operations on the primary is usually less than 5 percent if flashback block new optimization is in effect; otherwise the impact can be up to 40%. Refer to block new optimization descriptions and exceptions under Oracle 11g feature list.
• Impact on redo apply on a physical standby database can be significant; however it is normally not noticeable because the observed redo apply rates is still 50 MB/sec for OLTP and 500 MB/sec for large insert or direct load operations after tuning recovery and fast recovery area. For the most part, the redo apply rates still outperform application's redo generation rates.

  ---

Has anyone either done any performance related testing of this feature or is using it in a busy database? Any feedback will be appreciated.

Thanks,
Amir

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l