How do I find out where tracing has been enabled in Oracle R12 ebusiness suite

Thanks schwertner but that doesn't solve my problem.

The platform is AIX and my question is how to figure out which tracing option has been enabled. I am think the answer will be of in the form of  a list of every possible option or parameter in an R12 environment that could enable tracing and/or possible some scripts to reveal the parameters.

Found only for Forms:

Note:
Unlike in Release 11i, you can no longer create a trace file in any ad hoc directory by using '&log=' directive like '&log=/usr/tmp/user1.log'.In R12, the FRD log file will be written in the directory pointed by environment variable $FORMS_TRACE_DIR and one can specify the log filename with '.log'extension in one of the following ways:

1. In appsweb.cfg:
Look for "log=" parameter after the 'ENVIRONMENT SPECIFIC PARAMETERS' section and set it with name that you want the trace file to be created with.

E.g
log=user1.log

2. Using +log directive in the URL used to set the frd trace via profile options or in ad hoc way

E.g
http://hostname.domain:port/forms/frmservlet?record=collect+log=user1.log
http://hostname.domain:port/OA_HTML/frmservlet?record=collect+log=user1.log

Generating the ATP Session Files
To perform all the steps in this action plan, you will need access to the Applications, SQL*Plus, and Unix.
You can generate the session or trace files with only Applications access, but confirming they are successfully created and retrieving the files requires full access to the system.
 
1.      Set the profiles:
a.       MSC: ATP Debug Mode to 'Debug and Database Trace' or 'Debug Only'.  If you are currently using a decentralized instance, then the profile should be set at the User level on the source (ERP) instance and the Site level on the destination (Planning) instance.
b.       If using the Sales Order form or Order Import program, then also generate the OM Debug Log file, by setting profile OM Debug Level = 5 at the user level. Then when you enter the sales order form, use /Tools/Debug and check the box to start the OM debug log file. Record the number returned to the screen for the log file name ( e.g. l1234567.dbg <lowercase L>number.dbg)


2.      To find the location of the session files at the Unix level, execute the following query in SQL*Plus:
SELECT
  ltrim(rtrim(value)) Value
FROM
  (select value from v$parameter2
   where name='utl_file_dir' order by rownum desc)    
WHERE rownum <2;


3.      Once the above have all been done, you are ready to generate the session file.  Navigate to the form where the ATP check is performed and execute the ATP Inquiry.  Finding the session file number differs depending on where the ATP check is performed.
a.       ATP Inquiry Form
                                                                           i.      Perform the query
                                                                         ii.      Select Help > Diagnostics > Examine
                                                                        iii.      Block = LINE
                                                                       iv.      Field = SESSION_ID
                                                                         v.      Value = <session number>
                                                                       vi.      Make note of the number, then navigate to Unix and get the corresponding file.


b.      Sales Order Form
                                                                           i.      Use /Tools/Debug and check the box to enable debug and get the file name returned in the note
                                                                         ii.      After performing the ATP Scheduling or Availability check, use /view/Requests - Submit a new request Diagnostics: OM Debug log file Retrieval - enter the log file name (lnumber.dbg)
                                                                        iii.      After the request completes open the OUTPUT File and search using CTRL-F to find MRP API
                                                                       iv.      The line should appear like the following in this example from an OM Debug log file:
ENTERING OE_SYS_PARAMETERS_PVT.VALUE
Parameter Value: 204
1. CALLING MRP API WITH SESSION ID 204859
3. AFTER CALLING MRP_ATP_PUB.CALL_ATPS
2. ENTERING LOAD_RESULTS_FROM_REC
-----------------Loading MRP Result---------------
MRP COUNT IS 1
SCHEDULE ACTION CODE ATP_CHECK
So for this example, the file name found in the system would be session-204859
                                                                         v.      Please see Note 121054.1 - How to Generate a Debug File in OM - for further instructions on generating the OM Debug file


