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 27 SQL #3 27 SQL #4 27 SQL #5 28 SQL #6 28 SQL #7 29 SQL #8 29 SQL #9 30 SQL #10 30 SQL #11 - DO NOT USE FOR 11.5.10 AND ABOVE 30 SQL #12 - DO NOT USE FOR 11.5.10 AND ABOVE 31 SQL #13 – For ODP data 32 SQL #14 – For ODP data 32 SQL #15 – For ODP data 33

Appendix B – List of APS Partitioned Tables 33 Summary List of Partitioned Tables 33 The MV Partitioned Tables 36

SQL #1a 37 Complete Table Listing 37

SQL #1b 38 1st List - Default Installation - 11.5.9 38 2nd List - MSC: Share Plan Partition = Yes - 11.5.9 41

Appendix C - References 43

PURPOSE @ the old note is available internally as Note:257508.1 This note should allow Support Engineers, Users and DBA’s 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. Terminology II. What Are APS Partitions III. Drop Partition or Drop Plan Partition & Create APS Partitions Concurrent

Requests IV. Operational Data Store - ODS V. Planning Data Store – PDS VI. ODS & PDS Data VII. The profile option MSC: Share Plan Partitions VIII. Performance Tuning for MSC Partitions IX. 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 it’s 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 DBA’s 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 it’s 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 PARTITION_NAME Comments MSC_SYSTEM_ITEMS SYSTEM_ITEMS_0 The Template partition – NEVER DELETE

PARTITION MSC_SYSTEM_ITEMS SYSTEM_ITEMS__1 Instance Partition #1 MSC_SYSTEM_ITEMS SYSTEM_ITEMS_1 Plan Partition #1 MSC_SYSTEM_ITEMS SYSTEM_ITEMS_2 Plan Partition #2 MSC_SYSTEM_ITEMS SYSTEM_ITEMS_3 Plan Partition #3 MSC_SYSTEM_ITEMS SYSTEM_ITEMS_4 Plan Partition #4 MSC_SYSTEM_ITEMS SYSTEM_ITEMS_5 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 PARTITION_NAME Comments

MSC_SYSTEM_ITEMS SYSTEM_ITEMS_0 The Template partition – NEVER DELETE THIS PARTITION

MSC_SYSTEM_ITEMS SYSTEM_ITEMS__1 Instance Partition #1 MSC_SYSTEM_ITEMS 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 PARTITION_NAME NUM_ROWS SAMPLE_SIZE LAST_ANALYZED GLOBAL_STATSMSC_SUPPLIES SUPPLIES__21 14700 1470 10/21/2003 15:08 YES

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 from msc_inst_partitions; INSTANCE_ID FREE_FLAG CREATION_DATE LAST_UPDATE_DATE

21 2 5/8/2000 0:40 5/8/2000 0:40 61 2 1/25/2002 11:28 1/25/2002 11:28 81 2 10/14/2002 13:44 10/14/2002 13:44 101 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

INSTANCE_CODE INSTANCE_ID APPS_VER A2M_DBLINK M2A_DBLINK ST_STATUS

TST 21 3 0 LEG 61 -1 0 V86 81 3 APS visus86 0

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 PARTITION_NAME NUM_ROWS SAMPLE_SIZE LAST_ANALYZED GLOBAL_STATMSC_SUPPLIES SUPPLIES_347 900 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 Plan ID Instance ID Owning Org Last Run Date Plan Type Production Flag Launch Workflow ATP P

JMCVCONALT 5759 64 BOB:D2 3/21/2007 3:54 Manufacturing MRP No No No

JMESL80 6759 64 BOB:M1 8/8/2006 14:11 IO Plan No No No

JMMRPSHRK 11758 64 BOB:S1 6/1/2006 15:09 Master No No No

JMPROD 21758 64 BOB:M1 3/6/2007 1:39 Production MPS No No No

JMUNCSS 14759 64 BOB:M1 7/13/2006 17:03 Master No No No

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 from msc_plan_partitions

