Search Results msc_plan_partitions




Overview

The MSC_PLAN_PARTITIONS table in the MSC schema (Advanced Supply Chain Planning) stores partition information for planning plans in Oracle EBS 12.1.1 and 12.2.2. Each row captures the partitioning metadata associated with a plan, defining how plan data is segmented and identified within the planning engine. This object is central to the way Advanced Supply Chain Planning (ASCP) organizes and retrieves planning results across large data sets, and it is documented as VALID in the ETRM repository.

The heuristic Data Vault classification mined from the foreign-key structure is standalone, suggesting a modeling pattern where the table functions as an independent reference or hub-like object rather than a dependent satellite or a link between two other entities. In practice, this means MSC_PLAN_PARTITIONS can be modeled as its own primary entity keyed by PLAN_NAME, without assuming a mandatory parent dependency in the Data Vault sense.

Key Information Stored

The documented physical schema exposes 13 columns. The most significant are:

Note the distinction between the surrogate primary key (MSC_PLAN_PARTITIONS_PK on PLAN_NAME) and the unique business-key candidate (MSC_PLAN_PARTITIONS_U1 on PARTITION_NUMBER). Both must be honored in any integration or data-extraction logic.

Common Use Cases and Queries

Typical scenarios include identifying the partition layout for a given plan, verifying unused (free) partitions before initiating a new planning run, and reconciling partition metadata against plan execution history. A representative query to list partitions for a specific plan:

  • SELECT plan_name, plan_id, partition_number, free_flag FROM msc.msc_plan_partitions WHERE plan_name = :plan_name ORDER BY partition_number;
  • SELECT partition_number FROM msc.msc_plan_partitions WHERE free_flag = 'Y';
  • SELECT p.plan_name, p.partition_number, p.last_update_date, p.last_updated_by FROM msc.msc_plan_partitions p WHERE p.plan_id = :plan_id;

Reporting use cases include partition utilization reports, audit trails of partition creation by concurrent program (via REQUEST_ID and PROGRAM_ID), and data-cleanup scripts that purge partitions associated with obsolete plans.

Related Objects

Because the documented FK classification is standalone, no mandatory parent relationships are recorded. Nonetheless, in the MSC planning schema the following objects are commonly referenced alongside MSC_PLAN_PARTITIONS via PLAN_ID or PLAN_NAME:

These joins support both operational troubleshooting and historical analysis of planning partition lifecycles.