Search Results fnd_ts_mig_rules_pk

Overview

FND_TS_MIG_RULES is an Oracle E-Business Suite Applications Object Library (FND) configuration table owned by the APPLSYS schema. The name denotes "Tablespace Migration Rules," and the table stores the declarative ruleset that governs how database objects are assigned to tablespaces during tablespace migration, reorganization, and object-placement operations managed through the Oracle Applications DBA (AD) utilities. Each row encapsulates a migration rule expressed as a query and a target tablespace classification, allowing the EBS environment to map schemas, owners, and object types to specific tablespace types without hard-coding placement logic in the migration scripts.

The table is small and administrative in nature, holding nine documented columns. It is not transactional reference data used by end-user forms; rather, it is configuration metadata consumed by DBA-facing concurrent programs, AD utilities, and the AutoConfig/ADOP toolchain. In Oracle EBS 12.1.1 and 12.2.2 the object remains valid and is retained primarily for compatibility with tablespace migration and cloning procedures. From a heuristic Data Vault perspective, the mined relationship structure classifies FND_TS_MIG_RULES as satellite-leaning: it carries descriptive rule attributes keyed by a single surrogate identifier and is dependent on the tablespace classification reference table rather than acting as a transaction hub or an association link.

Key Information Stored

The table is anchored by the surrogate primary key RULE_ID, enforced through the FND_TS_MIG_RULES_PK constraint and mirrored by the unique index FND_TS_MIG_RULES_U1. RULE_ID is the sole business-key candidate documented; no natural composite key is defined, so RULE_ID serves simultaneously as surrogate and de facto business identifier. The most significant columns are:

• RULE_ID — numeric surrogate primary key uniquely identifying each migration rule.
• RULE_QUERY — the SQL fragment or query text that selects the database objects the rule applies to.
• TABLESPACE_TYPE — the classification of the target tablespace; participates in the foreign key to FND_TABLESPACES.
• OWNER — the schema or application owner to which the rule applies.
• LAST_UPDATE_DATE / LAST_UPDATED_BY — standard EBS audit columns capturing the most recent modification timestamp and the responsible user.
• CREATION_DATE / CREATED_BY — audit columns recording row creation.
• LAST_UPDATE_LOGIN — the login session identifier associated with the last change.

The first four columns define rule semantics; the remaining five are mandatory EBS audit/WHO columns common to nearly all FND configuration tables.

Common Use Cases and Queries

Typical usage centers on reviewing or validating the active ruleset before a tablespace migration, verifying that each rule points to a valid tablespace classification, and auditing who modified rules and when. A representative query joins the rule to its tablespace type:

SELECT r.rule_id, r.owner, r.tablespace_type, r.rule_query
FROM   applsys.fnd_ts_mig_rules r
WHERE  r.tablespace_type = :tablespace_type;

Investigation queries frequently filter on RULE_QUERY using a LIKE predicate to locate rules referencing a particular object or index naming pattern. Audit reporting extracts CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, and LAST_UPDATE_DATE to satisfy change-control evidence requirements. Because the table is configuration-related, reporting is generally read-only; changes are applied through supported migration utilities rather than direct DML.

Related Objects

The documented foreign key relationship is the primary integration point:

• FND_TABLESPACES — referenced via FND_TS_MIG_RULES.TABLESPACE_TYPE; the classification lookup governing valid tablespace types.
• FND_TS_MIG_RULES_PK — primary key constraint on RULE_ID.
• FND_TS_MIG_RULES_U1 — unique index providing the business-key candidate on RULE_ID.

Additional dependencies arise indirectly through the AD tablespace migration utility programs and AutoConfig templates that read this configuration, and through related FND configuration tables that share the standard WHO audit columns (CREATED_BY, LAST_UPDATED_BY referencing FND_USER). Administrators should treat FND_TS_MIG_RULES as read-only reference data and route all changes through the supported Oracle EBS migration and cloning procedures.