In this Document
APPLIES TO:
Oracle Demantra Demand Management - Version 7.0.2 and laterInformation in this document applies to any platform.PURPOSE
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.
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 ProcedureNOTE: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 WeblogicNOTE:1952102.1 - Demantra Debugging, Error Location, Log File Location, Log Files by Process, Patch, PatchingNOTE:848205.1 - No Demantra Forecast Generated - Common IssuesNOTE:1408753.1 - Demantra LOG_IT Setup Execution Explanation ORA Errors Detailed Log Production + New SET_LOG_IT_LOGGING ProcedureNOTE:1614966.1 - Oracle Demantra Development strongly suggests all customers uptake this critical patch. Patch 17808535. Critical Internal Processing PatchNOTE:1086704.1 - Demantra Engine on Linux or Unix Failure Hanging Error Not Starting Debugging Install and Configuration Checklist
