Search Results fnd_ops_instances




Overview
Explore in AI Chat

Overview

FND_OPS_INSTANCES is a configuration table owned by the APPLSYS schema within the FND – Application Object Library product of Oracle E-Business Suite. Its documented purpose is to store the service name mapping for each Oracle Parallel Server instance. In practical terms, the table allows the EBS application tier to associate a numeric instance identifier with one or more service names, so that concurrent nodes participating in an Oracle Parallel Server (or Real Application Clusters) configuration can be resolved to the correct database service at runtime.

Under the heuristic Data Vault classification derived from the foreign key structure, FND_OPS_INSTANCES is best modeled as a link. This classification reflects the table's role as a connector between an instance identifier and the audit-oriented entities FND_USER and FND_LOGINS. It is not a pure hub, because the instance number does not represent an independent business subject in isolation, nor a pure satellite, because the table is responsible for binding the instance to its associated service names and status attributes.

The table is present in both the 12.1.1 and 12.2.2 ETRM documentation, with the 12.2.2 physical schema comprising 13 columns. Note that some columns, such as STATUS and SERVICE_NAME, are documented in the physical schema alongside PRIMARY_SERVICE_NAME and SECONDARY_SERVICE_NAME, reflecting evolving conventions across releases.

Key Information Stored

The table's primary key, FND_OPS_INSTANCES_PK, is defined on INSTANCE_NUMBER. A unique index, FND_OPS_INSTANCES_U1, is also defined on INSTANCE_NUMBER, confirming it as the business-key candidate that uniquely identifies each row. The most significant columns include:

  • INSTANCE_NUMBER – Surrogate primary key; the numeric identifier for the parallel server instance.
  • PRIMARY_SERVICE_NAME – The primary database service name mapped to the instance.
  • SECONDARY_SERVICE_NAME – The secondary service name available for the instance.
  • SERVICE_NAME – An additional service name attribute retained in the physical schema.
  • ENABLED – Flag indicating whether the instance mapping is active.
  • STATUS – Status indicator for the instance record.
  • DESCRIPTION – Free-text description of the instance mapping.
  • CREATED_BY / CREATION_DATE – Standard WHO column audit trail for row creation.
  • LAST_UPDATED_BY / LAST_UPDATE_DATE – Standard WHO column audit trail for the most recent update.
  • LAST_UPDATE_LOGIN – Links the last modification to a specific login session.
  • TIME_STAMP – Timestamp column supporting concurrency and synchronization checks.

Common Use Cases and Queries

Typical use of this table is diagnostic and administrative. DBAs and EBS administrators query it to verify how each parallel server instance is mapped to its service names and whether the mapping is enabled. A representative query retrieving enabled instance mappings follows:

  • SELECT INSTANCE_NUMBER, PRIMARY_SERVICE_NAME, SECONDARY_SERVICE_NAME, ENABLED, STATUS FROM APPLSYS.FND_OPS_INSTANCES ORDER BY INSTANCE_NUMBER;
  • SELECT INSTANCE_NUMBER, SERVICE_NAME, TIME_STAMP FROM APPLSYS.FND_OPS_INSTANCES WHERE ENABLED = 'Y';

Reporting scenarios include auditing the WHO columns to determine when an instance mapping was created or last changed, and joining to FND_USER to resolve the operator responsible for a change.

Related Objects

The foreign key relationships documented in the ETRM metadata establish the following dependencies:

  • FND_USER – Referenced via CREATED_BY and LAST_UPDATED_BY. Each instance mapping is attributed to the EBS user who created and last updated it.
  • FND_LOGINS – Referenced via LAST_UPDATE_LOGIN. This links the last update to the originating login session for audit traceability.
  • FND_OPS_INSTANCES_PK – Primary key constraint on INSTANCE_NUMBER.
  • FND_OPS_INSTANCES_U1 – Unique index on INSTANCE_NUMBER, reinforcing the business key.

Because the table participates in the standard FND audit framework through FND_USER and FND_LOGINS, its records are consistent with the broader Application Object Library auditing model and should be evaluated alongside those tables when performing instance-level configuration analysis.