MFG DEM Advisor Webcast 2012 1114

2009 Oracle Corporation Proprietary and Confidential
1
FYI: New Portal with same DocID
The Upcoming Webcast Schedule and Archived
Webcasts documents have been consolidated into one
document.
Doc ID Doc
740966.1 ID740964.1
Advisor Webcasts
Current Schedule
and Archived
recordings
2
Doc ID 740966.1
Demantra Solutions Live Advisor
Webcast
Day, Date, 2004 Upcoming Community Webcasts:
November 14, 2012
time
11:00 am ETp.m. ET am
/ 9:00
MT / 8:00 am PT
Teleconference Access: December 12, 2012: Demantra Proactive Solutions
VOICE
North STREAMING
America: xxxx Live Demo and Discussion (Doc Id 800030.1)
ENABLED
International: xxxx
Password: Advisor For complete details on Demantra Solutions Webcast Events,
North America:
(866) 627-3315 please see Note 800030.1.
For complete details on Value Chain Planning Webcast Events,
International: please see Note 837233.1.
+1-706-758-7972
For complete details on All Other upcoming Oracle Advisor
Doc Id: 1148600.1 Webcast Events, please Note 740966.1.
Conf Id: Do you have any topic requests for future Advisor Webcast
Oracle DEM Events? Please email your suggestions to
[email protected], subject: Topics of Interest.
2012 Oracle Corporation Proprietary and Confidential 3

<Insert Picture Here>
Becoming a Demantra Data Master

Jeff Goulette, Senior Principal Technical Support Engineer
Clay Moore, Senior Technical Engineer
Safe Harbor Statement
The following is intended to outline our general

product direction. It is intended for information
purposes only, and may not be incorporated into
any contract. It is not a commitment to deliver any
material, code, or functionality, and should not be
relied upon in making purchasing decision. The
development, release, and timing of any features
or functionality described for Oracles products
remains at the sole discretion of Oracle.

<Insert Picture Here>
Becoming a Demantra Data Master

Jeff Goulette, Senior Principal Technical Support Engineer
Clay Moore, Senior Technical Engineer
AGENDA
Gain a better understanding of Demantra data points:

Key Datum
Data flow within Demantra
Data flow between integrated systems
Database objects
MDP_MATRIX
SALES_DATA
Using SQL to investigate Demantra Data
Best Practice

Key Database Objects
COMPUTED_FIELDS
table for SERIES
TRANSFER_LIST
table for INTEGRATION INTERFACE
TRANSFER_QUERY
table for DATA PROFILES
TRANSFER_QUERY_SERIES
table for list of SERIES selected in DATA PROFILE
TRANSFER_QUERY_LEVELS
table for LEVEL PROFILES
GROUP_TABLES -- table for LEVELS
Sales_Data
Mdp_matrix
Promotion_Data

Key Columns
min_fore_level parameter
Minimum forecast level that the engine will forecast. From that level down, the engine will split the
forecast using the precalculated proportions in the mdp_matrix table.
Max_Fore_Level
The maximum level on the forecast tree at which a forecast may be produced. Upon failure at this
level, the NAVE model will be used if enabled.
do_forecast
LOB Process workflow updates database column do_forecast so that only combinations within the
LOB are forecast
prediction_status
In mdp_matrix, the prediction_status indicator of a combination instructs the Analytical Engine
how to handle this combination.
Level_id
Identifier of the level from which the method was launched.

Key Columns
do_fore
Specifies whether to perform forecasting on this item-location combination. Choose one of the
following values:
0Do Not Do Forecast.
1Do Forecast (the default).
2Do Zero Forecast. This combination is not used in aggregation.
max_sales_date
The latest sales date loaded as history in the system.
Last_date
Last date of actual sales, to be used by the Analytical Engine and the proport mechanism. No
dates after this are used towards the forecast or the proport calculation.
prop_changes
Specifies whether to run proport on this combination; used by the Run_full_matrix_proport
parameter.

Key Columns
aggri_98
User input Specifies whether to aggregate demand for this item-location combination, if this
combination is young. See "prediction_status".
0Will Not Be Used in Aggregation
1Will Use Aggregation
aggri_99
User input Specifies whether to aggregate demand for this item-location combination, if this
combination is dead. See "prediction_status".
do_aggri
Specifies whether to perform aggregation on this item-location combination. Choose one of the
following values:

Key Columns
FillParameter
This parameter is used by the preprocessing module of the Analytical Engine. It specifies how to
handle null (missing) values.
Use one of the following values:
If equal to 0, null values are replaced by zeros and FillMethod is ignored.
If equal to 1, null values are filled as specified by
FillMethod
This parameter is used by the preprocessing module of the Analytical Engine, if FillParameter
equals 1
The FillMethod parameter specifies how to fill any null or missing values.
Use one of the following values:
linear interpolation:
Fill in values by linear interpolation of nearest neighbors.
Omitting missing values:
Omit the null values and adjust the time scale of causal factors and trends of the Holt
procedure;
This parameter is ignored if FillParameter equals 0.

