Engine Parameters

This chapter describes the Analytical Engine parameters that you can see in Business Modeler and lists their default values, if any.

This chapter covers the following topics:

About Engine Parameters

For each parameter, this chapter indicates which engine variations that parameter can be used with. This chapter also indicates which parameters can be used with nodal tuning. Some of the Promotion Effectiveness (PE) parameters are useful only if your system also includes Promotion Optimization.

Oracle provides two different modes for the Analytical Engine:

As indicated, most parameters are visible to all users; a few are visible only if you log in as the owner of the component.

See also

"Theoretical Engine Models"

Analytical Engine Parameters

Parameter Location Default Engine Mode* Details Tuning
A          
add_zero_combos_to_mdp Engine > Data Manipulation yes Both** Visible only to owner. Specifies the Proport mechanism handles combinations whose historical data consists of zeros. Use one of the following values:
  • yes: Add these combinations to mdp_matrix even if their historical data consists of zeros.

  • no: Do not add these combinations.

 
AllowableExceptions Engine > Validation 10 PE only Visible only to owner. Specifies the permissible amount of exceptional uplifts, as a percentage of total number of uplifts. The LowerUpliftBound parameter controls the threshold for exceptional uplifts.
The engine discards a model (for a given forecast node) in either of two cases:
  • If the model generates too many exceptional uplifts (as specified by the LowerUpliftBound and AllowableExceptions parameters).

  • If any uplift exceeds the bound given by the UpperUpliftBound parameter.

Global setting only
AllowNegative Engine > Adjustment no Both This parameter is used by the fit and residuals module of the Analytical Engine. Use one of the following values:
  • yes: Negative values of fit and forecast are allowed.

  • no: Any non-positive fitted and forecasted values are set to zero.

Can be tuned by node
AnalyzeMdp Engine > Shell Full analyze Both Visible only to owner. Specifies how to analyze the mdp_matrix table after the Engine Manager divides the forecast tree into tasks. Use one of the following values:
  • 5 columns analyze: Enable a partial analysis using the five most important fields: prediction_status, prop_changes, branch_id, do_aggri, and do_fore.

  • Full analyze: Enable a full analysis.

  • No analyze: Disable the analysis.

Note: The branch_id field is for internal use only.

Global setting only
AverageHorizon Engine > Data Manipulation 12 for monthly 52 for weekly 7 for daily PE only Applies only to Promotion Optimization; parameter is visible only to owner. Specifies the length of time to be used in calculating the average baseline forecast. This window of time starts at the date given by the StartAverage parameter.
For information on configuring Promotion Optimization, see "Configuring Promotion Optimization for PTP".
Global setting only
B          
BatchRunMode Engine > Shell estimation and forecast run PE only Specifies the kind of forecasting to do:
  • run the forecast against only the learning (0; estimation)

  • run the promotion forecast (1; recommended setting)

  • estimation and promotion forecast run (2; fast simulation), using previously cached data. If no cached data is found, the Analytical Engine gives a message and calculates the needed data.


This parameter applies to both batch run and simulation run.
Global setting only
BottomCoefficientLevel Engine > Data Manipulation 1 PE only Applies only to Promotion Optimization; parameter is visible only to owner. Specifies the lowest forecast tree level for which the Analytical Engine will calculate coefficients. Use any forecast tree level between the lowest promotional level and the InfluenceRangeLevel, inclusive.
For information on configuring Promotion Optimization, see "Configuring Promotion Optimization for PTP".
Global setting only
BulkLoaderBlockSize Engine > Shell   Both Oracle only; visible only to owner. Specifies the minimum amount of number of rows that the Analytical Engine loads at one time, when writing to the database. The larger this is, the more quickly the data is loaded, but there is greater risk if the database connection is lost. Use a value between 100 and 100,000. Global setting only
BulkLoaderEnableRecovery Engine > Shell   Both Specifies whether Oracle Bulk Loader should perform recovery after a lost database connection. Oracle Bulk Loader is used by the Analytical Engine. Global setting only
C          
CachePath   Null Both Specifies the path to the directory into which the Analytical Engine should write its caching files. This can be any of the following:
  • A relative path (relative to Demantra_root/Demand Planner/Analytical Engines/bin).

  • An absolute path.

  • Null. In this case, the Analytical Engine creates its caches in Demantra_root/Demand Planner/Analytical Engines/bin/cache.


You should create the directory manually if it does not yet exist.
Global setting only
CalcOptimizationInput Engine > Data Manipulation no PE only Applies only to Promotion Optimization; parameter is visible only to owner. Specifies whether the Analytical Engine should calculate inputs needed for Promotion Optimization. Use one of the following values:
  • yes (1): See "Configuring Promotion Optimization for PTP". Make sure to set the IS_OPTIMIZATION flag equal to 1 for at least one of the linear engine models.

  • no (0)

Global setting only
cannibalism Engine > Data Manipulation   Both** Specifies the default values for aggri_98 and aggri_99, which are combination-specific fields.
If equal to 0 or 1, the defaults for both fields are 1.
If equal to 2, the default for aggri_98 is 1, and the default for aggri_99 is 0.
Global setting only
CannibalizationIgnore Engine > Data Manipulation   PE only Controls whether the Analytical Engine will calculate switching effects (cannibalization). You can use this parameter to easily switch off that calculation when needed, for example, when running specific simulations. Global setting only
COMPETITION_ITEM Engine > Shell   PE only Visible only to owner. Specifies the level (from the group_tables table) that defines the competitive item (CI) groups. Each node of this level represents a different item group.
The CI should be consistent with the item groups (I). Specifically, two items within a given item group must also belong to the same competitive item group. The easiest way to follow this rule is to set the CI equal to an item level that is higher than I and that is within the same hierarchy. A similar rule applies for the locations.

Note: You specify the item groups indirectly when you specify the IGL in the forecast tree. see "Configuring the Forecast Tree".

Global setting only
COMPETITION_LOCATION Engine > Shell   PE only Visible only to owner. Specifies the level (from the group_tables table) that defines the competitive location (CL) groups.
See the notes for COMPETITION_ITEM.
Global setting only
CutTailZeros Engine > Data Manipulation yes Both Visible only to owner. Specifies how the preprocessing module (of the Analytical Engine) should handle series that start with zero values. Use one of the following values:
  • yes: Delete the leading zeros.

  • no: Retain them as actual zero values.

