Search Results related_run

Overview

FND_TRACE_UTILS is an Oracle E-Business Suite diagnostic utility package owned by the APPS schema and classified under the OTHER API category in ETRM. Its primary business function is to render and format the output of the PL/SQL hierarchical profiler for the benefit of developers and DBAs troubleshooting performance issues within an EBS environment. The package header comments identify it as FND_TRACE_UTILS, and the source carries the AFPMUTLB.pls version identifier, indicating its association with the Application Framework/performance monitoring layer rather than with a specific functional module.

The package is not a business application interface; it exposes no public API intended for functional transactions. Instead, it serves as a reporting harness that queries the profiler data dictionary views populated by DBMS_HPROF / DBMS_PROFILER activity and emits HTML-formatted output describing the aggregated execution profile of a related set of profiler runs. The parameter name RELATED_RUN is central to this object: the profiler tables permit multiple runs to be linked together under a common "related run" identifier, and FND_TRACE_UTILS consumes that identifier to consolidate timing data across all associated run IDs.

Key Procedures and Functions

The documented public procedure in this package is PLSQL_PROF_RPT. Based on the source excerpt, this procedure is the reporting entry point that drives the profiler summary output. Its logic is built around the RELATED_RUN parameter: it executes a dynamic SQL statement against PLSQL_PROFILER_UNITS and PLSQL_PROFILER_RUNS to compute a grand total of accumulated execution time, filtering runs by the supplied RELATED_RUN value. The procedure then writes an HTML table via the internal output helper, producing a "Grand Summary For Related Run" heading followed by one row per profiler run containing the Run ID, Date, Total Time in seconds, percentage of total, and Run Comment.

The header excerpt also reveals two supporting procedures, OL and DLOG, which are autonomous-transaction output helpers. OL writes a line to the concurrent program report output via FND_FILE.PUT_LINE to FND_FILE.OUTPUT, while DLOG writes to the concurrent program log via FND_FILE.LOG. Both are declared with PRAGMA AUTONOMOUS_TRANSACTION so that diagnostic lines are persisted independently of the calling transaction. Their presence confirms that the package is designed to operate in a concurrent-program execution context, where FND_FILE is available.

Tables Accessed

According to the ETRM metadata, the package references the following APPS synonyms: ALL_OBJECTS, ALL_TABLES, DUAL, and V$INSTANCE. ALL_OBJECTS and ALL_TABLES are used for metadata lookups — determining which database objects or tables are relevant to the profiling report. DUAL supports scalar computations such as the grand-total accumulation, and V$INSTANCE supplies instance-level identification, which is useful when profiler data spans multiple instances or must be attributed to a specific database instance. In addition to these documented synonyms, the procedure logic shown in the source directly queries the PLSQL_PROFILER_UNITS and PLSQL_PROFILER_RUNS views, which hold the raw timing and run-comment data consumed by the report. All access is read-only; the package does not modify profiler tables.

Usage Notes

FND_TRACE_UTILS is typically invoked as a diagnostic aid rather than from standard EBS forms. It is most often run from a concurrent program or a SQL*Plus session against the APPS schema after a PL/SQL profiling session has been configured and executed. Because the output helpers write to FND_FILE, the canonical invocation path is through the concurrent manager, where report output and log files are generated and retrievable. The RELATED_RUN parameter supplied by the caller ties together runs generated by a single instrumented session or related workload, allowing developers to obtain a consolidated timing summary. Since ETRM reports zero packages referencing this object, it is a terminal utility with no downstream dependents, and it should be treated as a developer/DBA tool for performance forensics rather than as a supported integration point. The 2005 revision header suggests the package has remained stable across the 12.1.1 and 12.2.2 releases.