This document outlines the location of the main troubleshooting logs that you will need during all phases of Demantra Installation, Go-Live and Lifecycle Support.

Note that while this list is not exhaustive, or necessarily valid for all Demantra versions, it is meant to provide the locations of those logs that would commonly be used during first and
second line troubleshooting. Also, it should be stated these logs may not lead to the actual resolution of your issue but are meant to provide extra clues which could then be used to reference
other Support Notes and/or can be provided to Oracle Support.

Please check out the referenced documents at the bottom of this note.

Any questions about these logs or tables should be directed to Oracle Support.

SCOPE

This note should be used by anyone responsible for installing and/or maintaining the health of the Oracle Demantra Application

DETAILS

1. Installation of the Demantra Base Application, Patches or Version Upgrades

   For Clients installing or upgrading Demantra Versions 7.2.0 and higher then please refer to Note 1077000.1 for new logging options.

   Note that there will also be some ancillary logs under the following folders:

   .. Demand Planner\Database Objects\Oracle Server (Oracle back end database)

   .. Demand Planner\Database Objects\Microsoft SQL Server (Sql Server back end database)

More information on troubleshooting the Demantra base installation process is found in Note 430913.1

2. Error starting the Web Server and/or deploying the Demantra WAR file

Review the Collaborator.log which is found under the ...Collaborator\demantra\logs folder on the webserver where Demantra is running. Also, each individual webserver (ex. OAS, JRUN, Tomcat, Websphere, etc...) will have their own individual logs in various directories which can also be consulted. The individual webserver documentation should be reviewed for these log locations.

3. Error logs for the Demantra forecast engine - batch or simulation

When the Engine Executables are installed on Windows, additional troubleshooting tips for the Demantra Batch Engine are found in Note 848205.1.

   The key engine logs are found under the root drive of the machine where the engine executables are located and the engine is launched from. If you are using
   the distributed mode (ex. running the engine on Machines A, B and C):

   If the primary engine is on Machine A then all logs will be found on that Machine.  The folder on that machine, that holds these logs, usually have Engine2k somewhere in the name.
   Note that there should be at least Engine2k logs, these logs record the actual splitting and forecasts that the engine does, present in this folder.

   However, to write the primary EngineManager logs to this folder you need to go to the Engine Administrator
   (..Demand Planner\Analytical Engines\bin --> Settings --> Configure)
   and change the Engine Manager Log tab from STD to FILE. If you did not have Log set to FILE then we would expect you to re-run the engine one more time so that
   we can record this additional logging.

   Note: It is NOT advised to re-register the engine after making this change

   When the Engine Executables are installed on Linux (new option starting in Demantra v73)

   Engine and EngineManager logs are placed at the same level as installed BIN and LIB directories. They can be accessed under $ENGINE_ROOT/engine2k directory.
   Sub directories are arranged according to schema name, machine name and run time. Log placement can be configured in $ENGINE_ROOT/bin/Settings.xml file, relative to $ENGINE_ROOT/lib/Engine.exe location or by supplying full path.

4. Stored procedure errors with Active_Proc_Dyn somewhere in the error message

To view the errors go to Business Modeler --> Tools --> Procedure Error Log

Note that this looks to the backend table called db_exception_log

5. End user errors, when they occur in a Demantra worksheet, or when end user updates appear not to be processed or saved correctly.

   The important log that we want to review with end user issues (ex. screen freezes, error messages appear when running or editing a worksheet, end user updates
   are not being processed*, etc..) is the Java plugin log.

   There are two ways to get this log:

   1) In the bottom, right hand part of the machine you will see a Java coffee cup icon. Right click on it > Open Console. Note that if there are more than one
      icon then look for the log that referencesDemantra in the URL

      To make sure that you are not including old messages, press the clear button and then try to recreate the issue again.

   2) Clear your browser cache:

For IE, Hold the Ctrl key and press the F5 key - Or - hold the Ctrl key and click the Refresh button on the toolbar
For Mozilla Firefox, hold down the Ctrl key and then press F5 - Or - hold down both the Ctrl and Shift keys and then press R
For Chrome Either: Hold the Ctrl key and press F5 - Or - hold the Ctrl key and click Reload button

      If the machine has frozen up then a log is still usually saved on the back end of the machine. This can usually be found by going to C:/Documents and
      Settings/<Username>/Application Data/Sun/Java/Deployment/log

      If there are no errors evident in the java plugin log then go to the Collaborator.log found under:

      http://< Host Name of Webserver : Port Number>/demantra/admin/systemLogs.jsp

      For example if you normally log into Demantra using the following URL:

      http://DEMANTRAMACHINE:8080/demantra/portal/loginpage.jsp

      then these logs would be accessed by going to:

      http://DEMANTRAMACHINE:8080/demantra/admin/systemLogs.jsp

      An alternative way to view these logs is to go directly the machine hosting the webserver and go to the logs found under ...Collaborator\demantra\logs
      (note that this a Windows Directory path example and Demantra, when deployed on non-Windows boxes, will still be under this folder path but obviously with
       different directory navigation steps)

      Look for the entries in the log around the time of the error (note that the webserver might be in a different timezone so an error for an enduser in New York
      at 4pm will show up at 1pm in the Webserver based in California)

      Enhanced Logging for End User issues can be recorded by going to:

      http://< Host Name of Webserver : Port Number>/demantra/admin/loggerManager.jsp

      For v7203 and lower once there, turn on the following lines (note that if the button is marked TURN ON then actually it is OFF. Once the button is marked
      TURN OFF then the logging is actually ON which is what we want). For v730 and higher these will have check boxes instead of ON/OFF buttons.