PLAN_ID PLAN_NAME FREE_FLAG PARTITION_NUMBER 347 DG-APS1 2 347 391 PRN_SCP 1 391 411 411 1 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 count(*) from msc_system_items;

COUNT(*)

6876

This SQL shows the rows and the plan_id as well as the sr_instance_id where these rows originated

select count(*), sr_instance_id, plan_id from msc_system_items group by sr_instance_id, plan_id

COUNT(*) SR_INSTANCE_ID PLAN_ID

3132 21 -1 2931 81 -1

56 81 147 1 81 148

10 21 149 36 21 181 2 81 183 2 81 184 5 21 221 1 81 222

10 21 224 43 21 263 108 21 283

6 21 303 376 21 323 115 21 325

24 21 347 9 81 347 9 81 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 PARTITION_NAME NUM_ROWS SAMPLE_SIZE LAST_ANALYZED GLOBALMSC_SYSTEM_ITEMS SYSTEM_ITEMS_0 0 11/10/2003 0:50 YES MSC_SYSTEM_ITEMS SYSTEM_ITEMS_1 0 11/10/2003 0:50 YES MSC_SYSTEM_ITEMS SYSTEM_ITEMS__1 2280 228 11/11/2003 11:45 YES MSC_SYSTEM_ITEMS 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 User’s 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. Purge all plans in the APS instance. Go to Names form, click the delete icon, answer the prompt and then save for each plan.

2. 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).

3. Determine the instance_id to be removed using SQL #3. 4. 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.

5. 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.

6. 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

7. 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 8. Add an ODS partition by submitting the request Create APS Partitions

with plan_partition_count = 0 and inst_partition_count = 1 9. Setup the new instance to be collected from within the application.

See Setup the Instance and First Run of Data Collection 10. Launch Gather Schema statistics on the APS instance. 11. Set profile MSC: Source Setup Required = Y on the ERP Source

Instance. 12. Make sure statistics have been gathered on the ERP source instance. 13. On ERP instance, launch Refresh Collections Snapshot with

parameters Complete Refresh, ALL snaposhots and others as default. 14. Launch a Complete Refresh of Data Collection. 15. 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

16. Run Gather Schema Statistics for the MSC schema with the default parameters.

17. 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.

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. 2. 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.

3. If Cloning is the method chosen, then do the following:

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. 2. 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.

3. 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.

4. Change the destination Profile MSC: Share Partition = No. 5. 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

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. Check the tables using SQL #1 and keep a copy of that information. 3. 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 DB’s 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(partition_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 from msc_inst_partitions;

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 from msc_plan_partitions

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,&plan_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,&instance_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_id’s 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_id’s 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 Plan

Partition (PDS) or Instance Partition (ODS) or

BOTH

11.5.8 or 11iSCP_PF.H and 11.5.9 or 11iSCP_PF.I See Comments for new 11.5.10 and 12.0 tables

Present in 11.5.7 or

11iSCP_PF.G

Comments

Plan MSC_ALLOC_DEMANDS added for Allocated ATP Plan MSC_ALLOC_SUPPLIES added for Allocated ATP Plan MSC_ATP_PEGGING New 11.5.10 Plan MSC_ATP_SUMMARY_RES added for ATP Both MSC_ATP_SUMMARY_SD added for ATP

Instance MSC_ATP_SUMMARY_SO added for ATP Plan MSC_ATP_SUMMARY_SUP added for ATP Both MSC_BOMS Yes Both MSC_BOM_COMPONENTS Yes Plan MSC_CRITICAL_PATHS For Constrained Planning Both MSC_DEMANDS Yes Plan MSC_EXCEPTION_DETAILS Yes Plan MSC_EXC_DETAILS_ALL Used for Plan Comparison Report only Plan MSC_FULL_PEGGING Yes