Overview

Loading Data - sqlldr
Implement multiple freelists or freelist groups on the destination tables

Place undo tablespace and online redo logs on Solid-state disk
Use the Oracle Stripe and Mirror Everywhere approach (RAID 0+1, RAID10)
Continue to place your objects into separate tablespaces
Parallelize the data loads considering your number of processors
Try to saturate your processors with parallel processes
Monitor your CPU utilization during the load
Disable archiving during load

Loading Data
There are a few options here
1. Upgrade to Demantra 7.3.1.3. There is a tool starting with that version
for rebuilding/re-ordering the Demantra data tables.
2. If your data is partitioned by date then you can insert by partition in
parallel.
In other words, if your partition is by calendar year, you can
insert into 2011 and 2012 using different queries like this running at the same
time:
INSERT AS SELECT WHERE sales_date BETWEEN 2010-jan-01 AND 2011-jan-01
ORDER BY pk_columns;
INSERT AS SELECT WHERE sales_date BETWEEN 2011-jan-01 AND 2012-jan-01
ORDER BY pk_columns;
etc.
3. You can use PL/SQL and use bulk selects and inserts to limit context
switching. Your script could read 10,000 rows into memory, write them out in
bulk, and then commit

Improving Your Batch Forecast
How are you measuring forecast fit against historical actuals?
If you are looking at historical batch vs historical actuals make
sure you filter for combinations where the system forecast status
is good for forecasting.
This ensures that you are looking only at combinations where a
forecast is being generated.
The critical element we found was the correct setup of the
forecast tree to ensure that the majority of the forecast is being
generated at the lowest level.
The selection of the lowest level combination in the hierarchy
you expect and want the engine to get a forecast is critical.

To examine which levels the forecast is being generated use the
SQL statement
select level_id, count(*)
from mdp_matrix
where prediction_status = 1
group by level_id
order by level_id
The majority of the combinations should have a forecast
generated at the level set in the min_fore_level parameter.
If you have combinations with intermittent data, check the
intermittcrieteria parameter to make sure that these
combinations are being flagged correctly as intermittent so the
engine uses the intermittent models.

The methodology I use is to do forecast tuning is as follows:
Create a number of series to store previous engine runs output
Identify the combinations where the engine results are poor
Evaluate the levels in the MDP matrix
Make one change at a time to parameters or forecast tree
Rerun engine
Compare results to previous engine run to see if there is an
improvement
Repeat process until you are happy with the results

Prediction_Status
Controls how the Analytical Engine uses this combination. Each combination has one of the
following prediction status values:
96 (No Forecast) This status means that the Analytical Engine will completely ignore this
combination.
97 (Create Zero Forecast) --- A user has set do_fore equal to 2 manually.
This status means that the Analytical Engine will insert a zero forecast for this
combination but otherwise ignore it.
98 (Young) Sales for this combination are too new to be used for prediction.
99 (Dead) Sales for this combination are not recent enough to be used for prediction.
1 (Live or Active)Neither young nor dead.
The Analytical Engine ignores any young or dead combinations, except when it is necessary
to aggregate

Prediction_Status
In case of aggregation, Demantra considers the do_aggri, aggri_98, or aggri_99 flag of the combination.
These may be updated to 1, use aggregation is_fictive
1 means that the combination was created through Member Management and no data has been loaded for it
yet.
0 means that there are sales for this combination
2 means that there are no sales for this combination
3 means that an error occurred while loading this combination or while redefining this combination.
Demantra sets the prediction_status indicator as follows.
For fictive combinations (is_fictive = 1), Demantra automatically sets the prediction status to 98 (young)
For real combinations (is_fictive equal to 0 or 2), Demantra uses the following rules:
If do_fore is 0 (do not forecast), then prediction_status will be 99 (dead)
If do_fore is 1 (do forecast - default), then prediction_status is set as follows:
If the combination is dead because of the dying_time parameter, then prediction_status is set to 99
(dead).
If the combination is young because of the mature_age parameter, then prediction_status is set to
98 (young).
Otherwise, the prediction_status is set to 1
If do_fore is 2 (do zero forecast), then prediction_status will be 97 (create zero forecast).
Note: We will see a flowchart of this logic later

MDP_MATRIX
I find it useful to run this query after the forecast engine to debug analytical
engine problems.
select level_id,count(*) from mdp_matrix