appserver.sql
appserver.audit_trail_sql
appserver.update.operation
appserver.update.process
appserver.update.sql
appserver.retrieve.sql
appserver.retrieve.data.sql

      Note that this logging will be turned off either by the next time the webserver is restarted or by the user turning off the lines that were earlier turned on.

      * For issues where updates are not being reflected in the series after re-running the worksheet, and there doesn't appear to be any errors in the Java
        Plugin or Collaborator.logs, then close out of the worksheet completely and try to re-run the worksheet one more time. If the update is then reflected
        that that usually points to a possible issue the last_update_date column and needs to be addressed differently. It should also be mentioned to Oracle
        Support if this problem with updates only recently started occurring with this series or if this is a new series that is being tested out.

6. Errors with Workflows or Level Methods that call Workflows (ex. Load Scenario Data)

   Although the root cause might lie in another log, the first log that should be checked is the Collaborator.log This log can be accessed by going to the following URL:

   http://< Host Name of Webserver : Port Number>/demantra/admin/systemLogs.jsp

   So for example if you normally log into Demantra using the following URL:

   http://DEMANTRAMACHINE:8080/demantra/portal/loginpage.jsp

   then these logs would be accessed by going to:

   http://DEMANTRAMACHINE:8080/demantra/admin/systemLogs.jsp

   To make sure you are not looking at older cached System Logs then press F5 since this is the IE method to refresh the cache.

An alternative way to view these logs is to go directly the machine hosting the webserver and go to the logs found under ...Collaborator\demantra\logs (note that this a Windows Directory path example and Demantra, when deployed on non-Windows boxes, will still be under this folder path but obviously with different directory navigation steps)

Look for the entries in the log around the time of the error (note that the webserver might be in a different timezone so an error for an enduser in New York at 4pm will show up at 1pm in the Webserver based in California)

   To enable Java console log:

   Start ->control Panel ->Java - >Advanced->

   Click for Enable Trace, Enable console and show console option

   Enhanced Logging for Workflow issues can be recorded by going to:

   http://< Host Name of Webserver : Port Number>/demantra/admin/loggerManager.jsp

Once there, turn on any line that has Workflow in it and then re-run the workflow in question. Note that this logging will be turned off either by the next time the webserver is restarted or by the user turning off the lines that were earlier turned on.

   For v730 and higher these will have check boxes instead of ON/OFF buttons.

appserver.workflow.general
appserver.workflow.steps
appserver.workflow.timing
workflow.general

If the error is in a Transfer step then you might need to consult that Integration Interface logs in the next section of this document.

7. Integration Interface / Transfer Step / APS.bat / APS.exe Errors or Data Issues

   Although the root cause might lie in another log, the first log that should be checked is the Integration.log This log can be accessed by going to the following URL:

   http://< Host Name of Webserver : Port Number>/demantra/admin/systemLogs.jsp

   So for example if you normally log into Demantra using the following URL:

   http://DEMANTRAMACHINE:8080/demantra/portal/loginpage.jsp

   then these logs would be accessed by going to:

   http://DEMANTRAMACHINE:8080/demantra/admin/systemLogs.jsp

   To make sure you are not looking at older cached System Logs, clear the browser cache:

For IE, Hold the Ctrl key and press the F5 key - Or - hold the Ctrl key and click the Refresh button on the toolbar
For Mozilla Firefox, hold down the Ctrl key and then press F5 - Or - hold down both the Ctrl and Shift keys and then press R
For Chrome Either: Hold the Ctrl key and press F5 - Or - hold the Ctrl key and click Reload button

An alternative way to view these logs is to go directly the machine hosting the webserver and go to the logs found under ...Collaborator\demantra\logs (note that this a Windows Directory path example and Demantra, when deployed on non-Windows boxes, will still be under this folder path but obviously with different directory navigation steps)

Look for the entries in the log around the time of the error (note that the webserver might be in a different timezone so an error for an enduser in New York at 4pm will show up at 1pm in the Webserver based in California)

   Note that errors might also be found in the following tables in the Demantra schema/database:

   - <Integration Interface Table name>_ERR (ex. if the staging table is name Biio_Supply_Plan then the error table would be Biio_Supply_Plan_Err)

