Results for “fnd_oam_metalink_docs”

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

Overview

FND_OAM_METALINK_DOCS is a table owned by the APPLSYS schema within the FND (Application Object Library) product module of Oracle E-Business Suite. Its documented purpose is to store information about Metalink documents — the support knowledge base content historically delivered through Oracle Metalink and later My Oracle Support. In Oracle EBS 12.1.1 and 12.2.2, this table forms part of the Oracle Applications Manager (OAM) infrastructure that surfaces support-related documentation and diagnostic references directly within the EBS application tier.

The object is documented as VALID in the ETRM repository for 12.2.2, with a physical schema of ten columns. Its heuristic Data Vault classification is standalone, meaning the mined foreign-key structure shows no dependencies on other tables. As a modeling suggestion, this implies the table behaves functionally like a satellite or reference table that records descriptive attributes keyed by a single identifier, rather than acting as a hub or link in a formal Data Vault model. This classification reflects the absence of enforced foreign keys rather than a strict data warehousing design decision.

Key Information Stored

The table is anchored by the primary key constraint FND_OAM_METALINK_DOCS_PK, defined on the DOC_ID column. A unique index, FND_OAM_METALINK_DOCS_U1, also exists on DOC_ID, confirming it as the business-key candidate in addition to its role as the surrogate primary key. The documented columns include:

• DOC_ID — the unique identifier for each Metalink document record; serves as both primary key and unique-index column.
• TITLE — the descriptive title of the referenced Metalink document.
• DOC_LAST_UPDATE_DATE — the date on which the source Metalink document was last modified by Oracle.
• DOC_LAST_UPDATE_DETECTED_DATE — the date on which the EBS instance detected that the source document had changed, enabling synchronization tracking.
• UPDATE_SUMMARY — a textual summary describing what changed in the most recent document revision.
• CREATED_BY, CREATION_DATE — the standard EBS auditing pair recording who created the row and when.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard EBS auditing columns capturing the most recent row modification, the responsible user, and the login session identifier.

The table also documents a system-generated LOB index, SYS_IL0000319252C00009$$, which indicates that at least one column (commonly the ninth positional column, plausibly UPDATE_SUMMARY) is backed by a LOB segment. This reinforces that free-text content is stored alongside the metadata columns.

Common Use Cases and Queries

Typical use cases center on support diagnostics and content-refresh monitoring. Administrators and support analysts query this table to determine which Metalink documents have been detected as updated, and to review the update summaries. A representative query to identify recently detected document changes would select DOC_ID, TITLE, DOC_LAST_UPDATE_DATE, DOC_LAST_UPDATE_DETECTED_DATE, and UPDATE_SUMMARY, filtering on DOC_LAST_UPDATE_DETECTED_DATE within a recent date range and ordering by that column descending.

A second pattern compares the source update date against the detected date to measure synchronization lag — for example, computing the difference between DOC_LAST_UPDATE_DETECTED_DATE and DOC_LAST_UPDATE_DATE. Reporting use cases include auditing the freshness of support content surfaced to users, reconciling document titles against known My Oracle Support article numbers, and tracking who last updated a record via LAST_UPDATED_BY and LAST_UPDATE_DATE. Because the table is small and keyed by a single identifier, most queries are simple single-table retrievals with no joins required.

Related Objects

The ETRM metadata documents no foreign-key relationships for FND_OAM_METALINK_DOCS, consistent with its standalone Data Vault classification. Consequently, no join columns to parent or child tables are formally documented. Related objects that logically accompany this table within the same FND/OAM functional area include the other FND_OAM_* tables that store Oracle Applications Manager configuration and content metadata under the APPLSYS schema, together with the OAM application-tier views and concurrent programs that populate and refresh Metalink document information. Because the supplied metadata records the table as standalone, any cross-object joins should be treated as application-level relationships rather than database-enforced constraints, and should be validated against the specific 12.1.1 or 12.2.2 instance before reliance. The primary key FND_OAM_METALINK_DOCS_PK and unique index FND_OAM_METALINK_DOCS_U1 remain the authoritative access paths for this table.