How To Manage APS Partitions in the MSC Schema

Rev 2.4.5.3 - See revision notes at end

Printer Friendly PDF file click here

Contents
Contents 1 PURPOSE 2 Section One 3 Section Two 3 I. Terminology 3 II. What Are APS Partitions 6 SQL #1 7 Notes 8 III. Drop Partition or Drop Plan Partition & Create APS Partitions Concurrent Requests 8 Drop Partition or Drop Plan Partition 8 Create APS Partition 9 IV. Operational Data Store - ODS 10 ODS Tables and Instance Partitions 10 SQL #2 10 SQL #3 10 V. Planning Data Store - PDS 11 PDS and Plan Partitions 11 SQL #4 12 SQL #5 13 VI. ODS & PDS Data 14 VII. The Profile Option MSC: Share Plan Partitions 15 VIII. Basic Performance Tuning for MSC Partitions 16 IX. Setup the Instance and First Run of Data Collection 17 Section Two 19 X. ODS - ODS Data Cleanup - Dropping old ODS partition / Create and Setup a New Partition 20 XI. Moving the APS Installation from a Centralized to a Decentralized Installation 21 Back to Top 22 XII. PDS - Converting From Shared Plan Partitions to Individual Plan Partitions 22 XIII. PDS - Conversion From Individual Plan Partitions to Shared Plan Partitions 23 XIV. Your Instance has become corrupted beyond repair 23 XV. Advanced Cloning - Attempts to preserve data that has been setup on the APS Destination Instance 24 Appendix A - SQL References 26 SQL #1 26

SQL #2 SQL #3 SQL #4 SQL #5 SQL #6 SQL #7 SQL #8 SQL #9 SQL #10 SQL #11 - DO NOT USE FOR 11.5.10 AND ABOVE SQL #12 - DO NOT USE FOR 11.5.10 AND ABOVE SQL #13 For ODP data SQL #14 For ODP data SQL #15 For ODP data Appendix B List of APS Partitioned Tables 33 Summary List of Partitioned Tables The MV Partitioned Tables SQL #1a Complete Table Listing SQL #1b 1st List - Default Installation - 11.5.9 2nd List - MSC: Share Plan Partition = Yes - 11.5.9 Appendix C - References 43

27 27 27 28 28 29 29 30 30 30 31 32 32 33 33 36 37 37 38 38 41

PURPOSE
@ the old note is available internally as Note:257508.1

This note should allow Support Engineers, Users and DBAs to better understand and implement the Advanced Planning and Scheduling (APS) application. Understanding how partitions are handled in APS is a key factor to a successful implementation and ongoing maintenance of the application. This note is a major revision of both Note 174500.1 and Note 137293.1. The notes have been combined, retested under 11.5.9 and revised with the latest information available. Sep 2006 - general review and edit - minor updates for 11.5.10, updated for SNO/PS integration, preliminary review for 12.0 Disclaimer: This information is presented as is and Oracle does not warrant this information fit for any use. The note is divided into two Sections:

Section One
Understand the implementation of partitioning within the MSC schema. Understand the implications of profile MSC: Share Plan Partitions. Comprehend the diagnostics required to maintain MSC partitions. Basic Performance Tuning of MSC Partitions I. II. III. IV. V. VI. VII. VIII. IX. Terminology What Are APS Partitions Drop Partition or Drop Plan Partition & Create APS Partitions Concurrent Requests Operational Data Store - ODS Planning Data Store PDS ODS & PDS Data The profile option MSC: Share Plan Partitions Performance Tuning for MSC Partitions APS Partition Facts

Section Two
How to manipulate the partitions in the MSC Schema for various purposes such as: X. The ERP Source instance has changed and the ODS data and partition needs to be reset. Cloning an APS instance and converting from one source instance to a new source instance is the primary example. XI. Converting from a single, centralized APS configuration to a Distributed configuration using separate servers for the ERP and APS instances, partition and data clean up steps. XII. Converting from individual plan partitions to a shared plan partition, the individual plan partitions should be removed. XIII. Converting from shared plan partition to individual plan partitions, it is necessary to drop the shared plan partition. XIV. The install has been corrupted to the point of no recovery, partition clean up or partition deletion and recreation may be required. XV. Advanced Cloning - Attempts to preserve data that has been setup on the APS Destination Instance Appendix A - SQL References Appendix B List of the APS Partitioned Tables Appendix C References Back to Top

I. Terminology

Advanced Planning and Scheduling Suite - APS The APS Suite which can include Advanced Supply Chain Planning (ASCP), Global Order Promising (GOP), Oracle Demand Planning (ODP), Collaborative Planning (CP - 11.5.8 and above), Transportation Planning (TP - 11.5.10 and above), integrations to Strategic Network Optimization (SNO) and Production Scheduling (PS) - available in 11.5.10 and above - and integration to Demantra to be released in 2007. Centralized Configuration A Centralized Configuration means only one instance is involved. This is usually used for ATP based on Collected data. This means that the ERP Source data and the APS Destination data are stored in one instance. Patching a centralized configuration is simpler since all patches are applied to the same instance. All patches for the APS suite contained detailed instructions for patching between Centralized and Distributed instances. For a centralized instance, apply all patches on the one instance. Decentralized or Distributed Configuration A Decentralized Configuration means there are two or more instances involved. These instances (one or more ERP Source instances and an APS Destination instance) speak to each other via database links. This will mean that the ERP Source and APS Destination instances are located on separate boxes. This configuration is generally used when all or part of the APS suite is being used. Read patch readme notes carefully to apply patches to the correct instance. Some patches are always applied to both instances (GOP and Data Collections) and others are only applied to the APS Destination (ASCP Engine/UI patches) but may have ERP Source patches that are also required and are listed in the patch readme. Operation Data Store ODS The ODS stores the data that collected from the ERP Source Instance. This is the ERP Source data that is stored in the tables of the MSC Schema under the PLAN_ID = -1. It is kept in an Instance Partition. This data is used to feed an ASCP Plan OR for ATP based on Collected Data. The same tables are used for both ODS and PDS and are segregated by the plan_id and also by the partition where they are stored. Planning Data Store PDS Created when an Advanced Supply Chain plan is run and is stored in the MSC Schema under a PLAN_ID > 0. This is kept in a Plan Partition. The same tables are used for both ODS and PDS and are segregated by the plan_id and also by the partition where they are stored.

Instance Partition or ODS Partition The Collected Data that is used for APS is stored in a partition where the partition_name has a double-underscore__number e.g. MSC_SYSTEM_ITEMS__21 Each ERP Source Instance requires a separate Instance Partition. Plan Partition or PDS Partition The Planning data created when an Advanced Supply Chain plan is run and is stored in a partition where the partition_name has a single-underscore_number e.g. MSC_SYSTEM_ITEM_1 Each ASCP Plan requires its own Plan Partition unless the profile MSC: Share Plan Partition = Yes. MSC: Share Plan Partition Profile Option Default setting = No. This means that each ASCP Plan requires a Plan Partition to store the output of a planning run. When Yes, then the partition _999999 will be created when Create APS Partitions request is run. Then all plans will store their planning data under this single partition. This would be useful if the customer has a large number of plans. Generally speaking, more than 15 plans are considered a large number. Note: In later releases, 11.5.8 and above with 9i RDBMS or higher, we do NOT recommend the use of Shared Plan partition. Data Collections The process of collecting data from the ERP Source transactional instance (or schemas) and gathering data in a recognizable form in the APS Destination instance/schema. The Source ERP information is stored in the product schemas (INV, OM, BOM, WIP, MRP, PO, etc.) and collected to the MSC Schema for ASCP and also for GOP and CP. There are three steps to this process Refresh Snapshots - This process always runs only on the ERP Source instance when Distributed installation Planning Data Pull - Moves the data from the ERP Source schemas INV, WIP, BOM, PO, OM, etc to the MSC_ST% staging tables ODS Load - This process does data cleansing and manipulation and then loads from the MSC_ST% staging tables to the MSC Base tables. For ODP, information is collected to the MSD schema where the Demand Planning specific information is stored. These processes are run from the Demand Planning System Administrator responsibility. Some of the data in the MSC schema is used as well as the MSD specific data. The ODP process Setup Data Collections is the same process as standard Data Collections in ASCP. The other collections processes in ODP are MSD specific.

Advanced Planning Administrator Starting in 11.5.8 or 11iSCP_PF.H, this new responsibility was introduced to handle Organization Security and the admin needs of Collaborative Planning. This is where the Instance Partition created by the system is assigned to be used for Data Collections and ASCP. This was formerly under Advanced Supply Chain Planner / Setup / Instances. Other features are also available under this responsibility. APS Tablespaces - MSCD and MSCX The default tablespaces for APS are MSCD for data and MSCX for indexes. These tablespaces and the tables within should be examined at each step of the implementation to make sure that they are sized appropriately and help prevent ORA errors during Data Collections or APS Plannning. Note 220115.1 Managing MSCD and MSCX Tablespaces for APS Implementations has been created to help DBAs understand more about how space is consumed in APS tablespaces. In 11.5.10, the base installation uses a new tablespace model - OATM - which reduces the number of tablespaces for the applications and the tablespace name will be different. OATM can also be installed separately from a fresh installation of the application. Back to Top

II. What Are APS Partitions

Partitions are used in APS to segregate data. This improves overall performance because the data can be manipulated separately by partition. APS uses partitions for some of the data that is needed by the Operational Data Store (ODS) and the Planning Data Store (PDS). 1. The same tables are generally used for both ODS and PDS data and are segregated by the plan_id and also by the partition. 2. The number of partitioned tables will vary depending on the Family Pack level of your system. 3. The ODS is the destination of collected data. a. After Data Collections has completed successfully, the partitioned data will be inserted into ODS Instance Partition and other tables that are not partitioned. b. These rows have a plan_id = -1 c. If several Oracle instances are collected, instance data will be stored in individual ODS Instance Partitions. d. Additionally, the tables contain a column called SR_INSTANCE_ID or INSTANCE_ID. This reveals the ERP Source instance where the data originated. 4. The PDS is the destination of ASCP Planning data.

a. After an ASCP plan has completed successfully, the data will be inserted into the PDS Plan Partition and other tables that are not partitioned. b. These rows have a plan_id > 0 c. In the default setup, each plan will have its own Plan Partition. d. Additionally, the tables contain a column called SR_INSTANCE_ID or INSTANCE_ID. This reveals the ERP Source instance where the data originated. 5. Default installation of APS creates 1 Instance Partition, and 5 Plan Partitions. They can be viewed using SQL #1 SQL #1
-- Run this from SQL*Plus the column HIGH_VALUE is column type LONG and will not format correctly in a spreadsheet set lines 200 set colsep | spool SQL-1_137293.1.txt SELECT table_name, partition_name, num_rows, high_value, sample_size, last_analyzed, global_stats FROM all_tab_partitions WHERE table_name like 'MSC%' order by substr(partition_name,instr(partition_name,'_',1,1)+1) -- To check the partition count of each table use order by table_name, partition_name spool off

