vcp perf maintenance v1-2

Copyright 2013 Oracle Corporation

All Rights Reserved

BEST PRACTICES – PERFORMANCE and MAINTENANCE of VCP

We encourage you to use this document along with apscheck.sql to determine the status and

to plan the maintenance required to achieve best performance using Oracle Value Chain

Planning suite of products.

Information regarding apscheck.sql is as follows:

VCP - Value Chain Planning (formerly APS - Advanced Planning and Scheduling)

This script is valid for 11.5.x through R12.1.x

Revision Date: 28-OCT-2013

Important: Download the latest version of this script to have the latest revision

NEW !! - Oct-2013 - Optionally, you can install our new Diagnostic Tool for apscheck so that users can run

this via the Diagnostic Framework -

See Document 1475522.1

This script is revised every time new Rollup/Cumulative patches are released for the VCP Applications

For 11.5.x - see Document 223026.1 - List of High Priority Patches for the VCP Applications for the latest

patch information

For R12 - see Document 421097.1- R12 - Latest Patches and Critical Information for Value Chain Planning

(aka APS - Advanced Planning and Scheduling)

For 12.1 - see Document 746824.1 - 12.1 - Latest Patches and Installation Requirements for Value Chain

Planning (aka APS Advanced Planning & Scheduling)

For 12.2.x Please see Document 1361221.1 - FAQ - Getting Started With 12.2 for Value Chain Planning

(VCP) Applications

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?id=1475522.1





Error! Use the Home tab to apply Heading 1 - no numbering to the text that you want to appear here. Oracle Corporation Confidential - For Oracle internal use only of 19

Overview

This paper will discuss the maintenance activities and best practices which should

be implemented after go-live. These activities should help keep the performance at

an acceptable level as the system grows in size.

This paper will discuss the following topics:

Monitor hardware sizing

Database/Middle tier related activities

Scripts on the ERP server itself to check for bad planning data

Audit reports on the VCP server

Applying latest patches

Other Improvements


Monitor Hardware sizing

Customers should capture the hardware specifications and other benchmark

information on or after go-live, when the plan performance is optimal. From the

planning perspective, the memory (RAM) and storage space used by the plan

should be routinely monitored at both, application server and database server.

The memory should be monitored by using TOP command (or any other tool like

vmstat) when plan is running. A sample output of TOP command is following:

CPU states: 87.4% idle, 12.0% user, 0.6% kernel, 0.0% iowait, 0.0% swap

Memory: 64G phys mem, 1886M free mem, 50G total swap, 50G free swap

PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND

69510 appsrspa 1 30 0 32G 30G cpu/135 339:38 6.37% MSONWS64.exe

77507 orasrspa 11 51 0 5320M 4885M sleep 0:43 2.98% oracle

92086 orasrspa 17 51 0 5347M 5100M cpu/129 2:41 1.81% oracle

77503 appsrspa 1 52 0 99M 73M sleep 0:53 0.86% frmweb

………

The above output above shows that the system has 64 GB of physical memory, of

which 1886 MB is currently free, and the rest is occupied by other processes. The

ASCP Plan (MSONWS64.exe) is running for the last 339 minutes and 38 seconds

and is using 32 GB of memory.

These metrics, related to memory consumption and plan completion time, should

be collected when the plan performance is optimal, monitored on a periodic basis.

If significant changes occur, based on factors like additional organizations being

added or the number of demands increased, the benchmark should be reset and

monitoring continued from the new basis.

If plan starts consuming more memory after certain interval of time (a month, a

quarter or a year etc), one of the key factors could be an increase in the input data,

i.e. number of planned items, number of sales orders, forecast etc.


Following are a few sample SQL scripts that will capture the plan data for

benchmarking. These data are the basis for periodic comparative analysis.

Items:

select count(*) from msc.msc_system_items where plan_id=<<plan_id>>;

Customer needs to provide the plan_id of its plan which can be taken from the following SQL

Select plan_id from msc_plans where compile_designator=<<plan name>>;

Forecasts:

select count(*) from msc.msc_demands where plan_id=<<plan_id>> and origination_type =29;

Sales Orders:


Purchase Orders and Purchase Requisitions:

