Maximum Availability Architecture and Oracle E-Business Suite Release 11i

 

Businesses today operate in a highly networked, 24x7 global economy. They cannot afford to be down, and the IT systems supporting today's businesses have to be always available.

This is where MAA comes in. This document provides a step-by-step method for creating the technical components of such an IT service continuity, or disaster recovery, infrastructure for the Oracle Applications system(Ebusiness Suite 11i).

Pre-requisites for Secondary Site:

 

The site for your standby environment should:

• Be physically separate from the primary site, to protect against local and regional disasters. In terms of distance, it is typical practice for an organization to locate its standby data center in a different place (may be different city or state) from the production data center.
  
• Employ the same type of servers as at the production site, in the required numbers for adequate performance if put into use because a disaster has actually occurred, or because disaster recovery procedures are being tested (as they periodically should be).
  
• Have reliable and efficient network services to the primary data center and the location of the users (which may not be the same place).
  
• Have sufficient network bandwidth to the primary data center to cater for peak redo data generation.
  
• Have the required additional network bandwidth to support synchronization of the report, log, and output files, if your concurrent processing output needs to be mirrored.
  

Step 1à Enable Force Logging:

Place the primary database in FORCE LOGGING mode by using the following SQL statement:

SQL> ALTER DATABASE FORCE LOGGING;

Step 2à Configure Net Aliases to Point to Standby:

Under the $TNS_ADMIN directory on the production database system, create a <context_name>_ifile.ora file, and add a TNS aliases that points to the standby system database instances.

Step 3à Enable Archive Logging on Production System:

• Add the following lines to the
  ORACLE_HOME>/dbs/<CONTEXT_NAME>_ifile.ora
  of the first instance (instance1) of your production system:
  

  <log_archive_dest_1='LOCATION=<location of the archive log directory>' log_archive_dest_2='SERVICE=<standby_sid1> LGWR ASYNC REOPEN=10 ALTERNATE=log_archive_dest_4'
  log_archive_dest_3='SERVICE=<production_sid2> ARCH REOPEN=10'
  log_archive_dest_4='SERVICE=<standby_sid2> LGWR ASYNC REOPEN=10'
  log_archive_dest_state_4=ALTERNATE
  #log_archive_dest_state_2= defer
  log_archive_format=<production_sid1>_%s_%t.log
  log_archive_min_succeed_dest=1
  log_archive_start=TRUE
  

Step 3à Enable Archive Logging on Production System:

• Shut down the instance using the command:
  

  SQL> shutdown immediate;
  

in the $ORACLE_HOME/dbs/init<production_instance>.ora file, and then issue the following commands:

SQL> startup mount
SQL> alter database archivelog;
SQL> alter database open;
SQL> shutdown immediate;

and issue the command:

SQL> startup;

Step 4à Enable Archive Logging on Production System:

 

• Oracle E-Business Suite Release 11.5.10 introduced support for the Oracle Net security feature, tcp.validnode_checking, which is used to prevent unauthorized Oracle Net access (for example via SQL*Plus) to the Applications database. If a node or PC is not registered, the connection attempt will fail with the error ORA-12537: TNS: connection closed.
  
  
• This feature is enabled by default. If you are sure you do not want to use it, you can set the Profile Option 'SQLNet Access' (FND_SQLNET_ACCESS) to the value 'ALLOW_ALL'. If you require the feature to remain in use, you must add all the standby host systems to a special list of invited nodes in the SQLNET.ORA file.