This table shows the Default installation for one table MSC_SYSTEM_ITEMS. (use where table_name like 'MSC_SYSTEM_ITEMS' for the above SQL) For a full list of tables, see Appendix B.
TABLE_NAME MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS PARTITION_NAME SYSTEM_ITEMS_0 SYSTEM_ITEMS__1 SYSTEM_ITEMS_1 SYSTEM_ITEMS_2 SYSTEM_ITEMS_3 SYSTEM_ITEMS_4 SYSTEM_ITEMS_5 Comments The Template partition NEVER DELETE PARTITION Instance Partition #1 Plan Partition #1 Plan Partition #2 Plan Partition #3 Plan Partition #4 Plan Partition #5

We can easily identify the ODS partition based upon the double underscore '__' in the partition_name. See SYSTEM_ITEMS__1. This partition has been reserved for instance_id 1 (collected data will have value of 1 in column sr_instance_id and 1 for column plan_id). The Plan Partitions have a single underscore, SYSTEM_ITEMS_1 through SYSTEM_ITEMS_5, will be used to store PDS plan data. IF the setup desired is to have MSC: Share Plan Partition = Yes, THEN follow the steps of XIII. PDS - Conversion From Individual Plan Partitions to Shared Plan Partitions. After completion, the table for MSC_SYSTEM_ITEMS would be as follows. All the original plan partitions would be removed and only _999999 would remain. The ODS partition __1 is still avail 23able. Note: In later releases, 11.5.8 and above with RDBMS 9i and above, we do NOT recommend the use of Shared Plan partition.

TABLE_NAME MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS

PARTITION_NAME SYSTEM_ITEMS_0 SYSTEM_ITEMS__1

Comments The Template partition NEVER DELETE THIS PARTITION Instance Partition #1

SYSTEM_ITEMS_999999 Shared Plan Partition 999999

Notes
1. If there is a drastic mistake made during the manipulation of ODS/PDS data, please keep in mind that this data is either source data, as in the case of the ODS, or plan data, as in the case of PDS. The ODS data can be recollected and the PDS data can be reproduced by submitting the ASCP plan. 2. If the template (or base) partition_0 is accidentally dropped, then the best step is to restore the instance from a backup and start over.

III. Drop Partition or Drop Plan Partition & Create APS Partitions Concurrent Requests
Drop Partition or Drop Plan Partition
NEVER Drop the _0 or Template Partition. This will cause the instance to fail and it will have to be restored from a backup or reinstalled.

Starting in 11.5.9, Drop Partition is available and can drop either a Plan partition or an Instance partition. Set parameter Plan to Yes will drop a Plan partition and set to No will drop an Instance partition. In 11.5.6 - 11.5.8 only Plan partitions may be dropped and the request is called Drop Plan Partition. See SQL below to manually drop an Instance Partition. Notes: There may be an error about default values when attempting to enter the Parameters for the request in 11.5.9. It may be ignored. Press OK and continue. IF dropping a Plan Partition, THEN the Plan needs to be purged BEFORE dropping the partition. In the Names screen, hit Delete icon and then save, to start the purge process. Dropping the Instance Partition does not remove all the data that has been collected for that instance_id. The SQL to delete all the remaining APS data is found under SQL #6 and SQL #7 The Drop Partition or Drop Plan Partition request must be added to the All MSC Reports request group. o System Administrator NAV: Security / Responsibility / Request o Query for the Group %MSC% to retrieve All MSC Reports o Highlight a line and press the add icon. o For the field Name, choose Drop Partition (11.5.9 and above) or Drop Plan Partition (11.5.8 and below) from the lookup values. o Save your work. SQL #8 and SQL #9 will perform the same actions as the request. Use SQL #9 to drop an Instance Partition..

Create APS Partition

This request is run from the System Administrator responsibility OR the request may have been assigned to All MSC Reports, which means it can be run from either Advanced Supply Chain Planner OR Advance Planning Administrator (11.5.8 and above). The parameters are: 1. Plan partition count which creates Plan Partitions which store the PDS data created when an ASCP Plan is run 2. Instance partition count which creates Instance Partitions to gather ODS data from an ERP Source Instance . IMPORTANT NOTE: Create and maintain the minimum number of partitions needed for your system. Empty partitions can cause performance issues within the application. Drop any extra partitions that are not needed. Back to Top

IV. Operational Data Store - ODS

ODS Tables and Instance Partitions
The ODS partitioned tables have __nn (double underscore) as shown below Appendix B has a complete lists of the tables.
TABLE_NAME MSC_SUPPLIES PARTITION_NAME NUM_ROWS SAMPLE_SIZE LAST_ANALYZED GLOBAL_STATS 14700 1470 10/21/2003 15:08 YES SUPPLIES__21

ODS partitions are created using the sequence MSC_APPS_INSTANCES_S and are visible in the table MSC_INST_PARTITIONS SQL #2 -- Free_flag 1 = Free 2 = In use
select instance_id, free_flag, creation_date, last_update_date msc_inst_partitions;

from

INSTANCE_ID 21 61 81 101

FREE_FLAG CREATION_DATE LAST_UPDATE_DATE 2 5/8/2000 0:40 5/8/2000 0:40 2 1/25/2002 11:28 1/25/2002 11:28 2 10/14/2002 13:44 10/14/2002 13:44 1 9/17/2003 23:34 9/17/2003 23:34

In this table we can see that instance_id 101 has been created and still has free_flag = 1, which means it can be assigned to a new instance for data collections.

Once a partition has been assigned to an ERP Source Instance using the Instance Setup form, the FREE_FLAG = 2 and a line is inserted into MSC_APPS_INSTANCES. SQL #3 -- ST_STATUS 0 = No source pull or collection is in process 1 = Pull and collection process has begun 2 = Collection has ended and waiting for load to begin 3 = Load has begun 4 = Load has ended and staging tables are being purged

select

instance_code, instance_id, apps_ver, a2m_dblink, m2a_dblink, st_status from msc_apps_instances A2M_DBLINK M2A_DBLINK ST_STATUS 0 0 0

INSTANCE_CODE INSTANCE_ID APPS_VER TST 21 3 LEG 61 -1 V86 81 3

APS

visus86

Here we see that TST is assigned to the local Centralized ERP instance. That is why a2m_dblink and m2a_dblink are NULL V86 is assigned to another 11i Instance (apps_ver = 3) on another box and dblinks were created and populated in the Instance Setup form so that the connection could be made for Data Collections and other operations to be successful. See IX. Setup of an ODS Instance for Data Collection for more information on this process. LEG is for Custom Collections from a non-Oracle data source (apps_ver = -1). This would be when all data is being populated from an external system using Legacy Collections. The ODS data can be identified by the plan_id. For ODS data, this is always -1. When more than once instance is being collected, differentiate this data by the SR_INSTANCE_ID or INSTANCE_ID column in the table. See INSTANCE_ID column above for the number. All Columns beginning with SR% in the MSC tables refer to a value obtained from the ERP Source Instance. (e.g. sr_instance_id, sr_inventory_item_id) IF you have cloned an instance and have to link to a new source instance, THEN the data from the old instance can cause constraint errors in certain tables and should be removed before running Data Collection for the new instance X. ODS ODS Data Cleanup - Dropping old ODS partition / Create and Setup a New Partition 20

V. Planning Data Store - PDS

PDS and Plan Partitions
The partitioned tables also have partitions for each plan and they have _nn (single underscore) as shown below Appendix B has a complete list of the tables.
TABLE_NAME MSC_SUPPLIES PARTITION_NAME NUM_ROWS 900 SUPPLIES_347

SAMPLE_SIZE LAST_ANALYZED GLOBAL_STAT 90 10/17/03 6:28 PM YES

The plan_id and partition_number are controlled by the sequence MSC_PLANS_S The PDS plan_id is identified by selecting the plan_id from MSC_PLANS SQL #4 Plan Type the following: 1 Manufacturing Plan 2 Production Plan 3 Master Plan 4 Inventory Plan 5 Distribution Plan (R12 and up) 6 SNO Schedule (11.5.10 and R12.0.4 and up) 7 PS Schedule (11.5.10 and R12.0.4 and up)
select mp.COMPILE_DESIGNATOR "Plan Name", mp.PLAN_ID "Plan ID", mp.SR_INSTANCE_ID "Instance ID", mtp.ORGANIZATION_CODE "Owning Org", mp.PLAN_COMPLETION_DATE "Last Run Date", decode (mp.PLAN_TYPE, 1, 'Manufacturing MRP', 2, 'Production MPS', 3, 'Master MPP',4,'IO Plan', 5, 'Distribution Plan' , 7, 'PS Production Schedule', 6, 'SNO Schedule') "Plan Type", decode (md.PRODUCTION,1, 'Yes', 2, 'No', NULL, 'No') "Production Flag", decode (md.LAUNCH_WORKFLOW_FLAG,1, 'Yes', 2, 'No', NULL, 'No') "Launch Workflow", decode (md.INVENTORY_ATP_FLAG,1, 'Yes', 2, 'No', NULL, 'No') "ATP Plan", mp.CURR_START_DATE "Start Date", mp.CUTOFF_DATE "End Date" from msc_designators md, msc_plans mp, msc_trading_partners mtp where md.designator=mp.compile_designator and md.sr_instance_id=mp.sr_instance_id and mtp.sr_instance_id=mp.sr_instance_id and md.sr_instance_id=mtp.sr_instance_id and mtp.sr_tp_id=md.organization_id and mtp.sr_tp_id=mp.organization_id and mp.organization_id=md.organization_id and mtp.partner_type = 3 ORDER BY "Plan Name";
Plan Name JMCVCONALT JMESL80 JMMRPSHRK JMPROD JMUNCSS Plan ID Instance ID Owning Org Last Run Date 5759 6759 11758 21758 14759 64 BOB:D2 64 BOB:M1 64 BOB:S1 64 BOB:M1 64 BOB:M1 Plan Type Production Flag Launch Workflow No No No No No No No No No No ATP P No No No No No 3/21/2007 3:54 Manufacturing MRP 8/8/2006 14:11 IO Plan 6/1/2006 15:09 Master 3/6/2007 1:39 Production MPS 7/13/2006 17:03 Master

SQL #5 MSC_PLAN_PARTITIONS shows how planning partitions are being used when the profile MSC: Shared Plan Partition = No When the profile MSC: Shared Plan Partition = Yes, then NO lines should appear in MSC_PLAN_PARTITIONS. **
select plan_id, plan_name, free_flag, partition_number msc_plan_partitions

from

PLAN_ID 347 391 411

PLAN_NAME DG-APS1 PRN_SCP 411