c.       Workaround - You may still find the session file without the actual session number.
                                                                           i.      In Unix, ensure that you are in the directory from the query in step #2
                                                                         ii.      Perform the ATP check
                                                                        iii.      Execute the command 'ls -ltr sess*'
                                                                       iv.      Ususally the session file associated with the ATP check is the last file returned.  Confirm this by the timestamp on the file.
                                                                         v.      In latest versions of the ATP Code, the order number is listed in the session file, which helps confirm that the right file has been chosen.


4.      Upload the following to the SR
a.       If generated, upload OUTPUT file after retrieving the OM Debug Log file
b.      Screen shots of the results.
c.       Session file(s) to the SR.
 IF the installation is decentralized with separate APS and ERP instances,
THEN two session files will be created. Be sure to get BOTH session files if they exist. The name of the session file is the same on both instances. (using the example above, support would expect two files named session-204859. Please label them for easy reference)
d.      The Diagnostic Tools OR apscheck.sql outoput  see APSCheck Diagnostic Script
 
Generating BOTH the Trace and Session files
To perform all the steps in this action plan, you will need access to the Applications, SQL*Plus, and Unix.
You can generate the session or trace files with only Applications access, but confirming they are successfully created and retrieving the files requires full access to the system.
 
1.      Set the profile MSC: ATP Debug Mode to 'Debug and Database Trace'. If you are currently using a decentralized instance, then the profile should be set at the User level on the source (ERP) instance and the Site level on the destination (Planning) instance.


2.      To find the location of the session files at the Unix level, execute the following query in SQL*Plus:
SELECT
  value
FROM
  v$parameter
WHERE
  name = 'user_dump_dest';
Example Result
VALUE
------------
/u02/oracle/apsdb/9.2.0/admin/udump


3.      Once the above have all been done, you are ready to generate the trace file.  Navigate to the form where the ATP check is performed and execute the ATP Inquiry.


4.      While still in the form, select Help > About Oracle Applications and make note of the value associated with VERSION_DATABASE_PROCESS.  This is the trace ID you will be looking for in Unix.
Example Result
VERSION_DATABASE_PROCESS : 22397


5.      On the database server in Unix, go to the directory returned by the query in step #2 and search for the trace file.
Example Result
$ cd /u02/oracle/apsdb/8.1.7/admin/udump
$ ls -ltr *22397*
-rw-r--r--   1 oracle   dba       224475 Aug  5 08:04 aps_ora_22397.trc


6.      If you are in a decentralized environment, you will need to retrieve the trace file from the destination instance as well.  Use the SQL in step #2 to find the trace file location on the destination and then run the following unix command to find a recently generated trace file associated with the ATP Inquiry:
for c in `ls *.trc`;
do
if strings -a $c | grep -i "MRP_ATP_DETAILS" > /dev/null; then ls -al $c; fi;
done
 
You should be able to use the timestamp to find the trace file.
Example Result
[applmgr@aps udump]$ for c in `ls *.trc`; do if strings -a $c | egrep  "MRP_ATP_DETAILS"  > /dev/null; then ls -al $c; fi; done
-rw-r--r--  1 oracle dba 3261271 Dec 26 19:04 aps_ora_24182.trc
-rw-r--r--  1 oracle dba 38903222 Dec 13 21:44 aps_ora_23521_TRACE_01.trc
-rw-r--r--  1 oracle dba 733353 Dec 12 17:09 aps_ora_28722.trc
-rw-r--r--  1 oracle dba 465656 Dec  6 12:57 aps_ora_16199.trc


7.      TKPROF the trace file
Example
tkprof aps_ora_22397.trc aps_ora_22397.txt sys=no explain=apps/<apps password>


8.      Upload the following to the SR:
a.       Zip the raw and tkprof trace files and upload them to the SR.
b.      Use the Steps 2 & 3 in Generating the ATP Session files in to get the session file that matches the trace file and upload that file as well.
c.       The Diagnostic Tools OR apscheck.sql outoput  see APSCheck Diagnostic Script