where prediction_status = 1
group by level_id
order by level_id;
This query tells you how many combinations are being forecasted at the various
levels in your forecast tree. The majority of combinations should be forecasted
at the level set by the min_fore_level parameter and very few at the highest level:
Sample output:
LEVEL_ID COUNT(*)
---------------------- ----------------------
2 18
3 13

prediction_status = 1 and do_fore = 1
Review the number of active combinations/Individual Branches should

optimally be set between 1000-2000 per branch for Demand Management
/Sales and Operation Planning Engine runs.
This will give us an understanding if some of the individual branches have an
unusually large number of rows and thus might indicate that the engine is not
efficiently dividing up the parallel tasks.
Run the following SQL to determine how even the branches are being split by
the engine:
select count(*),
branch_id
from mdp_matrix
where prediction_status = 1 and do_fore = 1 group by branch_id;

prediction_status = 1 and do_fore = 1
Based on the results of this SQL, we may want to adjust the branch id
multiplier and/or the number of engines, both of these settings are found
in the Engine Administrator
This will give us an understanding at which level of the Forecast Tree
the forecast is being generated.
Having a majority of combinations higher on the forecast tree might
indicate either a poorly designed forecast tree and/or engine parameters
that are too strict
Based on the results of this we would adjust the Forecast Tree to see
if choosing a different hierarchy might produce a better forecast, for
more combinations, at a lower level.
select count(*),
level_id
from mdp_matrix
where prediction_status = 1 and do_fore = 1 group by level_id;

Performance Related Data Investigation
This will allow you to assess the fragmentation, chain_cnt and

statistics are up to date;
select *
from user_tables
order by num_rows desc;

MDP_MATRIX
1) select count(*), do_fore, prediction_status from mdp_matrix group by
do_fore,prediction_status;
This will give us an overview of how many combinations have a prediction_status = 1,
good for forecast). This will also ensure that we do not have any invalid combinations as
there should be no null values in either/both columns. Any null values should be set to
do_fore = 1 and prediction_status = 1)
2) update mdp_matrix set prediction_status = 99, prop_changes=1;

commit;
exec proport;
This will reset all of the prediction statuses to 'do not forecast' and then let proport make
sure that only truly good for forecast combinations are set to prediction_status = 1
3) select count(*), do_fore, prediction_status group by do_fore,prediction_status;

Re-run SQL #1 again to see if the count has changed and make sure that at least some
combinations are good for forecast, indicating sufficient sales_data for the engine to
process. If there are not any set to prediction_status = 1, then you need to evaluate why
there is no sales_data

MDP_MATRIX
Check the forecast tree structure , use following SQL to see the
nodal structure
SELECT count(*),level_id FROM mdp_matrix
WHERE do_fore = 1 AND
prediction_status = 1
GROUP BY level_id
order by level_id;
Also use treehierarchytest.exe to validate the forecast tree.
Then run the Proport procedure with parameters set to "ma" and "1
See more on this later in this presentation
Then run the forecast engine to check the generated forecast, at
the level where the business normally looks
Also check for parameters FillParameter and FillMethod
More on these parameters later

MDP_MATRIX and the CTO Model
A specific combination shows in the engine log as receiving a model and level
forecast but when you review the combination in the database, the model and
level_id are not populated
To validate this issue please do following:
1. Set LEVEL_ID=99 ,MODELS=none, ITEM_NODE=0 and LOC_NODE=0
2. Run Engine
3. Observe MDP_MATRIX for problematic combinations and use following query:
select item_id,
location_id,
ITEM_NODE,
LOC_NODE,
level_id,
models
from mdp_matrix
All nodes with non zero ITEM_NODE,LOC_NODE values should have proper
LEVEL_ID and MODELS output

MDP_MATRIX and CTO Model Cont
Procedure ProcessTempMdpTable0
Is responsible for updating information into the mdp_matrix
level_id and models columns are updated by this procedure
Model information is gathered in MDP Matrix.
MDP Matrix is on ITEM_ID and LOCATION_ID resolution. So there
may be the same ITEM_NODE LOC_NODE for different rows in MDP
Matrix .
CTO Model information is written only for those combinations that have
received forecast.
For example , if we have 3 nodes at level 2
Forecast succeeds on level 4
Only 2 of 3 combinations received output
So it may be that under same parent some item_id/location_id
will receive models update and some will not.

MDP_MATRIX
The following SQL will tell you
How many active combinations are in mdp_matrix
prediction_status = 1 and do_fore= 1
How many Young
prediction_status = 98 and do_fore= 1
Dead combinations are part of the aggregated sales history, do_aggri =
1 and aggri_98/aggri_99 = 1
Used by the Engine in order to create a forecast
prediction_status= 99 and do_fore= 1
Interesting exercise:
Determine all combinations then
Determine how many are dead