The ERR table mentioned above is checked to see when the record does not make it from the staging table (ex. Biio_Supply_Plan) to the end Demantra table (ex. Sales_Data). For certain types of integration there might be 4 additional intermediate tables which should also be checked for records being kicked out or else not fully processed.

   They are:

UPDATE_BATCH_TRAIL
UPDATE_BATCH_VALUES
UPDATE_BATCH_TRAIL_ERR
UPDATE_BATCH_VALUES_ERR

Each of the above ERR table will have a message field with at least a brief description of why it was kicked out.

8. Errors with Member Management or Chaining

Note that issues with actually launching these two applications from the Collaborator Workbench and other silent installer issues should be addressed by reviewing Note 947322.1

   Errors that occur in Member Management might be seen by going to Business Modeler --> Tools --> Procedure Error Log

   Note that this looks to the backend table called db_exception_log

   Errors that occur during Chaining* might also be might be seen by going to Business Modeler --> Tools --> Procedure Error Log

   An additional error message table for Chaining is the Chains_Queue table (can only be viewed by use of SQL commands).

   * It should be noted that this error has to do with when the Status states 'Failed' and is not meant to cover legitimate warning messages like 'No Common
     Population or Source' indicating that the setup of your chaining profile is possibly incorrect.

9. Issues with EBS/ASCP Integration to/from Demantra (ex. Shipment and Bookings, SCI Data, etc..)

   This section talks about troubleshooting integration or data loads that start with the job launching outside of Demantra (ex. Launching the jobs from the Oracle
   EBS Concurrent Request screen such as the Collect Bookings and Shipment History job).   Data Collections, like Load Scenario Data, which is launched directly
   from the Demantra Collaborator Workbench (ex. by right click functionality) should be debugged, at least initially, using the Errors with Workflows or Level
   Methods that call Workflows (ex. Load Scenario Data) section of this note.

For those persons used to working with Oracle EBS/ASCP applications you know that most jobs (ex. Collections) can be logged using the steps found in Note 245974.1.

However, jobs that directly relate to Demantra (ex. Shipment and Bookings Collection, Load SCI, etc..) can have extra logging turned on by changing MSD_DEM: Debug Mode to Yes (default is No) and MRP DEBUG: Yes at the User level (turn on this logging in both the Source and Destination instances).

Note that as these jobs move to the other side of the wall from EBS/ASCP to the Demantra side of the database (usually indicated by when you start seeing references to the Demantra schema or tables like t_src_items_tmpl, t_src_sales_tmpl_err, biio_sci_data, etc.) then these errors may need to be tracked using the Workflow or Active_Proc_Dyn or Demantra specific troubleshooting sections of this note.

Review in:

Concurrent Request Log/ View Output Log / View Logs
Log for the Request_id Log in question
Demantra Staging tables and related Err tables
apscheck.sql

10. Error with Legacy Demantra Scheduler Application (ex. Manuals_Ins, Dynamic_Sync, etc.)

Prior to Demantra Version 6.x, when the application became a Web Based front end application, clients would have used a native Demantra application, commonly referred to as Scheduler, to run various stored procedures at set intervals. The most important of these jobs was the Manuals_Ins stored procedure which pre-dates the asynchronous Java Updater (the latter which came into the application starting in v7.x). Errors on the Scheduler, usually indicated by a Red Stripe over the job on the application interface, can be tracked by going to the logs found under the ..Demand Planner\Scheduler\bin folder on the machine where the Scheduler is running.

11. EP_LOAD PROPORT and MORE Can Use LOG_IT to Enhance Log File Information

LOG_IT is a logging mechanism for Demantra PL/SQL database procedure code. It is analogous to log4j in Java.
LOG_IT can be used to trace a procedure flow, show variable values and record performance timing without having to run a debugger.
LOG_IT is only available for a limited number of procedures like CHAINING, PROPORT, SIMULATION, EP_LOAD, ADD_MISSING_DEFAULT_ROWS and more. The list keeps growing.

The available procedures are listed in the LOG_IT_PARAMS table.

See Note 1408753.1 for details regarding LOG_IT.

Summary

In summary, most clients who have the Scheduler running at their site are going to be pre-Version 6.x clients but we might have some clients on the latest versions of Demantra continuing to run it due to Bug 6439497. Jobs that are running in the Scheduler should be ported over to the Demantra Workflow schedule by the client or consultant and given the same schedule run times and frequency as in the current Scheduler. Note that Dynamic_Sync and Manuals_Ins however serve no purpose in v7.x versions of Demantra and higher and should not be ported over to the Workflow.

REFERENCES