Instance MSC_ITEM_CATEGORIES Yes Plan MSC_ITEM_EXCEPTIONS Yes Both MSC_JOB_OPERATIONS New 11.5.10 Both MSC_JOB_OPERATION_NETWORKS New 11.5.10 Both MSC_JOB_OP_RESOURCES New 11.5.10 Both MSC_JOB_OP_RES_INSTANCES New 11.5.10 + for SNO/PS integration Both MSC_JOB_REQUIREMENT_OPS New 11.5.10 Both MSC_NET_RESOURCE_AVAIL Yes Both MSC_NET_RES_INST_AVAIL New 11.5.10 + for SNO/PS integration Both MSC_OPERATION_RESOURCES Yes Both MSC_OPERATION_RESOURCE_SEQS Yes Plan MSC_PQ_RESULTS New 11.5.10 Both MSC_RESOURCE_INSTANCE_REQS New 11.5.10 + for SNO/PS integration

Both MSC_RESOURCE_REQUIREMENTS Yes Both MSC_ROUTINGS Yes Both MSC_ROUTING_OPERATIONS Yes

Instance MSC_SALES_ORDERS Yes Plan MSC_SINGLE_LVL_PEG New 11.5.10 Plan MSC_SUPPLIER_REQUIREMENTS New R12 Both MSC_SUPPLIES Yes Both MSC_SYSTEM_ITEMS Yes

See MV info below MSC_RESOURCE_HIERARCHY_MV Yes

See MV table below

See MV info below MSC_ITEM_HIERARCHY_MV Yes

See MV table 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 PARTITION_NAME MSC_ST_BOMS ST_BOMS_DEF MSC_ST_BOM_COMPONENTS ST_BOM_COMPONENTS_DEF MSC_ST_CALENDAR_DATES ST_CALENDAR_DATES_DEF MSC_ST_DEMANDS ST_DEMANDS_DEF MSC_ST_DEPARTMENT_RESOURCES ST_DEPARTMENT_RESOURCES_DEF MSC_ST_ITEM_CATEGORIES ST_ITEM_CATEGORIES_DEF MSC_ST_JOB_OPERATIONS ST_JOB_OPERATIONS_DEF MSC_ST_JOB_OP_RESOURCES ST_JOB_OP_RESOURCES_DEF

MSC_ST_JOB_REQUIREMENT_OPS ST_JOB_REQUIREMENT_OPS_DEF MSC_ST_NET_RESOURCE_AVAIL ST_NET_RESOURCE_AVAIL_DEF MSC_ST_NET_RES_INST_AVAIL ST_NET_RES_INST_AVAIL_DEF MSC_ST_OPERATION_COMPONENTS ST_OPERATION_COMPONENTS_DEF MSC_ST_OPERATION_RESOURCES ST_OPERATION_RESOURCES_DEF MSC_ST_OPERATION_RESOURCE_SEQS ST_OPERATION_RESOURCE_SEQS_DEFMSC_ST_PROCESS_EFFECTIVITY ST_PROCESS_EFFECTIVITY_DEF MSC_ST_RESOURCE_INSTANCE_REQS ST_RESOURCE_INSTANCE_REQS_DEF MSC_ST_RESOURCE_REQUIREMENTS ST_RESOURCE_REQUIREMENTS_DEF MSC_ST_ROUTING_OPERATIONS ST_ROUTING_OPERATIONS_DEF MSC_ST_SALES_ORDERS ST_SALES_ORDERS_DEF MSC_ST_SHIFT_DATES ST_SHIFT_DATES_DEF MSC_ST_SOURCING_HISTORY ST_SOURCING_HISTORY_DEF MSC_ST_SOURCING_RULES ST_SOURCING_RULES_DEF MSC_ST_SUPPLIES ST_SUPPLIES_DEF MSC_ST_SYSTEM_ITEMS ST_SYSTEM_ITEMS_DEF MSC_ST_TRADING_PARTNERS ST_TRADING_PARTNERS_DEF MSC_ST_TRADING_PARTNER_SITES 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 PARTITION_NAME MSC_ST_SYSTEM_ITEMS ST_SYSTEM_ITEMS_LEG MSC_ST_SYSTEM_ITEMS ST_SYSTEM_ITEMS_DEF MSC_ST_SYSTEM_ITEMS 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. Select table_name, partition_name from all_tab_partitions where table_name in ('MSC_ITEM_HIERARCHY_MV','MSC_RESOURCE_HIERARCHY_MV') order by table_name 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 PARTITION_NAME MSC_ITEM_HIERARCHY_MV ITEM_HIERARCHY_0 MSC_ITEM_HIERARCHY_MV ITEM_HIERARCHY_1 MSC_ITEM_HIERARCHY_MV ITEM_HIERARCHY_2 MSC_RESOURCE_HIERARCHY_MV RES_HIERARCHY_0 MSC_RESOURCE_HIERARCHY_MV RES_HIERARCHY_1 MSC_RESOURCE_HIERARCHY_MV 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 PartitionsRemember 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 table_name, partition_name from all_tab_partitions where table_name like 'MSC%' order by table_name, partition_name