MDP_MATRIX - ACTIVE COMBINATIONS and ENGINE PERFORMANCE
Introducing a useful SQL

Whenever encountering Engine performance issues and/or
OutOfMemory errors the following SQL needs to be run:
Select count(*),
prediction_status,
do_fore,
do_aggri,
aggri_98,
aggri_99,
level_id
from mdp_matrix
Group by prediction_status, do_fore, do_aggri, aggri_98, aggri_99, level_id;

MDP_MATRIX
COUNT(*) PREDICTION_STATUS DO_FORE DO_AGGRI AGGRI_98 AGGRI_99 LEVEL_ID
4 99 1 1 1 1 3
169 99 1 1 1 1 2
150000 1 1 1 1 1 2
34 99 1 1 1 1 4
3 99 0 1 1 1 2
6 98 1 1 1 1 5
44 98 1 1 1 1
6 99 0 1 1 1 5
2086 99 1 1 1 1 5
1101 99 1 1 1 1
50000 1 1 1 1 1 3
You have 4 available CPUs on your machine.

The above SQL output shows 200k active combinations plus another 3444 Young (98) and Dead (99) combinations to be used in
aggregation.
For Engines you have 4 CPUS x 1.5 = 6 Engines (5 distributed)
For branches you would have 200k active combs / 1500 active combs per branch (average) = 133.33 branches total.
Then for the branch ID multiplier you would have 133.33 branches / 6 engines = 22.22
Of course you cannot have a partial number for the multipler and it is always best practice to use an even number.
Taking into account the 3400 Young and Dead combinations you would round up to set the BranchID multiplier = 24.

Contains one record for each known combination of lowest-level item and lowest-level
location. This includes all combinations that have had sales, as well as any combinations
created manually in the user interfaces. Matrix series select data from this table.
do_fore
Perform forecasting on this item-location combination. Choose one of the following
values:
0Do Not Do Forecast
1Do Forecast, the default
2Do Zero Forecast. This combination is not used in aggregation
do_aggri
Perform aggregation on this item-location combination. Choose one of the following
values:
aggri_98
Aggregate demand for this item-location combination, if this combination is young. See
"prediction_status"
aggri_99
aggregate demand for this item-location combination, if this combination is dead. See
"prediction_status".
level_id
The strategy of the forecast tree where the forecast for this combination was generated

Explain the Column prediction_status
Controls how the Analytical Engine uses this combination.

Each combination has one of the following prediction status
values:
96 (No Forecast) This status means that the Analytical Engine

will completely ignore this combination.
97 (Create Zero Forecast) A user has set do_fore equal to 2
manually. This status means that the Analytical Engine will insert
a
Zero forecast for this combination but otherwise ignore it
98 (Young) Sales for this combination are too new to be used
for prediction.
99 (Dead) Sales for this combination are not recent enough to
be used for prediction.
1 (Live or Active)Neither young nor dead.

MDP_MATRIX
My Data Combinations do not have do_fore=1 or prediction_status=1
To resolve we are submitting an update to repair
Engine does not directly look at do_forecast
It references the prediction_status series
When proport is run and do_forecast=0 the results should translate to
prediction_status=99 for which the engine will not generate a forecast
The primary method to resolve is Run proport to update prediction_status

You can ensure proport only runs on the desired combinations by setting
prop_changes=1, another hidden series based on the do_fore series.
If do_forecast is modified you set the series connect to prop_changes=1.
Prior to batch run, the expectation is that proport is being executed
If you are loading data, proport should run automatically

If not tied to data load you need to call the procedure or run a workflow step
which calls proport for the specific engine_profile you care about.

MDP_MATRIX Prediction_Status
Y do_fore=0, do not forecast
Is_Fictive=1 Prediction_status =98 or young
do_fore=1, forecast-default
N do_fore=2, zero forecast
Y Y
Is_Fictive=0 or 2 Do_Fore=0 Prediction_status =99 or dead
N N
Choice Not Available

Y Y
Do_Fore=1 Dying_Time? Prediction_status =99 or dead
N N
Y Y
Prediction_status =97 zero fcst Do_Fore=2 Mature_Age=Y Prediction_status =98 or young
N Prediction_status =1 or Active
Choice Not Available N

MDP_MATRIX
The Analytical Engine ignores any young or dead combinations, except when it is
necessary to aggregate
In case of aggregation, Demantra considers the do_aggri, aggri_98, or aggri_99
flag of the combination recall these control aggregation
Demantra sets the prediction_status indicator as follows
For fictive combinations, is_fictive = 1, Demantra automatically sets the
prediction status to 98
For real combinations, is_fictive equal to 0 or 2, Demantra uses the following
rules:
If do_fore is 0, then prediction_status will be 99
If do_fore is 1, then prediction_status is set as follows:
If the combination is dead because of the dying_time parameter, then
prediction_status is set to 99
If the combination is young because of the mature_age parameter, then
prediction_status is set to 98
Otherwise, the prediction_status is set to 1
If do_fore is 2, then prediction_status will be 97