In certain circumstances, it may be desirable to restore a database from an RMAN backup onto a machine other than the original host. For example, to recover data at a given point in time, or to duplicate a production instance.
The example assumes:
 
 - the target database is on host A
 - the database is to be restored onto host B
 - the directory structure of host B is different to host A
 - the ORACLE_SID will not change for the restored database
 - a recovery catalog is being used
 - the backups were carried out to disk (for illustrative purposes, and to disassociate from any media manager specific issues)
 
The following steps are required:
 
 - backup the target on host A
 - list the datafile locations on host A
 - make the backup available to host B
 - make a copy of the init.ora available to host B
 - edit the init.ora to reflect directory structure changes
 - configure SQL*Net connectivity from host to the recovery catalog and  
   duplicated database
 - set up a password file for the duplicated database
 - startup nomount the duplicated database
 - RMAN restore the controlfile(s)
 - mount the database
 - restore and rename the datafiles
 - recover and open the database
 
These steps are expanded further below.  
 
1.0 Backup the Target on Host A
-------------------------------
 
The target database needs to be backed up using RMAN.  
The following is one example of RMAN doing an online database backup. In this example, the backup sets are written to disk.
 
run {
allocate channel t1 type disk;
allocate channel t2 type disk;
allocate channel t3 type disk;
 
#backup the whole db
backup
  tag whole_database_open
  format '/oracle/backups/BFS/df_%u'
  database;
 
# switch out of the current logfile
sql 'alter system archive log current';
 
#backup the archived logs
backup  
  archivelog all
  format '/oracle/backups/BFS/al_%u';
 
# backup a copy of the controlfile that contains records for the  
# other backups just made
backup  
  current controlfile  
  tag = cf1  
  format '/oracle/backups/BFS/cf_%u';
 
}
 
2.0 List Datafile Locations on Host A
-------------------------------------
 
The datafile numbers and location on host A are required. These datafile locations will change on host B (see Section 7.3).
 
SVRMGR> select file#, name from v$datafile;
 
  file#   name
  -----   ------------------------------
  1       /oracle/OFA_base/u01/oradata/V805X/system01.dbf
  2       /oracle/OFA_base/u01/oradata/V805X/rbs01.dbf
  3       /oracle/OFA_base/u01/oradata/V805X/temp01.dbf
  4       /oracle/OFA_base/u01/oradata/V805X/tools01.dbf
  5       /oracle/OFA_base/u01/oradata/V805X/users01.dbf
  6       /oracle/OFA_base/u01/oradata/V805X/users02.dbf
  7       /oracle/OFA_base/u01/oradata/V805X/rbs02.dbf
  8       /oracle/OFA_base/u01/oradata/V805X/rcvcat.dbf
 
The log file names should also be recorded (see Section 7.4).
 
SVRMGR> select group#, member from v$logfile;
 
  group#  member
  -----   ------------------------------
  1       /oracle/OFA_base/u01/oradata/V805X/redo01.log
  2       /oracle/OFA_base/u01/oradata/V805X/redo02.log
  3       /oracle/OFA_base/u01/oradata/V805X/redo03.log
 
3.0 Make the Backups Available to Host B
----------------------------------------
 
3.1 Disk Backups
 
During restore, RMAN will expect the backup sets to be located in the same directory as written to during the backup. For disk backups, the DBA can accomplish this in many ways:
 
   - set up an NFS directory, mounted on both host A and host B
   - create the same directory structure on host A and host B
   - use of symbolic links on host B
 
3.2 Tape Backups
 
The media management software must be configured such that host B is a  
media manager client, and can read the backup sets. The media management vendor should be consulted for support on this issue.
 
4.0 init.ora on host B
----------------------
 
The "init.ora" needs to be made available on host B. Any location specific  parameters must be ammended. For example,
  - ifile
  - *_dump_dest
  - log_archive_dest*
  - control_files
 
5.0 SQL*Net configuration
-------------------------
 