select count(*) from msc.msc_supplies where plan_id=<<plan_id>> and order_type in (1,2);

Work Orders, Work order demands and Resource requirements:

select count(*) from msc.msc_supplies where plan_id=<<plan_id>> and order_type =3;


select count(*) from msc.msc_resource_requirements where plan_id=<<plan_id>>;

Planned Orders:

select count(*) from msc.msc_supplies where plan_id=<<plan_id>> and order_type =5;

BOM and BOM components:

select count(*) from msc.msc_boms where plan_id=<<plan_id>> ;

select count(*) from msc.msc_bom_components where plan_id=<<plan_id>> ;

Routing related data

select count(*) from msc.msc_routings where plan_id=<<plan_id>> ;

select count(*) from msc.msc_routing_operations where plan_id=<<plan_id>> ;

select count(*) from msc.msc_operation_resources where plan_id=<<plan_id>> ;


Trading Partners:

select count(*) from msc.msc_trading_partners where partner_type=3 and sr_instance_id=<<instance

_id>> ; -- Organizations

select count(*) from msc_plan_organizations_v where plan_id=<<plan_id>>; -- planned organizations in

a plan

select count(*) from msc_trading_ partners where partner_type==1; --Suppliers

select count(*) from msc_ trading_partners where partner_type==2; --Customers

Trading Partner Sites:

select count(*) from msc.msc_trading_partner_sites where partner_type=1 and sr_instance_id=<<instance

_id>> ; -- Supplier sites

select count(*) from msc.msc_trading_partner_sites where partner_type=2 and sr_instance_id=<<instance

_id>> ; --Customer sites

It is expected, if plan input data is increased or plan horizon is increased, the plan

may take more memory and time. If peak memory, used by the plan or other

processes running on same system, is close to total memory of the system (e.g.

after adding two more organizations) customers should plan to re-size the system

perhaps adding more memory to the machine.

A 32 bit operating system may be too small for a high performance production

system and most likely, will not provide sufficient ability to expand. As your plan

size approaches the maximum limit of the resources supported by the operating

system, you may experience performance derogation or failures. A 64-bit

operating system is recommended to be used on the concurrent manager node/web

logic for performance of larger plans.


Database/Middle tier related activities

Run “Gather Schema Statistics” on regular intervals

If table statistics are not gathered or schemas are not analyzed at frequent

intervals, performance of the application can degrade. Stale statistics

causes poor performance. It is recommended to run the “Gather Schema

Statistics” concurrent program at frequent intervals (daily or weekly).

If the planning server is deployed in a distributed architecture, the Gather

Schema Statistics program should be run on the destination for “MSC”

schema. In addition, the Gather Schema Statistics program should be run

on the source instance (ERP instance) for INV, BOM, WIP, PO, MRP,

ONT and AP schemas.


A single table can also be analyzed by using the “Gather Table Statistics”

concurrent program. This is useful when performance is degrading

because of old statistics in few tables only (e.g. many modifications have

been made on these tables).

Old, unused plans should be periodically purged. These plans will result in

redundant data in the database tables, which can impact UI performance.

Old MBP data files should be purged from the application server at regular

intervals. This will prevent the system running out of disk space. MBP

data files are stored at $APPLCSF/out directory. In addition, for Rapid

Planning, the older binary files should also be deleted from the WebLogic

server, preferably after the engine managed server is bounced or a new

deployment of a the engine ear file.

DBA’s should properly manage the extent sizes through following storage

parameters:

- INITIAL_EXTENT

- NEXT_EXTENT

- PCT_INCREASE

- MAX_EXTENTS

Poor extent management can lead to fragmentation and poor performance.

Review the support note 220115.1 for managing table spaces for VCP

implementations.

For application performance issues (e.g. some concurrent program is taking

a longer than usual), users should enable the trace at concurrent program, or

database trace, to diagnose the issue. Trace helps identifying the SQL which

is taking excessive time. DBAs can further tune the SQL. Once the SQL is


identified, the trace should be turned off. SQLTXPLAIN and AWR reports

can also be used for diagnosing performance issues.

To improve the performance of VCP collections, run the Refresh Collection

Snapshots program in the automatic mode on a periodic basis. Automatic

Refresh truncates the MLOG$ tables and performs a Complete Refresh of

