Results for “fnd_performance_data”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

FND_PERFORMANCE_DATA is a table owned by the APPLSYS schema within the FND - Application Object Library product of Oracle E-Business Suite. As documented in the ETRM metadata for release 12.1.1 and 12.2.2, its stated purpose is the storage of network performance test data. In practical terms, this table serves as a repository for diagnostic measurements collected by Oracle EBS utilities that assess the responsiveness of the application tier, the database tier, and the network path between them. Rows captured here are typically consumed by performance-tuning exercises, capacity assessments, and troubleshooting workflows rather than by transactional business processes.

The heuristic Data Vault classification supplied in the metadata identifies this object as standalone. Interpreted as a modeling suggestion, this implies the table behaves most like a satellite or a self-contained measurement fact: it holds descriptive attributes keyed by its own surrogate identifier and does not participate in the hub-and-link relationship structure that characterizes core EBS entities. No foreign-key dependencies to other EBS tables are documented, reinforcing its isolated, diagnostic character. The primary key constraint FND_PERFORMANCE_DATA_PK and the unique index FND_PERFORMANCE_DATA_U1 are both defined on the single column DATA_ID.

Key Information Stored

The documented physical schema for release 12.2.2 contains 36 columns. The most significant are described below.

• DATA_ID — The surrogate primary key and the sole documented business-key candidate (via unique index FND_PERFORMANCE_DATA_U1). All access paths to an individual measurement row resolve through this identifier. Because the user search term was "data_id," this column is the natural filter predicate for nearly every query against the table.
• D1 through D30 — Thirty generic, sequentially named data columns. Their meaning is positional and context-dependent, loaded by whatever performance-testing routine populated the row. Each Dn column holds a single measured or descriptive value, such as a timing figure, a throughput rate, a response-code, or an environment marker. Application code, rather than column names, carries the semantics.
• CREATION_DATE, CREATED_BY — Standard EBS audit columns recording when the measurement row was inserted and by which application user or process. CREATION_DATE is the primary discriminator for time-series analysis.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard EBS "who columns" capturing the most recent modification, its author, and the associated login session.

Notably, the table carries no documented foreign-key columns, no descriptive name column, and no explicit unit or test-type column, which confirms its design as a lightweight, workload-driven capture structure.

Common Use Cases and Queries

The principal use cases center on diagnostics and historical trend reporting.

• Retrieving a specific measurement by surrogate key:

  SELECT * FROM applsys.fnd_performance_data WHERE data_id = :data_id;

• Trending over time using the audit columns:

  SELECT data_id, creation_date, d1, d2, d3
  FROM   applsys.fnd_performance_data
  WHERE  creation_date >= SYSDATE - 30
  ORDER  BY creation_date;

• Correlating a measurement to the user who created it, joining CREATED_BY to FND_USER.USER_ID.
• Capacity and baseline comparison, aggregating D-column values across test runs to establish expected network latency or throughput profiles.
• Cleanup and retention, deleting rows older than a retention threshold to keep the diagnostic table compact.

Because the D1–D30 semantics are not encoded in the dictionary, any production-grade query should reference Oracle's supporting performance utility documentation to map each positional column to its measured quantity.

Related Objects

The metadata documents no foreign-key relationships, so the objects below are related by convention rather than by enforced constraint. The most significant are:

• FND_PERFORMANCE_DATA_PK — The primary key constraint on DATA_ID.
• FND_PERFORMANCE_DATA_U1 — The unique index on DATA_ID, serving as the documented business-key candidate.
• FND_USER — Joined on FND_PERFORMANCE_DATA.CREATED_BY = FND_USER.USER_ID to attribute measurements to originating users.
• FND_LOGIN_RESPONSIBILITIES / FND_LOGINS — Correlated on the LAST_UPDATE_LOGIN value to associate rows with a specific session.
• FND_CONCURRENT_REQUESTS — Referenced when the population of this table is driven by a concurrent program, correlating inserts to a request identifier.
• FND_APPLICATION — Provides the application context for the diagnostic utility that writes into the table.

Consumers should treat FND_PERFORMANCE_DATA as an internal, diagnostic object. Oracle does not document it as a supported integration surface, and direct dependence on it should be limited to read-only analysis of ETRM-documented structures.