If running rman from host A:
 
 a. connectivity to the catalog remains unchanged
 b. configure tnsnames.ora on host A to connect to duplicated db on host B  configure listener.ora on host B to accept connections for duplicated database
 
If running rman from host B:
 
 a. configure tnsnames.ora on host B to connect to catalog
    listener.ora on catalog host remains unchanged
 b. configure tnsnames.ora on host B to connect to duplicated db on host B configure listener.ora on host B to accept connections for duplicated database    
 
If running rman from host C (i.e., neither host A or host B):
 
 a. connectivity to the catalog remains unchanged
 b. configure tnsnames.ora on host C to connect to duplicated db on host B configure listener.ora on host B to accept connections for duplicated database    
 
 
6.0 Setup Password File
-----------------------
 
In order to allow RMAN remote connections, a password file must be setup for the duplicated database. For example,
 
orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=kernel
 
 
7.0 Recover Duplicated Database
-------------------------------
 
7.1 startup nomount the database
 
    SVRMGR> startup nomount pfile=<location of init.ora>
 
7.2 restore the controlfile(s)
     
    For example,
    run{
      allocate channel c1 type disk;
      restore controlfile;
    }
7.2 mount the database
 
    SVRMGR> alter database mount;
 
7.3 rename and restore the datafiles, and perform database recovery
   
    RMAN can be used to change the location of the datafiles from the location   on host A (see Section 2) to the new location on host B.
 
    For example,
    run {
 
     allocate channel c1 type disk;
     allocate channel c2 type disk;
     allocate channel c3 type disk;
 
     set newname for datafile 1 to '/oracle/datafiles/system01.dbf';
     set newname for datafile 2 to '/oracle/datafiles/rbs01.dbf';
     set newname for datafile 3 to '/oracle/datafiles/temp01.dbf';
     set newname for datafile 4 to '/oracle/datafiles/tools01.dbf';
     set newname for datafile 5 to '/oracle/datafiles/users01.dbf';
     set newname for datafile 6 to '/oracle/datafiles/users02.dbf';
     set newname for datafile 7 to '/oracle/datafiles/rbs02.dbf';
     set newname for datafile 8 to '/oracle/datafiles/rcvcat.dbf';
 
     restore database;
 
     switch datafile all;
    }
 
7.4 recover and open the database
    Perform incomplete recovery:  
     
    SVRMGR> recover database using backup controlfile until cancel;
     
    Forward the database applying archived redo log files until you decide to stop recovery by typing cancel at the prompt (assuming that you have required archived redo log files in the log_archive_dest directory)
    You may archive the source database redo log files and apply them at the target database if required.
     
       
    SVRMGR> alter database open resetlogs;
     
    Note: this will create the online redo logs in the same location as that on host A. If this directory location does not exist, then this will fail with:
    ora-344 : unable to recreate online log <name>
 
    The workaround is to rename the logfiles prior to opening the database:
    SVRMGR> alter database rename file  
            '<host A location>' to '<host B location>';
 
    Alternatively, the logfile groups can be dropped and recreated. However, attempts to drop the current logfile group will fail. The current logfile must be renamed.
 
 

Please ignore the last post.
It is done by error.
Sorry.

Based on some of the replies I feel I may not be expressing the questions clearly enough.

I know how to enable and disable tracing and I can locate the trace files when I do.  My question is a bit more generic. In Oracle EBS  there are quite a few methods that can be enacted to enable tracing e.g.

- A user can enable tracing from their form session
- A concurrent program definition can be altered to turn on tracing
- There are profile options such as FND : Debug Enabled
...

I was just wondering if anyone knew of a list of all of the possible methods. I have had cases where some tracing will occur and threaten to fill up file systems and it would be nice to have a list of places to check.

It may be an impossible question to answer, in which case I will close the question. But I thought it was worth asking the community

thanks

Thanks Schwertner, I do have access to metalink. But as you probably know it's a mine field of information. I was just wondering if someone had gone to the trouble of compiling a succinct list