NOTE:1675117.1 - Demantra Topical and Procedural Debugging Using Log Files and Key Troubleshooting Techniques Including LOG_IT and the NEW SET_LOG_IT_LOGGING Procedure
NOTE:947322.1 - Step by Step Troubleshooting of the Silent Installer (opening up the Business Modeler, Chaining, or Member Management links from the Demantra Collaborator Workbench)
NOTE:1481533.1 - Oracle Demantra v7.3.1.4 to v12.2 Installation Guide to Simplify Installation Process Using Weblogic
NOTE:1952102.1 - Demantra Debugging, Error Location, Log File Location, Log Files by Process, Patch, Patching
NOTE:848205.1 - No Demantra Forecast Generated - Common Issues
NOTE:1408753.1 - Demantra LOG_IT Setup Execution Explanation ORA Errors Detailed Log Production + New SET_LOG_IT_LOGGING Procedure
NOTE:1614966.1 - Oracle Demantra Development strongly suggests all customers uptake this critical patch. Patch 17808535. Critical Internal Processing Patch
NOTE:1086704.1 - Demantra Engine on Linux or Unix Failure Hanging Error Not Starting Debugging Install and Configuration Checklist

Key Logs When Troubleshooting Demantra Issues - From Installation to Operations (Doc ID 741464.1)

In this Document

Purpose

Scope

Details

1. Installation of the Demantra Base Application, Patches or Version Upgrades

2. Error starting the Web Server and/or deploying the Demantra WAR file

3. Error logs for the Demantra forecast engine - batch or simulation

4. Stored procedure errors with Active_Proc_Dyn somewhere in the error message

5. End user errors, when they occur in a Demantra worksheet, or when end user updates appear not to be processed or saved correctly.

6. Errors with Workflows or Level Methods that call Workflows (ex. Load Scenario Data)

7. Integration Interface / Transfer Step / APS.bat / APS.exe Errors or Data Issues

8. Errors with Member Management or Chaining

9. Issues with EBS/ASCP Integration to/from Demantra (ex. Shipment and Bookings, SCI Data, etc..)

10. Error with Legacy Demantra Scheduler Application (ex. Manuals_Ins, Dynamic_Sync, etc.)

Configuration and Troubleshooting Demantra and 12c In Memory Columns and Tables for Faster Read Transactions. Release 12.2.5.1 and Above. Known Issues, Monitoring+! (Doc ID 2126233.1)

In this Document

APPLIES TO:

Oracle Demantra Demand Management - Version 12.2.5.1 and later
Information in this document applies to any platform.

ABSTRACT

Demantra, starting from version 12.2.5.1, is certified to work with Oracle DB 12c.

This DB version includes the ability to load data into memory to enable faster read transactions from the database; this provides a significant performance gain on some of the Demantra operations, mainly worksheet run time.

HISTORY

Created 13-Apr-2016.

DETAILS

The following guidelines and suggestions have been compiled based on internal work done by Oracle Demantra Development team, as well as real customer experience with this capability and configuration.

SUMMARY

Configuration

Oracle 12c allows the capability of bringing to memory columns or tables, the recommendation is not to load complete tables to memory, like mdp_matrix and data tables. But rather load relevant columns from mdp_matrix and the data tables, sales_data as an example, for a DM solution.

It is important to remember that loading data into memory will improve the performance of read transaction, but is less relevant for insert/update transactions.

Therefore while discussing the columns that need to be loaded to memory, we can ignore engine / data loading processes and focus mainly on worksheets and export needs.

Relevant columns for these types of operations can be identified by analyzing the SQLs the application is generating while loading the worksheets used by the users and in the export process.

If your data table is partitioned, it is also recommended to load columns only on relevant partitions, and not just load the full columns to memory from all available partitions.

The suggested options when loading columns to memory are:
InMemory Compress – use the option “For Query Low” – this means less compression and better performance, if you need to compress the data more, you can use the option “For Query High”.
Priority – you should load the columns into memory with priority set to “Critical”

As part of the notes mechanism of Demantra, some mdp_matrix columns are added to the SQL queries, these are columns like IS_PROMOTION, IS_SUPPLY_PLAN, IS_SCENARIO_RESOURCE , IS_T_EP_CTO and more.

This will need to be fixed in future releases, but currently, for achieving the desired performance gains, these columns will need to be loaded to memory as well. The full list should be obtained by analyzing the queries SQLs.

Troubleshooting

1. To monitor the status of IMCS build-up, use the following query:

select inst_id, owner||'.'||segment_name segment_name,partition_name,populate_status status
, round(sum(INMEMORY_SIZE)/1024/1024,2) im_size_mb
, round(MAX(BYTES)/1024/1024,2) disk_size_mb
, round(sum(BYTES_NOT_POPULATED)/1024/1024,2) not_mb
, count(*)
, '1:'||round(MAX(BYTES)/sum(INMEMORY_SIZE),1) as compress_ratio
from gv$im_segments
group by inst_id, owner,segment_name,partition_name,populate_status
order by segment_name, inst_id, partition_name;

Note that only when the status = COMPLETED the actual IMCS load is done.

Other two useful SQL statements that complete the IM segments status are:

