Shared Application File System in R12 and 11i

E-Business suites (EBS) 11i and R12 both support the sharing of the Applications Tier File System. Sharing a file system in EBS involves sharing a volume between 2 or more physical servers. In a shared Application Tier File System (ATFS) implementation, the application services can be configured to run (utilize CPU and memory) on any server sharing the ATFS simply by changing some context file variables via OAM, running Autoconfig and restarting the services. This process is detailed in the following notes:

R12: Note.384248.1: Sharing the Application Tier File System in Oracle E-Business Suite Release 12
11i:   Note.233428.1: Sharing the Application Tier File System in Oracle Applications 11i

Some key concepts of sharing ATFS:

• Each server sharing the ATFS will have its own context file
• Certain context file variables dictate which application services start and run on which server(s)
• Certain context file variables dictate how AD Utilities will behave on each server

The Unified Applications Tier File System (UATFS)

The term "Unified Applications Tier File System" (UATFS) came along with R12 as a new feature. Oracle Development decided it would be beneficial to always install all the files needed on every server in a given R12 installation, even if the server was only to host some of the Application services. Even though this term was coined for an R12 feature, it still applies to some 11i file systems. A Unified Applications File System essentially means that the file system contains all the files required to support all 4 base service groups in E-Business Suite:

• Web
• Forms
• Admin (Not a true process or service as the other 3 are. The "admin" component dictates which server administers the application database objects and therefore has the needed files for that task.)
• Concurrent Processing (Reports)

Again, all versions of R12 are always installed with UATFS as delivered by Rapid Install. However in 11i only single node-installations are unified at install time. In 11i in order to achieve a unified file system from a multi-node installation, a merge of the file systems must be performed. This is the only supported manner in which to achieve a unified file system from an installation which was originally multi-node. APPL_TOP Merging in 11i is accomplished by Note 233428.1, Section 4, "Merging existing APPL_TOPs into a single APPL_TOP". Because R12 is always unified there is not an APPL_TOP merge process in R12.

Some Non-Typical Scenarios for Shared File Systems in 11i

In 11i it is also possible to share an ATFS even if the file system is not unified or complete; i.e., it only supports 1, 2 or 3 of the 4 core services. For example 11i can have an ATFS which only has the files for Forms and Web. That ATFS can then be shared with another server for Forms / Web services only. The other core services, Admin and Concurrent would then have its own ATFS on another server or servers. This would be done for some advanced topology configurations like load-balancing or perhaps a standby Web / Forms server and would minimize the footprint of the ATFS. Because the ATFS in this example is not unified, the ATFS of the Forms/Web servers could never host the Concurrent Processing or Admin services without first being merged with an ATFS which has the necessary Concurrent Processing and Admin files. So while in 11i it is possible to share a non-unified ATFS, it would not be a typical configuration. A typical configuration is sharing 1 unified ATFS for amongst multiple servers. The advantages of this non-typical example would be:

• Smaller Footprint for the ATFS on each volume/disk (however the overall combined footprint would be larger)
• Better performance from the shared volume/disk, as there are 2 instead of 1

The disadvantages would be:

• Must maintain multiple ATFS's
• Patches have to be applied multiple times 
• Cloning is more difficult as 2 ATFS's must be cloned

For disk performance reasons, you could implement a similar strategy in R12, for example sharing 2 volumes (VOL1, VOL2) amongst 4 servers: 2 web/forms servers accessing only VOL1 and the 2 CCM/Admin servers accessing only VOL2. Those 2 disks would each have a unified ATFS in R12, where the same configuration in 11i the file systems could be partial or unified.

For more information please refer :

Explanation of Context Variables for Shared Application File System in R12 and 11i [ID 1070152.1]

References
NOTE:233428.1 - Sharing the Application Tier File System in Oracle Applications Release 11i
NOTE:384248.1 - Sharing The Application Tier File System in Oracle E-Business Suite Release 12
NOTE:406558.1 - Configuring Applications Node Services in Oracle E-Business Suite Release 12
NOTE:415385.1 - On a R12 Multi-Node Install -- Why do all Middle Tiers run all Services?

Quest Foglight - Oracle E-Business Management

 

Oracle E-Business Management       

Foglight helps organizations achieve application service levels and improve

Oracle E-Business application performance.

 

http://www.quest.com/application-and-service-management-technology/oracle-e-business.aspx

Symantec i3 for Oracle Applications

 

Check this out !

 

http://www.linxcel.co.uk/software_symantec_I3oracleapp.html

Steps to Create a Read-Only APPS Schema

 

Here we are going to create a schema similar to the APPS schema but has only read-only prviliges.

Steps:

1. Create the user for the required schema:

SQL> connect system/manager
SQL> create user <your_user> identified by <your_user_password> default tablespace
<tablespace_to_assign_to_user> temporary tablespace temp;

2. Grant connect and resource privileges to your user:

SQL> connect system/manager
SQL> grant connect, resource to <your_user>;

3. Use the following select statement to generate a script that will grant privileges on APPS
objects to your user.
Note the following:

A. This select statement should generate a script that will grant almost all required permissions
to a user called MYUSER.
B. This select statement is a guide only. You should work with your DBA to enhance it according to
your requirements.

