Flashback database
From: Hameed, Amir <Amir.Hameed_at_xerox.com>
Date: Tue, 5 Feb 2013 15:27:21 +0000
Message-ID: <AF02C941134B1A4AB5F61A726D08DCED083E07_at_USA7109MB012.na.xerox.net>
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:
Performance Observations
Date: Tue, 5 Feb 2013 15:27:21 +0000
Message-ID: <AF02C941134B1A4AB5F61A726D08DCED083E07_at_USA7109MB012.na.xerox.net>
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:
Performance Observations
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-lReceived on Tue Feb 05 2013 - 16:27:21 CET