Search Results eam_asset_failures_u2




Overview

EAM.EAM_ASSET_FAILURES is a transactional table in the Oracle E-Business Suite Enterprise Asset Management (EAM) module. It stores failure events reported against an asset within the context of a business flow — most commonly during the lifecycle of a work order. Each row captures a point-in-time snapshot of the asset, the source object against which the failure was logged, and other key asset attributes as they existed at the moment of failure reporting.

In Oracle EBS 12.1.1 and 12.2.2, failure entry is recorded at the work order level. The SOURCE_TYPE column is restricted to a value of 1, which corresponds exclusively to Work Order. This means failures cannot currently be logged against other source objects, and the table functions as a normalized, denormalized-enriched record of asset reliability events tied to maintenance execution. The physical storage resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10.

The metadata does not assign a formal Data Vault classification; however, the documented structure — a single unique failure identifier plus foreign key references to departments and functional areas — suggests a satellite-style modeling approach, where the failure event is an immutable, auditable fact keyed to a hub asset identifier.

Key Information Stored

The most significant columns include:

The primary key is FAILURE_ID; SOURCE_ID is a documented alternate unique (business-key) candidate via EAM_ASSET_FAILURES_U2. A non-unique index, EAM_ASSET_FAILURES_N1, exists on OBJECT_ID to support asset-centric lookups.

Common Use Cases and Queries

Because the table drives asset reliability reporting, common scenarios include MTBF/MTTR calculations, root-cause analysis by department or area, and work order failure trending. Analysts typically join to work order tables via SOURCE_ID and to asset masters via OBJECT_ID.

Representative query patterns include: retrieving all failures for a given asset using WHERE OBJECT_ID = :asset_id; aggregating failures by department with WHERE DEPARTMENT_ID = :dept_id; or grouping failures by month using FAILURE_DATE. A sample join to failure codes is shown below:

  • SELECT f.FAILURE_ID, f.FAILURE_DATE, f.OBJECT_ID FROM EAM.EAM_ASSET_FAILURES f WHERE f.OBJECT_ID = :p_asset_id ORDER BY f.FAILURE_DATE DESC;
  • SELECT f.DEPARTMENT_ID, COUNT(*) FROM EAM.EAM_ASSET_FAILURES f GROUP BY f.DEPARTMENT_ID;
  • SELECT f.FAILURE_ID, c.FAILURE_CODE FROM EAM.EAM_ASSET_FAILURES f JOIN EAM.EAM_ASSET_FAILURE_CODES c ON c.FAILURE_ID = f.FAILURE_ID;

Related Objects

The table participates in a compact but important set of referential relationships documented in ETRM metadata:

  • EAM.EAM_ASSET_FAILURE_CODES — Child table referencing EAM_ASSET_FAILURES.FAILURE_ID, storing failure code assignments per failure event.
  • BOM.BOM_DEPARTMENTS — Referenced via DEPARTMENT_ID, providing department attribution.
  • PAY.PAY_FUNCTIONAL_AREAS — Referenced via AREA_ID, providing area or location attribution.
  • WIP entities (via SOURCE_ID) — SOURCE_ID maps to the WIP entity ID when SOURCE_TYPE = 1, linking each failure to the originating work order.
  • MTL_SERIAL_NUMBERS — The asset identified by OBJECT_ID is sourced from the generic object identifier in MTL_SERIAL_NUMBERS.

Together these objects support end-to-end failure tracking from work order execution through reliability reporting within Oracle EAM.