select 'TABLE' as object_type,owner||'.'||table_name as object_name,
inmemory,
inmemory_priority,
inmemory_distribute,
inmemory_compression,
inmemory_duplicate
from dba_tables
where inmemory is not null
and (inmemory <> 'DISABLED' or inmemory is null)
UNION
select 'PARTITION',table_owner||'.'||table_name||' Part: '||partition_name as table_name,
inmemory,
inmemory_priority,
inmemory_distribute,
inmemory_compression,
inmemory_duplicate
from dba_tab_partitions
where inmemory is not null
and (inmemory <> 'DISABLED' or inmemory is null)
order by object_type desc,object_name;

SELECT owner,
table_name,
segment_column_id,
column_name,
inmemory_compression
FROM v$im_column_level
WHERE inmemory_compression <> 'NO INMEMORY'
ORDER BY owner,table_name,column_name;
 

2. In some versions of 12c we have encountered an ORA-01795: maximum number of expressions in a list is 1000 - error while trying to load into memory data from partitioned table, this is a known DB defect 19670592 : ORA-1795 ON QUERYING AN IN MEMORY TABLE WITH MORE THAN 1000 PARTITIONS , and if you do encounter this problem, there is a need to log a DB SR to get a one off (or get instructions of the bundle patch with this fix).

3. Additional DB patch may be needed to resolve a problem where for few tables and partitions “populate_status” is not getting updated. This is fixed by defect BUG 18549042 - THE STATUS OUT OF MEMORY IS NOT SHOW IN VIEW V$IM_SEGMENTS.

4. We are seeing cases where although sales_data columns are in memory, the DB is using the table and indexes on sales_data and not the in-memory columns; this is an issue we are still exploring to understand the root cause.

Troubleshooting Guide for the Demantra Engine Issues (Doc ID 1456714.1)

In this Document

Purpose

Troubleshooting Steps

References

APPLIES TO:

Oracle Demantra Demand Management - Version 7.3.0 and later
Information in this document applies to any platform.

PURPOSE

To trouble shoot demantra engine issues

TROUBLESHOOTING STEPS

Whenever you face the problem with the Batch/Simulation Engine, you need to provide the following information to the oracle support for troubleshooting the engine issues.

1. Engine 2k log files

2. Engine manager log files

3.Please also upload these query outputs in the Excel sheet with the column headers:

Select * from forecast_history order by time_sig;

Select * from version_details_history order by upgrade_date desc;

Select * from sys_params;

Select * from init_params_0;

In addition to, for the simulation engine you need to provide the following:

Simulation only:

select * from simulation_q;

select * from simulation_list;

4. Whenever you run the engine from the workflow, If the engine is taking long time to complete it, please enable the Enhanced Logging for Workflow

http://<Host Name of Webserver : Port Number>/demantra/admin/loggerManager.jsp

Turn on following Workflow related entries:

Once you enable the Enhanced Logging, you need to Re-run the workflow and upload/Review the collaborator log file.

Note that this logging will be turned off either by the next time the web server is restarted or by the user turning off the lines that were earlier turned on.

5.Please make sure command line in the workflow provided is correct as it needs to have full path:

"#application_root#\..\..\Demand Planner\Analytical Engines\bin\EngineManager.exe" 1 1

6. Please make sure that engine is running on 32-bit oracle client version on the client or server machine when you run the engine from the workflow.

7. Please also make sure that the AppServerURL is correctly in this path

select pval from sys_params where pname = 'AppServerURL'

8. When you run the engine on Linux machine,

Engine Manager Pre Run Log.txt
$ORACLE_HOME/j2ee/home/Engine Manager Pre Run Log.txt or $ENGINE_ROOT/bin/Engine Manager Pre Run Log.txt file.

settings.xml

9. Please enhance the Engine logs using this path
EngineAdmininstrator.exe
setting>>configure
please enhance by clicking once the SQL tab, If the tab is down, then it is enhanced.

10.When you are running the engine and your Demantra schema is large or big, you need to make sure that BranchID Multiple is set correctly using this formula

Check how many active combinations are in MDP_MATRIX

 select count(*) from mdp_matrix where do_fore=1 and prediction_status = 1

This result will be called TOTAL which then you use in the following calculation:

BranchID Multiplier = TOTAL / 2000 / Number of engines configured to run (ex. 1 if you have only one localhost). Note that the number of engines allowed on one machine would roughly be 2 per physical CPU as long as there is around 1.5GB memory available per engine instance.

So in this example if Total = 200,000 and Number of CPU = 2 the calculation would look like: 200,000 divided by 2000 divided by number of engines, which is 4 since you have 2 Engines per CPU. 200,00/2000/4=25, as your BranchID Multiplier

Save the change. There is no need to re-register the engine after changing and saving this setting.

11. Whenever the Proportions(P1 to P12 values) are high on a new combination even though very less sales on this combination, then you need to review these parameters(proport missing and proport spread) in the init_params_0 table.

select * from init_params_0 where pname='proport_missing';

select * from init_params_0 where pname='proport_spread';