SELECT 'GRANT '
|| DECODE(O.OBJECT_TYPE,'TABLE','SELECT',
'VIEW','SELECT',
'EXECUTE')
|| ' ON '
|| DECODE(O.Owner,'PUBLIC','',O.Owner || '.')
|| '"'
|| O.OBJECT_NAME
|| '"'
|| ' TO MYUSER;' COMMAND
FROM ALL_OBJECTS O
WHERE O.OBJECT_TYPE IN ('TABLE','PACKAGE','PACKAGE BODY','PROCEDURE', 'VIEW','FUNCTION')
UNION
SELECT 'GRANT '
|| DECODE (O2.object_type, 'TABLE', 'SELECT',
'VIEW', 'SELECT',
'EXECUTE')
|| ' ON '
|| DECODE(O.Owner,'PUBLIC','',O.Owner || '.')
|| '"'
|| O.object_name
|| '"'
|| ' TO MYUSER;' COMMAND
FROM ALL_OBJECTS O
, ALL_OBJECTS O2
, DBA_SYNONYMS S
WHERE O.object_type = 'SYNONYM'
AND O.object_name = S.synonym_name
AND O2.object_name = S.table_name
AND O2.OBJECT_TYPE IN ('TABLE','PACKAGE','PACKAGE BODY','PROCEDURE', 'VIEW','FUNCTION')

4. Use the following select statement to generate a script that will create synonyms in
<your_user> schema for all objects owned by APPS.

SELECT 'CREATE SYNONYM MYUSER.'
|| O.OBJECT_NAME
|| ' FOR APPS.'
|| O.OBJECT_NAME
|| ';' COMMAND
FROM DBA_OBJECTS O
WHERE O.Owner = 'APPS'

5. Run the above two scripts as SYS user.

Now Live: R12: Install, Patch and Maintain Applications (1Z0-238)

 

Upgrade your Oracle Applications Certifications

 

XClone - Automated Solution for Cloning Oracle Apps

 

XClone is the world's first completely automated solution for cloning

Oracle databases, applications and and middleware solutions.

 

 

 

http://www.babboo.com/

Concurrent Request Phase and Status

 

A concurrent request has a life cycle consisting of the following phases:

pending, running, completed, and inactive.

During each phase, a concurrent request has a specific condition or status. The below table

lists each phase/status combination and describes its meaning in relation to a request.

 

Concurrent Request Phase and Status

Phase	Status	Description
PENDING	Normal	Request is waiting for the next available manager.
	Standby	Program to run request is incompatible with other program(s) currently running.
	Scheduled	Request is scheduled to start at a future time or date.
	Waiting	A child request is waiting for its Parent request to mark it ready to run. For example, a request in a request set that runs sequentially must wait for a prior request to complete.
RUNNING	Normal	Request is running normally.
	Paused	Parent request pauses for all its child requests to finish running. For example, a request set pauses for all requests in the set to complete.
	Resuming	All requests submitted by the same parent request have completed running. The Parent request resumes running.
	Terminating	Request is terminated by choosing the Cancel Request button in Requests window.
COMPLETED	Normal	Request completed successfully.
	Error	Request failed to complete successfully.
	Warning	Request completed with warnings. For example, a request is generated successfully but fails to print.
	Cancelled	Pending or Inactive request is cancelled by choosing the Cancel Request button in the Requests window.
	Terminated	Request is terminated by choosing the Cancel Request button in the Requests window.
INACTIVE	Disabled	Program to run request is not enabled. Contact your system administrator.
	On Hold	Pending request is placed on hold by choosing the Hold Request button in the Requests window.
	No Manager	No manager is defined to run the request. Check with your system administrator. A status of No Manager is also given when all managers are locked by run-alone requests.

Individual Request Progress

Generally when you submit a request, its phase is Pending, which means that it has not yet

started running. When it does start running, its phase changes to Running. Upon completion

the status of the request becomes either Success, Warning or Error. If your request ends in

warning or error, you can use the Special Menu to select Diagnostics from the Requests

window to view any diagnostic messages stored in the log file.

Request Set Progress for Stages

When you submit a request set, all the requests in a stage run simultaneously and the phase

and status of the set begins as Pending Normal until an available concurrent manager can

process it. When a concurrent manager becomes available, the stages's phase and status

change to Running Paused as the stage waits for all of its requests to finish. Then the stage

changes from Running Paused to Running Normal to write completion information in the

report and log files. Finally, the stage phase changes to Completed and its status becomes

Success, Warning, or Error.

Progress of Individual Requests in a Stage

When a stage submits its requests, all requests start as Pending Normal, then change to

Running Normal, and finally end as either Completed Success, Completed Warning, or

Completed Error.

Progress of Linked Stages

When you submit a request set with more than one stage, the request set submits all

the stages but only runs one stage at a time, ensuring that each stage completes before

submitting the next. Each stage shows a phase of Pending and a status of Normal while

it waits for a concurrent manager to process it. As the next available concurrent manager

processes the stage, the request set phase and status changes to Running and Paused,

as the first stage begins to run. After each stage finishes, the request set temporarily

changes to a Normal status to check whether the stage ended in error and to determine

whether to stop or which stage should be processed next based on how you linked the

stages when you defined the request set.

Once the check is done for a completed stage, the set goes back to Paused status during

which the next stage runs. The set alternates between Normal and Paused status for each

stage in the set. The set itself resumes running (Running Normal), after all the requests

finish, to write completion information in the report and log files. The set ends in a

Completed phase, either with Success, Warning or Error status. A request set ends when

a stage ends with a completion status that does not link to a subsequent stage.