1st List - Default Installation - 11.5.9

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

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

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

MSC_ROUTINGS ROUTINGS_4 MSC_ROUTINGS ROUTINGS_5 MSC_ROUTINGS ROUTINGS__1 MSC_ROUTING_OPERATIONS ROUTING_OPERATIONS_0 MSC_ROUTING_OPERATIONS ROUTING_OPERATIONS_1 MSC_ROUTING_OPERATIONS ROUTING_OPERATIONS_2 MSC_ROUTING_OPERATIONS ROUTING_OPERATIONS_3 MSC_ROUTING_OPERATIONS ROUTING_OPERATIONS_4 MSC_ROUTING_OPERATIONS ROUTING_OPERATIONS_5 MSC_ROUTING_OPERATIONS ROUTING_OPERATIONS__1 MSC_SALES_ORDERS SALES_ORDERS_0 MSC_SALES_ORDERS SALES_ORDERS__1 MSC_SUPPLIES SUPPLIES_0 MSC_SUPPLIES SUPPLIES_1 MSC_SUPPLIES SUPPLIES_2 MSC_SUPPLIES SUPPLIES_3 MSC_SUPPLIES SUPPLIES_4 MSC_SUPPLIES SUPPLIES_5 MSC_SUPPLIES SUPPLIES__1 MSC_SYSTEM_ITEMS SYSTEM_ITEMS_0 MSC_SYSTEM_ITEMS SYSTEM_ITEMS_1 MSC_SYSTEM_ITEMS SYSTEM_ITEMS_2 MSC_SYSTEM_ITEMS SYSTEM_ITEMS_3 MSC_SYSTEM_ITEMS SYSTEM_ITEMS_4 MSC_SYSTEM_ITEMS SYSTEM_ITEMS_5 MSC_SYSTEM_ITEMS 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 PARTITION_NAME MSC_ALLOC_DEMANDS ALLOC_DEMANDS_0 MSC_ALLOC_DEMANDS ALLOC_DEMANDS_999999 MSC_ALLOC_SUPPLIES ALLOC_SUPPLIES_0 MSC_ALLOC_SUPPLIES ALLOC_SUPPLIES_999999 MSC_ATP_SUMMARY_RES ATP_SUMMARY_RES_0 MSC_ATP_SUMMARY_RES ATP_SUMMARY_RES_999999 MSC_ATP_SUMMARY_SD ATP_SUMMARY_SD_0 MSC_ATP_SUMMARY_SD ATP_SUMMARY_SD_999999