select * from init_params_0 where pname='def_delta';

You can also re-calculate the proportions using this update statement

BEGIN
UPDATE mdp_matrix
SET prop_changes = 1
where item_id = << your_item_id>>
and location_id = << your_location_id>>;
COMMIT;
proport;
END;

You can also run this update statement whenever you change the engine parameters manually.

These parameters control how proportions will be assigned to months with no history, either those which were prior to the first sale or those which have null values.
By modifying these two parameters you can control how proportions will be assigned to months which did not have demand.
Please review Demantra Implementation Guide for more information.

12.If you find out of sync in the mdp_matrix table and sales_data table,then you can run this query on Demantra schema

SELECT ITEM_ID,LOCATION_ID FROM (
SELECT ITEM_ID,LOCATION_ID,FROM_DATE,UNTIL_DATE FROM MDP_MATRIX
UNION
SELECT ITEM_ID,LOCATION_ID, MIN(SALES_DATE), MAX(SALES_DATE) FROM SALES_DATA
GROUP BY ITEM_ID,LOCATION_ID)
GROUP BY ITEM_ID,LOCATION_ID
HAVING COUNT(*) > 1
ORDER BY ITEM_ID,LOCATION_ID;

If the above query returns zero rows, it means that the tables are in sync.

If the above query returns rows, then the tables are not sync. Then, you need to run this update statement

UPDATE MDP_MATRIX
SET FROM_DATE = NULL,
UNTIL_DATE = NULL;
COMMIT;
EXEC UPDATE_MDP_MATRIX_DATES;

13. When ever you run the engine on Linux, if the engine has hang, then you should review this metalink document to solve the problem

Unable to start the Engine on Linux server Note 1325321.1

14. Whenever you get this error message

WARNING Retrying bulk insert for file: sqlldr due to communication Error: 256

There was no executable permissions for $ENGINE_ROOT/lib/sqlldr file, so you need to give the full or executable permissions for this file.

15. Whenever EngineStarters become stacked for some reason if corresponding engines are killed brutally. So after killing engine with "kill -9" you need to restart the EngineStarter.

List Of High Priority Patches For Oracle Demantra Including EBS, Siebel and E1 Integrations (Doc ID 470574.1)

APPLIES TO:

Oracle Demantra Real-Time Sales and Operations Planning - Version 7.0.2 and later
Oracle Demand Planning - Version 11.5.10 to 12.0.3 [Release 11.5 to 12]
Oracle Demantra Deduction and Settlement Management - Version 7.0.2 and later
Oracle Demantra Advanced Forecasting and Demand Modeling - Version 7.0.2 and later
Oracle Demantra Predictive Trade Planning - Version 7.0.2 to 7.2 [Release 7 to 7.2]
Information in this document applies to any platform.

PURPOSE

!!!PLEASE READ NOTE 788671.1 AS THERE IS AN IMPORTANT ALERT THAT DEALS WITH DEMANTRA CUMULATIVE PATCH AND BASE VERSION INSTALLATIONS!!!

This document is intended to provide the latest rollup patches available for Demantra as well as general patch number information for EBS/Siebel/E1 to/from Demantra integrations. There are other reference note links to topics that would be beneficial to the customer and Oracle personnel. Please note that all Rollup patches are cumulative unless otherwise specified.

It should be remembered that when applying a Demantra patch that if you are using a WAR file to deploy the application to the web server (common, but not limited, to those clients using Oracle Application Server (OAS), WebLogic, and Websphere) that after the patch is installed on the centralized box that the WAR file needs be recreated and redeployed. This is so that the changes that the patch made to the web application files (ex. java, .jsp, classes, etc.) are propagated to the web server.

In addition, if the patch you are applying contained changes to the Demantra Engine executables (check the Patch ReadMe), and you are utilizing a multi-machine distributed engine, then follow Note 751772.1 as to how to propagate those changes to these distributed machines.

SCOPE

The intended audiences include Oracle Support, Oracle Partners, Oracle Development, Oracle Sales, Oracle Consulting and Oracle Customers

DETAILS

This Document was last updated on 17-MARCH-2021

Demantra 12.2.x:

From 12.2.x onward compatibility between Demantra VCP is as follows:

Demantra 12.2.x will work with VCP 12.2.x, same version for both demantra and VCP

Demantra 12.2.x individual versions compatibly as follows:

Demantra 12.2.10 will only work with VCP 12.2.10

Demantra patches for 12.2.10 see Note 2714991.1
For VCP Patching see Note 1361221.1 - Known Issues for 12.2.10 - R12.SCP_PF.C.delta.11
Demantra 12.2.10 and VCP 12.2.10 will work with
- EBS 12.1.3
- EBS 12.2.10

Demantra 12.2.9 will only work with VCP 12.2.9

