Configure standby EBS 12.1.3 apps server to work with primary database in place

[Mohammed Misbahuddin]

       
HI,
We followed the  document Business Continuity for Oracle E-Business Suite Release 12.1 Using Oracle 12c Physical Standby Database ( Doc ID 1900663.1 )
In this document we have a section as below:

Section 5: Configuration on Application Tiers After Standby Database is Enabled.
we do not need to configure the application tier after standby is enabled.

we need the standby application server to be ready to work with existing primary database, i.e. before enabling the standby DB.....if the primary application server is down, on the standby application server we should be able to start the services connecting to Primary database .


Let me clarify further:
1) We want to have 2 DR configurations for application tier......One standby application will work with the physical standby once the standby is enabled......as per the doc Section 5: Configuration on Application Tiers After Standby Database is Enabled

2) The second application standby should work with the existing primary database as it is.

To make it even simpler for you to understand what we are looking for:

Let's assume our existing application server is crashed .......we have a new application server ....we copied the application files from the backup to this new application server........now, how to configure the applicaiton copied on this new server so that it works with the existing EBS database.

Kindly advice the best possible way

[ErmanArslansOracleBlog]

Okay..  I understand..

Actually , you should manage this by using a virtual host or something similar in your OS and/or DNS level..
if you want that kind of a customized HA environment, then you will follow a customized action plan.

So you want the apps tier of one of your secondary DR environment to connect to the primary database (in case of a disaster) So you think that your primary app tier will be down, but your primary db  tier will be up.
You dont want any extra configuration, you only want to start the apps services in the secondary env..
Then you need to have the same filesystem paths and the same hostname for the secondary apps tier env as the primary apps tier env.

Just copy the apps tier from primary to secondary. (using the same paths as the primary for the secondary)
Enable a virtual host in the secondary apps tier to be the same as the primary apps tier. Or use the same hostname for the secondary app host as the primary (but isolate the network, ensure no on
e is able to connect to secondary app accidentally) and manage it through DNS.. That's it.
With this configuration, you can just start the apps tier services without doing any configuration in the apps tier of the secondary env, and that apps tier services will connect to do the primary database.

Again, you should be very careful while implementing this. We don't want someone to try connecting the secondary normally.  Risk is yours.

[Mohammed Misbahuddin]

Hi,
Thanks a lot for the prompt response....Yes, we kept the directory structure same on the second apps tier.....we have solaris 11 on m4000 server as our secondary apps server....so if we keep the hostname same as primary and start the services...will it work?...the IP address will be still different....

Our plan is to have a different hostname of the 2nd apps server...when the primary apps goes down....we will create application context and run autoconfig...and start the services......the users will be give a different shortcut to connect ..like APPSDR with the new URL …….

http://apps1.com.sa:8006  this will be our primary apps server EBS url….

http://appsdr1.com:8006 this will be our secondary apps server URL....

We want to follow the below step from the business continuity doc:

Step 3 Configuration of application tiers after standby database is enabled

Perform file-based configurations on standby application tiers

After the application tier software copies are complete, the file system configurations need to be updated to reflect the new environment. To do this on the application tiers, log onto each standby application tier system as the APPLMGR user and execute the following commands. Since your environment scripts are not yet set up, you will need to manually resolve the reference to and .
If the directory structure on standby is different than the primary then you need to run "perl adcfgclone.pl atTechStack" instead of adclonectx.
$ cd /clone/bin
$ perl adclonectx.pl /appl/admin/.xml


When the script is finished and the context file is created, execute the following commands, again resolving the reference to

$ cd APPL_TOP/ad/12.0.0/bin
$ perl adconfig.pl contextfile=$INST_TOP/appl/admin/.xml run=INSTE8
Answer the questions when prompted. This creates your environment files on the application tier. It tries to connect to the database, so some portions will fail, but the environment scripts should be created successfully. /LI>
Optionally, set up rsync for log and out files. If you wish to synchronize your concurrent manager log and out files from primary to the standby, first create directories matching matching to the APPLCSF environment variables in the appropriate place on the standby application tier server(s). For example:

$ mkdir -p /log
$ mkdir -p /out
Repeat this on the primary server, creating directories matching the standby context name, so as to be ready for a switchover operation. For UNIX systems, on the primary application tier(s), set up an rsync job in cron, to run every few minutes. This example synchronizes the log directory.
$ rsync av < APPLCSF>/log : /log --rsync-path=/usr/local/bin/rsync

----------------------------------------------------------------------------------------------
The only difference will be in our case we will not have standby db enabled....we will do the above steps connecting the primary db

Do you think the above idea is feasible ...will it work?

[ErmanArslansOracleBlog]

If you consider and accept creating the context file and running autoconfig during such a failover, then it is ok.
Basically, you must not touch the database side configuration of that secondary apps node. That secondary apps node should still configured to connect to the primary database, however; it shouldn't connect to the primary during the standby apps tier configuration phase! this is important!

