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 preconfigured 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+mdI0X9MW1UepPHLTQsF9nz74DW
0vx5JBOf5T37kiXQRUh:1288091168031 the cookie name is
F5HySVWSzQpwy3pFeB+mdI0X9MW1UepPHLTQsF9nz74DW0vx5JBOf5T37kiX
QRUh
6. Get the Session ID using the following sql:
SQL> select session_id from fnd_sessions where session_cookie =
'F5HySVWSzQpwy3pFeB+mdI0X9MW1UepPHLTQsF9nz74DW0vx5JBOf5T37ki
XQRUh'
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