Results for “fnd_perf_variables”

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

Overview

FND_PERF_VARIABLES is a configuration repository table owned by the APPLSYS schema within the FND – Application Object Library product. Its name indicates that it stores performance-related variable definitions used by the Oracle E-Business Suite runtime environment, likely consumed by framework components that tune behavior based on administrator- or system-defined settings. The table resides in the APPLSYS schema alongside other core FND infrastructure objects and is documented as valid in both ETRM 12.1.1 and 12.2.2 releases.

The ETRM extract carries the annotation "- Retrofitted," indicating that the object's documentation was added to the repository after an earlier documentation gap, and that the metadata presented reflects a retrospective capture rather than an original design specification. From a Data Vault modeling perspective, the heuristic classification mined from the FK structure is standalone. This suggests the table functions as an independent reference or configuration hub, with no documented foreign-key relationships to other tables. Analysts modeling this source should treat it as a self-contained entity and validate any implied dependencies manually, since the classification is heuristic rather than authoritative.

Key Information Stored

The documented physical schema contains seven columns, with VARIABLE serving as the business-meaningful identifier and the primary key.

• VARIABLE – The primary key column (enforced by FND_PERF_VARIABLES_PK). Holds the name or identifier of each performance variable. Because it is both the sole PK column and the natural business key, there is no separate surrogate sequence column in the documented schema.
• VALUE – Stores the configured value assigned to the corresponding VARIABLE. This is the operative payload of the table and the column most frequently read at runtime.
• CREATION_DATE – Audit timestamp recording when the row was first inserted.
• CREATED_BY – Standard EBS audit column identifying the user or process that created the row.
• LAST_UPDATE_DATE – Audit timestamp of the most recent modification.
• LAST_UPDATED_BY – Identifies the user or process responsible for the latest update.
• LAST_UPDATE_LOGIN – Captures the login session associated with the last update, supporting traceability in a multi-user environment.

The presence of the full EBS audit column set (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) indicates that changes to performance variables are trackable, but the table does not itself retain history rows. Current state is the only state stored.

Common Use Cases and Queries

Typical usage involves inspecting or verifying the values that govern runtime behavior, comparing configuration across environments, and auditing who last changed a setting.

• Retrieve a specific variable: SELECT variable, value FROM applsys.fnd_perf_variables WHERE variable = :name;
• List all configured variables with their audit trail: SELECT variable, value, last_update_date, last_updated_by FROM applsys.fnd_perf_variables ORDER BY variable;
• Identify recently changed entries: SELECT variable, value, last_update_date, last_updated_by FROM applsys.fnd_perf_variables WHERE last_update_date > SYSDATE - 30;
• Environment comparison: extract VARIABLE and VALUE from each instance and diff the result sets to detect drift between development, test, and production.
• Audit reporting: join LAST_UPDATED_BY against FND_USER to translate the numeric user identifier into a user name for change-management reporting.

Because the table is small and read frequently at startup, queries should generally avoid full scans in hot paths and instead target the VARIABLE primary key.

Related Objects

The ETRM relationship data classifies FND_PERF_VARIABLES as standalone, meaning no foreign-key constraints link it to other tables. Related objects are therefore inferred from naming convention, schema co-location, and the audit column conventions:

• FND_USER – Not an enforced FK, but the conventional join target for CREATED_BY and LAST_UPDATED_BY to resolve user identities.
• FND_CONCURRENT_PROGRAMS and FND_CONCURRENT_REQUESTS – Framework objects whose runtime behavior may be influenced by performance variables set here.
• FND_PROFILE_OPTIONS and FND_PROFILE_OPTION_VALUES – Sibling configuration tables in APPLSYS; useful for cross-referencing whether a given setting is profile-driven or variable-driven.
• FND_APPLICATION – Identifies the owning FND application context for reporting purposes.
• FND_PERF_VARIABLES_PK – The primary key constraint itself, referenced by any index-based access path on VARIABLE.

Because no referential integrity is documented, integrators should treat this table as an independent configuration source and confirm dependencies against FND framework code rather than assuming database-enforced relationships.