The processes in EBS are mostly dependent to hostname. Having a different IP address is not that much necessary.. you may have minor problems by having a different ip address for the same hostname in your secondary and/or your customization may fail (if they are somehow dependent to the IP address of your apps server) , but generally the effects will be near- zero , or very minor.

*** I mentioned that the effects of having different IP address are minor, but here is the documented method for changing IP address in EBS 11i and R12 environments.. You may consider the actions documented in the document below to your customized failover procedure as well.. ->

Correct Method of Changing the IP Address in 11i & R12 (Doc ID 751328.1)

Yes.. Why not... (can be implemented during failover -- only during your customized failover..)

However; this instruction is dangerous -> "Answer the questions when prompted. This creates your environment files on the application tier. It tries to connect to the database, so some portions will fail, but the environment scripts should be created successfully."

This is dangerous as you will have the same database to connect to.. We don't want any writes to the primary database during your standby apps tier configuration process..

So, what I recommend you is not connect to the primary during your configuration proces.

Just, have the same directory paths and same hostname for the secondary apps tier...
If you can't have the same hostname, then during your failover; just do the following;

Deregister the current Applications server
Create a new Context file
Shutdown the Application Tier Services (already shutdown in your case)
Change the server machine hostname. (already different in your case)
Run autuconfig on apps tier
Start the Applicataion Tier Services

Ref: Apps-Tiers related sections of MOS document "How to change hostname for E-Business Suite Release 12 on single node (Doc ID 1277556.1)"

Remember you will have to do the same thing when you fail back to your original primary...

Test this procedure in your test env and optimize it.
As this is not a standard procedure, the risk is yours!

[Mohammed Misbahuddin]

Hi,
Thank you very much for all the clarifications and options.

I feel now the procedure mentioned in Correct Method of Changing the IP Address in 11i & R12 (Doc ID 751328.1)  should satisfy our needs.....if used along with the procedures for apps tier hostname change mentioned in    How to change hostname for E-Business Suite Release 12 on single node (Doc ID 1277556.1)"

The steps will be the same as you suggested: In our case...
1) Shutdown the apps services or its crashed

2)Deregister the current application server by below procedures:
perl $AD_TOP/bin/adgentns.pl appspass=<APPSpwd> contextfile=./<SID>_oldhost.xml -removeserver

&

begin
FND_NET_SERVICES.remove_server('<SID>', '<hostname>');
end;
/
commit;

&

exec fnd_conc_clone.setup_clean;

3) APPS Tier: Create a new Context file

    You can create the new context file using whichever of the following methods:

    a. Manual Method:

        cd $APPL_TOP/admin
        cp <SID>_oldhost.xml <SID>_newhost.xml
         
        Edit <SID>_newhost.xml manually:
        Replace all oldhost with newhost

    b. Script Method:(The command below will create a new Context file of <SID>_newhost.xml in new <SID>_newhost directory.)

        cd $INST_TOP/appl/admin
        perl $COMMON_TOP/clone/bin/adclonectx.pl contextfile=./<SID>_oldhost.xml

4)  APPS Tier: Reseed the Net Services Topology Model

    The Net Services Topology Model is automatically updated by running AutoConfig.
    $AD_TOP/bin/adconfig.sh contextfile= $INST_TOP/../<SID>_newhost//appl/admin/<SID>_newhost.xml appspass=<appspasswd>

5) finally run autoconfig without passing the context file name and start the services...


Hope the above is exactly as you suggested.
Will test this weekend …...

[ErmanArslansOracleBlog]

if you execute "exec fnd_conc_clone.setup_clean; ", then you will need to run autoconfig on database tier as well!

So ensure what you are doing. Test it carefully.
You may try going with executing  "exec fnd_conc_clone.setup_clean; ".. Test it and verify it.
or , include db tier autoconfig to your action list as well..

Again, dont run these command while your primary env is up and running.. This kinds of a customized action plan is only applicable for your customized failover scenario (during a custom failover that you described.)

And why  -> "without passing the context file name and start the services..."?

Just implement the synthesis of the apps tier specific actions that are documented in  1277556.1 and 751328.1. I mean a union set of the the apps tier specific actions that are documented in  1277556.1 and 751328.1 .. Ofcourse in the correct order..

In your secondary app env (to make it be the primary app env, with the original primary db)->

*Deregister the current Applications server "perl $AD_TOP/bin/adgentns.pl ......remove" --> for your apps host
*Remove "Run FND_NET_SERVICES.remove_server('<SID>', '<hostname>');" --> for your apps host
*Create a new apps tier Context file
*Shutdown the Application Tier Services (already shutdown in your case)
*Change the server machine hostname. (already different in your case)
*Run autuconfig on apps tier
*Start the Applicataion Tier Services

[Mohammed Misbahuddin]

OK Erman….it is clear now....will test it and let you know the results....

[ErmanArslansOracleBlog]

okay..
again.. 5 principal.. 1)Don't write to production db 2)Don't test on production. 3)don't do the same things again and again.. (just implement the union set of actions, dont take the actions more than once if they are intersecting with eachother 4)take the actions in the correct order 5)test it carefully before considering taking it into production.