Oracle Applications DBA APPSLab

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

Labels: Misc

 

Check this out !

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

 

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.

Labels: Common APPS

 

Upgrade your Oracle Applications Certifications

Labels: Misc

 

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

Oracle databases, applications and and middleware solutions.

http://www.babboo.com/

Labels: Misc

 

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

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.