Demantra patches for 12.2.9 see Note 2652288.1
For VCP Patching see Note 1361221.1 - Known Issues for 12.2.9 - R12.SCP_PF.C.delta.10
Demantra 12.2.9 and VCP 12.2.9 will work with
- EBS 12.1.3 (EBS Source on must be on VCP 12.1.3.9.2)
- EBS 12.2.9

Demantra 12.2.8 will only work with VCP 12.2.8

Demantra patches for 12.2.8 see Note 2482698.1
For VCP Patching see Note 1361221.1 - Known Issues for 12.2.8 - R12.SCP_PF.C.delta.9
Demantra 12.2.8 and VCP 12.2.8 will work with
- EBS 12.1.3 (EBS Source on must be on VCP 12.1.3.9.2)
- EBS 12.2.8

Demantra requires 12.2.7.1 which works with VCP 12.2.7.1

Demantra patches for 12.2.7.1 see Note 2413191.1
For VCP Patching see Note 1361221.1 - Known Issues for 12.2.7 - R12.SCP_PF.C.delta.8
Demantra 12.2.7.1 and VCP 12.2.7.1 will work with

EBS 12.1.3 (EBS Source on must be on VCP 12.1.3.9.2)
EBS 12.2.4
EBS 12.2.5
EBS 12.2.6
EBS 12.2.7.1

Demantra requires 12.2.6.3 which works with VCP 12.2.6.3

Demantra patches for 12.2.6.3 see Note 2392888.1
For VCP Patching see Note 1361221.1 - Known Issues for 12.2.6 - R12.SCP_PF.C.delta.7
Demantra 12.2.6 and VCP 12.2.6 will work with

EBS 12.1.3 (EBS Source on must be on VCP 12.1.3.9.2)
EBS 12.2.4
EBS 12.2.5
EBS 12.2.6

Demantra 12.2.6 will work with JD Edwards EnterpriseOne 9.1 and 9.2.

Demantra requires 12.2.5.1 which works with VCP 12.2.5.1

Demantra patches for 12.2.5.1 see Note 2069281.1
For VCP Patching see Note 1361221.1 - Known Issues for 12.2.5 - R12.SCP_PF.C.delta.6
Demantra 12.2.5.1 and VCP 12.2.5.1 will work with

EBS 12.1.3 with VCP Cum Patch 12.1.3.9.1 OR 12.1.3.9.2
EBS 12.2.4
EBS 12.2.5

Demantra 12.2.5.1 will work with JD Edwards EnterpriseOne 9.1 and 9.2.

Demantra requires 12.2.4.1 which works with VCP 12.2.4.1

Demantra patches for 12.2.4.1 see Note 1342064.1
For VCP Patching see Note 1361221.1 - Known Issues for 12.2.4.1
Demantra 12.2.4.1 and VCP 12.2.4.1 will work with

EBS 12.1.3 with VCP Cum Patch 12.1.3.9.1 OR 12.1.3.9.2
EBS 12.2.4

Demantra 12.2.4.1 will work with JD Edwards EnterpriseOne 9.1 using the AIA 11.4 for the Value Chain Planning Base Integration Pack.

Demantra 12.2.3 will work with VCP 12.2.3.

Demantra patches for 12.2.3 see Note 1342064.1
Demantra 12.2.3 and VCP 12.2.3 will work with

EBS 12.2.3

Demantra 12.2.3 will work with JD Edwards EnterpriseOne 9.1 using the AIA 11.4 for the Value Chain Planning Base Integration Pack.

Demantra 12.2.2 will work with VCP 12.2.2.

Demantra patches for 12.2.2 see Note 1342064.1
Demantra 12.2.2 and VCP 12.2.2 will work with

EBS 12.2.2

I. Demantra Version 7.3.1

a) 7.3.1.5 - Install PATCH 17850720 - from INSTALL Main Release Patches & How to Upgrade Note. - -Document: 1342064.1

---- VCP 12.1.3.9 is certified ONLY with Demantra Release 7.3.1.5.

-- In 12.2 Demantra/VCP connection to 11i EBS source will no longer be supported. 12.2 VCP supports only EBS 12.1 and EBS 12.2. So customer on EBS 11i will stay in 7.3.1.x line until they upgrade their EBS instance to 12.1 or 12.2.
-- Specific EBS/VCP (formerly ASCP) - Demantra Integration patches go away beginning in VCP 12.1.1 and higher; Please note that beginning with the release of VCP (the name previously given to ASCP) v12.1.1 and higher that no separate EBS/VCP - Demantra patches (ex. Bug 8551184) required. Customer should still run 'Update Synonyms' For Demantra 7.3.1

b) 7315 CDP - Install Patch 17248308 / Focuses on providing a new solution In-Memory Consumption Driven Planning. IMCDP provides the ability and scale to load support daily store level forecasting, safety stock generation and initialization of replenishment orders
Please note that customers upgrading to 7.3.1.5 will be unable to upgrade to currently available 12.2.1 and future release 12.2.2. A supported 12.2.X release for upgrade will be available in the future. Customers who believe they will upgrade to 12.2 branch in the near future should not implement using or upgrade to 7.3.1.5