Explain the Column prop_changes
Specifies whether to run proport on this combination; a value of 1 means Yes.

Used by the Run_full_matrix_proport parameter.
PROP_CHANGES are used to calculate status and proportions of MDP_MATRIX
combinations.
An example of prop_changes manipulation
1. In order for the Proport procedure to review and act upon existing item location
combination records in the mdp_matrix table, the column prop_changes must
be set from 0 to 1 otherwise running the Proport procedure will not have any
effect:
SQL>update mdp_matrix
set prop_changes =1;
commit; make sure the commit is performed, otherwise the changes will not
take effect
2. From SQL run the following script to execute the Proport procedure to review all
item location combinations in the mdp_matrix table to verify if the
prediction_status is accurate and effect any change as applicable on that
column
SQL>exec proport

Explain the Column prop_changes Cont
3. Run the following sql to see if many of the item location combinations
that had a
prediction_status of 99, dead, before and now have a prediction_status
= 1, mature
select count(*), prediction_status

from mdp_matrix
where prediction_status in (1,99)
group by prediction_status;
Keep in mind that there could be many dead addresses based on the
data in the sales_data table that Proport reviews.
In this case where there were several thousand item location
combinations all with a dead address, we now had just under 900 rows
that have a correct prediction_status = 1 after performing the above.
This will vary customer by customer
4. Rerun the batch analytical engine and review the future forecast
results in the worksheet.

Whenever encountering Engine performance issues and/or

OutOfMemory errors the following SQL needs to be run:
Select count(*),
prediction_status,
do_fore,
do_aggri,
aggri_98,
aggri_99,
level_id
from mdp_matrix
Group by prediction_status, do_fore, do_aggri, aggri_98, aggri_99,
level_id;

MDP_MATRIX
COUNT(*) PREDICTION_STATUS DO_FORE DO_AGGRI AGGRI_98 AGGRI_99 LEVEL_ID

150000 1 1 1 1 1 2
6 98 1 1 1 1 5
44 98 1 1 1 1
900 99 1 1 1 1
2503 1 1 1 1 1
50000 1 1 1 1 1 3
Former Dead No level_id
The results after our manipulation of prop_changes

Notice the former dead
There is no level_id until we run the engine
The 3000+ Dead from slide 30 are now only 900

MDP_MATRIX
This information is important to use for Engine performance issues
because too many or too few active combinations per Branch can cause
issues with the Engine run.
The rule of thumb is from 1000 to 2000 active combinations per branch.
We usually start with 1,500 for the average and work from there.
To go along with that, you want to have 1.5 engines per physical CPU
Make use of your CPUs, run multiple engines you will have less branches per CPU
Plus 1.5 gb free memory per engine instance.

SALES_DATA
Contains one record for each lowest-level item, lowest-level
location, and datefor all combinations and dates where sales
actually occurred.
Sales series select data from this table.
We want to create rows in SALES_DATA without calculating any
forecast information.
Yesterday's engine run added approx 100,000 rows into
Sales_Data over 100 item/location combinations but took 14
hours to complete.
How can we insert records in sales_data table without executing
the engine?
New rows are inserted into sales_data table by INSERT_UNITS
procedure that is fire by engine. It is not the engine that is
inserting this new rows, but this procedure.
This is executed before the engines are started.

SALES_DATA Insert_Units
INSERT_UNITS procedure has 2 arguments:
(id_start_date DATE,
is_fore_col VARCHAR2)
id_start_date should be max_sales_date:
select pval from sys_params where pname ='max_sales_date'
is_fore_col should be next FORE_X value for forecast_history

select fore_column_name from forecast_history
order by time_sig desc;
Eg: if the first record returned is FORE_3 then next FORE_X is
FORE_2.
To take the first record you can also use:
select get_fore_col(0) from dual;
But you will still need to calculate the next FORE_X based on
previous selection returned.

SALES_DATA and INSERT_UNITS
WARNING EngNewSystemProcessor::FillMissingDates() detected
missing future dates rows
Either INSERT_UNITS was not run at all or failed to run correctly
Insert_Units inserts forecast rows in sales_data from max_sales_date
to max_sales_date + lead.
Analytical engine uses last_date as last date of actual sales
If you are using an older date for actual sales then the latest sales
loaded in the system as history
Please ensure you have all the records in sales_data table until
max_sales_date.
This warning could be caused by the values of the max_sales_date
and last_date / last_date_backup parameters.
Verify your dates
Should you run your forecast out of your normal window, typically
once a month, and execute the forecast two weeks early. the last two
weeks are now history not part of your monthly run. Your monthly
run would start as of the last submission.

