Planning - Maintenece and Performance

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

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

DBAs 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 collections 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.

Planning - Maintenece and Performance

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Planning - Maintenece and Performance

Uploaded by

Copyright:

Available Formats

Copyright 2013 Oracle Corporation

All Rights Reserved

You might also like