Major release with two logical stbys and two physical stbys

Question

I have a 300G 11g database in production with two physical standby and 2 logical standby databases. We are planning for a major release which include heavy data load and ddls. What would be the best way to salvage my standbys while running the release scripts.
I am afraid that we have 70/30 chance of successfully releasing the release, which means that I have 30% possibility to "restart" the release process from the point 0. Someone in my shop suggested using flashback, but I don't know if my server have that much of space to assign to the flashback recovery area. The upgrade/release takes approximately two days to run.
I was thinking of stopping the log transfer to all the standby database locations while running the load and once I am done, then transfer all the logs and re-enable the standby to "catch up", but would it work for logical standby, too?
I could not just disable all the standbys and re-create them once the release is completed because two of the standby databases are located at off-site with the limited network speed, and re-creating standby through network takes too long for us to do so.
Any thoughts would be appreciated.
Thanks,

Answer 1

I have a 300G 11g database in production with two physical standby and 2 logical standby databases. We are planning for a major release which include heavy data load and ddls. What would be the best way to salvage my standbys while running the release scripts. What would be the approximate size of data size it is going to load?
If its very huge then see the disadvantages:
1) Log of redo
2) in equal size of Archive logs
3) FRA/arch space issues at OS Level
4) Network traffic to 4 sites(2 physical + 2 logical)
5) Lot of archives on Standby databases too
6) How fast standby can fetch & apply?
I am afraid that we have 70/30 chance of successfully releasing the release, which means that I have 30% possibility to "restart" the release process from the point 0. Someone in my shop suggested using flashback, but I don't know if my server have that much of space to assign to the flashback recovery area. The upgrade/release takes approximately two days to run.Its production, When you flashback database it will open database in resetlogs then your complete DR setup is in trouble.
is it flashback or restorepoint with flashback?
Restore Points in Oracle10g Release2 [ID 330535.1] --> applicable for 11g too.
I was thinking of stopping the log transfer to all the standby database locations while running the load and once I am done, then transfer all the logs and re-enable the standby to "catch up", but would it work for logical standby, too?That is the good plan. Mseberg already given Documents which you can refer for logical standby.
BTW what is your protection mode?
You can refer below links for physical standby
http://docs.oracle.com/cd/B28359_01/server.111/b28294/rman.htm#CIHIAADC
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_53.shtml#Physical%20Standby%20Database%20Lags%20Far%20Behind%20the%20Primary%20Database
I could not just disable all the standbys and re-create them once the release is completed because two of the standby databases are located at off-site with the limited network speed, and re-creating standby through network takes too long for us to do so.Re-creating standby is bad thinking, when you have other options.
Think how much time you can spend on performing rollforward &
how much time to re-create standbys?
Hope you have answer for this.