MSC_ATP_SUMMARY_SD ATP_SUMMARY_SD__1 MSC_ATP_SUMMARY_SO ATP_SUMMARY_SO_0 MSC_ATP_SUMMARY_SO ATP_SUMMARY_SO__1 MSC_ATP_SUMMARY_SUP ATP_SUMMARY_SUP_0 MSC_ATP_SUMMARY_SUP ATP_SUMMARY_SUP_999999 MSC_BOMS BOMS_0 MSC_BOMS BOMS_999999 MSC_BOMS BOMS__1 MSC_BOM_COMPONENTS BOM_COMPONENTS_0 MSC_BOM_COMPONENTS BOM_COMPONENTS_999999 MSC_BOM_COMPONENTS BOM_COMPONENTS__1 MSC_CRITICAL_PATHS CRITICAL_PATHS_0 MSC_CRITICAL_PATHS CRITICAL_PATHS_999999 MSC_DEMANDS DEMANDS_0 MSC_DEMANDS DEMANDS_999999 MSC_DEMANDS DEMANDS__1 MSC_EXCEPTION_DETAILS EXCEPTION_DETAILS_0 MSC_EXCEPTION_DETAILS EXCEPTION_DETAILS_999999 MSC_EXC_DETAILS_ALL EXC_DETAILS_ALL_0 MSC_EXC_DETAILS_ALL EXC_DETAILS_ALL_999999 MSC_FULL_PEGGING FULL_PEGGING_0 MSC_FULL_PEGGING FULL_PEGGING_999999 MSC_ITEM_CATEGORIES ITEM_CATEGORIES_0 MSC_ITEM_CATEGORIES ITEM_CATEGORIES__1 MSC_ITEM_EXCEPTIONS ITEM_EXCEPTIONS_0 MSC_ITEM_EXCEPTIONS ITEM_EXCEPTIONS_999999 MSC_ITEM_HIERARCHY_MV ITEM_HIERARCHY_0 MSC_ITEM_HIERARCHY_MV ITEM_HIERARCHY_1 MSC_ITEM_HIERARCHY_MV ITEM_HIERARCHY_2 MSC_NET_RESOURCE_AVAIL NET_RESOURCE_AVAIL_0 MSC_NET_RESOURCE_AVAIL NET_RESOURCE_AVAIL_999999 MSC_NET_RESOURCE_AVAIL NET_RESOURCE_AVAIL__1 MSC_OPERATION_RESOURCES OPERATION_RESOURCES_0 MSC_OPERATION_RESOURCES OPERATION_RESOURCES_999999 MSC_OPERATION_RESOURCES OPERATION_RESOURCES__1 MSC_OPERATION_RESOURCE_SEQS OPERATION_RESOURCE_SEQS_0 MSC_OPERATION_RESOURCE_SEQS OPERATION_RESOURCE_SEQS_999999 MSC_OPERATION_RESOURCE_SEQS OPERATION_RESOURCE_SEQS__1 MSC_RESOURCE_HIERARCHY_MV RES_HIERARCHY_0 MSC_RESOURCE_HIERARCHY_MV RES_HIERARCHY_1 MSC_RESOURCE_HIERARCHY_MV RES_HIERARCHY_2 MSC_RESOURCE_REQUIREMENTS RESOURCE_REQUIREMENTS_0 MSC_RESOURCE_REQUIREMENTS RESOURCE_REQUIREMENTS_999999 MSC_RESOURCE_REQUIREMENTS RESOURCE_REQUIREMENTS__1 MSC_ROUTINGS ROUTINGS_0

MSC_ROUTINGS ROUTINGS_999999 MSC_ROUTINGS ROUTINGS__1 MSC_ROUTING_OPERATIONS ROUTING_OPERATIONS_0 MSC_ROUTING_OPERATIONS ROUTING_OPERATIONS_999999 MSC_ROUTING_OPERATIONS ROUTING_OPERATIONS__1 MSC_SALES_ORDERS SALES_ORDERS_0 MSC_SALES_ORDERS SALES_ORDERS__1 MSC_SUPPLIES SUPPLIES_0 MSC_SUPPLIES SUPPLIES_999999 MSC_SUPPLIES SUPPLIES__1 MSC_SYSTEM_ITEMS SYSTEM_ITEMS_0 MSC_SYSTEM_ITEMS SYSTEM_ITEMS_999999 MSC_SYSTEM_ITEMS 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 TRev 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