Fine Tuning and Scaling Demantra
This chapter covers the following topics:
- Overview
- Basic Parameters
- Time Zone Support
- Application Server
- Demantra Local Application
- Database
- Date/Time Formats
- Integration
- Item Aggregation
- Logs and Old Data
- Proport Mechanism
- EngineOutputThreshold
- Simulation
- Solution Branding
- Threading
- Workflow
- Worksheets
- Configuring User Productivity Kit (UPK)
Overview
Typically you adjust parameters to control your solution's global behavior, including various defaults and performance settings. This chapter provides an overview of most of the parameters, grouped into specific areas.
Basic Parameters
For reference, Demantra stores basic configuration information in the following parameters. Unless otherwise noted, you should not change these parameters after going live:
Time Zone Support
Global companies often have planning organizations and planners in different time zones. For these customers, the data loaded and planning cycles could be offset by a few hours. When Demantra is deployed as a single global instance, this can create an issue where the last sales date tracked by the system is the most recent sales date, regardless of the location of the planners or organizations. This can lead to the following issues:
-
Worksheets display a frozen time period for the global region that is few hours behind or in the previous calendar day.
-
Calculations in a given time bucket may not be performed since its considered a historical period for that region.
-
On hand inventory now must be offset to support calculations since the time period is considered historical.
When you enable time zone support in Demantra, all data and worksheet calculations are aligned to a planner's current system date, which is important in global daily planning systems. This allows both worksheets and user initiated actions to respect user locality. Worksheets display the first forecast row based on the user's system date.
Enabling Time Zone Support
Time zone support is enabled in Demantra by setting the SetEarliestTimezone parameter. The max_sales_date parameter determines the last history date that is displayed on a worksheet. If SetEarliestTimezone is defined, then the specified time zone is used to convert MaxSalesDate to the local MaxSalesDate. When processing data for a specific region, batch jobs can be configured to use the appropriate MaxSalesDate. Worksheet Level methods pass the user's system time zone to the workflow to be used while running batch jobs.
Time Zone Support Parameters
The following parameters are used to configure time zones.
| Parameter | Location | Description |
| HistoryLagBuckets | init_params | Specifies the number of days to move back the last date backup. The last_date_backup parameter determines the last history date that is used by the engine. If this parameter is defined the engine use the value of this parameter instead of the last_date_backup. |
| SetEarliestTimezone | sys_params | Specifies the earliest time zone where data will be loaded. This time zone is used convert MaxSalesDate to the local MaxSalesDate. The value of this parameter is available in the workflow dictionary #Local_Timezone# for use in custom steps. If a workflow is invoked from a method, then the user's system time zone is passed to the workflow and ise used in conjunction with system timezone to support adjustments of process, shifting of dates, and so on. |
Application Server
The APS queue uses the following parameters:
Demantra Local Application
The following parameters control the Demantra Local Application. Also see "Solution Branding" for parameters that control the Demantra Local Application titles.
General
The following parameters control the Demantra Local Application in general:
Also see "Customizing Demantra Web Pages".
My Tasks
The following parameter affects the My Tasks pane of Demantra Local Application:
| Parameter | Description |
|---|---|
| general.userList.tasks | Specifies whether the My Tasks module displays the Create Task button: |
Who's Online
The following parameters control the Who's Online pane of Demantra Local Application:
Content Panes
The following parameters control the default behavior of graph-type content panes:
See also
"Email"
"Workflow"
"Worksheets"
Database
The following parameters control how Demantra connects to and uses the Demantra database.
For additional parameters that specify which database Demantra connects to, see the Oracle Demantra Installation Guide.
General Database Settings
Database Connections
The following parameters control Oracle Demantra's database connections:
Oracle Tablespaces
For Oracle databases, Demantra writes to multiple tablespaces, as specified during installation. The tablespace assignments are controlled by parameters, which you can edit through the Business Modeler. Make sure that these parameters refer to tablespaces within the appropriate database user, and make sure each has enough storage. Additional parameters control the default initial sizes and how much storage is added.
* You set these parameters during installation.
Oracle recommends that you use the standard names for these tablespaces, as documented in the Oracle Demantra Installation Guide. Then it is easier for you to share your database with Oracle Support Services in case of problems.
Demantra provides a database procedure that you can run at regular intervals that checks tables for missing primary keys, unoptimized ordering of null columns, and other conditions that may negatively impact database performance. You can set a threshold determining the minimum number of rows a table must have before it is checked. You can also set the frequency at which a reminder to run the thorough check will appear in the 'log_table_reorg' table after running the quick check. For each finding identified by the check, a corresponding message is logged in the 'log_table_reorg' table. The message specifies the table with the particular problem, In some cases a finding can be a recommendation to reorganize a table. For that you can run a sql script on the table that will reorganize and optimize it for better performance.
There are two types of database checks: 1) a quick check that normally runs in less than 20 seconds, and 2) a more thorough one that, depending on system data volume, can run up to several hours.
Both the quick check and the thorough checks can be launched manually using PLSQL by running the procedure TABLE_REORG.check_reorg, and specifying a parameter of 'T' to run the thorough check, or 'Q' to run the quick check. For example, enter CHECK_REORG('Q') to run the quick check.
This script is located in the Demantra installation directory, under \Demand Planner\Database Objects\Oracle Server\admin.
You can also run the script by defining a workflow that contains the 'Stored Procedure' workflow step. Specify 'TABLE_REORG.check_reorg' as the procedure name and either 'T' or 'Q' as the parameter.
All activity of the checks and reorg operation are logged in detail in the log_table_reorg table. Please review this table when troubleshooting (order by log_time) for detailed error output and comments.
Technical Settings
The following parameters should be adjusted only by someone experienced with databases:
See also
"Integration"
Overview of Database Health Check
Demantra provides a database procedure that you can run at regular intervals that checks tables for missing primary keys, unoptimized ordering of null columns, and other conditions that may negatively impact database performance. You can set a threshold determining the minimum number of rows a table must have before it is checked. You can also set the frequency at which a reminder to run the thorough check will appear in the 'log_table_reorg' table after running the quick check. For each finding identified by the check, a corresponding message is logged in the 'log_table_reorg' table. The message specifies the table with the particular problem, In some cases a finding can be a recommendation to reorganize a table. For that you can run a sql script on the table that will reorganize and optimize it for better performance.
There are two types of database checks: 1) a quick check that normally runs in less than 20 seconds, and 2) a more thorough one that, depending on system data volume, can run up to several hours.
Both the quick check and the thorough checks can be launched manually using PLSQL by running the procedure TABLE_REORG.check_reorg, and specifying a parameter of 'T' to run the thorough check, or 'Q' to run the quick check. For example, enter CHECK_REORG('Q') to run the quick check.
This script is located in the Demantra installation directory, under \Demand Planner\Database Objects\Oracle Server\admin.
You can also run the script by defining a workflow that contains the 'Stored Procedure' workflow step. Specify 'TABLE_REORG.check_reorg' as the procedure name and either 'T' or 'Q' as the parameter.
All activity of the checks and reorg operation are logged in detail in the log_table_reorg table. Please review this table when troubleshooting (order by log_time) for detailed error output and comments.
Health Check System Parameters
The system parameters listed below control the behavior of this database procedure. For details about each parameter, see Non-Engine Parameters.
SYSTEM_PRIMARY_KEY
MIN_NUMROWS_FOR_REORG
QUICK_CHECK_TIMEOUT
THOROUGH _CHECK_INTERVAL
THOROUGH_CHECK_TIMEOUT
Thorough Database Health Check
The "Thorough Database Health Check" is used to launch the thorough health check procedure. It writes output to the log_table_reorg table. This procedure requires more time than the quick check but provides greater accuracy. At the end of the thorough check, purging is done to keep only 2 months of information in the log table. If it recommends reorganizing the database tables, then run the table reorganization utility described below. You should run the thorough check after major changes in data volume, such as large engine runs or changes to table metadata. An example of this would be creating or deleting a series that affects column modification in the table.
Note: In order to run the table reorg, additional privileges are required for the Demantra schema. These privileges can be obtained by running the grant_table_reorg.sql script. This script is located in the Demantra installation directory, under \Demand Planner\Database Objects\Oracle Server\admin.To revoke these privileges, run revoke_table_reorg.sql (same location as the 'grant' script).
For information regarding database privileges that may impact the Table Reorganization Utility, see the sys_grants.sql section of the Demantra Installation Guide.
Running the Table Reorganization Utility
There are several ways to run this utility, including:
-
Running Table Reorganization SQL Script
-
Calling the TABLE_REORG.REORG stored procedure
-
Running a workflow
You can use SQL*Plus to run the SQL script or to run the TABLE_REORG.REORG stored procedure. In both cases you need to log into the Demantra schema as described below.
-
Be sure you have a complete and valid backup of the database.
-
Login with SQL*Plus as SYS (sqlplus sys/demantra@orcl where 'sys' is the system username, 'demantra' is the schema name and 'orcl' is the database name)
-
Grant Demantra schema the required privileges to run the reorg. For example, run grant_table_reorg.sql in the Demantra installation directory under Demantra_installation\Demand Planner\Database Objects\Oracle Server\admin.
-
Login with SQL*Plus as the Demantra database schema name (for example: sqlplus demantra/dem1@orcl)
Note: Shutting down the application server is not required. However, running this process during a heavy load will slow down production operations.
Running the Table Reorganization SQL Script
After logging in with SQL*Plus, perform the following steps:
-
Call the run_table_reorg.sql script (for example: SQL> @run_table_reorg.sql)
-
Enter the name of the table you want to reorganize.
-
Enter reorg type 'R' or 'C'. Entering 'R' causes a row reorg. Entering 'C' also causes a row reorg, but additionally re-sequences columns so that null columns come after columns with data.
-
Enter the value for PCTFREE (see note below). The default value is 20%.
-
Enter the degree of parallelism. This determines the number of worker threads running. The default value is 4.
-
Hit any key to start the reorg process (or Ctrl C to abort).
Note: The PCTFREE parameter sets the minimum percentage of a data block to be reserved as free space for possible updates to rows that already exist in that block. For example, setting PCTFREE to 10 causes 10% of each data block in the table's data segment to be kept free and available for possible updates to existing rows. However, this value is considered low and could cause "row chaining." Row chaining occurs when data for a single row must span more than one data block, which slows database performance. At the other end of the spectrum, a value such as 50 would likely prevent row chaining, but also consumes more disk space.
Calling the TABLE_REORG.REORG Stored Procedure
This is another way of performing the reorg process. After logging in with SQL*Plus, execute the table_reorg.reorg procedure, passing in arguments for the REORG procedure. For details refer to the Database Procedures chapter in the Oracle Demantra Implementation Guide.
For example:
BEGIN
table_reorg.reorg('DEMANTRA','SALES_DATA','C',10,4);
END;
This example executes a column reorganization as defined by the following parameters:
| Schema: | DEMANTRA |
| Table: | SALES_DATA |
| Row or Column Reorganization | Column |
| Min % reserved free space (PCTFREE | 10 |
| Degree of parallelism (Num of parallel slaves) | 4 |
After Running the Script or Stored Procedure
-
After the process completes successfully, verify that the reorganized table is valid by running a worksheet with many series that are related to that table. For example, if the process ran on the PROMOTION_DATA table, you could open the Promotion Comparison worksheet.
-
After confirming the table is valid, you can drop the original table which the process renames to RDFDDHHMISS$-original table name (where DDHHMISS is date format Day,Month,Hour. The table name is truncated to 30 characters, and the hour format is 24).
-
If grants were given by running the grant_table_reorg.sql script, revoke the privileges you granted earlier by connecting to SQL*Plus again as SYS and running revoke_table_reorg.sql located in the same directory.
Running the Table Reorganization Procedure Using a Workflow
If desired, the table reorganization procedure can be run using a workflow. If you are implementing the Oracle In-Memory Consumption Driven Planning (CDP) module, the table reorganization procedure TABLE_REORG.REORG can be set up to run periodically using the predefined workflow “CDP Weekly Data Tables Maintenance.” The workflow is set up to reorganize the T_EP_CDP_DATA and SALES_DATA tables by default. Each run of the REORG procedure is logged in a dedicated log table named LOG_TABLE_REORG. For details about this workflow, refer to the Oracle In-Memory Consumption-Driven Planning User's Guide.
To enable this workflow to run periodically, select the 'Enable automated table reorganization' checkbox in the “DBA Details” screen when installing or upgrading Demantra. This check box appears in the 'DBA Details' Installer screen and can be selected even if you are not implementing CDP. However, the CDP Weekly Data Tables Maintenance workflow will not be enabled nor will it be set up to run automatically unless CDP is installed.
If you are not installing CDP, you can either define a workflow to automate the process of running the TABLE_REORG procedure or you can run it manually. When defining a workflow to run the procedure, use the "Stored Procedure" workflow step and specify the table_reorg.reorg procedure, and then enter the Demantra schema name, the table name, reorg level, PCTFREE and degree of parallelism in the Parameters. These parameters are listed in "Calling the TABLE_REORG.REORG stored procedure.”
For details about running the procedure manually, see “Running the Table Reorganization Utility.”
Note: If this option is selected, then a new database role will be created (DEM_SECURE) with additional privileges that are required to reorganize a table. This role is not enabled by default and is password protected. When the REORG procedure is executed, it enables the role, reorganizes the table and then revokes the role so the session has the extra privileges only during the reorganization process.
Database Partitioning
To use the data partitioning tool, in the Business Modeler go to Tools > Database > Create Partitions.
Profile Selection screen
This window displays the “New” icon and all profiles already existing in the system. The list can be displayed as large icons or as a list by pressing either one of the two buttons to the right of the list area. Double clicking any icon starts the wizard by opening the first wizard screen - “Profile Details”. To create a new profile, select the “New Partition Profile” icon.
Profile Details screen
-
Name- This is a mandatory text field with a maximum limit of 30 characters. Spaces are not allowed in this field.
-
Description – This is a text area with a limit of 2000 Characters.
-
Last Update Date – This displays the last time this profile was updated.
-
Last Executed Date - This displays the last time this profile was executed.
Time-Dimension Partitioning screen
The next screen allows the user to define partitioning of the time dimension. Two different modes can be used: partitioning via an existing time dimension, or partitioning by a custom definition.
-
Time Level Panel - The time level panel allows the user to define time dimension partitions based on time levels already defined in the system, such as Fiscal Month, Fiscal Quarter, Fiscal Week, and Fiscal Year. After selecting a time level, Add/Delete buttons will appear. You can then add time partitions by grouping different periods together into a partition.
-
Custom Panel – The custom panel allows for the definition of custom time ranges that are not related to any specific Time level. The panel includes a table area for defining partitions and two buttons (Add/Delete) for controlling the content of the table. This table allows the user to define custom time partitions by giving the partition a name and specifying the maximum date value of the partition. The table consists of two columns
Level-based Sub-partitions screen
This screen allows the user to define the sub-partition scheme by selecting a location or product dimension for partitioning. The components of this screen are identical to the components available in the previous screen for time level selection.
Final review and execution screen
This screen displays the partitioning profile definition as well as the load distribution for the selected partitioning scheme.
-
Time Partition and Level Sub-partition Columns – these columns display the partition scheme as defined in the previous two stages.
-
Table Name percentage Column – Displays the proportion of the table in the sub-partitions and partitions according the selected partitioning scheme.
-
Create Button – Use this button to initiate a database process that will create stored procedures and scripts that will partition the selected table.
-
Revert Button – Reverts a partition setup back to an non-partitioned state.
Date/Time Formats
The following parameters control the formats of date and date/time values throughout Demantra:
Adding a New Date Format
If the date format you want in a worksheet is not available be default, a custom Java-compatible date format can be defined. This can be done by an administrator, by defining the format in the TIME_FORMAT table and restarting the application server.
To add a new date format:
-
Review existing date formats in Demantra. For example:
-
Open the Demantra Local Application.
-
Open any worksheet.
-
Select 'Time' from the toolbar or the Worksheet menu.
-
Click on the Advanced button.
-
Review the available date formats.
-
-
Using a tool such as SQL Developer, add any Java-compatible date format to the TIME_FORMAT table. For example:
FORMAT_ID DATE_FORMAT FORMAT_ACTIVE IS_DEFAULT APPLICATION_ID 9 MMMM: dd yyyy 1 1 My_NEW_FORMAT If FORMAT_ACTIVE is '1' then the format is enabled and available for use in Demantra worksheets. If you do not want end users to see a date format in Worksheet Designer, set FORMAT_ACTIVE to '0'.
If IS_DEFAULT is '1' then the format will be the default in all new worksheets.
-
Restart the application server.
-
Log into the Demantra Local Application and open any worksheet.
-
Select 'Time' from the toolbar or the Worksheet menu.
-
Click Advanced.
-
Review the available date formats.
-
Select the new format and then click OK.
-
Re-run the worksheet and verify that the new time format appears as expected.
Please note the following:
-
Incorrect date formats will be rejected when restarting the application server and will appear in the Demantra Local Application log file
-
If no format is specified as the default, MM/dd/yy will be used
-
If multiple formats are specified as defaults, the one with lowest internal ID will be used
If you are using any of the Demantra Web-based software, Demantra can automatically send email on specific occasions, for example, within workflows. To enable this, first set up an administrator email account on an SMTP server; this account will be the originator of all Demantra's automatic messages. You will probably need the help of the IT department to get this account configured correctly, depending on the network security.
Then use the parameters in this section to specify that email account for use by Demantra.
Configuring Demantra Email
First, the following parameters specify the email account from which Demantra Web-based software will send email.
Strings Used in Demantra Email
In addition, the following parameters control the strings used in the email messages that Demantra sends.
Integration
The following parameters control import and integration in Demantra. These parameters apply only to the core Demantra tools
Item Aggregation
For improved performance, you can configure Demantra to aggregate data by items and use that aggregated data whenever possible. In this case, Demantra maintains the branch_data_items table in addition to the usual tables. Demantra uses this table whenever possible; it does not use the table whenever you need to view specific locations or filter by location. To configure Demantra in this manner, set the UseItemsAggri parameter.
Note: Also be sure the DYNAMIC_SYNC is scheduled to run periodically to keep the branch_data_items table up to date.
Logs and Old Data
The following parameters control how long Demantra keeps various kinds of historical data:
| Parameter | Description |
|---|---|
| audit_history_length | Number of months of audit data to keep. |
| log.history | The number of days for which workflow history is kept. |
Also see "Logging Messages of the Application Server".
Proport Mechanism
Parameters That Control Behavior
Parameters That Affect Performance
Proport handles large amount of data processing and can require a substantial amount of time and system resources. It is possible to improve run time performance using parallelization and by grouping the Proport process into several iterations.
To do this, define the following parameters in the init_params table for each engine profile:
Example:
ProportTableLabel = 'Item'
ProportRunsInCycle = 10
ProportParallelJobs = 2
When running Proport with these settings in the example above, processing occurs for all combinations associated with 1/10 of the Item level members. Each execution invokes 2 parallel jobs in the DBMS_JOB queue. Proport is called ten times before all combinations have been processed.
Use caution when choosing the level by which Proport will be broken into separate tasks. The process will treat each member as equal and will not be aware that some members contain far more data than others. Selecting an inappropriate level could result in an uneven processing time between different session runs.
Example:
ProportTableLabel = 'Segment'
ProportRunsInCycle = 5
ProportParallelJobs = 4
If there are 10 segments, then each Proport process will execute on 2 (10/5) segments and use 4 parallel processes. If a specific segment contains a much larger number of items than other segments, then processing of this specific segment require more time to run.
EngineOutputThreshold
The forecast for certain combinations may not change significantly between runs, this typically occurs for steady sellers, or extremely slow moving items. Writing out a new forecast in this case would have only marginal benefit to the supply chain. However, it would add cost in:
-
Engine I/O processing
-
The noise of minute variations in the production forecast
The parameter "EngineOutputThreshold" provides control over whether to write the forecast for a combination that has changed very little. Example: If the new value is 3% larger than the old value, and the EngineOutputThreshold is 5%, then the engine will not output the new value, and the old value will remain. In this case the new value would need to be at least 5% larger or smaller than the old value before it replaces the existing forecast value. Note that if either the old value or new value is zero, then the difference will be calculated as 100% (unless they're both zero, in which case the difference would be 0%).
Simulation
When a user starts a large simulation, it is useful to check the size of that simulation and provide a warning if it will take a long time to run. You may also want to prevent simulations that are too long from being run at all.
You can configure Demantra to detect large simulations and display a message to the user, to confirm that this is what the user wants to do. You use the following parameters:
| Parameter | Purpose |
|---|---|
| SimWarnSize | Specifies the threshold size of a simulation that is large enough to trigger a warning message to the user. Specify this as a percentage of the total number of combinations. |
| SimMaxSize | Specifies the threshold size of a simulation that is too large to run. If a user tries to perform a simulation of this size, Demantra displays a message and does not attempt the simulation. Specify this as a percentage of the total number of combinations. |
| MatrixCombs | Indicates the number of combinations currently in the mdp_matrix table. This information can be useful in helping you to set SimMaxSize and SimWarnSize. |
You should run some trial simulations on the solution hardware and set threshold values that are appropriate for the actual users.
Solution Branding
The following parameters control titles throughout the Demantra solution:
Threading
Demantra uses threading mechanisms in multiple places. Threading is a general mechanism that uses system resources more effectively to run several tasks in parallel.
-
"Threading for the Attribute Update Mechanism"
-
"Threading for the Update Mechanism"
-
"Threading for Updating Parallel Values"
-
"Threading for Promotion Copy/Paste"
-
"Threading for Methods"
-
"Threading in the Web Worksheets"
-
"Threading in the Business Logic Engine"
Threading for the Attribute Update Mechanism
This thread pool uses the following parameters:
| Parameter | Description |
|---|---|
| threadpool.attributesUpdate.per_comb | Maximum number of threads that a single thread can use. |
| threadpool.attributesUpdate.size | Maximum number of allowed threads for this thread pool. This should be less than MaxDBConnections. |
| threadpool.attributesUpdate.time-out | Idle time-out period. This specifies how long (in milliseconds) a thread is left unused before it is ended automatically. |
Threading for the Update Mechanism
The update mechanism saves data to the database. This thread pool uses the following parameters:
Threading for Updating Parallel Values
This thread pool uses the following parameters:
Threading for Promotion Copy/Paste
Another thread pool handles copying and pasting promotions. This thread pool uses the following parameters:
Threading for Methods
Another thread pool handles level methods. This thread pool uses the following parameters:
Threading in the Web Worksheets
The Web worksheets also use threading
Threading in the Business Logic Engine
The Business Logic Engine uses threading as follows: The thread pool specifies the number of parallel BLE tasks, each of which loads a different combination of the worksheet, runs the calculation engine on it, and saves the data back to the database. The number of threads in the pool is affected by the system resources, mainly the number of CPUs that the machine has (each thread runs on a different CPU). The following parameters control this threading mechanism:
Workflow
The following parameters control the Workflow module:
See also
"Solution Branding" "Demantra Local Application" "Email"
Worksheets
The following parameters affect the Web-based worksheets. They are grouped into several areas:
-
"General Worksheet Behavior"
-
"Worksheet Performance"
-
"Worksheet Designer"
For another way to improve performance, see also "Managing Level Caching".
The following parameters control the default behavior of the Web-based worksheets
The following parameters affect the performance of the Web client:
Worksheet Designer
The following parameters control the defaults in the worksheet/content designer
See also
"Demantra Local Application"
Parallel Hints for Worksheets
Some worksheets access a large amount of data which can cause them render slowly. A parallel hint can be implemented to improve performance for such worksheets. A hint specifies the number of threads used by the worksheet query and can be applied to two parts of the worksheet: generation of the combinations and retrieval of data to be displayed in the worksheet.
Warning: Use caution when implementing worksheet hints. When a large number of users simultaneously access the database, too many hints can overwhelm the database connection pool and substantially decrease performance.
Setting a hint requires manually adding a row to the WORKSHEET_HINTS table; this task should be performed only by an experienced system or database administrator.
The WORKSHEET¬_HINTS table contains the columns in the table below.
| QUERY_ID | USER_ID | CONTEXT_ID | POPULATION_HINT | DATA_HINT |
|---|---|---|---|---|
| Q | 0 | 0 | The hint to be used for worksheet Q with any user and any context in the Population SQL | The hint to be used for worksheet Q with any user and any context in the Population SQL |
| Q | U | 0 | The hint to be used for worksheet Q with user U and any context in the Population SQL. For all other users besides U, the generic hint defined above is used, if one exists. | The hint to be used for worksheet Q with user U and any context in the Data SQL. For all other users beyond U, the generic hint defined above is used. |
| Q | U | C | The hint to be used for worksheet Q with user U and context C in the Population SQL. For all other contexts and for the same user U, the above row is used. For all other users, the generic hint is used, if one exists. | The hint to be used for worksheet Q with user U and context C in the Data SQL. For all other contexts and for the same user U, the hint in the row above is used. For all other users, the generic hint is used. |
The POPULATION_HINT and DATA_HINT columns contain the actual hint as an SQL string. For example, to specify that the query should use 8 threads when accessing the branch_data table, this field would be "parallel(branch_data 8)".
The QUERY_ID, USER_ID, and CONTEXT_ID columns specify the circumstances when this hint would be used.
QUERY_ID specifies the internal ID of the worksheet for which the hint should be applied.
USER_ID specifies for which user the hint will apply when opening the worksheet. When this field is set to zero, the hint will apply to all users.
CONTEXT_ID specifies the level member name; it corresponds to the level member that is selected when a worksheet is opened with the "Open With" menu option. If the CONTEXT_ID is zero, then the hint will apply to all contexts. If the worksheet is opened without “Open With,” this setting is ignored.
Configuring User Productivity Kit (UPK)
If you have licensed and installed UPK, perform the following to launch UPK from Oracle Demantra Web help.
-
Install and configure UPK on a Web server. Refer to UPK documentation for details.
-
Launch Business Modeler, and then locate the LaunchUPK parameter.
-
In the Value field, enter a valid URL to launch UPK.
For example: http://server name/virtual directory name/index.html
-
Save the changes.
-
Log in to Demantra, and then click Help from the Demantra Local Application, Workflow Manager, or from within a worksheet.
-
Click the “UPK” link. The Player should launch successfully.