Data Collections Irrelevant Rows
Irrelevant records in the sales_data table could be created when
Shipment and Booking History collection is run in complete
refresh mode when Purge History Data integration interface has
Profile From Date: 01-01-2000
BIIO_PURGE_HISTORY_SERIES is populated with the '01-Jan-
2000' dates hence the SALES_DATA was being inserted with
the same old data for all the MDP_MATRIX combinations.
The date range of the data profile is updated at the run time with
the date range chosen while running the concurrent collection
program.
The date range of the collection should be inclusive of the old
and new dates. It should not start with '01-Jan-2000' .
When the program is run in complete refresh mode, all the
historical data is collected from ERP. No filter on date range is
applied.

Data Collections Cont
If the requirement is to collect data only for specific date range,
then use net-change collection with Absolute or rolling date
range types.
History should be purged for both net-change and refresh
collections.
Note - The complete refresh collection is not meant for regular weekly runs.
Ideally it should be run only once (boot strap) and that too only if user wants
to collect all the data from Order Management into Demantra.
User should run only net-change collection for regular runs.
Also for bootstrap data load, if OM has more data than required
inside Demantra, net-change collection with appropriate date
range should be run.

Managing Simulations
You can control out of spec simulations by implementing several
parameters in the SYS_PARAMS tables
MatrixCombs contains the current combinations in the
MDP_MATRIX table
To direct a warning to the user submitting the simulation that the
size of the desired simulation is a potential performance killer
SimMaxSize
Threshold size of a simulation that is too large to run. Specify this as a
percentage of the total number of MatrixCombs combinations. A message is
sent, the simulation will not be ran.
SimWarnSize
The threshold size of a simulation that is large enough to trigger a warning
message to the user. Specify this as a percentage of the total number of
MatrixCombs combinations

Tasks and Branches
A small number of Tasks and/or one or two Tasks with a large count,
when compared to the other branches, would indicate that the forecast tree
is unbalanced and the engine cannot split the run into an adequate number
of tasks.
The result will be lopsided tasks which lead to memory issues. If this is
the case then re-evaluate your forecast tree to see if the data can be
grouped in alternate ways.
The unbalanced tasks are caused directly by the size of the branches the
engine allocates to the tasks.
A branch must be assigned wholly to a single task.
If a branch is particularly big then the tasks to which it is assigned is likely
to be very large as well.
Note: A branch must be associated with a single tasks

Branch Example
Engine Administrator --> View --> Branch Information and run TreeHierarchyTest.exe on
your Demantra schema
In this example it is likely that two branches contain 90814 and 61595 combinations
respectively. Since a branch must be associated with a single tasks it is not possible to break it
apart and generate a more balanced task allocation.
If you see results similar to the ones listed below (column names and values will be different
for all clients) indicating a few large Tasks, in relation to the other Tasks, then your Forecast
Tree needs to be re-evaluated.
t_ep_I_ATT_2_ep_id = 8 : t_ep_L_ATT_3_ep_id = 6 : 90814 <<< much larger
t_ep_I_ATT_2_ep_id = 6 : t_ep_L_ATT_3_ep_id = 6 : 61595 <<< than the rest
t_ep_I_ATT_2_ep_id = 8 : t_ep_L_ATT_3_ep_id = 3 : 201

Branch Example Continued
t_ep_I_ATT_2_ep_id = 8 : t_ep_L_ATT_3_ep_id = 6 : 90814 <<< much larger
t_ep_I_ATT_2_ep_id = 6 : t_ep_L_ATT_3_ep_id = 6 : 61595 <<< than the rest
To resolve this you must review the 2nd highest level in the forecast tree, below
highest/highest, as this is the level which determines the size of the branches.
If a few resulting tasks are too large it is recommended that the forecast tree level driving
branches be revised or at times completely removed from the forecast tree.
For example, if the highest level of the forecast tree is set to Brand/All Locations.
A customer has 10 brands but 2 of the brands account for 67% and 29% of all combinations.
There is a distinct possibility that the tasks resulting from these 2 branches will be too large
for the engine process.
Some possible solutions could be to remove the Brand level and instead use a different
product grouping which has a more even distribution, possibly Product Group.
It is also possible to add a location dimension to this forecast tree level for example
Customer, this will also reduce forecast tree branch size and will help result in more balanced
task allocation..
A correctly configured Tree is something done by the Implementation team and is not the responsibility of Oracle Support