FREE_FLAG 2 1 1

PARTITION_NUMBER 347 391 411

The example above shows that: o DG-APS1 is a plan that is being used - free_flag = 2 o PRN_SCP is a plan that has been purged, but a new plan has not been defined that uses that partition_number. The plan name will be replaced when a new plan AND the plan options have been defined. o Plan name 411 is a new partition created by the Create APS Partitions request and has never been used. o This means that 2 new plans could be defined in the Names form in ASCP and AFTER the Plan Options are defined and saved, then this table will be updated with the plan name and the free_flag = 2. o IF no rows with free_flag = 1 are returned, THEN you may still create the new plan in the Names form, BUT when attempting to define the Plan Options and Save them, an error will be received similar to No free partitions available, Contact the DBA to create partitions 1. This is because the Names form only inserts into the table MSC_DESIGNATORS. 2. When Plan Options are defined, then the process checks MSC_PLAN_PARTITIONS and updates the free_flag and plan_name. 3. The tables inserted/updated are MSC_PLANS, MSC_PLAN_ORGANIZATIONS, MSC_DESGINATORS and MSC_SUBINVENTORIES. o Use the concurrent request Create APS Partitions with parameters inst_partition_count = 0 and plan_partition_count = 1 to create a new plan partition. In 11.5.10 and above, this parameters are named Plan partition count and Instance partition count ** NOTE: In earlier versions, SQL #5 may return one line with PARTITION_NUMBER 999999. In recent testing in 11.5.6 and above, this line was not present in the table.

Back to Top

VI. ODS & PDS Data

Data within the ODS and PDS is identified by sr_instance_id (or instance_id) and plan_id. Rows with a plan_id = -1 belong to the ODS and if more than one Source ERP instance is being used, can further be isolated by using sr_instance_id. Rows with a plan_id >0 belong to the PDS and can also be isolated by using sr_instance_id Consider the following SQL: All rows within MSC_SYSTEM_ITEMS, this includes all partitions.
select from COUNT(*) 6876 count(*) msc_system_items;

This SQL shows the rows and the plan_id as well as the sr_instance_id where these rows originated
count(*), sr_instance_id, plan_id from msc_system_items group by sr_instance_id, plan_id COUNT(*) 3132 2931 56 1 10 36 2 2 5 1 10 43 108 6 376 115 SR_INSTANCE_ID PLAN_ID 21 -1 81 -1 81 147 81 148 21 149 21 181 81 183 81 184 21 221 81 222 21 224 21 263 21 283 21 303 21 323 21 325 select

24 9 9

21 81 81

347 347 349

As you can see from the queries above, we have collected from the TST and V86 instances, instance_id 21 and 81 respectively. This ODS data resides under plan_id 1. We have not yet loaded any legacy data for instance_code LEG, instance_id 61. Additionally, several plans have been run and items populated according to those plans. Note that plan_id 347 was run against ODS data collected from both instances, therefore this plan_id is listed twice in this SQL showing the rows which belong to each sr_instance_id.

VII. The Profile Option MSC: Share Plan Partitions

Note: In later releases, 11.5.8 and above with 9i RDBMS or higher, we do NOT recommend the use of Shared Plan partition. Default setting = No. This means that each ASCP Plan requires a Plan Partition to store the output of an ASCP planning run. When Yes, then the partition _999999 will be created when Create APS Partitions request is run. Then all plans will store their planning data under this single partition. This would be useful if the customer has a large number of plans. Generally speaking, more than 15 plans are considered a large number. The Default installation of APS will create 5 Plan Partitions and 1 Instance Partition as was discussed in What Are APS Partitions The process of switching from Yes to No for this profile option is covered in Section Two under XII. PDS - Converting From Shared Plan Partitions to Individual Plan Partitions The process of switching from No to Yes for this profile option is covered in Section Two under XIII. PDS - Conversion From Individual Plan Partitions to Shared Plan Partitions At the end of the process of switching from No to Yes, the table MSC_PLAN_PARTITIONS should have NO ROWS. It has been observed many times that NOT ALL of the Plan Partitions are removed properly by customers when switching this profile. This can cause performance problems for ASCP either when running the ASCP Plan or accessing the Planner Workbench and other forms. At typical example of what has been observed would be the following: 1. The profile option was changed and at least one partition is left in the system. See output below from SQL #5

2. The output of SQL #1 with the alternate where clause for only one table where table name = MSC_SYSTEM_ITEMS is also below 3. The RED row shows that SINGLE UNDERSCORE _1 partition is the PDS Plan Partition partition_number 1. 4. The BLUE row shows the DOUBLE UNDERSCORE __1 partition which is the ODS Instance partition. 5. If any rows exist in MSC_PLAN_PARTITIONS, then the Drop Partition Request should be run to remove these lines and their associated partitions from the system to avoid any performance problems. a. After running Drop Plan Partitions correctly SQL #5 will return no rows. b. The RED row will no longer be present in the SQL #1 for any tables EXCEPT the %_MV tables. See Appendix B for more information on these tables. Output of SQL #5
PLAN_ID PLAN_NAME FREE_FLAG PARTITION_NUMBER 1 1 1 1

Output of SQL #1 for one table

TABLE_NAME MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS

PARTITION_NAME NUM_ROWS SAMPLE_SIZE LAST_ANALYZED GLOBAL SYSTEM_ITEMS_0 0 11/10/2003 0:50 YES SYSTEM_ITEMS_1 0 11/10/2003 0:50 YES SYSTEM_ITEMS__1 2280 228 11/11/2003 11:45 YES SYSTEM_ITEMS_999999 3850 385 11/10/2003 0:50 YES

Back to Top

VIII. Basic Performance Tuning for MSC Partitions

1. If 11.5.8 or below, read this, otherwise go to step #2. Patch 2405219 fixes a problem with partitioned tables in the procedure FND_STATS, which is run for the concurrent program Gather Schema Statistics. This is a very important patch. 2. MSC: Share Plan Partition = No is required setting. Using MSC: Share Plan Partitions = Yes can cause performance issues, and requires that you perform steps to convert to No (Section XII) before you perform any volume testing or go-live. The conversion requires purging all plans from the system. 3. Do not create extra plan partitions. Unused plan partitions consume space in the Oracle RDBMS SGA Data Dictionary and can be very bad for performance. There are 18 or more tables in the MSC schema in which partitioning is used depending on the release. If 10 partitions are created, this results in 180+ database objects, not including indexes. See Appendix B List of Partitioned Tables for more information. 4. NEVER DELETE THE _0 PARTITION!!!!

a. This is a 'model' partition for the creation of all other partitions. b. Deleting this partition will cause the instance to stop functioning!! 6. Determine if you have any free partitions. a. Use SQL #2 to check for free_flag = 1 for Instance Partitions b. Use SQL #5 to check for free_flag = 1 for Plan Partitions c. If any free_flag partitions exist, then remove them using the steps described under III. Drop Partition or Drop Plan Partition & Create APS Partitions Concurrent Requests d. NOTE: A plan name can be assigned, but not active and the free_flag = 1. This usually indicates that the plan has been purged and not yet replaced by a new plan name. If performance problems are occurring, then delete the partition and create a new partition when needed. 7. For any performance problems with planning or the Workbench in ASCP do the following: a. If 11.5.9 or 11i FND.G - 2655277 has not been applied, then ensure that patch 2405219 has been applied for Gather Schema Statistics. b. Follow step #6 and eliminate any partitions not being used. c. Run Gather Schema Statistics for MSC schema at 50% d. Run Analyze Plan partition program for the plan name e. For performance problems in the Horizontal Plan that are persistent, please use the following SQL to attempt to resolve the issue
analyze table msc.msc_form_query compute statistics; analyze table msc.msc_supplies compute statistics; analyze table msc.msc_demands compute statistics;

f. If the above steps fail to improve the performance, then apply the latest ASCP Engine/UI Rollup Patch listed in Section I of Note 223026.1 8. For more information about the APS Tablespaces, please see Note 220115.1 - Managing MSCD and MSCX Tablespaces for APS Implementations 9. For more information about maintaining sufficient rollback for the APS application, please see Note 266797.1 - Rollback Segment Assignment and Automatic Undo Management Mode for MRP and APS Applications ORA-01555

IX. Setup the Instance and First Run of Data Collection

Starting in 11.5.8 there is a new responsibility Advanced Planning Administrator -- where the Instance Setup form is located. Login to the application and choose 'Advanced Supply Chain Planner' (11.5.7 and below) or Advanced Planning Administrator as the responsibility.

NEW Click HERE and download a Flash Viewlet shows the new functionality in the form for 11.5.10 and 12.0 that is not included in the ASCP Users Guide 1. NAV> Admin / Instances: 1. Instance Code: Pick any three-letter code. We used V86 when setting up instance_id 81. 2. Instance Type: Typically Discrete - or Discrete and Process if organizations are setup for Process Manufacturing 3. Version: 11i in our example 4. Application Database Link: Enter the link created on the source that points to the destination. If this is a Centralized installation, leave blank. 5. Planning Database Link: Enter the link created on the destination that points to the source. If this is a Centralized installation, leave blank. 6. Enable: The box should be checked 7. GMT Difference: This is the difference from GMT. Our server is in the EST time zone, so we entered -5. 8. Currency: We choose USD 9. Assignment Set: Since we may have multiple assignment sets to work with, we left this blank. 10. 11.5.10 and above Enable ATP and Enable Release - these new settings are for a new feature that allows multiple APS Destination Instances to be linked to a single 11.5.10 ERP Source. 11. Save the newly created row, then click on Organizations. 1. Depending on your Family Pack level, all of the organizations for the source instance should be visible OR available by clicking on the Organization lookup. 2. In 11.5.10 and above (with latest patches installed) there are new settings: 1. In earlier versions, all orgs are automatically collected for ODP. Now flags for Enabled (ASCP) and Demand Planning Enabled are offered. 2. Collection Group is available - a free form field to assign a name to be used to collect only specific organizations when running Data Collections. The options to choose a Collection Group is seen in the parameters for Data Collections 3. You MUST collect data from the Master Organization In 11.5.10 and above you must also enable the organization to be used for ATO and inline Forecast Explosion during the ASCP plan. 1. Then select the other organizations that will be collected. 12. Save your work. 13. Verify that the new instance is ready for collections.

1. On the destination instance, using SQL #3 to make sure that msc_apps_instances.st_status = 0 for the instance_code. If the st_status is not 0 for the instance_code, run Planning Data Collection - Purge Staging Tables to reset the status and clean up the collection tables. ST_STATUS 0 = No source pull or collection is in process 1 = Pull and collection process has begun 2 = Collection has ended and waiting for load to begin 3 = Load has begun 4 = Load has ended and staging tables are being purged. It is highly recommended that for new or cloned instances, that Refresh Collection Snapshots be run as a standalone request BEFORE launching Data Collections Request set for the first time. On the ERP Source Instance, from the Material Planner Responsibility, submit the concurrent request Refresh Snapshots using Complete Refresh and other parameters as default. See Note 211121.1 for more information on running this request as a standalone request See Note 207644.1 for more information on the Setup Requests that create all the Objects used by data collections and how to handle errors and performance issues that may occur. Back to Top

