9.

Handling Performance Issues In MRP

Foremost thing is to check whether the Gather Schema Statistics has been
run frequently or not.
Problem with MPS Relief Worker and MDS Relief Worker
Either the MPS Relief Worker or MDS Relief Worker is running
continuously or more relief workers are spawned. So basically we have to
check in the MRP_RELIEF_INTERFACE the statuses of the records.
About MRP_RELIEF_INTERFACE
MRP_RELIEF_INTERFACE is the table, which is used by the planning manager
for performing supply relief and demand relief.
Will discuss more in detail about how the supply records gets in their and
how they are being processed by the planning manager in later sections.
Presently we discuss about the columns relief_type and process_status.
Relief_type 1 indicates MDS Relief records
Relief_type 2 indicates MPS Relief records
Process_status 2 indicates records are waiting to be processed, 3
indicates records are being considered by the planning manager for process,
4 indicates that the records are errored out and 5 indicates records are
successfully processed. So the concern is records with process_status
4.There should not be any record with process_status 4 in this table. If so
then the records needs to be resubmitted for processing.
Please check the following note to know about resubmitting of records
NOTE.103037.1 - Issues with the MRP_RELIEF_INTERFACE TABLE
If the following profiles are set to yes then the records will be taken for
process by the planning manager.
MRP: Consume MDS
MRP: Consume MPS
And also the relief check box in MDS names window and the MPS names
window should have been checked.
If the above said profiles are set to No then the records gets into
MRP_RELIEF_INTERFACE table but will not be processed by the planning
manager.

Problem with Planning Manager or Planning Manager Once a Day

Task worker
If the planning manager is running for a longer time then the case
mentioned for MPS relief Worker could also be one reason.
Check the following profiles
a ) MRP: Purge Batch Size
Setting this profile to a low or high value will cause performance issues.
Default is 75000
b ) MRP: Planning Manager perform function in Loads
Set this profile to No
c ) MRP: Planning Manager Batch Size
A high value will make the planning manager to run for a longer time.Default
is 500 which is recommended and it can be set to 1000 max.
Problem with Memory Based Snapshot, Snapshot Monitor, Snapshot
Workers.
Check the following profile
MRP: Snapshot Workers.
Lets say that the profile has been set to a value of 5.
A ) Check the standard manager process defined.
Navigation:
System Administrator > Concurrent > Manager > Define
Query for the standard manager and the click on the work-shifts and check
the field Processes.

The basic idea is that this should be set to a value based on the following
formula
Number of standard Manager processes = 4 + (2 * profile option
value).
So in the above case it will be 4 + (2*5) = 14. So minimum of 14 processes
are required.

The recommended setting is 15 to 20 processes.

B ) Check the profile Concurrent: Active Request Limit.
This setup determines how many requests that can be active at a time. This
should also follow the same formula as above and by default the profile is set
to Null, which is recommended
C) Set the profile Concurrent: Sequential Requests to No
D) If you are able to see the following message in the log files
LOCKS MTL_MATERIAL_TRANSACTIONS_TEMP TABLE
This indicates the fact that the MTL_MATERIAL_TRANSACTIONS_TEMP is
locked and the processes are waiting for the lock to get released.This can
happen if the plan option Snapshot Lock Tables is checked.
Navigation:
Material Planning > MRP > Options

If it is checked then uncheck the option and rerun the MRP to see if it
completes successfully.
E) If everything is fine as mentioned above then it may be a bug which might
have been fixed or need a fix so please generate trace and tkprof to find out
which is the sql that is causing the issue.
To find out the current running sql use the following sql.
SELECT r.request_id,
sq.sql_text,
ss.SID,
ss.SERIAL#
FROM fnd_concurrent_requests r,
v$process p,
v$session ss,
V$SQLAREA sq
WHERE r.request_id IN (&request_id1, &request_id2, ...)
AND p.spid = r.oracle_process_id
AND ss.paddr = p.addr
AND sq.ADDRESS = ss.SQL_ADDRESS;

Check the locks on the above objects, which the requests are accessing at
the moment and see if removing locks is making the plan to complete
successful.
F) In some cases the following sql may be the one that is causing the issue.
DECLARE ret_code NUMBER := 0;
snp_exception
EXCEPTION;
snp_timed_out
EXCEPTION;
BEGIN
ret_code := dbms_pipe.receive_message(:ipname, 10);
IF ret_code = 1 THEN
RAISE snp_timed_out;
END IF;
IF ret_code <> 0 THEN
RAISE snp_exception;
END IF;
dbms_pipe.unpack_message(:opname);
dbms_pipe.unpack_message(:request_id);
dbms_pipe.unpack_message(:msg_type);
dbms_pipe.unpack_message(:file_type);
IF dbms_pipe.next_item_type = 9 THEN
dbms_pipe.unpack_message(:dat);
dbms_pipe.unpack_message(:ctl);
dbms_pipe.unpack_message(:dis);
dbms_pipe.unpack_message(:bad);
END IF;
EXCEPTION
WHEN snp_timed_out THEN
:time_out := 1;
WHEN others THEN
:err_msg := '( ' || to_char(ret_code) || ') ' || sqlerrm;
:err_code := SQLCODE;
END;
In this case bouncing the database will help.
Performance Issue with Memory Based Planner
Remember Memory based planner works in memory and it will not work in
sqls.So if the MBP is running for a longer time then taking a trace on that will
never help to identify the cause.So taking a trace on MBP is not required.
It may be due to huge amount of data which is the first reason to be

suspected.Some setups which can cause the MBP to run for a longer time.
1.Launching the plan with All Planned Items
2.Launching a supply chain plan with more organizations
3.Launching with Pegging turned on
So check if launching the plan with demand schedule items only is making
the plan to complete faster. If supply chain plan, then reduce the number of
organizations and break the existing plan into 2 or more plans. Disable
pegging for all non-critical items.
These are generic recommendations, which can be tried to see if the issue is
happening because of volume of data or some other thing