Branch Example conclusion
Having tasks allocated as equal as possible not only prevents memory allocation issues but
also to allow the engine to use parallelism more efficiently.
Many small Tasks Branches can be distributed out more efficiently into smaller more
balanced tasks than a few large Tasks which cannot can be better divided among distributed
processing.
What if my total number of branch_id s generated by the engine is low even though I have
set up the branch id multiplier correctly and I have more than enough distributed engines set
up?
The solution was to remove that forecast tree level and make their max_fore_level
minus 1 level equal to Preferred DC by Class.
This will allow the maximum number of engine tasks to equal be the number of distinct
Preferred DC/Class combinations in the mdp_matrix table.
Note that the native Highest Fictive by Highest Fictive level, that comes by default with the
forecast tree, does not have this calculation limitation.

BranchIDMultiple
Settings.xml
- <Entry>
<Key argument="BranchIDMultiple" />
<Value type="int" argument="1" />
</Entry>
This entry is deprecated beginning in 7.3.1.3 replaced by TargetTaskSize. See note
1473437.1. If you are not using 7.3.1.3 and above, consider the following:
Generally, you should calculate the number of active combinations from mdp_matrix or
t_ep_spf_matrix for different profiles.
Divide number of active combinations by 2000.
The result will be desired number of branches.
Then divide number of branches by number of processor engines and you receive the actual
number that should be used in Settings.xml BranchIDMultiple parameter.
Engines can work fine with branches with less than 2000 combinations but may fail if branch
has more than 2000 active combinations

BranchIDMultiple and TargetTaskSize
Old parameter: BranchID Multiple, deprecated 7.3.1.3 onwards
Parameter Location: Parameters > System Parameters > Engine >Proport
Default: 0
Engine Mode: Both
Details:
Specifies how many MDP_MATRIX combinations the analytical engine attempts to
assign to each forecasting task.
Allocation will be affected by forecsat tree branch size.
TaskTargetSize is automcatically calculated. It holds the perferred branch size, in
number of combinations in the lowest level.
This parameter is adjusted to a lower value for smaller schemas, depending on the
number of available engines.

BranchIDMultiple Cont
To confirm how many active combinations there are in branch 1
select count(*)
FROM mdp_matrix m,
engine_branch_list e
WHERE m.prediction_status = '1'
AND m.do_fore <> 0
AND e.item = m.T_EP_E1_ITEM_CAT_1_EP_ID
AND e.location = m.T_EP_LR4_EP_ID
and e.branch_id = 1;

BranchIDMultiple Cont
A break down of active combinations in branch 1 showing the distribution of
forecast rows.
select all_fore, sum(the_count) how_many
from (
SELECT SUM(CASE WHEN (s.sales_date > '05-01-2012 00:00:00' AND s.sales_date
<= '11-01-2013 00:00:00') THEN 1 ELSE 0 END) all_fore, 1 the_count
FROM sales_data s,
mdp_matrix m,
engine_branch_list e
WHERE s.item_id(+) = m.item_id
AND s.location_id (+) = m.location_id
AND m.prediction_status = '1'
AND m.do_fore <> 0
AND e.item = m.T_EP_E1_ITEM_CAT_1_EP_ID
AND e.location = m.T_EP_LR4_EP_ID
and e.branch_id = 1
GROUP BY m.item_id, m.location_id ) x
group by all_fore

Becoming a Demantra Data Master Part 2
Demantra Database Objects
Proport Management
Useful SQL
Demantra Processing and Database Objects
Database Object Management

Managing Data, Collections
<not sure if there is anything important about the following. Is it worth a slide or
demo?>
History should be purged for both net-change and refresh collections. If this is not
working please contact Oracle Support
Note, the complete refresh collection is not meant for regular weekly runs. Ideally it
should be run only once (boot strap) and that too
only if you want to collect all the data from Order Management (OM) into Demantra.
You should run only net-change collection for regular runs. Also for bootstrap data
load, if OM has more data than required for Demantra,
net-change collection with appropriate date range should be run.

To ask a question on the
phone line, select *1 on your
phone.
To ask a question online, use
the Q&A area at the top.
Your question will be

read aloud in the order
received.
Question can also be asked
on the My Oracle Support
Communities

Visit My Oracle Communities
Collaborate with a large network of your industry peers, support professionals, and Oracle
experts to exchange information, ask questions & get answers. Find out how your peers are
using Oracle technologies and services to better meet their support and business needs.
Exchange Knowledge
Resolve Issues
Gain Expertise
Visit the My Oracle Support

Community now!!
1. Log into My Oracle Support.
2. Select the Community tab.
3. Select the Enter Here button.
4. Select the Community Name
link under the E-Business
Suite section of the My
Communities Menu on the left
side of the window.