1. 12.1.x VCP instance -
        The minimum VCP patch level required - 10192383:R12.SCP_PF.B - VCP 12.1.3.2 PATCH. However it is recommended that you get to the latest VCP/ASCP patch for 12.1.3 that's shown in Note 746824.1
        This means that, if you have a centralized environment, it should only be 12.1.3 or higher in order for Demantra to work.
        Note
        - Service Parts Forecasting (SPF) is only supported for 12.1 (source/destination). For 11510 or 12.0.6 source, SPF is not supported.
        - VCP 12.1.3.2 continues to support 7301, 730(without CTO), 720X

1.1 Supported SOURCE Instances for 12.1.x VCP instance -
i) 12.1.x - 10192383:R12.SCP_PF.B - VCP 12.1.3.2 PATCH

  ii) 12.0.6 - (This scenario is not certified by QA. But we do have a patch available)
    1. Patch 9830310 :R12.MSD.A - R12 EBS-DEMANTRA INTEGRATION RUP#09
    2. Patch 11058441:R12.MSD.A - 12.0.6 COMPATIBILITY PATCH FOR VCP 12.1.3.2 (Controlled Release)

iii) 11.5.10 CU2 -
a. Patch 9072397 - DEMANTRA INTEGRATION RUP#07 PATCH FOR 11.5.10
b. Patch 11058665 - 11.5.10 CU2 COMPATIBILITY PATCH FOR VCP 12.1.3.2

Note : Patches 9072397 and 11058665 are mandatory patches for 11510CU2 source, if customer is upgrading his 12.1 instance to VCP 12.1.3.2 or above, irrespective of the Demantra version.

2. 12.0.X VCP instance - Not Supported.
3. 11510CU2 VCP instance - Not Supported.

-- Attention: Oracle Value Chain Planning (VCP) Release 12.1.3.8 can only be applied to Oracle EBS Release 12.1.3 or 12.1.2. VCP 12.1.3.8 can be integrated with Demantra Release 7.3.1.4.

Official Note on VCP 11.5.10.2

The VCP policy is to have customers stay with EBS 11i but upgrade their VCP install to the level compatible with Demantra. So for 7314 they would work with the following configuration: EBS 11.5.10 (11i), VCP 12.1.3.8 Demantra 7.3.1.4
Most customers are unwilling to upgrade their EBS due to customizations, users and overall effort required, but upgrading their VCP apps is easier and is supported.

The customers leave their 11i source system as it is now and installs a separate VCP 12.1 instance which will collect data from 11.5.10.2. This is a fully supported configuration and allows them to connect Demantra 7.3.1.4 to EBS 11i10.
They don't even need to use any VCP apps other than Demantra, but the data flows through the 12.1 VCP instance into Demantra 7.3.1.4. This is the certified configuration for 11i and Demantra 7314, so we advise customers to this.
The additional benefit the customers get is the ability to bring their VCP apps forward without impacting their other EBS applications.

II. Important Reference Notes

Note 443969.1 Oracle Demantra Demand Management Documentation Library
Note 434991.1 EBS-Demantra Integration Installation Overview and Diagram

III. Latest Demantra Version for SQL Server Databases

The latest Demantra Version that supports Microsoft SQL Server Databases is v7.2.0.1.1 Patch 8811761. Note that the resulting file that is downloaded from this link should be p8811761_720_WINNT.zip. After installing that version and/or upgrading from earlier Demantra versions then please also apply Cumulative Patch 8823379
NOTE:1319331.1 Latest Supported Demantra Release For Sql Server and Installation

REFERENCES

NOTE:434991.1 - EBS-Demantra Integration Installation Overview and Diagram
NOTE:223026.1 - List of High Priority Patches for the Value Chain Planning (aka APS - Advanced Planning & Scheduling) Applications
NOTE:727237.1 - What patches are required to integrate Demantra with EBS?
NOTE:751772.1 - Distributed Engine Windows and Linux Deploying Multiple Engines Howto and Troubleshoot
NOTE:1361221.1 - Release 12.2.x Oracle Value Chain Planning Installation Notes - Known Issues, FAQ and Latest Patch Information
NOTE:443969.1 - Oracle Demantra: Documentation, Release Notes, Transfer of Information (TOI), and Training
NOTE:1969589.1 - Is Demantra 7.3.0.2 supported on a distributed installation of EBS 12.1.3.9 and VCP 12.1.3.9
NOTE:746824.1 - 12.1.x - Latest Patches and Installation Requirements for Value Chain Planning (aka APS Advanced Planning & Scheduling)
NOTE:1319331.1 - Latest Supported Demantra Release For Sql Server and Installation
NOTE:865764.1 - Patches for Demantra version 7.2.0
NOTE:421097.1 - R12.0 - Latest Patches and Critical Information for VCP - Value Chain Planning (aka APS - Advanced Planning and Scheduling)