FAQ On The Options Available In The Troubleshooting Menu In Fusion Application 

This FAQ explains, offers recommended usages, and provides references to help understand the features and tools accessible from the Troubleshooting Options menu item in Fusion Applications (shown below).

For more details on the Run Diagnostic Tests menu option see Note   1314486.1  - How To Get The Most from Fusion Applications Diagnostic Test Framework (DTF)

What are the Features Available?

There are essentially three features here, two related to database processing and one for application logging.  These can be made accessible to end users and intended as switches to be set on before reproducing problems so more information can be collected. 

Equivalent features (and a lot more) exist in Enterprise Manager and other back-end administrator tools, however here we are specifically discussing the basic tools available inside of Fusion Applications pages.

How are the Features Secured?

a) Troubleshooting Options

This is secured by the Duty Role FND_SET_SUPPORTABILITY_LEVEL_DUTY itself containing the privilege FND_SET_SUPPORTABILITY_LEVEL_PRIV. This is Duty Role is pre-assigned to only the FND_APPLICATION_ADMINISTRATOR_JOB and DIAG_ADMINISTRATOR Job Roles.

For use by regular application users, the Duty Role will need explicitly assigning (in APM) for the Troubleshooting Options menu item to be available.  Once any logging or tracing work is complete the duty role can be easily revoked (which is recommended as inadvertently leaving logging and tracing on can impact resources and performance).

Note: There is no finer-grained restriction possible on the features within the Troubleshooting Options page, or on the selection of values or parameters within it.

b) Run Diagnostic Tests 

This option is only available to users who are associated with the pre-configured job roles for the Diagnostic Dashboard application. These job roles are: Diagnostic Viewer, Diagnostic Regular User, Diagnostic Advanced User, and Diagnostic Administrator.  Without any of these the menu option will not appear to that user.

What is the PL/SQL Profiler?

This tool is essentially intended to help understand any problems that originate from PL/SQL code execution.  It's focus is around providing a HTML report of line execution information, ordered by the amount of time they took to execute, helping show especially slow processes.  The profiler is turned on to start collecting information and then turned off.   This raw data is then passed through a script that converts it into the readable report that is found on the Database server filesystem.  The report contains the following:

Run details including time window profiled What PL/SQL libraries (packages, procedures, functions, triggers) that were

included Top 10 code lines executed during that time window, including numbers of

iterations and maximum, minimum and total time taken Breakdown of specific library execution showing code lines and time taken

details

When might the PL/SQL Profiler be used?

The Profiler should not be confused with utilities like TKPROF or SQLTXPLAIN both of which focus on understanding more about the execution of SQL

Statements.  The focus of the Profiler is purely PL/SQL code execution and not related queries, DDL, or DML statements.

As such it can be particularly useful when a problematic process is known to be related to PL/SQL program execution.  For Fusion Applications this tends to be found in the data crunching processes, especially those related to ESS jobs.  As such the Profiler can be enabled before job launch (immediate not scheduled) and then turned off once complete.

What is Database Trace?

Database Tracing allows all the activities that occur on the database that are associated with one users specific work to be recorded.  This means when specific features perform slowly, or encounter problems related to data from the database, a helpful trace of activities can be obtained for more details analysis.  

This results in a trace file, and can be looked at as-is, or more commonly used as a data-source for analysis tools like TKPROF mentioned above.  Database traces include lots of different pieces of information including but not limited to:

SQL statements executed as a result of the users actions (e.g. data submission)

SQL statements executed as a result of processes spawned by user actions (e.g. ESS jobs)

How many times each statement was executed How much time each execution took How many rows statements returned or updated What system impact that statement had on things like CPU and disk What the execution plan was that the database performed in running

that statement (useful for looking for indexing / full table scans)

For Database Trace, when should I include Bind Variables and Wait Events?

Bind Variables are the parameters that are passed into a SQL Statement at runtime, such as a specific order number, customer id, or other search criteria value.  By default these are not included in trace files and are an optional extra.  They are normally useful to have since they can ensure that specific problems really do related to the trace files being analyzed, for example a problem with one order that doesn't occur for other orders.

Wait Events are activities inside the database that can cause a slow down in SQL Statement execution time.  These might be issues related to network (SQL*Net) communication between database components, and file reading and locking mechanisms related to accessing data for a specific statement. 

Since features in Fusion Applications generally uses a standard database configuration these may be less immediately obvious as causes, however remain an option to consider checking.

When might I use Database Trace?

Traces are generally helpful in checking the database activities related to problems and deciphering to what extent specific queries might be contributing. The majority of times they are used in performance type issues, especially for processes that are known (or logically) data-centric.

They can also be helpful in understanding the data model (tables, views, joins etc) being used behind specific functional processes as well, especially when looking for bad data type problems.

How Do I Run Database Trace and Get the Output Trace File?

1. Clear all cookies from the browser

2. Launch the application URL and login

3. Enable the database trace from the application

 a) Go to Help > Troubleshooting > Troubleshooting Options

 b) Check the DB trace and the Capture Binds Variable check box

 c) Save and Close

4. Reproduce the steps you want to get trace. After reproducing the issue uncheck the trace options, and save.

5. Before you log out get the cookie name.

 a) In the browser (e.g. Mozilla Firefox) go to Tools >Options> Privacy Tab.

 b) Click on "delete individual Cookies".

 c) Search for the Cookie named like this: ORA_FND_SESSION_<SID> where SID is that of the Database. Click on that entry.

d) Get the value between the ":". For example if it is DEFAULT_PILLAR:F5HySVWSzQpwy3pFeB+mdI0X9MW1UepPHLTQsF9nz74DW0vx5JBOf5T37kiXQRUh:1288091168031 the cookie name is F5HySVWSzQpwy3pFeB+mdI0X9MW1UepPHLTQsF9nz74DW0vx5JBOf5T37kiXQRUh

6. Get the Session ID using the following sql:SQL> select session_id from fnd_sessions where session_cookie = 'F5HySVWSzQpwy3pFeB+mdI0X9MW1UepPHLTQsF9nz74DW0vx5JBOf5T37kiXQRUh'

7. Look for the files with the above session id appended to them, in the directory given in the "Diag Trace" value from the following query:

SQL:> select * from v$diag_info

What is Applications Logging?

This option controls the output of debug log lines to files for investigating problems.  Much more detail can be found in the Fusion Applications Administrator's Guide, Chapters 13 and 17, and also in Note 1310286.1 - How To Get The Most From Fusion Applications Logging

When should I Enable All or just choose some?

Enabling everything might seem like an easy option, however can eat up resources, impact performance, and also general overwhelming volume of information to then have to sift through.  It is generally best to consult the Applications Administrator for advice and look carefully at both the problem and the feature and work out which troubleshooting feature is most likely to provide helpful information. As a very general rule, logging catches errors and tracing catches performance issues, however as a database-based application both operate together to provide user features.

Please refer metalink note (Doc ID 1317068.1) for more detail