Can be tuned by node
D          
DampPeriod Engine > General 0 Both This parameter is used by the Bayesian blending module of the Analytical Engine. It specifies the length of periods in which the residuals will receive the same weights. The dampening of weights is done between each successive period.
This parameter lets you put greater weight on models that perform better on most recent historical data, as opposed to models that show close fit to the remote history.
Can be tuned by node
DampStep Engine > General 0 Both This parameter is used by the Bayesian blending module of the Analytical Engine. It specifies the rate of weights decay. By setting this parameter to 0 (or 1), you set all weights to be equal to 1 (equal weights). Can be tuned by node
def_delta Engine > Proport 0.75 Both** Specifies the default value for the delta field in the mdp_matrix table. If delta equals null for a given combination, the system uses the value of this parameter instead.
All new combinations created through data loading, member management, and/or chaining will have a null value in their delta column, thus indicating that they will also take the default delta value from this parameter.
In turn, the delta field is used in the proport calculation as in the following example:
P1 = glob_prop * delta + (monthly demand) * (1 - delta)
Global setting only
DeleteIsSelfRows     PE only Specifies whether the Analytical Engine deletes unneeded promotion_data records. Use one of the following values:
  • 0 means that the Analytical Engine does not delete records in promotion_data.

  • 1 means that the Analytical Engine deletes unneeded records.


A record is considered unneeded if all the following conditions are true:
It is flagged as is_self = 0
All lifts (uplift, pre and post effect, and switching effects) equal 0
The condition specified by DeleteIsSelfCondition is true
Also see "Is_Self".
Global setting only
DeleteIsSelfCondition     PE only Specifies an additional true/false condition that must be met to delete unneeded records in promotion_data. Used only if DeleteIsSelfRows is 1.
This parameter is used as an SQL extra where clause. The Analytical Engine uses it to restrict the deletion.
Global setting only
detect_cp Engine > Outlier and Regchange yes Both This parameter is used by the preprocessing module of the Analytical Engine. Use one of the following values:
  • yes: The engine should attempt to detect a regime change in the level or trend. If it finds a change point, it performs the analysis on the leveled out series. The threshold for change points is controlled by the RegimeThreshold parameter.

  • no: The engine should not attempt to detect change points. The RegimeThreshold parameter is ignored.

Can be tuned by node
detect_outlier Engine > Outlier and Regchange yes Both This parameter is used by the preprocessing module of the Analytical Engine. Use one of the following values:
  • yes: The engine should attempt to detect outliers. If it finds outliers, it considers them in the analysis.

  • no: The engine should not attempt to detect outliers.


Also see GrossRemove. To disable all outlier detection, both these parameters must be switched off.
Can be tuned by node
DetectModelOutliers     Both Visible only to owner. Specifies whether to check for outlier models for each forecast node. Outlier models are models that do not fit well enough. The sensitivity of the test is controlled by the ModelValidationBound parameter. Global setting only
DeviationFactor Engine > Validation 5 Both  Visible only to owner. This parameter is used by the fit validation module of the Analytical Engine, and it controls the sensitivity of one of the fit validation tests. In this test, residuals are checked for presence of large deviations, as specified by DeviationFactor. This parameter specifies the maximum number of standard deviations that the residuals are allowed to attain. A model is rejected if it fails this test. Can be tuned by node
DownTrend Engine > Adjustment 0.2 Both This parameter is used by the adjustment module of the Analytical Engine, if that module is enabled (via EnableAdjustment). It controls the forecast adjustment for downward trend. Specifically, it specifies the amount by which the forecast is rotated to align with recent trend in data.
Use a value from 0 to 1, inclusive.
Enabling adjustment is not recommended, unless it is known that a change in trend happened recently, which is likely to be missed by the models.
Can be tuned by node
dying_time Engine > Proport 0.5 season (1 season in media) Both** If no sales occurred during the length of time specified by this parameter, the combination is marked as dead. See prediction_status. Global setting only
E          
EnableAdjustment Engine > Adjustment no Both This parameter controls the adjustment module of the Analytical Engine. Use one of the following values:
  • yes: Enable the adjustment module, which performs a final tuning of the forecast, adjusting the forecast to the recent trend in the historical data.

  • no: This is the recommended setting, unless you are sure that a change in trend happened recently, which is likely to be missed by the models.

Can be tuned by node
EnableFitValidation Engine > Validation yes Both Visible only to owner. This parameter controls the fit validation module of the Analytical Engine. Use one of the following values:
  • yes: Perform a normal validation for the fit.

  • no: Perform only a weak validation.

Can be tuned by node
EnableForecastValidation Engine > Validation yes Both Visible only to owner. This parameter is used by the forecast validation module of the Analytical Engine. Use one of the following values:
  • yes: Perform a normal validation for the forecast.

  • no: Perform only a weak validation.

Can be tuned by node
EnableModifiedVariance Engine > General no Both Visible only to owner. This parameter is used by the fit validation module of the Analytical Engine. Use one of the following values:
  • yes: Perform the modified variance, which specifies how the variance is calculated in determining weights for Bayesian blending.

  • no

Can be tuned by node
EnableSimGLFilter Engine > General yes PE only Visible only to owner. Specifies whether simulation should respect or ignore any general-level filtering applied to the worksheet. Use one of the following values:
  • yes: Respect the general level filter and run the simulation only on combinations in the worksheet and only on the general level members that is included in the filter. This option ignores, for example, any other general level members associated with those combinations.

    This setting should be used for fast simulations only. If used on promotions or scenarios, only the selected member will receive a regeneration of uplift. All other members—even if they would normally interact with each other—will be excluded. If learning is run using this setting, there is a very good chance that engine results will be wrong due to inclusion of only a part of history.

  • no: Ignore the general level filter and potentially run the simulation on combinations that are not included in the worksheet. This is the previous behavior.

    This parameter has no effect if the worksheet is not filtered by a general level.

