Search Results dpp_log_messages_u1

Overview

DPP.DPP_LOG_MESSAGES is a standalone diagnostic logging table in the Oracle E-Business Suite 12.1.1 and 12.2.2 environments. It resides in the DPP schema (Oracle Demand Planning / Advanced Planning products) and is explicitly documented as a repository used to log debug messages. Unlike transactional or master-data tables, its purpose is operational observability: capturing verbose runtime output generated by DPP programs and concurrent processes so that developers, DBAs and support analysts can trace execution paths, diagnose exceptions and validate data transformations.

The table is a simple two-column structure with a single-column numeric surrogate identifier. Its host tablespace, APPS_TS_NOLOGGING, reflects its ephemeral, high-volume nature: DML against the table is not intended to support point-in-time recovery, and the design prioritizes write throughput over durability. The heuristic Data Vault classification derived from the FK structure is standalone, and from a modeling perspective this object is best treated as a satellite-style detail table rather than a hub or link, because it records sequential descriptive attributes (debug text) against a monotonic sequence key rather than describing a business entity or a relationship between entities. There are no foreign keys inbound or outbound, so it participates in no referential integrity with the rest of the EBS data model.

Key Information Stored

The documented schema is deliberately minimal, containing two columns:

• LOG_ID (NUMBER) — The logical primary key column, described simply as "Log ID." It is populated as a monotonically increasing sequence value and serves as the surrogate identifier for each debug record. A primary key constraint, DPP_LOG_MESSAGES_PK, is documented on this column.
• LOG_MESSAGE (VARCHAR2(4000)) — The "Debug Log Message" payload. Its 4000-byte width is the standard pre-12c SQL VARCHAR2 limit, so callers should assume a single message cannot exceed that bound; longer diagnostics must be split across multiple rows or truncated by the writing code.

The unique index DPP_LOG_MESSAGES_U1 is defined as NORMAL, UNIQUE, on the single column LOG_ID, in the APPS_TS_NOLOGGING tablespace. Because it is the only documented unique index and covers exactly the same column as the primary key, LOG_ID is both the surrogate primary key and the sole documented business-key candidate; there is no separate natural or composite business key. Physical attributes are PCT Free 10 with no documented PCT Used value, consistent with append-only insert workloads.

Common Use Cases and Queries

The primary use case is post-mortem and live troubleshooting of DPP planning runs. Typical patterns include:

• Retrieving the most recent debug output: SELECT LOG_ID, LOG_MESSAGE FROM DPP.DPP_LOG_MESSAGES ORDER BY LOG_ID DESC;
• Pattern-matching for an error keyword, for example WHERE LOG_MESSAGE LIKE '%ORA-%' or WHERE UPPER(LOG_MESSAGE) LIKE '%ERROR%'.
• Correlating a session's activity by filtering on a context string embedded by the writing program.
• Housekeeping: because rows accumulate rapidly in a NOLOGGING tablespace, DBAs periodically purge old rows, for example DELETE FROM DPP.DPP_LOG_MESSAGES WHERE LOG_ID < :high_water_mark;, followed by a commit.
• Reporting on message volume over time by joining LOG_ID ranges to a run-timestamp reference table or by bucketing on insertion order.

Because no timestamp column is documented, temporal analysis must rely on LOG_ID ordering or on external run metadata; this is an important limitation to note when designing diagnostics dashboards.

Related Objects

The ETRM dependency data records that DPP.DPP_LOG_MESSAGES does not reference any database object, and that it is referenced by the synonym APPS.DPP_LOG_MESSAGES. Consequently, the APPS-side public synonym is the principal access path for SQL executed in the EBS application schema, allowing developers to write SELECT ... FROM DPP_LOG_MESSAGES without a schema qualifier, subject to grant availability. Beyond the synonym, no FK-based dependencies exist, so there are no join columns to other registries such as FND_LOG, FND_CONCURRENT_REQUESTS or DPP planning tables. Readers seeking richer diagnostic context should correlate LOG_ID sequences against concurrent program output files, FND log tables and DPP run-control tables maintained outside this object. The table's isolation is a design characteristic, not an omission: it exists solely to persist free-form debug text identified by a system-generated key.