the snapshots used for Collections. Truncation of the MLOG helps to

recover space, and resets the high water mark for the table, which helps with

performance and space allocation for the RDBMS.

Do not create extra plan partitions. Unused plan partitions consume space in

the Oracle RDBMS SGA Data Dictionary and can be bad for performance.

Rebuild the indexes on a periodic basis.


Scripts at ERP server

There have been many cases where plans have failed because of bad data in the

ERP instance. The ‘bad data’ term here is in reference to planning purpose only.

For example, if Item attribute fixed_order_quantity is set to 1, there could be cases

where plan can create millions of planned orders each of quantity 1.

These issues can be minimized by proactively removing/correcting this bad data.

Following are some sample scripts which can be used to correct most obvious bad

records in the source instance, Oracle ERP. The values in the scripts can be

changed to suit your business needs.

Identify item attributes related to order modifiers to avoid unwanted order

sizes and plan failures due to it, e.g. a plan can fail if number of planned

orders for a demand exceeds the profile value MSC: Maximum number of

planned orders per demand.

Select msik.segment1, msik.organization_id, msik.fixed_order_quantity,

minimum_order_quantity, fixed_days_supply, maximum_order_quantity from

mtl_system_items_b msik

WHERE (((msik.mrp_planning_code IS NOT NULL AND msik.mrp_planning_code <> 6)

OR (msik.PICK_COMPONENTS_FLAG = 'Y' OR msik.BOM_ITEM_TYPE=3))

AND ( msik.inventory_item_flag = 'Y' OR msik.eng_item_flag = 'Y')

AND msik.planning_make_buy_code IN (1,2) -- planning make/buy code

AND msik.primary_uom_code IS NOT NULL)

AND (nvl(minimum_order_quantity,0) > 100000 -- minimum order quantity is greater than 100 000

OR nvl(fixed_order_quantity,100) < 5 -- fixed order quantity is less than 5

OR nvl(fixed_days_supply,0) > 40 -- fixed days supply is greater than 40

OR nvl(maximum_order_quantity, 9999)=0) -- maximum order quantity is 0;

Run the above script for planned organizations only. Planners can change

the values/script as per their business needs, e.g. there could be a valid

requirement to keep minimum order quantity > 100000.


Identify items with big lead times: Verify if planning time fence and other

item lead times are correct. Big lead times may give undesired planning

results, e.g. if planning_time_fence_code is big, no new supply would be

created till planning_time_fence_date. Again users can change the values as

per their business needs.

select msik.segment1, msik.organization_id, msik.planning_time_fence_code,

msik.postprocessing_lead_time, msik.preprocessing_lead_time, msik.FULL_LEAD_TIME from

mtl_system_items_b msik






AND (planning_time_fence_days > 100 -- planning time fence days

OR postprocessing_lead_time > 20 -- post processing lead time

OR preprocessing_lead_time > 10 -- pre processing lead time

OR FULL_LEAD_TIME > 100 -- processing lead time

);


Identify Sales orders with very big order quantities:

If the demand quantities are very big, might be wrongly entered, the plan

might fail because of numeric precision. Following query lists all the sales

orders with ordered quantity greater than 10 million. Run this query only for

planned organizations, ship from organization.

SELECT OOL.INVENTORY_ITEM_ID,

OOL.SHIP_FROM_ORG_ID,

OOL.ORDERED_QUANTITY,

OOL.LINE_ID DEMAND_ID,

ool.line_number

from OE_ORDER_LINES_ALL OOL,

MTL_SYSTEM_ITEMS_B msik,

OE_ORDER_HEADERS_ALL ooha,

OE_TRANSACTION_TYPES_TL ottl,

MTL_SALES_ORDERS mso,

PJM_PROJECT_PARAMETERS mpp,

MTL_SALES_ORDERS_KFV so,

FND_LANGUAGES fnl,

GL_SETS_OF_BOOKS gsb,

AR_SYSTEM_PARAMETERS_ALL aspa ,

MTL_PARAMETERS mp

WHERE ool.open_flag ='Y'

AND OOL.VISIBLE_DEMAND_FLAG = 'Y'

AND OOL.ORDERED_QUANTITY <> 0

