Wednesday, June 29, 2016

EBS 12.2 -- interesting question on Business Continuity for Oracle E-Business Suite Release 12.2

One of my collegues asked me the following question ->
"Before the postclone , there should be only the  Ebsapps directory(<APPL_TOP>, <common_top>,Oracle AS Tools 10.1.2 Oracle_Home) present in the host where the postclone script is wanted to be executed. This means $APPL_TOP_NE should be deleted beforehand.
If that so; why do we rsync the concurrent request log and out files from primary to standby application server? I m asking this question, because during a failover a switchover, I will execute a post clone on standby apps server, thus I will have to delete the APPL_TOP_NE before executing it and as the concurrent log and out files are stored in APPL_TOP_NE, why do we rsync them?"

Well, the answer is there in My Oracle Support.
The important point is that, according to the latest documentation, we execute the post clone in the first place when we are creating the standby application tier environment. This postclone will save us from executing future postclones when there will be a switchover or a failover operation required in the future. So as we execute the post clone in the configuration phase of the standby apps tier, we only need to execute the autoconfig in apps tier for switching over ort failing over to the standby site.
This means, our synched concurrent request log and out files will be there in the standby application tier after the switchover or failover operation.

I wanted to share this with you , because the question and its answer was interesting.
So once again, the importance of following the Oracle Support notes was proven.
read -> Business Continuity for Oracle E-Business Suite Release 12.2 Using Oracle 12c (12.1.0.2) Physical Standby Database (Doc ID 1963472.1)

4 comments :

  1. Hi Erman,

    Could you please explain why we no need to run postclone in case of failover despite we are running autoconfig.
    ( Autoconfig will erase postclone changes).

    Thanks,
    Uday

    ReplyDelete
  2. Hi Jampani,

    That's becauase we execute post clone while we are configuring the standy apps tier.

    So, after the Standby Database has been Enabled, we open the standby database by converting it to a snapshot and then remove the applications configuration and then we execute autoconfig.
    We even execute postclone in standby apps tier and then revert our standby database to its original state.

    So our apps tier become ready, before performing a switchover.
    Well.. if we do these things while configuring the standby Apps Tier, we don't need to run post clone while performing role transtions.

    As I stated in the blog post above; "we execute the post clone in the configuration phase of the standby apps tier, we only need to execute the autoconfig in apps tier for switching over ort failing over to the standby site."

    ReplyDelete
  3. 1.During switchover if we run AC , postclone changes ( done during configuration phase) will be lost?
    2.How about syncing(rsync) all 3 FS to DR Apps servers and bringing up services( pointing DNS entries to Dr apps servers ), would that work?

    ReplyDelete
  4. 1)I don't know what kinds of changes are you doing in postclone's configuration phase, but you can run the adchkcfg utility to get an html report that lists all the files and profile options that get changed when you run AutoConfig.
    2)The hostnames+ip addresses of the DR apps servers should be set to the hostnames+ip addresses of the primary apps servers. (if you do this, then you can directly start the apps services after finishing db site switchover properly)

    ReplyDelete