Tuesday Aug 13, 2013

Do Not Run Multiple Branch Processes in Parallel

Query to show log:

select (select schema_name
        from  demantra.wf_schemas
        where schema_id = a.schema_id),
        to_char(a.record_created, 'DD-MON-YYYY HH24:MI:SS'),
        to_char(a.record_updated, 'DD-MON-YYYY HH24:MI:SS'),
from    demantra.wf_process_log a
where process_id >= 922599
order by a.record_created desc

Does the above output indicate that you are running multiple batch processes in parallel?

Please review your environment and make sure you run processes in the correct order and
that the processes are not competing for hardware resources.

If you are trying to run processes that compete for same data in same tables you can try extending
your undo space and settings to be much larger, assuming your hardware can support this path.

However, running overlapping engines is not recommended.

* Attain the process ID from the OS for the most recently ran batch process 

Friday Jul 06, 2012

Demantra Controlling MDP_MATRIX Combinations Assigned to Forecasting Tasks Using TargetTaskSize

New parameter: TargetTaskSize

Old parameter: BranchID  Multiple, deprecated 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.

  - As the forecast is generated the engine goes up the tree using max_fore_level and not top_level -1.  Max_fore_level has
    to be less than or equal to top_level -1.  Due to this requirement, combinations falling under the same top level -1
    member must be in the same task.  A member of the top level -1 of the forecast tree is known as a branch.  An engine
    task is therefore comprised of one or more branches.

    - Reveal current task size
      go to Engine Administrator --> View --> Branch Information and run the application on your Demantra schema.  This will be deprecated in since there is no longer a means of adjusting the brach size directly.  The focus is now on proper hierarchy / forecast design.

    - Control of tasks
      The number of tasks created is the lowest of number of branches, as defined by top level -1 members in forecast
      tree, and engine sessions and the value of TargetTaskSize.  You are used to using the branch multiplier in this
      calculation.  As of, the branch ID multiple is deprecated.

    - Discovery of current branch size
      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.

    - Control of foreacast tree branch size
        - 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;
          This will give you 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.

        - 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)

          select count(*), level_id from mdp_matrix where prediction_status = 1 and do_fore = 1 group by level_id;

          This will give us an understanding at which level of the Forecast tree where 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 forecast, with more combinations, at a lower level.

          For example:

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

            - You have 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
              a single engine to 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 deliver a balanced task allocation.

            - A correctly configured Forecast Tree is something that is done by the Implementation team and is
              not the responsibility of Oracle Support. 

Allocation will be affected by forecast tree branch size.  When TargetTaskSize is set to 0, the default value, the system
automatically calculates a value for 'TargetTaskSize' depending on the number of engines.

  - QUESTION:  Does this mean that if TargetTaskSize is 1, we use tree branch size to allocate branches to tasks instead
               of automatically calculating the size?
    ANSWER: DEV Strongly recommends that the setting of TargetTaskSize remain at the DEFAULT of ZERO (0).

  - How to control the number of engines?
    Determine how many CPUs are on the machine(s) that is (are) running the engine.  As mentioned earlier, the general
    rule is that you should designate 2 engines per each CPU that is available.  So for example, if you are running the
    engine on a machine that has 4 CPU then you can have up to 8 engines designated in the Engine Administrator.  In this
    type of architecture then instead of having one 'localhost' in your Engine Settings Screen, you would have 'localhost'
    repeated eight times in this field.

    Where do I set the number of engines?
        To add multiples computers where engine will run, please do a back-up of Settings.xml file under
        Analytical Engines\bin\ folder, then edit it and add there the selected machines.
        Example, this will allow 3 engines to start:

        - <Entry>
          <Key argument="ComputerNames" />
          <Value type="string" argument="localhost,localhost,localhost" />

Otherwise, if there are no additional engines defined, the calculated value of 'TargetTaskSize' is used.
(Oracle does not recommend changing the default value.)

The TargetTaskSize holds the engines prefered branch size, in number of level 1 combinations.

  - Level 1 combinations, known as group size

The engine manager will use this parameter to attempt creating branches with similar size.
  * The engine manager will not create engines that do not have a branch.

The engine divider algorithm uses the value of 'TargetTaskSize' as a system-preferred branch size to create branches that
are more equal in size which improves engine performance.  The engine divider will try to add as many tasks as possible to
an existing branch, up to the limit of 'TargetTaskSize' level 1 combinations, before adding new branches.

Coming up next:
- The engine divider
- Group size
- Level 1 combinations
- Engine Parameters



This blog delivers the latest information regarding performance and install/upgrade. Comments welcome


« July 2016