AND ool.SHIP_FROM_ORG_ID IS NOT NULL

AND ool.shipped_quantity is NULL

AND ool.schedule_ship_date IS NOT NULL

AND msik.organization_id= mp.organization_id

AND msik.inventory_item_id= ool.inventory_item_id

AND msik.organization_id= ool.SHIP_FROM_ORG_ID

AND fnl.installed_flag = 'B'

AND ool.schedule_ship_date IS NOT NULL

AND ool.header_id = ooha.header_id

AND ooha.order_type_id = ottl.TRANSACTION_TYPE_ID

AND ottl.language = fnl.language_code

AND mso.segment1 = to_char(ooha.order_number)

AND mso.segment2 = ottl.name

AND mso.segment3 = FND_PROFILE.VALUE('ONT_SOURCE_CODE')

AND so.sales_order_id = mso.sales_order_id

AND mpp.Project_ID(+)= OOL.Project_ID


AND mpp.organization_id(+) = OOL.SHIP_FROM_ORG_ID

AND nvl(ooha.org_id,-99) = nvl(aspa.org_id,-99)

AND aspa.set_of_books_id = gsb.set_of_books_id

AND (((msik.mrp_planning_code IS NOT NULL AND msik.mrp_planning_code <> 6)





AND OOL.ORDERED_QUANTITY > 10000000;

Identify forecasts from Demantra with very big quantities. Run the

following query in VCP instance:

select * From msd.msd_dp_scn_entries_denorm where quantity >

10000000;

Primary unit of measure in the items should also exist in UOM base tables

otherwise plan will fail.

The following SQL will identify the items which are MRP planned and

primary unit of measure does not exist in base UOM tables.

select msik.segment1, msik.organization_id, msik.primary_uom_code from mtl_system_items_b

msik WHERE (((msik.mrp_planning_code IS NOT NULL AND msik.mrp_planning_code <> 6)



AND msik.planning_make_buy_code IN (1,2)


and not exists (select 1 from MTL_UNITS_OF_MEASURE muom where

msik.primary_uom_code = muom.uom_code);

select msik.segment1, msik.organization_id, msik.primary_uom_code from mtl_system_items_b

msik





AND msik.planning_make_buy_code IN (1,2)


and not exists (select 1 from MTL_UOM_CONVERSIONS muom where

msik.primary_uom_code = muom.uom_code);

Audit reports at VCP server

As explained in previous section, the data from the source instance needs to be

accurate and set up properly for reliable planning output. Data from a source

instance can be corrupt due to many reasons: bad transactions, missing

transactions, human error, improper formats, conflicting and/or missing setups and

profile options.

The other approach to identify bad records is through VCP Audit reports. The

Audit Statements Report is a self-explanatory report that evaluates data setups,

profile options that are incorrectly set, invalid package bodies, invalid objects and

invalid triggers, etc. It suggests remedies for the problems that are found.

The report should be submitted on VCP instance. The concurrent program name is

“Audit Statements Report”. Users can audit collection’s setups as well as planning

data for a specific plan.

There are four categories of reports: GOP, IO, ASCP and ODP. Each group offers

following four choices:

- Summary report (Do not want to look at details of the errors and

warnings) - Detail report - errors only (details of errors only)

- Detail report - errors and warnings. (Details of both errors and warnings)

- Detail report – complete (Summary, errors and warnings included)


An example report output is as follows:

Validating Instance Setup information in the Source.

No errors.

Checking to see if the Instance information matches between the tables

MRP_AP_APPS_INSTANCES in SOURCE and MSC_APPS_INSTANCES in

DESTINATION.

No errors.

Checking if the User exists on the Source Instance.

Please note that all the users planning to run Collections should run this report.

No errors.

Checking if the Responsibility exists on the Source Instance.

MESSAGE TYPE

The RESPONSIBILITY running this Audit Report is not setup on the SOURCE

instance ERROR

ERROR- The Responsibility running this Validation program is not defined on the

Source instance.


If Collections is run using this Responsibility, it will error out in the Refresh

Snapshots program. (COUNT=1)

Checking for Planning flexfields information in the Source instance.

No errors.

Checking for Profile Option values corresponding to the Planning flexfields in the

Source instance.

No errors.

Checking for Views in the Source instance.

No errors.

Checking for Triggers in the Source instance.

No errors.

Checking for Snapshots in the Source instance.

No errors.


Report to Audit Planning Data

The output of report is as following:

Checking if there are assemblies whose standard cost is less than the

sum of the standard cost of the individual components.

No errors.

Checking if there are assemblies whose carrying cost is less than the

sum of the carrying cost of the individual components.

No errors.

Checking if the carrying cost of items in the destination organization

is less than that in the source organization.

No errors.

Checking if there are items with zero standard cost.

No errors.

Checking if there are items with zero carrying cost.


No errors.

Checking if there are substitute components, cheaper than the primary component.

No errors.

Checking if items at an alternate source is cheaper than the primary source.

No errors.

Checking if there are items with incorrect safety stock methods.

No errors.

Checking if there are items whose lead time is zero.

No errors.

Validating to check if Fixed Lead time > 100 days.

No errors.

Applying latest patches

It is recommended that the application code be kept up to date with the latest

release. The VCP server should be updated with the latest releases from VCP as

well as respective operating system. It is strongly recommended that the customer

should test these patches on a test/dev environment before applying them on a

production instance.


Other Improvements

If an item is not used any more by planning or in execution system , e.g.

replaced by a new item, these items should not be collected. The collection

of these items can be restricted by marking them as “Not Planned” in EBS

instance. This will help keeping the plan size to a minimum.

If performance issues are experienced in the “loader workers” of the

Memory Based Snapshot or Memory Based Planner process, enable Direct

Load, if it has not been enabled. Follow the support note 307443.1 for more

information.

Use the concurrent program “Cleanup Instance Partition” for creating

missing instance partitions in existing tables. Refer to note 821535.1 for

details.

After application of patches, make sure that the schema is compiled and no

MSC packages are invalid.

Users can run plans in parallel to improve overall run time. Refer to support

note 881761.1 for details.

While running plans in parallel make sure the system has enough memory

(RAM) to hold these plans. For example, if users are running ‘n’ similar

plans, then system should have at least ‘n’ CPU cores and (‘n’ * memory

required by one plan) RAM.

Regularly monitor the disk space where MBP data files are written

($APPLCSF/out) and make sure system has enough disk space. Purge older

plans on a periodic basis.

Take care of the following while copying one plan to another, to avoid

failure


- Source plan is still running

- System does not have any free plan partitions

- MBP data files created by source plan has been moved or deleted from

$APPLCSF/out

- Source Plan never Completed Normally, plan_end_date is null in

msc_plans table

Avoid any loops in the supply chain. Loops can be created due to wrong

data setups, e.g., in BOM an item is a child of its own, an item in

organization M1 is sourced from organization M2, which intern is sourcing

from M1. This can lead to poor performance of plan or plan failures,

especially in case of Rapid Planning.

ASCP breaks the loop randomly and this can be viewed in the Memory

Based Planner log file. Rapid Planning does not break the loops and it can

lead to poor performance and plan failures. Users can detect the loops in

Rapid Planning engine log file after setting the value of column

OPTIMIZE_FLAG to 4 in MSC_PLANS table for a particular plan. The

plan needs to run again with refresh snapshot after setting this value.

In the case of ASCP, if significant time is consumed in I/O operations

(connecting to database multiple times) during the Memory Based Planner

process, set the internal profile MSC_CACHE_SEQ to a higher value.

Default value is 500. This profile has to be created manually on the VCP

instance with the internal name MSC_CACHE_SEQ.

During the planning phase, the engine generates several unique indexes (e.g.

transaction_id in MSC_SUPPLIES, demand_id in MSC_DEMANDS) from

the sequences defined in the database. Engine accesses sequences from the

database and keeps its values in the buffer. If the buffer is consumed, then it

caches them by connecting to database again. In case of huge data volumes,

connecting to the database multiple times can degrade performance.

Turn off the trace and debug mode. Trace and debug can be disabled by

profile options MRP:Trace Mode and MRP:Debug Mode respectively.

vcp perf maintenance v1-2

Documents

vcp value chain planning

planning perspective

vcp server

oracle internal use

r12 latest patches

maintenance of vcp

plan performance

latest patch information