Global setting only
EngDimDef_ItemOrLoc Engine > Tables none DM only Determines which forecast tree dimension, item or location displays additional levels. The default is that no additional levels are shown. Global Setting only
EngineOutputThreshold Engine > General 0 Both see Fine Tuning and Scaling Demantra -- EngineOutputThreshold Global Setting only
EngKeyDef_Supersession Engine > Proport item_id, location_id DM only Key used to aggregate members belonging to the same supersession set. When set to the same value as EngKeyDefPK, the proport calculates proportions for each lowest-level member processed by the engine individually and no special handling of supersessions is done. If set above the level defined by EngKeyDefPK, then calculation of proportions is done at this aggregated level considered the supersession and all underlying combinations receive the same proportional values. Global Setting only
EngKeyDefPK Engine > Tables item_id, location_id DM only Defines the primary key of the combination and data tables selected for this analytical engine profile. Global Setting only
EngTabDef_HistoryForecast Engine > Tables SALES_DATA DM only Table that holds historical demand and into which the forecast to be written. Global Setting only
EngTabDef_Inputs Engine > Tables INPUTS DM only Table that contains time definitions for the chosen engine profile. This parameter should not be modified. Global Setting only
EngTabDef_Matrix Engine > Tables MDP_MATRIX DM only Table that holds the combinations available for the chosen engine profile. Global Setting only
EngTabDef_Parameters Engine > Tables PARAMETERS DM only Table that holds the analytical model parameters for chosen engine profiles. This parameter defines the method that the supersession forecast is allocated to general level members during the supersession forecast. When set to the default for each period, proportions are allocated completely to the member with the latest starting date. If set to All Active Revisions for each period, proportions are allocated equally among all active members. Global Setting only
F          
FillMethod Engine > Data Manipulation linear interpolation Both 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 (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; also see the UpTime parameter.

  • This parameter is ignored if FillParameter equals 0.

Can be tuned by node
FillParameter Engine > Data Manipulation 0 Both 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:
  • yes:

  • no:

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

Can be tuned by node
ForecastGenerationHorizon Engine > Time 0 Both Specifies what historical fit data the engine will write to the database. If this parameter is 0, the engine writes the forecast only. If this parameter is a positive integer N, the engine writes the last N historical fit values. Global setting only
ForecastMeanRelativeDistance Engine > Validation 3.5 Both Visible only to owner. This parameter is used by the forecast module of the Analytical Engine. It specifies the sensitivity of forecast validation. The smaller the value, the stricter the test. Can be tuned by node
G          
GLPropSuperSessionMethod Engine > Proport latest revision DM only Defines the method general level proportions use to allocate proportions during supersessions. When set to the default for each period, proportions are allocated completely to the member with the latest starting date. If set to All Active Revisions for each period, proportions are allocated equally among all active members. Global setting only
GrossRemove Engine > Outlier and Regchange yes Both This parameter is used by the preprocessing module of the Analytical Engine. Use one of the following values:
  • yes: The engine should process gross outliers. Enable this feature only if there is a clear reason to remove obviously unreasonable values. The threshold for gross outliers is controlled by the OutlierStdError parameter.

  • no

Can be tuned by node
H          
HighestSquaring Engine > Validation 4 Both Visible only to owner. This parameter is used by the fit validation module of the Analytical Engine. It specifies the number of residual standard deviations, beyond which the residuals participate in the sum of squares calculation in their absolute value, rather than squared. Can be tuned by node
hist_glob_prop Engine > Proport 1 season Both** Maximum number of base time buckets to use in calculating glob_prop, the running average demand for any given item-location combination. This parameter is used by the proport mechanism. Global setting only
HistoryLength Engine > Time 0 Both The number of base time buckets to consider for fit estimation and for the proport mechanism. Must be a non-negative integer. If equal to 0, the length of the history is set by the start_date parameter instead. Can be tuned by node
I          
InfluenceGroupLevel Engine > Shell   PE only Read-only. Specifies which level (from the group_tables table) is used as the influence group level of the forecast tree. To specify this parameter, you use the Forecast Tree Editor within the Business Modeler. Global setting only
InfluenceRangeLevel Engine > Shell   PE only Read-only. Specifies which level (from the group_tables table) is used as the influence range level of the forecast tree. To specify this parameter, you use the Forecast Tree Editor within the Business Modeler. Global setting only
IntermitCriterion Engine > General 99 Both This parameter is used by the preprocessing and intermittent flow modules of the Analytical Engine. It specifies the minimum percentage of zero data points that a series must have to be considered intermittent.
In this test, leading zeros may or may not be considered (depending on the setting of CutTailZeros). Trailing zeros are ignored in either case.
In the extreme case where this parameter equals 0, all series are treated as intermittent.
Can be tuned by node
IntUpdate Engine > Adjustment 0.5 Both This parameter is used by the intermittent flow module of the Analytical Engine. It specifies the degree to which the Analytical Engine will update the fit after the last spike in history, in the case where there is decline in demand at the end of historical period.
Use a number between 0 and 1, inclusive.
The value 1 means that the change in fit is to be carried forward fully to the forecast.
On the other extreme, the value 0 means that no change is to be applied.
A value between 0 and 1 will be used as a weight for combining past and updated behavior.
Can be tuned by node
L          
last_date Engine > Time 1/1/1900 Both 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. If this parameter equals 1/1/1900, the system instead uses last_date_backup. Global setting only
last_date_backup Engine > Time   Both Specifies a backup value to use for the last sales date, in case last_date is 1/1/1900.
Sometimes, when you load sales data, you need to change this parameter so that you can ignore a recent subset of history.
The proport mechanism makes sure that this parameter is never later than max_sales_date.
See "max_sales_date".
Global setting only
lead Engine > Time 12 for monthly data, 52 for yearly, 30 for daily Both The number of base time buckets to predict. The Analytical Engine generates a forecast for the base time buckets in the span from max_sales_date to max_sales_date + lead.
See "max_sales_date".
Global setting only
LogCorrection Engine > General no Both This parameter is used by the fit and forecast modules of the Analytical Engine. The issue is that logarithmic models use log-transformed demand data, which can give inaccurate results if that transformed data is near to 1 in value. In such a case, you may want to use this parameter to make an internal adjustment. Use one of the following values:
yes: Use correct form of the expectation of a lognormal variable.
no: Do not perform the log correction.
Can be tuned by node
LogLevel       Controls the amount of detail that is written into the Analytical Engine log. Use one of the following values:
  1. Critical

  2. Error

  3. Warning

  4. Message

    Note: This corresponds to the amount of detail that the log has contained in past releases.

  5. Info

  6. Detail


This setting applies to all log groups chosen through the Engine Administrator:
Global setting only
LowerUpliftBound Engine > Validation 3 PE only Visible only to owner.Specifies the limit beyond which an uplift value is considered "exceptional." This limit is specified as a proportion of baseline. For each model, the Analytical Engine compares the absolute value of the uplift, divided by baseline, to this parameter.
The engine discards a model (for a given forecast node) in either of two cases:
  • If the model generates too many exceptional uplifts (as specified by the LowerUpliftBound and AllowableExceptionsparameters).

  • If any uplift exceeds the bound given by the UpperUpliftBound parameter.

Can be tuned by Node
M          
mature_age Engine > Data Manipulation 2 Both** Controls the mature_date of each combination, which is calculated backwards from the current date using the mature_age parameter.
A combination is young (rather than active) if it does not have any non-zero sales data on or before the mature_date.
See prediction_status.
Global setting only
max_accept_num       Maximum absolute value that is permitted for the forecast results. If the Analytical Engine generates a result larger than this in absolute value, it substitutes this maximum (or minimum, if applicable).

Tip: Make sure the forecast columns are large enough to accommodate a number of this size, and be sure to account for a possible negative sign. Errors occur if the Analytical Engine cannot write the forecast because the database columns are not large enough.

Global setting only
max_fore_level Engine > Shell Level just below the highest fictive level Both The maximum level on the forecast tree at which a forecast may be produced. Upon failure at this level, the NAIVE model will be used (if NaiveEnable is yes).
In Promotion Effectiveness, this must be at or below the influence range level (IRL); see InfluenceRangeLevel.
Global setting only
MaxEngMemory Engine > Proport 100 Both Specifies the maximum amount of system memory usage (in megabytes) at the end of a task, before an engine is re-initiated.
Use this parameter to prevent the analytical engine from failing or generating errors when processing large amounts of data.
For machines that run multiple engines, ensure that each engine has access to the amount of memory specified.
Global setting only
MeanRelativeDistance Engine > Validation 0.5 Both Visible only to owner. This parameter is used by the fit validation module of the Analytical Engine, and it controls the sensitivity of one of the fit validation tests. A model is rejected if its MAPE (Mean Absolute Percentage Value) is greater than this threshold.
The smaller the value, the stricter is the validation.
Can be tuned by node
min_fore_level Engine > Shell 1 Both 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.
For PE, this must be at or above the lowest promotional level (LPL).
Can be tuned by node
MinLengthForDetect Engine > Outlier and Regchange 12 for monthly data, 52 for weekly, 14 for daily Both This parameter is used by the preprocessing module of the Analytical Engine. It specifies the minimum number of data points needed in order for the engine to try to detect outliers and regime changes. Can be tuned by node
ModelValidationBound   0.2 Both Specifies the sensitivity of the test used to detect "outlier" models for a given node. Outlier models are models that do not fit well enough. This parameter is used only if model outlier detection is enabled (via the DetectModelOutliers parameter.) Global setting only
N          
NaiveEnable Engine > General yes Both Specifies what to do at the highest forecast level, upon failure of all models. Use one of the following values:
  • no (0): Do not enable either NAIVE or Moving Average models. Do not generate a forecast.

  • yes (1): Enable use of the NAIVE model.

  • 2 or higher: Enable use of the Moving Average model. In this case, the setting of NaiveEnable specifies the number of recent time buckets to use in calculating the moving average.

Can be tuned by node
need_spread Engine > Adjustment produce continuous forecast Both This parameter is used by the intermittent flow module of the Analytical Engine, and it controls whether the final result should be given in the form of spikes. Use one of the following values:
produce forecast with spikes
produce continuous forecast
This applies only to intermittent models.
Can be tuned by node
node_forecast_details Engine > Shell forecast is written to node_forecast_q Both Visible only to owner. Specifies whether the Analytical Engine should write forecast data for each node, before splitting to lower levels. Use one of the following values:
  • forecast is written with model details (1): The Analytical Engine writes intermediate forecast data for each node, to the NODE_FORECAST table. The table includes information on how each model was used for that node. The Analytical Engine will run more slowly because of the additional work in writing to this table.

  • forecast is written to node_forecast_q (0): The Analytical Engine writes the forecast as usual.

Global setting only
NonNegRegrMaxTolMult       Specifies the maximal multiplier to be used in order to increase the tolerance value in nonnegative regression. When you disable negative coefficients (via UseNonNegRegr) and are unable to acquire a solution, it may be helpful to increase this tolerance.
Recommended value range: 30 - 2000
Default value: 30
Global setting only
NormalizationFactor Engine > Data Manipulation 0 PE only Parameter is visible only to owner. Specifies the degree of normalization to perform, if NormalizeResults is yes. Use a number from 0 to 1, inclusive. The ends of this range have the following meanings:
  • 1 means preserve the baseline fit. In this case, all residuals are added to the uplift.

  • 0 means that both the baseline and uplift are modified according to the normalization algorithm. This is the recommended setting.


This normalization is applied only to historical data (where the baseline is known).
Global setting only
NormalizeResults Engine > Data Manipulation no PE only Parameter is visible only to owner. Specifies whether to normalize the historical engine results so that the observed baseline values are preserved. Use one of the following values:
  • yes (1): Normalize historical engine results so that the observed baseline values are preserved. In this case, the Analytical Engine writes these results into the columns fore_a_normal, etc. This setting is recommended for use when historical analysis is of importance. Will cause Base + Lift to exactly match demand (quantity_form). The results are written in different column from base and lift to enable ease of comparison. No normalized results are available for future dates, because of the lack of normalization number; this potentially makes the connection between historical and future forecast not smooth.

  • no (0): Do not perform normalization.

Global setting only
NumShapes Engine > Validation 8 Both Parameter is visible only to owner. Specifies the maximum number of allowed shape causal factors for the engine to use for a given node in the forecast tree. Use an integer from 0 to 8, inclusive. Applies to activity shape modeling (rather than to promotional shape modeling). Global setting only
O          
oracle_optimization_mode Engine > Shell cost Both Oracle only; visible only to owner. Optimization mode of the database. Global setting only
OutliersPercent Engine > Outlier and Regchange 25 Both This parameter is used by the preprocessing module of the Analytical Engine. A set of points, suspicious as outlying, will be regarded as such only if its size does not exceed this given percentage of data. Can be tuned by node
OutlierStdError Engine > Outlier and Regchange 2.5 Both This parameter is used by the preprocessing module of the Analytical Engine, if gross outlier processing is enabled (via the GrossRemove parameter).
The OutlierStdError parameter specifies the sensitivity of gross outlier detection. The greater this value, the less sensitive (more liberal) is detection of gross outliers. The value 0 is not allowed.
Can be tuned by Node
P          
PartitionColumnItem     Both Specifies the name of the column that partitions the data by item. This column must exist in sales_data, mdp_matrix, and (for Promotion Effectiveness) promotion_data.
If this is null, data is not partitioned by item.
See "Database Partitioning for the Engine".
Global setting only
PartitionColumnLoc     Both Specifies the name of the column that partitions the data by location. This column must exist in sales_data, mdp_matrix, and (for Promotion Effectiveness) promotion_data.
If this is null, data is not partitioned by location.
See "Database Partitioning for the Engine".
Global setting only
PercentOfZeros Engine > Adjustment 0.2 Both This parameter is used by the adjustment module of the Analytical Engine, if that module is enabled (via the EnableAdjustment parameter). It specifies the maximum fraction of zero values in data beyond which no forecast adjustment is performed. Use 0.2 for 20 percent, for example.
Enabling adjustment is not recommended, unless it is known that a change in trend happened recently, which is likely to be missed by the models.
Can be tuned by node
PopulationExtraFilte Engine> Shell Null Both This parameter can be used to apply an extra filter on the combination population processed by the engine. This can help support incremental engine runs as well as ensure only desired combinations are forecasted.
The default setting is null, applying no additional filter. An expected filter is on the MDP_MATRIX table with the synonym M. This filter will not require specifying the table for this table, and should only include the additional WHERE clause used by the filter.
Example: WHERE PREDICTION_STATUS=1
Filters including other tables must specify those other tables and join then to MDP_MATRIX. The syntax for the additional tables must begin with a comma, followed by the table name. It is not recommended that tables with a time dimension be used, including SALES_DATA. Care should be taken when defining columns for the filter, as they may exist in multiple tables, causing SQL errors. It is strongly recommended that any column referenced in the filter be prefaced by the table from which it is being retrieved.
Example: … ITEMS I WHERE I.ITEM_ID=M.ITEM_ID AND I.ITEM_ID < 100
Example: … T_EP_FRANCHISE T1, T_EP_RETAILER T2 WHERE T1.FRANCHISE_ID=M.FRANCHISE_ID AND T2.RETAILER_ID=M.RETAILER_ID AND T1.FRANCHISE_CODE < 100 AND T2.RETAILER_CLASS > 5
Global Setting Only
PROMO_AGGR_LEVEL Engine > Shell   PE only Read-only. Specifies which level is used as the lowest promotional level of the forecast tree. To specify this parameter, you use the Forecast Tree Editor within the Business Modeler. Global setting only
PromotionStartDate Engine > Time   PE only Parameter is visible only to owner. Earliest date for which promotion data can be considered reliable. The Analytical Engine ignores any promotion data before this date. This parameter applies only to combinations that have promotions. Global setting only
PromotionSeries Engine > Proport null Globally Defined see chapter Configuring the Analytical Engine, section Split Forecast by Series Global Setting only
proport_missing Engine > Proport treated as zero observations Both** Specifies how missing dates are treated. Use one of the following values:
  • treated as zero observations: The missing dates are set equal to zero. That is, suppose that you have three months worth of data as follows: 30, null, 60. If proport_missing equals 0, the average of these three months is calculated as 30 (or [30+0+60]/3)

  • treated as missing: The missing dates are assumed to have average values. Using the previous example, if proport_missing equals 1, the average of these three months is calculated as 45 (or [30+60]/2). This is mathematically equivalent to assuming that the missing month has average sales (45).

Global setting only
proport_spread Engine > Proport receive 0 proportions/global proportions Both** Specifies how months that are missing from historical data are filled. Use one of the following values:
  • receive zero proportions: For each missing month, set the proportions equal to 0.

  • receive global proportions: For each missing month, set the proportions equal to glob_prop. In this case, Demantra checks the value of the proport_missing parameter and then does the following:

    • If proport_missing equals 0, then missing months receive glob_prop*delta.

    • If proport_missing equals 1, then missing months receive the rolling average (glob_prop).

  • receive 0 proportions/global proportions: For missing months that would have occurred after the first sale for this combination, assign 0 proportions. For months that could not occur in the range of first sale- end of sales, use glob_prop. In this case, for months that could not have been included, Demantra checks the value of the proport_missing parameter and then does the following:

    • If proport_missing does not equal 1, then missing months receive the rolling average (glob_prop).

    • If proport_missing equals 1, then missing months receive glob_prop*delta.

Global setting only
proport_threshold Engine > Proport 0 Both** Specifies how many different months of the year must include data in order for Demantra to calculate proportions for the individual months (P1 - P12, PW1-PW6, etc.). Use any integer from 0 to 12, 24, inclusive.
For each combination, the number of unique observable buckets is found (having 3 different observations of January counts as only one month).
If not enough months have non-null values, Demantra checks the value of the proport_missing parameter and then does the following:
If proport_missing equals 0, then missing months receive glob_prop*delta.
If proport_missing equals 1, then missing months receive the rolling average (glob_prop).
Global setting only
ProportParallelJobs Engine > Proport 1.00 Both** The number of parallel jobs used when running Proport calculations. This parameter's value should not exceed the number of CPUs on the database server. Global setting only
ProportRunsInCycle Engine > Proport 1.00 Both** The number of groups that the Proport process is broken down into. Global setting only
ProportTableLabel Engine > Proport   Both** The name of the level by which the process is broken down. The total number of members in this level is divided into equally sized groups, and one group is processed each time Proport is run. Global setting only
Q          
Quantile Engine > Outlier and Regchange 2.5 Both Visible only to owner. This parameter is used by the validations module of the Analytical Engine, when checking the influence of outliers. It specifies a standard normal percentile for detecting outliers at a prescribed significance level. Can be tuned by Node
quantity_form Engine > Data Manipulation See details. Both Visible only to owner. Expression that the Analytical Engine uses to compose the historical demand from the sales_data table; the result of this expression is the data that the engine receives as input.
This expression should return 0, null, or a numeric quantity for any date. A date with 0 is treated as if there were no sales. A date with null is treated as a missing date; in this case, the system can interpolate a value or just ignore the date.
On Oracle, the default is as follows:
nvl(pseudo_sale,actual_quantity)*(1 + nvl(demand_fact,0)) + nvl(demand_lift,0)
Global setting only
R          
RegimeThreshold Engine > Outlier and Regchange 5 Both This parameter is used by the preprocessing module of the Analytical Engine. It specifies the sensitivity of regime change detection. The smaller the value, the more aggressively the engine will detect regime changes.
This parameter is used only if regime change is enabled (via the detect_cp parameter).
Can be tuned by node
RemoveResidOutlier   0 Both Specifies the percentage of residuals (by number) to remove before validating the fit. The residuals are sorted by size and the largest residuals are removed. Can be tuned by node
ResetForeVals Engine > Shell yes Both Visible only to owner. Specifies whether the engine should clear out previous forecast data before generating the forecast. Use one of the following values:
  • yes: Demantra clears the previous forecast for all combinations with prediction status equal to 99. (The other combinations are left alone, because the engine will overwrite their forecast anyway.)

  • no: Demantra does not clear out the previous forecast. This is less ideal but runs more quickly.

Global setting only
resetmat Engine > Shell yes Both Visible only to owner. Use one of the following values:
  • yes: Reset loc_node, item_id, and location_id in mdp_matrix.

  • no: Do not reset these fields.

Global setting only
RunFastDivider Engine> Shell Yes - Divide into engine tasks using lookup table Both This parameter is used to control whether division of forecasted combinations is done by updates to a lookup table or to MDP_MATRIX directly. When set to Yes (default), updates to the lookup table can generate substantial performance benefits for large scale environments. Setting of No will update BRANCH_ID column in MDP_MATRIX, which will take more time but is easier to query in order to determine which branch a specific combination belongs to. Global Setting Only
RunPartialDivider Engine > Shell No Both No = before every new forecast, reallocate all combinations to tasks. Yes = only allocate new combinations to tasks Global Setting only
RunInsertUnits     Both Specifies the behavior of the INSERT_UNITS procedure, which Demantra calls at the start of an engine run. This procedure makes sure the engine has rows to write into when generating the forecast. This parameter also controls whether Demantra runs the active rolling data profiles when it runs this procedure. Use one of the following values:
  • 0 means that Demantra does not insert rows and does not execute the rolling data profiles.

  • 1 means that Demantra insert rows and executes the active data profiles (by running the EXECUTE_PROFILES procedure).

  • 2 means that Demantra does not insert rows, but does execute the active data profiles.

Global setting only
RUNMODE     Not applicable Read-only; parameter is visible only to owner. Specifies which version of the Analytical Engine to use.
  • Use 1 to specify the Promotion Effectiveness version.

  • Use 0 to run the engine in demand planning mode. This mode will not generate promotional lift. If you use this setting make sure that the LPL is the same as the minimum forecast level.

Global setting only
RunPartialDivider Engine> Shell No - Assign new Branch to every combination participating in forecast Both This parameter is used to control whether all combinations are assigned a branch at the beginning of a new engine run. Setting of No (default) will assign a branch ID to all combinations taking part in the engine run. Setting of Yes will assign Branch ID only to nodes that currently do not have a branch ID. Note: Setting value to No can improve engine run performance but may result in unbalanced engine tasks over time. Global Setting Only
S          
SdeAnalyzeSwitch Engine > General yes Both Specifies how the Analytical Engine should analyze the sales_data_engine table. Use one of the following values:
  • yes: Use external logic to analyze this table. See "Reconfiguring the sales_data_engine Table".

  • no: Analyze the sales_data_engine table as usual.

Global setting only
SdeCreateJoin Engine > General no Both Specifies whether the Analytical Engine should join sales_data_engine (or its synonym) and mdp_matrix during its run. Use one of the following values:
  • yes: Join sales_data_engine and mdp_matrix.

  • no: Do not join these tables.


See "Reconfiguring the sales_data_engine Table".
Global setting only
SdeCreateSwitch Engine > General internal logic Both Specifies whether to use external logic to create the sales_data_engine table. Use one of the following values:
  • use internal logic (0): Create the sales_data_engine table using internal logic.

  • use external logic (1): Use external logic. If you use this option, you must rewrite the create_process_temp_table, create_object, and drop_object procedures. See "Reconfiguring the sales_data_engine Table".

  • use external logic done by engine (2). When forecasting on general levels (for example, for service parts forecasting)l, set to external logic engine.

Global setting only
season Engine > Time season length Both Read-only. Season length (52 for weekly systems, 12 for monthly, 7 for daily). Can be tuned by node
set_rb Engine > Shell SET transaction use rollback segment RB1 Both** Oracle 8i only; visible only to owner. Set Rollback Segment command for the database. This is database dependent. See your database documentation. Global setting only
ShapeSign Engine > Data Manipulation   Both Specifies the signs for the shape causal factors when using them in non-negative regression. Use one of the following values:
  • 0 means that after the preliminary estimation, the signs are kept as is.

  • 1 means that after the preliminary estimation, the shape casual factors are made positive.


This parameter is ignored if UseNonNegRegr is set to prevent negative coefficients.
Can be tuned by node
ShiftBaseCausals Engine > Shell 0 PE only Parameter is visible only to owner. Specifies the number of base time buckets by which the baseline causal factors should be shifted; this applies to the causal factors in the causal_factors table. Specify an integer (can be negative). The default setting (0) is recommended. Can be tuned by node
ShiftDynPromoDate     PE only SQL expression that returns the number of days to add to the sales date for any given promotion; typically this is a negative number. If the resulting dates are already in the Inputs table, the Analytical Engine inserts those dates into promotion_data with is_self equal to 0.
If this expression is null, then the default promotion dates are used.
  • If the expression aggregates multiple rows from promotion_data, then be sure to use an aggregate function such as DISTINCT.

  • Dates are compared to the dates in the Inputs table. If a newly generated date does not match a date in that table, then the date is deleted.

  • You can apply filters on the resulting dates, via the Promotional Causal Factor window in the Business Modeler.

Global setting only
ShiftPromoCausals Engine > Shell 0 PE only Parameter is visible only to owner. This parameter is a global setting that applies to all promotions. You may want to use ShiftDynPromoDate instead, because that gives a greater amount of control.
This parameter specifies the number of base time buckets by which the promotional causal factors should be shifted; this applies to the causal factors in the m3_causal_factors table. Specify an integer that can be negative. For example, to make the promotional causal factors active one week after the promotions occur, specify 1 (in a weekly system).
Can be tuned by node
ShiftPromoMaxValue     PE only Specifies the number of additional future time buckets to bring into history, when shifting promotions to the dates given by ShiftDynPromoDate.
By default, the Analytical Engine considers only historical promotions and ignores any future promotions. If you shift promotion dates, that typically means you need to shift promotions that are planned for the very near future. This parameter specifies how many time buckets of the future the Analytical Engine should consider when it shifts the promotion dates.
Global setting only
start_date Engine > Time 1-1-1995 Both First sales date, the start date as it appears in the Inputs table. Can be changed according to the length of history needed for fit estimation and for the proport mechanism. It is strongly recommended this parameter be reset to beginning actual date where history begins. See also the HistoryLength parameter. Global setting only
start_new_run Engine > Shell prompt Both Specifies whether to start a new Analytical Engine run or to perform an engine recovery. Internally, the engine records information to indicate its current processing stage. As a result, if the previous engine run did not complete, you can run recovery, and the Analytical Engine will continue from where it was interrupted.
Use one of the following values:
  • yes: Always start a new run, regardless of the status of the last run.

  • no: Detect whether the previous run was complete and perform a recovery if the previous run did not complete.

  • prompt: Detect whether the previous run was complete and ask whether to perform a recovery run or a new run.

Global setting only
StartAverage Engine > Data Manipulation -12 for monthly -52 for weekly -7 for daily PE only Promotion Optimization only; parameter is visible only to owner. Controls the starting date of the time span used to calculating the average baseline forecast. You specify this date relative to last_date.
The length of this span of time is controlled by the AverageHorizon parameter.
For information on configuring Promotion Optimization, see "Configuring Promotion Optimization for PTP".
Global setting only
StdRatio Engine > Validation 3 Both This parameter is used by the fit validation module of the Analytical Engine, and it controls the sensitivity of one of the fit validation tests. In this test, the residuals are split into two parts (earlier and later) controlled by TestPeriod. The parameter StdRatio is the maximum allowed ratio of the standard deviation of the later part to the standard deviation of the earlier part. A model is rejected if it fails the test. Can be tuned by node
T          
test_samp_len Engine > Validation 6 for monthly data, 26 for weekly 7 for daily Both This parameter is used by the fit validation module of the Analytical Engine. It specifies the length of data for forecast validation. Can be tuned by node
TestPeriod Engine > Validation 6 for monthly data, 26 for weekly 7 for daily Both This parameter is used by the fit validation module of the Analytical Engine, and it controls the sensitivity of one of the fit validation tests. In this test, the residuals are split into two parts (earlier and later) controlled by TestPeriod. The parameter StdRatio is the maximum allowed ratio of the standard deviation of the later part to the standard deviation of the earlier part. A model is rejected if it fails the test. Can be tuned by node
TooFew Engine > General 2 Both This parameter is used by the preprocessing module of the Analytical Engine. It specifies the minimum number of non-zero data points that a series must have in order for the Analytical Engine to consider it model-feasible. In this test, leading zeros may or may not be considered (depending on the setting of CutTailZeros). Trailing zeros are ignored in either case.
Must be 1 or greater.
If the series has too few data points, the forecast failure module is run.
Can be tuned by node
top_level Engine > Shell   Both Visible only to owner; read-only. Indicates the highest level of the forecast tree (the highest fictive level, HFL). This indicates the number of levels that the forecast tree contains. Global setting only
TopCoefficientLevel Engine > Data Manipulation   PE only Applies only to Promotion Optimization; parameter is visible only to owner. Specifies the highest forecast tree level for which the Analytical Engine will calculate coefficients. Use any forecast tree level between BottomCoefficientLevel and the InfluenceRangeLevel, inclusive.
For information on configuring Promotion Optimization, see "Configuring Promotion Optimization for PTP".
Global setting only
TrendDampPeriod     New Used during trend detection, this parameter specifies a block of time (as a number of buckets) over which the dampening is applied. The time that contains trend is divided into blocks, as specified by this parameter. For the nth block, the Analytical Engine applies a dampening factor n times. The result is exponential dampening. Can be tuned by Node
TrendDampStep     New Used during trend detection, this parameter specifies the dampening factor, which is applied n times to the nth block of time within the trend. The result is exponential dampening. Use a value between 0 and 1, inclusive; smaller values cause dampening to happen more quickly. Can be tuned by Node
TrendModelForShort     New Used during trend detection, this parameter specifies which engine model to use in order to generate the trend causal factor.
  • 1 means use the REGR model.

  • 2 means use the HOLT model.

Can be tuned by Node
TrendOutlierRatio     New Used during trend detection, this parameter specifies how to treat outliers during model fit. It specifies a numeric weight to apply to the outliers within the long segment. Can be tuned by Node
TrendPeriod Engine > Adjustment   Both This parameter is used in two parts of the Analytical Engine.
The adjustment module uses it as follows:
  • If EnableAdjustment is yes (1), then TrendPeriod specifies how far back in history the trend is measured for adjustment.

  • If zero, then no adjustment is performed. Enabling adjustment is not recommended, unless it is known that a change in trend happened recently, which is likely to be missed by the models.


This parameter is also used by trend detection as discussed in "The Forecasting Process" on page 589. If you have disabled negative regression (via UseNonNegRegr), then it is difficult for the Analytical Engine to detect downward trends. In such cases, you should enable trend detection.
Can be tuned by node
TrendPreEstimation     New Specifies whether to perform trend detection as described in "The Forecasting Process". Can be tuned by Node
TrendShortRatio     New Used during trend detection, this parameter specifies how to treat outliers during model fit. It specifies a numeric weight to apply to the outliers within the short segment. Can be tuned by Node
U          
update_dead_comb     Both** Specifies whether the MANUALS_INS procedure considers dead combinations. (A combination is dead if its prediction_status setting is 99; see "Mdp_matrix".) Use one of the following values:
  • 0 means that MANUALS_INS ignores the dead combinations (this is the typical setting).

  • 1 means that MANUALS_INS splits aggregated data to the dead combinations and saves it to those combinations.

Global setting only
UpliftThresholdMethod Engine > Validation 1 PE only Specifies how to determine the uplift threshold:
  • 0 means use absolute values

  • 1 means use percent of baseline

Global setting only
UpliftThresholdValue Engine > Validation .5 PE only Uplift and cannibalization values lower than this threshold are automatically set to null. This number must be greater than 0. Global setting only
UpperUpliftBound Engine > Validation 20 PE only Visible only to owner, Specifies the upper allowed limit for uplifts, as a proportion of baseline. For each forecasting model, the Analytical Engine calculates the lift for each node of the forecast tree. For any given node and model, if the absolute value of the uplift is greater than this limit, then that model is not used for this node.
The engine discards a model (for a given forecast node) in either of two cases:
  • If any uplift exceeds the bound given by the UpperUpliftBound parameter.

  • If the model generates too many exceptional uplifts (as specified by the LowerUpliftBound and AllowableExceptionsparameters).

Can be tuned by Node
UpTime Engine > Data Manipulation nvl(sum(nvl(UP_TIME,1)),1) Both This parameter is used by the preprocessing module of the Analytical Engine. It is used to flag whether each date in sales_data should be considered a sales date or not. Use an SQL expression that returns one of the following values:
  • 0 (to indicate a no-sales date)

  • 1 (to indicate a date on which sales could theoretically happen)

Global setting only
UpTrend Engine > Adjustment 0.2 Both This parameter is used by the adjustment module of the Analytical Engine, if that module is enabled (via EnableAdjustment). It controls forecast adjustment for upward trend. Specifically, it represents the amount the forecast is rotated to align with recent trend in data.
Use a value from 0 to 1, inclusive.
Enabling adjustment is not recommended, unless it is known that a change in trend happened recently, which is likely to be missed by the models.
Can be tuned by node 
UseBusinessFilter Engine > Data Manipulation no Both Specifies whether the Analytical Engine distinguishes business and non-business days. Use one of the following values:
  • yes: The Analytical Engine uses only business days (as indicated by business_day_filter series in the Inputs table).

  • no: The Analytical Engine uses all days.

Global setting only
UseEnvelope          
UseExternalSDUpdate Engine > Shell no Both Visible only to owner. Specifies how to update the sales_data table with the current forecast. Use one of the following values:
yes: Use an external procedure (create_process_temp_table.
no: Use an internal dynamic procedure.
The create_process_temp_table procedure is a template that creates the dynamic stored procedure that will be executed by the engine for the update. By default, this procedure creates the same SP that as the engine creates, but this can be overridden. The interface to this SP is as follows:
  • is_proc_name (VARCHAR2) specifies the name of the dynamic SP that the engine will execute.

  • is_tmp_tbl (VARCHAR2) specifies the temptable name.

  • is_fore_col (VARCHAR2) specifies the column name in sales_data that will be updated with the new forecast.

  • is_last_date (VARCHAR2) specifies a date to update mdp_matrix with.

Global setting only
usemodelspernode Engine > Data Manipulation   Both Specifies whether you can specify the forecasting models to use for specific nodes in the forecast tree, via the File > Analytics menu option in Promotion Effectiveness. Global setting only
UseNonNegRegr Engine > Validation yes Both Visible only to owner. Specifies whether to use non negative constraint estimation for all regression-based engine models. Use one of the following values:
  • yes: The coefficients are prevented from being negative.

  • no

Can be tuned by node
UseParamsPerNode Engine > Data Manipulation   Both Specifies whether you can specify the engine parameters to use for specific nodes in the forecast tree, via the File > Analytics menu option in Promotion Effectiveness. Global setting only
UseWeightedRegression   0 Both Specifies whether the Analytical Engine applies a weight to each observation when fitting each model.
  • If this parameter is set to 1 (yes), the OBS_ERROR_STD field (in sales_data) specifies the weights for each observation.

  • If this parameter is 0 (no), that field is ignored.

Can be tuned by Node
W          
WriteIntermediateResults Engine > Shell no Both Applies only to the desktop products; parameter is visible only to owner. Specifies whether to enable the advanced analytics function, which is available only on the desktop. Use one of the following values:
  • yes: Retain intermediate results (coefficients for causal factors) to enable advanced analytics. The results are written to the INTERM_RESULTS table. This information includes the coefficients for each model, and the weight of each model in the forecast.

    Warning: The Analytical Engine will run much more slowly.

  • no

Can be tuned by node
WriteMissingDatesUplift Engine > Shell no PE only Parameter is visible only to owner.Specifies whether to write uplifts for dates that are missing from sales_data. Use one of the following values:
  • yes: The Analytical Engine writes uplifts for any dates where it calculates them, even if no sales occurred. However, the uplifts will add up to the total uplift calculated by the engine.

  • no: The Analytical Engine writes uplifts only for dates that have sales. This means that the uplifts will not necessarily add up to the total uplift.

Global setting only
* PE only means PE mode only; Both means both PE and DP modes. ** This parameter is not used directly by the engine and thus is available for use with either engine mode.

Database Parameters for Tuning Engine Performance

The following parameters provide more advanced controls of how Demantra executes specific engine processes and allow you to tune the engine based on your implementation’s unique characteristics. These parameters can be set in the INIT_PARAMS_% tables.

Warning: Using these parameters to improve engine performance depends almost entirely upon the expertise of the implementer. System issues may result if they are not used correctly. Oracle does not recommend using these parameters unless you have been trained and have previous experience tuning the analytical engine

Parameter Details
DBHintBranchDivision This parameter applies hints to Engine DB statements that divide MDP_MATRIX combinations among forecast engine tasks. When the hint references to table MDP_MATRIX, use #DYNTABLE1# instead. The engine will automatically replace with MDP_MATRIX. For example, to run four parallel processes when executing branch division, set this parameter to + parallel(#DYNTABLE1# 4).
DBHintAggriSQL This parameter applies hints to Engine DB statements that aggregate data from the SALES_DATA table. When the hint references to table SALES_DATA, use #DYNTABLE1# instead. The engine will automatically replace with SALES_DATA. For example, to run four parallel processes when executing aggregation statements, set this parameter to + parallel(#DYNTABLE1# 4).
DBHintLoadActual This parameter applies hints to the Engine DB statement that retrieves the lowest level historical data during an analytical engine run. When referencing a table use #DYNTABLE1# or #DYNTABLE2# to designate the table.
The Engine automatically replaces dynamic strings with the relevant table name or alias. #DYNTABLE1# references SALES_DATA and #DYNTABLE2# references MDP_MATRIX. For example, to run four parallel processes on MDP_MATRIX and six parallel processes on SALES_DATA when querying lowest level information, set this parameter to + parallel(#DYNTABLE1# 6) parallel(#DYNTABLE2# 4).
DBHintCreatePDE This parameter applies hints to the Engine DB statements that create the temporary promotion data engine tables during an analytical engine run. When referencing a table, use #DYNTABLE1#, #DYNTABLE2# or #DYNTABLE3# to designate the table.
The Engine automatically replaces dynamic strings with the relevant table name or alias. Use #DYNTABLE1# to reference MDP_MATRIX, #DYNTABLE2# to reference PROMOTION and #DYNTABLE3# to reference PROMOTION_DATA. For example, to run four parallel processes on MDP_MATRIX and six parallel processes on PROMOTION_DATA when creating the PDE table, set this parameter to + parallel(#DYNTABLE1# 4) parallel(#DYNTABLE3# 6).