Section Two
This section covers the steps that are necessary to accomplish the 6 scenarios shown below. X. ODS - Deleting ODS and dropping the ODS partition - Use this when cloning an instance XI. Moving APS Installation from a Centralized to a Decentralized installation XII. PDS - Converting From Shared Plan Partitions to Individual Plan Partitions. XIII. PDS - Conversion From Individual Plan Partitions to Shared Plan Partitions. XIV. Your Instance has become corrupted beyond repair XV. Advanced Cloning - Attempts to preserve data that has been setup on the APS Destination Instance It is the responsibility of the user to choose which method to apply. Some of the following methods are obviously more destructive than others. Please test the chosen approach using a non-production environment.

Back to Top

X. ODS - ODS Data Cleanup - Dropping old ODS partition / Create and Setup a New Partition
1. 2. Purge all plans in the APS instance. Go to Names form, click the delete icon, answer the prompt and then save for each plan. Check that there is not free instance partition in the system using SQL #2. The only line(s) should be for the partition(s) currently in use to collect data from the ERP Source Instance(s). Determine the instance_id to be removed using SQL #3. In Release 12.0, Go to Advanced Planning Administrator / Admin / Instances Highlight the line for the instance to be removed and press the delete icon to remove the line from the form, then save. - Note: In 12.0.0 12.0.3 this step will fail Fixed in 12.0.4 - See Note 421097.1 Known Isssues for R12 and #10 for a workaround. Drop the partition relating to the previous ERP Source Instance using Drop Partition Request and set the parameter Plan = No. OR the use SQL #9. In the ERP Source Instance, remove the line from MRP_AP_APPS_INSTANCES_ALL (MRP_APPS_INSTANCES in 11.5.9 and BELOW)using SQL #10 Finish the cleanup of the APS Destination Instance using SQL #6 and SQL #7. a. For instances with ODP data, also see SQL #13, SQL #14, and SQL #15 Add an ODS partition by submitting the request Create APS Partitions with plan_partition_count = 0 and inst_partition_count = 1 Setup the new instance to be collected from within the application. See Setup the Instance and First Run of Data Collection Launch Gather Schema statistics on the APS instance. Set profile MSC: Source Setup Required = Y on the ERP Source Instance. Make sure statistics have been gathered on the ERP source instance. On ERP instance, launch Refresh Collections Snapshot with parameters Complete Refresh, ALL snaposhots and others as default. Launch a Complete Refresh of Data Collection. Set profile MSC: Calendar Reference for Bucketing to the correct value OR NULL. Ref: Note.452630.1 - Cannot Create and Save Plan Getting Calendar Error When Saving The Plan Options Run Gather Schema Statistics for the MSC schema with the default parameters. In 11.5.8 and above, setup the Organization Security for the Responsibilities. The lack of setups will cause an error in Plan Options / Organization Tab. There will not be a list of values available. Viewing Plans after they have run will not be possible without these setups.

3. 4.

5.

6.

7.

8. 9. 10. 11. 12. 13. 14. 15.

16. 17.

18.

Run the ASCP Plans. If the plan fails, then re-run it once more. If failure continues and it was working fine on the SAME code on the previous instance, then try Step 10 again and run the plan again.

XI. Moving the APS Installation from a Centralized to a Decentralized Installation

1. There are two options for this installation a. Perform a Fresh Installation of the application on the APS Destination box and setup APS i. Advantage is MUCH less disk space and less chance of corrupting the instance. ii. Disadvantage is additional setup time needed. b. Clone your existing instance onto a new box and then clean up the data on the ERP Source and APS Destination instances in the MSC schema. i. Advantage is that much of the setup will already be accomplished. ii. Disadvantage is all the disk space needed for all the unused data residing in other schemas. If a Fresh Installation is chosen, then do the following: a. On the ERP Source Instance i. Purge the ASCP Plans in the system - Use SQL #4 to assist in this task. Details in XII Step #1 ii. Use SQL #1 to find all the partitions in the system iii. Use Drop Partition request (or SQL #8 or Drop Plan Partition in 11.5.8 and below) to remove all the Plan partitions EXCEPT Partition_0 iv. In Release 12.0, Go to Advanced Planning Administrator / Admin / Instances Highlight the line for the instance to be removed and press the delete icon to remove the line from the form, then save v. Use Drop Partition (or SQL #9 in 11.5.8 and below) to remove the Instance partitions vi. Then clean up the additional data in the MSC schema using SQL #6 and SQL #7 vii. If ODP was installed and used also see SQL #13, SQL #14, and SQL #15 viii. Remove the line from MRP_AP_APPS_INSTANCES_ALL (MRP_APPS_INSTANCES in 11.5.9 and BELOW) table using SQL #10. b. Install Applications in the new instance and setup your employees, users, etc for basic applications access. c. Then use the APS Users Guide to setup the APS destination instance as if it was a brand new installation. If Cloning is the method chosen, then do the following:

2.

3.

a. Likely the clone will be performed before any data is purged to avoid downtime, so the following steps are required. b. Do all of Step 2.a above on BOTH the ERP Source Instance and APS Destination Instances i. When completed, SQL #1 should show only partition_0 on both instances c. Then on the APS Destination instance, do Steps 7 11 from X. ODS ODS Data Cleanup - Dropping old ODS partition / Create and Setup a New Partition 20 d. Then create the required number of PDS Planning partitions partition by submitting the request Create APS Partitions with plan_partition_count = n and inst_partition_count = 0 (Note: Do not create many partitions at one time add them gradually 2-3 at a time to avoid performance problems) e. Then create and launch your APS Plans. If the plan fails, then re-run it once more. If failure continues and it was working fine on the SAME code on the previous instance, then run Gather Schema statistics again with 50% and then try the plan once more. Back to Top

XII. PDS - Converting From Shared Plan Partitions to Individual Plan Partitions
1. Use SQL #4 to see the plans in the system. Purge all existing plans. a. As the Advanced Supply Chain Planner, NAV>Supply Chain Plan / Names. b. Highlight the plan, click delete icon and respond to the prompt, then save. c. As necessary, use NAV> Other / Change Instance-Organization to change the organization and repeat steps #1a and #1b. Use SQL #1 to check the table setups and that you have partition 999999 this partition and partition_0 and one ODS instance partition should be all that resides on the system. Use the concurrent request Drop Partition (or Drop Plan Partition in 11.5.8) to cleanup the 999999 partition (or use SQL #8 to drop the partition) a. Use parameters partition 999999 and (in 11.5.9 and up) parameter plan = Yes b. Run SQL #1 again and confirm that all _999999 partitions have been removed from the system. Change the destination Profile MSC: Share Partition = No. Submit Create APS Partition request with inst_partition_count = 0 and plan_partition_count = nn a. Note: Do not create more plan partitions than necessary. See VIII. Performance Tuning for MSC Partitions

2.

3.

4. 5.

6. Review the partitions created using SQL #1. 7. Define the plans and then launch them to recreate the data. Note: There is a bug in the Names form MSCFPCMN.fmb that does not filter the plans that are collected from the ERP Source Instance. This should be resolved in 11.5.10 and 11iSCP_PF.I - UI Rollup #2, and 11iSCP_PF.H - UI Rollup #6 See Note 223026.1 for more information on the Rollup patches.