Demantra Solutions Advisor Webcast
Calendar and Archive (Doc Id 800030.1)

FYI: New Portal with same DocID
The Upcoming Webcast Schedule and Archived
Webcasts documents have been consolidated into one
document.
Doc ID Doc
740966.1 ID740964.1
Advisor Webcasts
Current Schedule
and Archived
recordings
61
Doc ID 740966.1
select your
product:
e.g.
Oracle Database
62
Schedule Archives
63
Avoid the unexpected
Dont leave value on the table
Lower overall organizational costs through preventative
maintenance
Are You Ready Reduce risks and maximize uptime
To Get Proactive? Achieve resolution faster
Streamline and simplify your daily operations
Get even more through connection
Discover more about Get

Proactive
https://support.oracle.com/CSP/main/article?cmd=sho
w&type=ATT&id=1385165.1:DISCOVER
ACT Get Proactive

Access proactive capabilities available for your
products by visiting the product pages at My Oracle
Support; Article ID 432.1
Contact the Get Proactive team

today for help getting started
[email protected]
2012 Oracle Corporation Proprietary and Confidential

64
THANK YOU

MFG DEM Advisor Webcast 2012 1114

Uploaded by

Copyright:

Available Formats

MFG DEM Advisor Webcast 2012 1114

Uploaded by

Document Information

Original Title

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

MFG DEM Advisor Webcast 2012 1114

Uploaded by

Copyright:

Available Formats

2009 Oracle Corporation Proprietary and Confidential

2012 Oracle Corporation Proprietary and Confidential 3

Becoming a Demantra Data Master

The following is intended to outline our general

2012 Oracle Corporation Proprietary and Confidential 5

Becoming a Demantra Data Master

Gain a better understanding of Demantra data points:

2012 Oracle Corporation Proprietary and Confidential 7

2012 Oracle Corporation Proprietary and Confidential 8

2012 Oracle Corporation Proprietary and Confidential 9

2012 Oracle Corporation Proprietary and Confidential 10

2012 Oracle Corporation Proprietary and Confidential 11

2012 Oracle Corporation Proprietary and Confidential 12

2012 Oracle Corporation Proprietary and Confidential 13

Implement multiple freelists or freelist groups on the destination tables

2012 Oracle Corporation Proprietary and Confidential 14

2012 Oracle Corporation Proprietary and Confidential 15

2012 Oracle Corporation Proprietary and Confidential 16

2012 Oracle Corporation Proprietary and Confidential 17

2012 Oracle Corporation Proprietary and Confidential 18

2012 Oracle Corporation Proprietary and Confidential 19

2012 Oracle Corporation Proprietary and Confidential 20

select level_id,count(*) from mdp_matrix

2012 Oracle Corporation Proprietary and Confidential 21

Review the number of active combinations/Individual Branches should

2012 Oracle Corporation Proprietary and Confidential 22

2012 Oracle Corporation Proprietary and Confidential 23

This will allow you to assess the fragmentation, chain_cnt and

2012 Oracle Corporation Proprietary and Confidential 24

2) update mdp_matrix set prediction_status = 99, prop_changes=1;

3) select count(*), do_fore, prediction_status group by do_fore,prediction_status;

2012 Oracle Corporation Proprietary and Confidential 25

Also use treehierarchytest.exe to validate the forecast tree.

2012 Oracle Corporation Proprietary and Confidential 26

2012 Oracle Corporation Proprietary and Confidential 27

2012 Oracle Corporation Proprietary and Confidential 28

2012 Oracle Corporation Proprietary and Confidential 29

Introducing a useful SQL

2012 Oracle Corporation Proprietary and Confidential 30

You have 4 available CPUs on your machine.

2012 Oracle Corporation Proprietary and Confidential 31

2012 Oracle Corporation Proprietary and Confidential 32

Controls how the Analytical Engine uses this combination.

96 (No Forecast) This status means that the Analytical Engine

2012 Oracle Corporation Proprietary and Confidential 33

The primary method to resolve is Run proport to update prediction_status

Prior to batch run, the expectation is that proport is being executed

If you are loading data, proport should run automatically

2012 Oracle Corporation Proprietary and Confidential 34

N do_fore=2, zero forecast

Choice Not Available

2012 Oracle Corporation Proprietary and Confidential 35

2012 Oracle Corporation Proprietary and Confidential 36

Specifies whether to run proport on this combination; a value of 1 means Yes.

2012 Oracle Corporation Proprietary and Confidential 37

select count(*), prediction_status

2012 Oracle Corporation Proprietary and Confidential 38

Whenever encountering Engine performance issues and/or

2012 Oracle Corporation Proprietary and Confidential 39