Search Results fnd_log_messages_pk

Overview

FND_LOG_MESSAGES is an APPLSYS-owned table in the FND (Application Object Library) product that stores debug log messages generated by the FND_LOG PL/SQL package. It is the physical repository behind the Oracle E-Business Suite logging and diagnostics framework introduced with the 11i/12.x technology stack. When a developer or administrator sets a logging level through profiles such as FND_LOGGING_ENABLED and FND_LOG_LEVEL, the FND_LOG API writes structured entries into this table. These entries capture runtime diagnostics, errors, and trace information for concurrent programs, OA Framework pages, forms sessions, and Java services across the EBS 12.1.1 and 12.2.2 releases.

From a Data Vault modeling perspective, the mined metadata classifies FND_LOG_MESSAGES as a standalone object. This heuristic suggests it functions as a satellite (or more precisely, a standalone log/event store) rather than participating in a conventional hub-and-link relationship. Because it has no documented foreign keys to other EBS tables, it is best modeled as a self-contained fact or satellite carrying descriptive attributes keyed by its own composite identifier.

Key Information Stored

The table contains 20 documented columns. Its primary key, FND_LOG_MESSAGES_PK, is a composite surrogate key over TIMESTAMP and LOG_SEQUENCE. Together these two columns provide a monotonically ordered identity for every message, which is essential because log volume is high and multiple sessions may write concurrently. No separate business-key unique index is documented; the two documented unique indexes are SYS_IL0000098862C00019$$ and SYS_IL0000098862C00020$$, which are LOB indexes tied to the CALLSTACK and ERRORSTACK columns rather than business keys.

• MODULE — the originating package, form, or component name that emitted the message.
• LOG_LEVEL — the severity threshold (e.g., STATEMENT, PROCEDURE, EVENT, EXCEPTION, ERROR, UNEXPECTED).
• MESSAGE_TEXT — the formatted message body written by FND_LOG.
• SESSION_ID, USER_ID, AUDSID — session and user context for the logged activity.
• TIMESTAMP — event time, the first half of the primary key.
• LOG_SEQUENCE — the second half of the primary key, ordering messages within a timestamp.
• NODE, NODE_IP_ADDRESS, PROCESS_ID, DB_INSTANCE — the application-tier and database-tier location of the writer.
• JVM_ID, THREAD_ID — Java and thread context for concurrent or middle-tier logging.
• ECID_ID, ECID_SEQ — Execution Context ID correlation identifiers used to trace a transaction across tiers.
• CALLSTACK, ERRORSTACK — LOB columns holding captured stack traces; note the ENCODED column that indicates whether these payloads are encoded.

Common Use Cases and Queries

The most common use is diagnostic troubleshooting: identifying errors for a given module, session, or concurrent request. A typical query filters by a time window and module:

• SELECT timestamp, log_sequence, log_level, module, message_text FROM apps.fnd_log_messages WHERE module = 'FND' AND timestamp > SYSDATE - 1/24 ORDER BY timestamp, log_sequence;
• Correlating a user's session across tiers: SELECT * FROM apps.fnd_log_messages WHERE user_id = :p_user AND session_id = :p_session ORDER BY timestamp;
• Aggregating error frequency by module and level for a health dashboard.
• Purging old rows, since the table can grow rapidly under verbose logging: a scheduled delete restricted by TIMESTAMP is standard practice.

Because FND_LOG writes only when logging is enabled at the appropriate level, administrators must first confirm the FND_LOGGING_ENABLED and FND_LOG_LEVEL profile settings before relying on query results.

Related Objects

The table is written to and read from through the FND_LOG package, which is the primary API for insertion. The logging configuration is driven by FND profiles (FND_LOGGING_ENABLED, FND_LOG_LEVEL) rather than foreign keys, which explains the absence of documented referential constraints. Related and commonly joined objects include:

• FND_LOG — the PL/SQL API that populates the table.
• FND_CONCURRENT_REQUESTS — joins on request or session context to tie log output to a concurrent program run.
• FND_SESSIONS / FND_LOGINS — joins on AUDSID or session identifiers to resolve user activity.
• FND_USER — joins on USER_ID to translate numeric user identifiers into names.
• FND_LOG_METADATA — where present, supplies module and logger registration metadata.

Because no FK constraints are documented, all relationships above are logical join paths inferred from shared column semantics rather than enforced referential integrity.