XIII. PDS - Conversion From Individual Plan Partitions to Shared Plan Partitions
Note: In later releases, 11.5.8 and above with 9i RDBMS or higher, we do NOT want customers to use of Shared Plan partition. 1. (Optional It may be possible to skip this step and proceed to Step #2. In our testing, the plans ran fine and data was created under the 999999 partition after the partition was created. IF the ASCP plan fails in step 6, THEN create a new plan and test. IF problems persist, THEN use Steps 1a 1d to remove all the old plans) a. Use SQL #5 to see the plans. Purge all existing plans. b. As the Advanced Supply Chain Planner, NAV>Supply Chain Plan/Names. c. Highlight the plan, click delete icon and respond to the prompt, then save. d. As necessary, use NAV> Other/Change Instance-Organization to change the organization and repeat steps #1 and #2 2. If you have not applied 11iSCP_PF.H or 11.5.8, then apply patch 2389523. 3. Use the concurrent request Drop Plan Partition to cleanup the Plan Partitions. For 11.5.9 and up - use Yes for the Plan parameter a. Do NOT delete the 0 (ZERO) partition. 4. Set the profile MSC: Share Plan Partition = Yes 5. Submit the request Create APS Partitions with plan_partition_count = 1 and inst_partition_count = 0. 6. This will create partitions with the suffix of _999999. Use SQL #1 to review the new partition tables. 7. Run the ASCP plans. Note: IF 11.5.7 or 11iSCP_PF.G or lower is the system level AND patch 2389523 was not applied AND the Create Partition request errored, THEN you must drop the 999999 partition and repeat step 5 after the patch has been successfully applied.

XIV. Your Instance has become corrupted beyond repair

1. If the backup of the instance does not seem to have stable data then all partitions should be dropped and then recreated.

2. 3.

Check the tables using SQL #1 and keep a copy of that information. Use the concurrent request Drop Partition to cleanup the Plan Partitions. For 11.5.9 and above use Yes for the Plan parameter a. Do NOT drop the _0 (ZERO) template partition 4. Use the Drop Partition (or SQL #9) to remove the instance partition. For 11.5.9 and above use Drop Partition with No for the Plan parameter 5. Clean up all the data using SQL #6 and SQL #7 6. Submit Create APS Partition request with inst_partition_count = n and plan_partition_count = nn. a. Note: Do not create more partitions than necessary. See VIII. Performance Tuning for MSC Partitions 7. Use SQL #10 to remove the line from MRP_AP_APPS_INSTANCES_ALL (MRP_APPS_INSTANCES in 11.5.9 and BELOW) in the ERP Source Instance. 8. Do the steps for Setup of an ODS Instance for Data Collection 9. Run a Complete Refresh of Data Collection. 10. Run Gather Schema Statistics for the MSC schema with the default parameters for the request. 11. In 11.5.8 and above, setup the Organization Security for the Respnosibilities. This may also be required for the plan to run successfully. The lack of setups will cause an error in Plan Options / Organization Tab. There will not be a list of values available. Viewing Plans after they have run will not be possible without these setups 12. Setup and run the ASCP plans. If you have any problems setting up the plans, then purge them and create new plans. Back to Top

XV. Advanced Cloning - Attempts to preserve data that has been setup on the APS Destination Instance
This is COMPLETELY UNTESTED. Theoretically, this should be possible and can reduce time to setup a cloned instance. APS Support does not clone our APS Test Instances and does not have the resources to setup this complicated test case. APS Support was only able to test this in a Centralized instance. IF this works and/or the customer finds other steps necessary to make this process work and would like to provide feedback, that would be appreciated. However, Support cannot guarantee that this process will be effective. If this fails when tested, then proceed to use X. ODS - ODS Data Cleanup - Dropping old ODS partition / Create and Setup a New Partition 20 to clean up the instance and start over. Key Points to Remember to Avoid Data Corruption 1. MSC_APPS_INSTANCES is the APS destination table storing relevant data accessed by the MSC applications

2. MRP_AP_APPS_INSTANCES_ALL is the ERP source side table used by the ERP applications 3. These tables cannot have the same INSTANCE_ID and/or INSTANCE_CODE listed more than once in the table 4. Except under very controlled conditions, instance_code and instance_id should be different for each instance (DEV, TST, PCH, CRP, UAT, PRD) 5. Our specialized APS diagnostic script apscheck.sql (Note 246150.1) has in section 24 output called Instance Partition Data Integrity Check to help us make sure that instance setups have not been corrupted. a. It prints SQL output and has explanation of good and bad data. b. If you run this and find bad data, then the instance cloning and matching has not been performed correctly and data cleanup of the bad instance_id and resetting the effected instance will be required. c. We usually encounter this when customers are not aware of the implications of using the same instance code repeatedly across different instances, but with different instance_id, and they have not performed Section X of this note to clean up the old data before creating new instance codes and collecting data after cloning. Scneario #1 1. The Production APS instance (APSPROD) and Production ERP Source (PROD) have been brought live and have instance_id and database links defined and are working fine. 2. Clone BOTH instances to test systems, rename the DBs APSTEST and TEST, and create new database links, Gather stats run for both instances 3. Then update APSTEST table MSC_APPS_INSTANCES, columns A2M_DBLINK, M2A_DBLINK with the new values (Do NOT change column INSTANCE_CODE, this can cause data corrption) 4. Then update TEST table MRP_AP_APPS_INSTANCES_ALL (MRP_APPS_INSTANCES in 11.5.9 and BELOW) columns A2M_DBLINK, M2A_DBLINK with the new values (Do NOT change column INSTANCE_CODE, this can cause data corrption) 5. On ERP instance, launch Refresh Collections Snapshot with parameters Complete Refresh, ALL snaposhots and others as default 6. Then run Data Collections with a Complete Refresh 7. Then in the future, when further cloning is required for changes in the ERP Source PROD, you can clone only PROD to TEST and then recreate db links, run gather schema stats, and only have to repeat Step #4, 5, and 6, and all should work fine. This should avoid the need to clone the APSPROD again. Scenario #2

1. The APS Desitnation Instance APSTEST and ERP Source Instance in TEST have different instance_id settings than ASPPROD and PROD and this cannot be changed. 2. When ERP Source PROD is cloned to the ERP source TEST instance you need to setup TEST to link to APSTEST instance. (ONLY cloning the ERP Instance in this scenario) 3. BEFORE the clone, save or backup table MRP_AP_APPS_INSTANCES_ALL (MRP_APPS_INSTANCES in 11.5.9 and BELOW) 4. Perform the clone and setup the database, database links, etc.for TEST 5. Replace the values in MRP_AP_APPS_INSTANCES_ALL (MRP_APPS_INSTANCES in 11.5.9 and BELOW) with the values saved before the clone. 6. On ERP instance, launch Refresh Collections Snapshot with parameters Complete Refresh, ALL snaposhots and others as default 7. Then run Data Collections with a Complete Refresh IF the above steps do not allow for completion of data collections and linking of the instances correctly, THEN removing all data and following the steps in X. ODS - ODS Data Cleanup - Dropping old ODS partition / Create and Setup a New Partition 20 will cleanse the data in both instances and allow for complete rebuild of the data in the APS Destination instance

Appendix A - SQL References

All of these SQL commands are designed to be executed from SQL*Plus. They may not work correctly in a SQL Browser. ALWAYS use a test instance to check these scripts before using on a live instance. You may have to reformat some of these statements due to the way the browser is displaying them. SQL #1 -- This SQL will reveal the partitioned tables that are in the system.
-- Run this from SQL*Plus the column HIGH_VALUE is column type LONG and will not format correctly in a spreadsheet set lines 200 set colsep | spool SQL-1_137293.1.txt SELECT table_name, partition_name,

num_rows, high_value, sample_size, last_analyzed, global_stats FROM all_tab_partitions WHERE table_name like 'MSC%' order by substr(partition_name,instr(partiti on_name,'_',-1,1)+1) -- To check the partition count of each table use order by table_name, partition_name spool off

SQL #2 --This SQL will show the instance partitions that have been created -- Free Flag 1 = Yes 2 = No
select instance_id, free_flag, creation_date, last_update_date msc_inst_partitions;

from

SQL #3 -- This SQL will show the instance partitions that have been created and assigned to an ERP Source Instance
select instance_code, instance_id, apps_ver, a2m_dblink, m2a_dblink, st_status from msc_apps_instances

SQL #4 --This SQL will show the plans that have been created in the system, plan_type is the following: 1 Manufacturing Plan 2 Production Plan 3 Distribution Plan 4 Inventory Plan
select mp.COMPILE_DESIGNATOR "Plan Name", mp.PLAN_ID "Plan ID", mp.SR_INSTANCE_ID "Instance ID", mtp.ORGANIZATION_CODE "Owning Org", mp.PLAN_COMPLETION_DATE "Last Run Date", decode (mp.PLAN_TYPE, 1, 'Master', 2, 'Production MPS', 3,

'Manufacturing MRP',4,'IO Plan', 5, 'Distribution Plan') "Plan Type", decode (mp.PRODUCTION_FLAG,1, 'Yes', 2, 'No', NULL, 'No') "Production Flag", decode (md.LAUNCH_WORKFLOW_FLAG,1, 'Yes', 2, 'No', NULL, 'No') "Launch Workflow", decode (md.INVENTORY_ATP_FLAG,1, 'Yes', 2, 'No', NULL, 'No') "ATP Plan", mp.CURR_START_DATE "Plan Start Date", mp.CUTOFF_DATE "Plan End Date" from msc_designators md, msc_plans mp, msc_trading_partners mtp where md.designator=mp.compile_designator and md.sr_instance_id=mp.sr_instance_id and mtp.sr_instance_id=mp.sr_instance_id and md.sr_instance_id=mtp.sr_instance_id and mtp.sr_tp_id=md.organization_id and mtp.sr_tp_id=mp.organization_id and mp.organization_id=md.organization_id and mtp.partner_type = 3 ORDER BY "Plan Name"

Back to Top SQL #5 -- This SQL shows the plans and their plan partitions assigned to those plans Free Flag 1 = Yes, 2 = No
select plan_id, plan_name, free_flag, partition_number msc_plan_partitions

from

SQL #6 -- This SQL will build a script to delete all tables where the instance_id column appears
set heading off set pagesize 500 spool delete_instance_id.sql select distinct 'delete from '||TABLE_NAME||' where instance_id = nn;' -- replace nn with your instance_id from dba_tab_columns where column_name = 'INSTANCE_ID' and owner = 'MSC'; spool off

-- The script will have lines like the following and nn should have your instance_id
delete from MSC_APPS_INSTANCES where instance_id = nn; delete from MSC_ATP_SOURCES_TEMP where instance_id = nn; delete from MSC_COLL_PARAMETERS where instance_id = nn;

Edit the file to remove the SQL statement and the spool off command and then submit the file in SQL*Plus: SQL>@delete_instance_id.sql SQL>commit;

SQL #7 -- This SQL will build a script to delete all tables where the sr_instance_id column appears
set heading off set pagesize 500 spool delete_sr_instance_id.sql select distinct 'delete from '||TABLE_NAME||' where sr_instance_id = nn;' -- replace nn with your instance_id from dba_tab_columns where column_name = 'SR_INSTANCE_ID' and owner = 'MSC' and table_name like 'MSC%'; spool off

-- The script will have lines like the following and nn should have your instance_id
delete from MSC_ABC_CLASSES where sr_instance_id = nn; delete from MSC_ALLOCATION_ASSIGNMENTS where sr_instance_id = nn; delete from MSC_ALLOC_DEMANDS where sr_instance_id = nn;

Edit the file to remove the SQL statement and the spool off command and then submit the file in SQL*Plus: SQL>@delete_sr_instance_id.sql SQL>commit; Note: This Script will report an error when attempting to delete from a %MV or %SN table. This error can be ignored. SQL #8 -- Script to drop plan partition .
declare errbuf varchar2(1000); retcode number ; begin /* Dropping a plan partition */ msc_manage_plan_partitions.drop_force_partition(errbuf,retcode,&pl an_partition_number,1);

end ; /

SQL #9 -- Script to drop instance partition .

declare errbuf varchar2(1000); retcode number ; begin /* Dropping an instance partition */ msc_manage_plan_partitions.drop_force_partition(errbuf,retcode,&in stance_partition_number,2); end ; /

Note: In 12.0 - You MUST delete the instance listed in the Advanced Planning Adminstrator / Admin / Instances for BEFORE using this SQL to handle the new partitioned tables for the MSC_ST% staging tables Back to Top SQL #10 -- SQL to check the MRP_AP_APPS_INSTANCES table on the ERP Source Instance and delete the line from that table. 11.5.9 and below
select * from mrp_ap_apps_instances -- will show the line in the table delete from mrp_ap_apps_instances; -- will delete the line from the table commit; -- will commit the delete

11.5.10 and above

select * from mrp_ap_apps_instances_all -- will show the line(s) in the table delete from mrp_ap_apps_instances_all where instance_id = &instance_id; -- will delete the line from the table commit; -- will commit the delete

FOR UPGRADED instances check BOTH tables SQL #11 - DO NOT USE FOR 11.5.10 AND ABOVE -- This SQL will build a script to update all tables where the instance_id column appears
set heading off set linesize 200 set pagesize 500 spool update_sr_instance_id.sql select distinct 'update '||TABLE_NAME||' set sr_instance_id = <new_instance_id> where sr_instance_id = <old_instance_id>;' -- replace <new_instance_id> and <old_instance_id> with your instance_id's as directed from dba_tab_columns

where

column_name = 'SR_INSTANCE_ID' and owner = 'MSC';

spool off

-- The script will have lines like the following we used 41 and 21 for sr_instance_ids
update MSC_ABC_CLASSES set sr_instance_id = 41 where sr_instance_id = 21; update MSC_ALLOCATION_ASSIGNMENTS set sr_instance_id = 41 where sr_instance_id = 21; update MSC_ALLOC_DEMANDS set sr_instance_id = 41 where sr_instance_id = 21;

Edit the file to remove the SQL statement and the spool off command and then submit the file in SQL*Plus: SQL>@update_sr_instance_id.sql SQL>commit; Note: This Script will report an error when attempting to update a %MV or %SN table. This error can be ignored. SQL #12 - DO NOT USE FOR 11.5.10 AND ABOVE -- This SQL will build a script to update all tables where the instance_id column appears
set heading off set linesize 200 set pagesize 500 spool update_instance_id.sql select distinct 'update '||TABLE_NAME||' set instance_id = <new_instance_id> where instance_id = <old_instance_id>;' -- replace <new_instance_id> and <old_instance_id> with your instance_id's as directed from dba_tab_columns where column_name = 'INSTANCE_ID' and owner = 'MSC'; spool off

-- The script will have lines like the following we used 41 and 21 for instance_ids
update MSC_APPS_INSTANCES set instance_id = 41 where instance_id = 21; update MSC_ATP_SOURCES_TEMP set instance_id = 41 where instance_id = 21; update MSC_COLL_PARAMETERS set instance_id = 41 where instance_id = 21;

Edit the file to remove the SQL statement and the spool off command and then submit the file in SQL*Plus: SQL>@update_instance_id.sql SQL>commit;

SQL #13 For ODP data -- This SQL will build a script to delete all tables where the instance_id column appears
set heading off set pagesize 500 spool delete_ODP_instance_id.sql select distinct 'delete from '||TABLE_NAME||' where instance_id = nn;' -- replace nn with your instance_id from dba_tab_columns where table_name in (select object_name from all_objects where object_name like 'MSD%' and object_type like 'TABLE') and column_name like 'INSTANCE_ID'; spool off

-- The script will have lines like the following and nn should have your instance_id
delete from MSD_APP_INSTANCE_ORGS where instance_id = nn; delete from MSD_ITEM_RELATIONSHIPS where instance_id = nn; delete from MSD_LOCAL_ID_SETUP where instance_id = nn;

Edit the file to remove the SQL statement and the spool off command and then submit the file in SQL*Plus: SQL>@delete_ODP_instance_id.sql SQL>commit; SQL #14 For ODP data -- This SQL will build a script to delete all tables where the sr_ instance_id column appears
set heading off set pagesize 500 spool delete_ODP_sr_instance_id.sql select distinct 'delete from '||TABLE_NAME||' where sr_instance_id = nn;' -- replace nn with your instance_id from dba_tab_columns where table_name in (select object_name from all_objects where object_name like 'MSD%' and object_type like 'TABLE') and column_name like 'SR_INSTANCE_ID'; spool off

-- The script will have lines like the following and nn should have your instance_id
delete from MSD_DEMAND_PLANS where sr_instance_id = nn; delete from MSD_DP_PLANNING_PCT_DENORM where sr_instance_id = nn; delete from MSD_DP_SCN_ENTRIES_DENORM where sr_instance_id = nn;

Edit the file to remove the SQL statement and the spool off command and then submit the file in SQL*Plus: SQL>@delete_ODP_sr_instance_id.sql SQL>commit;

SQL #15 For ODP data -- This SQL will build a script to delete all tables where the instance column appears
set heading off set pagesize 500 spool delete_ODP_instance.sql select distinct 'delete from '||TABLE_NAME||' where instance = nn;' -- replace nn with your instance_id from dba_tab_columns where table_name in (select object_name from all_objects where object_name like 'MSD%' and object_type like 'TABLE') and column_name like 'INSTANCE'; spool off

-- The script will have lines like the following and nn should have your instance_id
delete from MSD_BACKUP_LEVEL_VALUES where instance = nn; delete from MSD_BOM_COMPONENTS where instance = nn; delete from MSD_BOOKING_DATA where instance = nn;

Edit the file to remove the SQL statement and the spool off command and then submit the file in SQL*Plus: SQL>@delete_ODP_instance.sql SQL>commit;

Back to Top

Appendix B List of APS Partitioned Tables

Summary List of Partitioned Tables
The list below shows the tables that are created as partitioned in the MSC Schema for APS. Understanding and managing the size of the APS tablespaces -- MSCD (Data) and MSCX (Indexes) is discussed in Note 220115.1 Managing MSCD and MSCX Tablespaces for APS Implementations 1. Tables may be created for either the Plan Partition, the Instance Partition or may be needed for BOTH for APS to work properly. 2. The table below shows how the tables are created in 11.5.7 through 11.5.9 Or APS Family packs G though I. 3. The %_MV tables (Materialized View) are special see below 4. When an instance is functioning properly you should see the tables created for the various partition types below. 5. An example of the complete setup is a larger table under Complete Table Listing.

This list can be easily seen by the following SQL.

select table_name from dba_part_tables where owner = 'MSC' Created for 11.5.8 or 11iSCP_PF.H and Plan 11.5.9 or 11iSCP_PF.I Partition See Comments for new (PDS) or 11.5.10 and 12.0 tables Instance Partition (ODS) or BOTH Plan MSC_ALLOC_DEMANDS Plan MSC_ALLOC_SUPPLIES Plan Plan Both Instance Plan Both Both Plan Both Plan Plan Plan Instance Plan Both Both Both Both Both Both Both Both Both Plan Both MSC_ATP_PEGGING MSC_ATP_SUMMARY_RES MSC_ATP_SUMMARY_SD MSC_ATP_SUMMARY_SO MSC_ATP_SUMMARY_SUP MSC_BOMS MSC_BOM_COMPONENTS MSC_CRITICAL_PATHS MSC_DEMANDS MSC_EXCEPTION_DETAILS MSC_EXC_DETAILS_ALL MSC_FULL_PEGGING MSC_ITEM_CATEGORIES MSC_ITEM_EXCEPTIONS MSC_JOB_OPERATIONS MSC_JOB_OPERATION_NETWORKS MSC_JOB_OP_RESOURCES MSC_JOB_OP_RES_INSTANCES MSC_JOB_REQUIREMENT_OPS MSC_NET_RESOURCE_AVAIL MSC_NET_RES_INST_AVAIL MSC_OPERATION_RESOURCES MSC_OPERATION_RESOURCE_SEQS MSC_PQ_RESULTS MSC_RESOURCE_INSTANCE_REQS Yes Yes Yes Yes Yes Used for Plan Comparison Report only Yes Yes Yes Yes Yes For Constrained Planning Present in 11.5.7 or 11iSCP_PF.G Comments

added for Allocated ATP added for Allocated ATP New 11.5.10 added for ATP added for ATP added for ATP added for ATP

New 11.5.10 New 11.5.10 New 11.5.10 New 11.5.10 + for SNO/PS integration New 11.5.10 New 11.5.10 + for SNO/PS integration

New 11.5.10 New 11.5.10 + for SNO/PS integration

Both Both Both Instance Plan Plan Both Both

MSC_RESOURCE_REQUIREMENTS MSC_ROUTINGS MSC_ROUTING_OPERATIONS MSC_SALES_ORDERS MSC_SINGLE_LVL_PEG MSC_SUPPLIER_REQUIREMENTS MSC_SUPPLIES

Yes Yes Yes Yes

New 11.5.10 New R12

Yes Yes See MV table below Yes See MV table below Yes

MSC_SYSTEM_ITEMS See MV info MSC_RESOURCE_HIERARCHY_MV below See MV info MSC_ITEM_HIERARCHY_MV below

NEW is Release 12.0 There are now partitions for the MSC_ST% staging tables that are controlled by the entries made in the Instances form in Advanced Planning Administrator. The MSC_ST% staging tables are used in Data Collections and inserted when the Planning Data Pull process pulls data from the ERP Source schemas. The partitions DEF and LEG are default partitions and when a line is created and saved or deleted and saved in the Instances form, and then triggers on table MSC_APPS_INSTANCES are used to create/update/delete the partitions for these tables. The following shows the tables and their partitions for PARTITION_NAME like %_DEF
SELECT TABLE_NAME, PARTITION_NAME FROM ALL_TAB_PARTITIONS WHERE TABLE_NAME like 'MSC_ST%' and partition_name like '%_DEF' order by table_name TABLE_NAME MSC_ST_BOMS MSC_ST_BOM_COMPONENTS MSC_ST_CALENDAR_DATES MSC_ST_DEMANDS MSC_ST_DEPARTMENT_RESOURCES MSC_ST_ITEM_CATEGORIES MSC_ST_JOB_OPERATIONS MSC_ST_JOB_OP_RESOURCES PARTITION_NAME ST_BOMS_DEF ST_BOM_COMPONENTS_DEF ST_CALENDAR_DATES_DEF ST_DEMANDS_DEF ST_DEPARTMENT_RESOURCES_DEF ST_ITEM_CATEGORIES_DEF ST_JOB_OPERATIONS_DEF ST_JOB_OP_RESOURCES_DEF

MSC_ST_JOB_REQUIREMENT_OPS MSC_ST_NET_RESOURCE_AVAIL MSC_ST_NET_RES_INST_AVAIL MSC_ST_OPERATION_COMPONENTS MSC_ST_OPERATION_RESOURCES MSC_ST_OPERATION_RESOURCE_SEQS MSC_ST_PROCESS_EFFECTIVITY MSC_ST_RESOURCE_INSTANCE_REQS MSC_ST_RESOURCE_REQUIREMENTS MSC_ST_ROUTING_OPERATIONS MSC_ST_SALES_ORDERS MSC_ST_SHIFT_DATES MSC_ST_SOURCING_HISTORY MSC_ST_SOURCING_RULES MSC_ST_SUPPLIES MSC_ST_SYSTEM_ITEMS MSC_ST_TRADING_PARTNERS MSC_ST_TRADING_PARTNER_SITES

ST_JOB_REQUIREMENT_OPS_DEF ST_NET_RESOURCE_AVAIL_DEF ST_NET_RES_INST_AVAIL_DEF ST_OPERATION_COMPONENTS_DEF ST_OPERATION_RESOURCES_DEF ST_OPERATION_RESOURCE_SEQS_DEF ST_PROCESS_EFFECTIVITY_DEF ST_RESOURCE_INSTANCE_REQS_DEF ST_RESOURCE_REQUIREMENTS_DEF ST_ROUTING_OPERATIONS_DEF ST_SALES_ORDERS_DEF ST_SHIFT_DATES_DEF ST_SOURCING_HISTORY_DEF ST_SOURCING_RULES_DEF ST_SUPPLIES_DEF ST_SYSTEM_ITEMS_DEF ST_TRADING_PARTNERS_DEF ST_TRADING_PARTNER_SITES_DEF

When a single ODS partition is created then the list of partitions for a single table would appear as follows if the ODS partition is 21
SELECT TABLE_NAME, PARTITION_NAME FROM ALL_TAB_PARTITIONS WHERE TABLE_NAME like 'MSC_ST_SYSTEM_ITEMS' TABLE_NAME MSC_ST_SYSTEM_ITEMS MSC_ST_SYSTEM_ITEMS MSC_ST_SYSTEM_ITEMS PARTITION_NAME ST_SYSTEM_ITEMS_LEG ST_SYSTEM_ITEMS_DEF SYSTEM_ITEMS_21 Note that the Instance Partition 21 does NOT contain ST prefix for the partition name

The MV Partitioned Tables

The two tables that are created as Materialized Views MSC_RESOURCE_HIERARCHY_MV and MSC_ITEM_HIERARCHY_MV

They do not follow the standard partition creation rules. IMPORTANT 1. These tables should NEVER be manipulated. 2. They are NOT removed or changed by any process such as Drop Partition or Create APS Partition requests. 3. SQL #8 which drops plan partitions will NOT drop these partitions.

4. When using SQL #7 and SQL #11 these tables will error in the script. This is not a problem and can be ignored. When the views are reinitialized, the proper information will be written to the tables You can use the modified SQL #1 shown below to check this setup quickly SQL #1a -- This SQL will reveal the partitioned %_MV tables that are in the system.
table_name, partition_name from all_tab_partitions where table_name in ('MSC_ITEM_HIERARCHY_MV','MSC_RESOURCE_HIERARCHY_MV') order by table_name Select

The installation of APS creates the following partitions for these tables. These are the only tables where 0 partition may have data. This is expected if the ASCP Plan partition_number is >31; Partition_1 is populated for plan partitions >31 and <61; Partition_2 is used for >61

TABLE_NAME MSC_ITEM_HIERARCHY_MV MSC_ITEM_HIERARCHY_MV MSC_ITEM_HIERARCHY_MV MSC_RESOURCE_HIERARCHY_MV MSC_RESOURCE_HIERARCHY_MV MSC_RESOURCE_HIERARCHY_MV

PARTITION_NAME ITEM_HIERARCHY_0 ITEM_HIERARCHY_1 ITEM_HIERARCHY_2 RES_HIERARCHY_0 RES_HIERARCHY_1 RES_HIERARCHY_2

Back to Top

Complete Table Listing

This was completed in 11.5.9 (11iSCP_PF.I ) and also applies to 11.5.8 (11iSCP_PF.H) See the table in List of APS Partitioned Tables for the tables that should exist in 11.5.7 (11iSCP_PF.G), and for the new tables added in 11.5.10 and 12.0 The 1st list shows an instance setup with the default installation of APS The 2nd list shows an instance where the default installation was changed to MSC: Share Plan Partition = Yes and the Drop Partition was run properly according to the instructions in XIII. PDS - Conversion From Individual Plan Partitions to Shared Plan Partitions Remember that the %_MV tables have their own rules as noted above and will always exist as shown below.

SQL #1b -- This SQL will reveal the partitioned tables that are in the system.
select from where order by table_name, partition_name all_tab_partitions table_name like 'MSC%' table_name, partition_name

1st List - Default Installation - 11.5.9

TABLE_NAME MSC_ALLOC_DEMANDS MSC_ALLOC_DEMANDS MSC_ALLOC_DEMANDS MSC_ALLOC_DEMANDS MSC_ALLOC_DEMANDS MSC_ALLOC_DEMANDS MSC_ALLOC_SUPPLIES MSC_ALLOC_SUPPLIES MSC_ALLOC_SUPPLIES MSC_ALLOC_SUPPLIES MSC_ALLOC_SUPPLIES MSC_ALLOC_SUPPLIES MSC_ATP_SUMMARY_RES MSC_ATP_SUMMARY_RES MSC_ATP_SUMMARY_RES MSC_ATP_SUMMARY_RES MSC_ATP_SUMMARY_RES MSC_ATP_SUMMARY_RES MSC_ATP_SUMMARY_SD MSC_ATP_SUMMARY_SD MSC_ATP_SUMMARY_SD MSC_ATP_SUMMARY_SD MSC_ATP_SUMMARY_SD MSC_ATP_SUMMARY_SD MSC_ATP_SUMMARY_SD MSC_ATP_SUMMARY_SO MSC_ATP_SUMMARY_SO MSC_ATP_SUMMARY_SUP MSC_ATP_SUMMARY_SUP MSC_ATP_SUMMARY_SUP MSC_ATP_SUMMARY_SUP MSC_ATP_SUMMARY_SUP MSC_ATP_SUMMARY_SUP MSC_BOMS PARTITION_NAME ALLOC_DEMANDS_0 ALLOC_DEMANDS_1 ALLOC_DEMANDS_2 ALLOC_DEMANDS_3 ALLOC_DEMANDS_4 ALLOC_DEMANDS_5 ALLOC_SUPPLIES_0 ALLOC_SUPPLIES_1 ALLOC_SUPPLIES_2 ALLOC_SUPPLIES_3 ALLOC_SUPPLIES_4 ALLOC_SUPPLIES_5 ATP_SUMMARY_RES_0 ATP_SUMMARY_RES_1 ATP_SUMMARY_RES_2 ATP_SUMMARY_RES_3 ATP_SUMMARY_RES_4 ATP_SUMMARY_RES_5 ATP_SUMMARY_SD_0 ATP_SUMMARY_SD_1 ATP_SUMMARY_SD_2 ATP_SUMMARY_SD_3 ATP_SUMMARY_SD_4 ATP_SUMMARY_SD_5 ATP_SUMMARY_SD__1 ATP_SUMMARY_SO_0 ATP_SUMMARY_SO__1 ATP_SUMMARY_SUP_0 ATP_SUMMARY_SUP_1 ATP_SUMMARY_SUP_2 ATP_SUMMARY_SUP_3 ATP_SUMMARY_SUP_4 ATP_SUMMARY_SUP_5 BOMS_0

MSC_BOMS MSC_BOMS MSC_BOMS MSC_BOMS MSC_BOMS MSC_BOMS MSC_BOM_COMPONENTS MSC_BOM_COMPONENTS MSC_BOM_COMPONENTS MSC_BOM_COMPONENTS MSC_BOM_COMPONENTS MSC_BOM_COMPONENTS MSC_BOM_COMPONENTS MSC_CRITICAL_PATHS MSC_CRITICAL_PATHS MSC_CRITICAL_PATHS MSC_CRITICAL_PATHS MSC_CRITICAL_PATHS MSC_CRITICAL_PATHS MSC_DEMANDS MSC_DEMANDS MSC_DEMANDS MSC_DEMANDS MSC_DEMANDS MSC_DEMANDS MSC_DEMANDS MSC_EXCEPTION_DETAILS MSC_EXCEPTION_DETAILS MSC_EXCEPTION_DETAILS MSC_EXCEPTION_DETAILS MSC_EXCEPTION_DETAILS MSC_EXCEPTION_DETAILS MSC_EXC_DETAILS_ALL MSC_EXC_DETAILS_ALL MSC_EXC_DETAILS_ALL MSC_EXC_DETAILS_ALL MSC_EXC_DETAILS_ALL MSC_EXC_DETAILS_ALL MSC_FULL_PEGGING MSC_FULL_PEGGING MSC_FULL_PEGGING MSC_FULL_PEGGING MSC_FULL_PEGGING MSC_FULL_PEGGING MSC_ITEM_CATEGORIES

BOMS_1 BOMS_2 BOMS_3 BOMS_4 BOMS_5 BOMS__1 BOM_COMPONENTS_0 BOM_COMPONENTS_1 BOM_COMPONENTS_2 BOM_COMPONENTS_3 BOM_COMPONENTS_4 BOM_COMPONENTS_5 BOM_COMPONENTS__1 CRITICAL_PATHS_0 CRITICAL_PATHS_1 CRITICAL_PATHS_2 CRITICAL_PATHS_3 CRITICAL_PATHS_4 CRITICAL_PATHS_5 DEMANDS_0 DEMANDS_1 DEMANDS_2 DEMANDS_3 DEMANDS_4 DEMANDS_5 DEMANDS__1 EXCEPTION_DETAILS_0 EXCEPTION_DETAILS_1 EXCEPTION_DETAILS_2 EXCEPTION_DETAILS_3 EXCEPTION_DETAILS_4 EXCEPTION_DETAILS_5 EXC_DETAILS_ALL_0 EXC_DETAILS_ALL_1 EXC_DETAILS_ALL_2 EXC_DETAILS_ALL_3 EXC_DETAILS_ALL_4 EXC_DETAILS_ALL_5 FULL_PEGGING_0 FULL_PEGGING_1 FULL_PEGGING_2 FULL_PEGGING_3 FULL_PEGGING_4 FULL_PEGGING_5 ITEM_CATEGORIES_0

MSC_ITEM_CATEGORIES MSC_ITEM_EXCEPTIONS MSC_ITEM_EXCEPTIONS MSC_ITEM_EXCEPTIONS MSC_ITEM_EXCEPTIONS MSC_ITEM_EXCEPTIONS MSC_ITEM_EXCEPTIONS MSC_ITEM_HIERARCHY_MV MSC_ITEM_HIERARCHY_MV MSC_ITEM_HIERARCHY_MV MSC_NET_RESOURCE_AVAIL MSC_NET_RESOURCE_AVAIL MSC_NET_RESOURCE_AVAIL MSC_NET_RESOURCE_AVAIL MSC_NET_RESOURCE_AVAIL MSC_NET_RESOURCE_AVAIL MSC_NET_RESOURCE_AVAIL MSC_OPERATION_RESOURCES MSC_OPERATION_RESOURCES MSC_OPERATION_RESOURCES MSC_OPERATION_RESOURCES MSC_OPERATION_RESOURCES MSC_OPERATION_RESOURCES MSC_OPERATION_RESOURCES MSC_OPERATION_RESOURCE_SEQS MSC_OPERATION_RESOURCE_SEQS MSC_OPERATION_RESOURCE_SEQS MSC_OPERATION_RESOURCE_SEQS MSC_OPERATION_RESOURCE_SEQS MSC_OPERATION_RESOURCE_SEQS MSC_OPERATION_RESOURCE_SEQS MSC_RESOURCE_HIERARCHY_MV MSC_RESOURCE_HIERARCHY_MV MSC_RESOURCE_HIERARCHY_MV MSC_RESOURCE_REQUIREMENTS MSC_RESOURCE_REQUIREMENTS MSC_RESOURCE_REQUIREMENTS MSC_RESOURCE_REQUIREMENTS MSC_RESOURCE_REQUIREMENTS MSC_RESOURCE_REQUIREMENTS MSC_RESOURCE_REQUIREMENTS MSC_ROUTINGS MSC_ROUTINGS MSC_ROUTINGS MSC_ROUTINGS

ITEM_CATEGORIES__1 ITEM_EXCEPTIONS_0 ITEM_EXCEPTIONS_1 ITEM_EXCEPTIONS_2 ITEM_EXCEPTIONS_3 ITEM_EXCEPTIONS_4 ITEM_EXCEPTIONS_5 ITEM_HIERARCHY_0 ITEM_HIERARCHY_1 ITEM_HIERARCHY_2 NET_RESOURCE_AVAIL_0 NET_RESOURCE_AVAIL_1 NET_RESOURCE_AVAIL_2 NET_RESOURCE_AVAIL_3 NET_RESOURCE_AVAIL_4 NET_RESOURCE_AVAIL_5 NET_RESOURCE_AVAIL__1 OPERATION_RESOURCES_0 OPERATION_RESOURCES_1 OPERATION_RESOURCES_2 OPERATION_RESOURCES_3 OPERATION_RESOURCES_4 OPERATION_RESOURCES_5 OPERATION_RESOURCES__1 OPERATION_RESOURCE_SEQS_0 OPERATION_RESOURCE_SEQS_1 OPERATION_RESOURCE_SEQS_2 OPERATION_RESOURCE_SEQS_3 OPERATION_RESOURCE_SEQS_4 OPERATION_RESOURCE_SEQS_5 OPERATION_RESOURCE_SEQS__1 RES_HIERARCHY_0 RES_HIERARCHY_1 RES_HIERARCHY_2 RESOURCE_REQUIREMENTS_0 RESOURCE_REQUIREMENTS_1 RESOURCE_REQUIREMENTS_2 RESOURCE_REQUIREMENTS_3 RESOURCE_REQUIREMENTS_4 RESOURCE_REQUIREMENTS_5 RESOURCE_REQUIREMENTS__1 ROUTINGS_0 ROUTINGS_1 ROUTINGS_2 ROUTINGS_3

MSC_ROUTINGS MSC_ROUTINGS MSC_ROUTINGS MSC_ROUTING_OPERATIONS MSC_ROUTING_OPERATIONS MSC_ROUTING_OPERATIONS MSC_ROUTING_OPERATIONS MSC_ROUTING_OPERATIONS MSC_ROUTING_OPERATIONS MSC_ROUTING_OPERATIONS MSC_SALES_ORDERS MSC_SALES_ORDERS MSC_SUPPLIES MSC_SUPPLIES MSC_SUPPLIES MSC_SUPPLIES MSC_SUPPLIES MSC_SUPPLIES MSC_SUPPLIES MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS

ROUTINGS_4 ROUTINGS_5 ROUTINGS__1 ROUTING_OPERATIONS_0 ROUTING_OPERATIONS_1 ROUTING_OPERATIONS_2 ROUTING_OPERATIONS_3 ROUTING_OPERATIONS_4 ROUTING_OPERATIONS_5 ROUTING_OPERATIONS__1 SALES_ORDERS_0 SALES_ORDERS__1 SUPPLIES_0 SUPPLIES_1 SUPPLIES_2 SUPPLIES_3 SUPPLIES_4 SUPPLIES_5 SUPPLIES__1 SYSTEM_ITEMS_0 SYSTEM_ITEMS_1 SYSTEM_ITEMS_2 SYSTEM_ITEMS_3 SYSTEM_ITEMS_4 SYSTEM_ITEMS_5 SYSTEM_ITEMS__1

Back to Top

2nd List - MSC: Share Plan Partition = Yes - 11.5.9

The 2nd list shows an instance where the default installation was changed to MSC: Share Plan Partition = Yes and the Drop Partition was run properly according to the instructions in XIII. PDS - Conversion From Individual Plan Partitions to Shared Plan Partitions
TABLE_NAME MSC_ALLOC_DEMANDS MSC_ALLOC_DEMANDS MSC_ALLOC_SUPPLIES MSC_ALLOC_SUPPLIES MSC_ATP_SUMMARY_RES MSC_ATP_SUMMARY_RES MSC_ATP_SUMMARY_SD MSC_ATP_SUMMARY_SD PARTITION_NAME ALLOC_DEMANDS_0 ALLOC_DEMANDS_999999 ALLOC_SUPPLIES_0 ALLOC_SUPPLIES_999999 ATP_SUMMARY_RES_0 ATP_SUMMARY_RES_999999 ATP_SUMMARY_SD_0 ATP_SUMMARY_SD_999999

MSC_ATP_SUMMARY_SD MSC_ATP_SUMMARY_SO MSC_ATP_SUMMARY_SO MSC_ATP_SUMMARY_SUP MSC_ATP_SUMMARY_SUP MSC_BOMS MSC_BOMS MSC_BOMS MSC_BOM_COMPONENTS MSC_BOM_COMPONENTS MSC_BOM_COMPONENTS MSC_CRITICAL_PATHS MSC_CRITICAL_PATHS MSC_DEMANDS MSC_DEMANDS MSC_DEMANDS MSC_EXCEPTION_DETAILS MSC_EXCEPTION_DETAILS MSC_EXC_DETAILS_ALL MSC_EXC_DETAILS_ALL MSC_FULL_PEGGING MSC_FULL_PEGGING MSC_ITEM_CATEGORIES MSC_ITEM_CATEGORIES MSC_ITEM_EXCEPTIONS MSC_ITEM_EXCEPTIONS MSC_ITEM_HIERARCHY_MV MSC_ITEM_HIERARCHY_MV MSC_ITEM_HIERARCHY_MV MSC_NET_RESOURCE_AVAIL MSC_NET_RESOURCE_AVAIL MSC_NET_RESOURCE_AVAIL MSC_OPERATION_RESOURCES MSC_OPERATION_RESOURCES MSC_OPERATION_RESOURCES MSC_OPERATION_RESOURCE_SEQS MSC_OPERATION_RESOURCE_SEQS MSC_OPERATION_RESOURCE_SEQS MSC_RESOURCE_HIERARCHY_MV MSC_RESOURCE_HIERARCHY_MV MSC_RESOURCE_HIERARCHY_MV MSC_RESOURCE_REQUIREMENTS MSC_RESOURCE_REQUIREMENTS MSC_RESOURCE_REQUIREMENTS MSC_ROUTINGS

ATP_SUMMARY_SD__1 ATP_SUMMARY_SO_0 ATP_SUMMARY_SO__1 ATP_SUMMARY_SUP_0 ATP_SUMMARY_SUP_999999 BOMS_0 BOMS_999999 BOMS__1 BOM_COMPONENTS_0 BOM_COMPONENTS_999999 BOM_COMPONENTS__1 CRITICAL_PATHS_0 CRITICAL_PATHS_999999 DEMANDS_0 DEMANDS_999999 DEMANDS__1 EXCEPTION_DETAILS_0 EXCEPTION_DETAILS_999999 EXC_DETAILS_ALL_0 EXC_DETAILS_ALL_999999 FULL_PEGGING_0 FULL_PEGGING_999999 ITEM_CATEGORIES_0 ITEM_CATEGORIES__1 ITEM_EXCEPTIONS_0 ITEM_EXCEPTIONS_999999 ITEM_HIERARCHY_0 ITEM_HIERARCHY_1 ITEM_HIERARCHY_2 NET_RESOURCE_AVAIL_0 NET_RESOURCE_AVAIL_999999 NET_RESOURCE_AVAIL__1 OPERATION_RESOURCES_0 OPERATION_RESOURCES_999999 OPERATION_RESOURCES__1 OPERATION_RESOURCE_SEQS_0 OPERATION_RESOURCE_SEQS_999999 OPERATION_RESOURCE_SEQS__1 RES_HIERARCHY_0 RES_HIERARCHY_1 RES_HIERARCHY_2 RESOURCE_REQUIREMENTS_0 RESOURCE_REQUIREMENTS_999999 RESOURCE_REQUIREMENTS__1 ROUTINGS_0

MSC_ROUTINGS MSC_ROUTINGS MSC_ROUTING_OPERATIONS MSC_ROUTING_OPERATIONS MSC_ROUTING_OPERATIONS MSC_SALES_ORDERS MSC_SALES_ORDERS MSC_SUPPLIES MSC_SUPPLIES MSC_SUPPLIES MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS MSC_SYSTEM_ITEMS

ROUTINGS_999999 ROUTINGS__1 ROUTING_OPERATIONS_0 ROUTING_OPERATIONS_999999 ROUTING_OPERATIONS__1 SALES_ORDERS_0 SALES_ORDERS__1 SUPPLIES_0 SUPPLIES_999999 SUPPLIES__1 SYSTEM_ITEMS_0 SYSTEM_ITEMS_999999 SYSTEM_ITEMS__1

Back to Top

Appendix C - References
Note 118086.1 - APS Documentation and Manuals Note 223026.1 - List of High Priority Patches for the APS Suite Note 183401.1 - Diagnostic Scripts: Data Collection Performance Management Note 184984.1 - MSCFPCMN - App-Fnd-01206 This Record Already Exists When Entering APS Plan Name Note 207765.1 - Important Information About The APS Family Pack Installed in the System Note 146016.1 - Data Collection fails with several messages Note 220115.1 - Managing MSCD and MSCX Tablespaces for APS Implementations (Data Collections Sizing) Note 211121.1 - How to run the Refresh Snapshot Concurrent Request from the Application Note 207644.1 - Data Collections is Failing - All Errors - First Diagnostic Steps Note 145419.1 - How to Set Up Data Collection for Order Management ATP Availability Note 220115.1 - Managing MSCD and MSCX Tablespaces for APS Implementations Note 266797.1 - Rollback Segment Assignment and Automatic Undo Management Mode for MRP and APS Applications ORA-01555 Note 280237.1 - RBS_INFO.sql Script To Report Rollback Segment Activity Note.452630.1 - Cannot Create and Save Plan - Getting Calendar Error When Saving The Plan Options Back to Top
Oracle Corporation For Internal and Customer Use only david.goddard@oracle.com Rev 2.3 Jan 2005 Rev 2.3 minor revisions and formatting created PDF for easy printing

Rev 2.4 Sep 2006 general review and edit - 11.5.10 minor edits / revised for 12.0 Rev 2.4.1 Octboer 2006 minor edits should use Complete Refresh and not automatic for first run of Refresh Snapshots on a new instance Rev 2.4.2 October 2006 added flash viewlet for instance seutp form Rev 2.4.3 April 2007 corrected SQL #7 for R12 to remove unwanted tables not named MSC% - new SQL for SQL #4 Rev 2.4.4 August 2007 added step for profile in Section X ref note 425630.1 Rev 2.4.5 October 2007 explained workaround and fix for Step 4 in Section X Rev 2.4.5.1 Dec 2007 clarified steps in Section XII Rev 2.4.5.2 Mar 2008 General edits, SQL #1 includes high_value, orient note toward 11.5.10 and above, change to Section XV Cloning Rev 2.4.5.3 Feb 2009 Edit Section X, Section XV