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
- Sharing Knowledge on Oracle E-Business Suite Applications, Database, Fusion Middleware !!!
http://www.quest.com/application-and-service-management-technology/oracle-e-business.aspx
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.
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
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.
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.
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.
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.
Customer wishing to implement load balancing should focus their attention firstly on the following note depending on their version of E-Business Suite: R11i The most common load balancer vendors chosen by our customers are F5 who produce the BigIp solution and Cisco which make the Context Switch Module (CSM) and Application Control Engine Module (ACE). If you are implementing a Cisco or F5 solution please see the referenced documents below. For a complete list of tested load balancers see: If you are implementing a Cisco or F5 Load balancer please use the following vendor created deployment along with the above Oracle documentation to implement your load balancer F5 Cisco Oracle customers may also consider using Oracle Web Cache as a load balancer. If this is of interest to you please consult the following documentation: |