Release 2(v9.0.2)
Part Number A95243-03
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle9iAS Personalization Administrator's Guide Release 2(v9.0.2) Part Number A95243-03 |
|
After you have installed OP and verified that the installation is correct, you can specify certain configuration parameters for OP.
This chapter
All OP configuration parameters reside on the system where Oracle9i is installed.
OP allows users to schedule package builds, deployments, and reports. The OP administrator can also specify that certain users get an email notification when a build, deploy, or report completes. The following configuration parameters in the MOR configuration table control scheduling and notification:
The default value of NAME - ADMIN_EMAIL_ADDRESS is the string Oracle.Personalization@oracle.com. Change this value when you install OP.
These parameters are divided into three categories:
Table 5-1 lists the RE configuration parameters, their data types, their default values, and a description for each. These parameters can be found in the RE_CONFIGURATION table.
|
1
Requires restart of OP. |
Table 5-2 describes the configuration parameters for the OP Mining Object Repository (MOR). The table shows their data types, their default values, and a description for each. These parameters can be found in the MOR_CONFIGURATION table.
The table includes a column titled Change. If the value in this column is "N," do not change the parameter. If the value in this column is "Y," the value of the parameter must be changed to a value suitable for your environment. The description of these parameters includes the instruction "change value on install."
| Parameter | Data Type | Value | Description | Change |
|---|---|---|---|---|
|
MOR_USERNAME |
string |
<user name> |
User name for Admin UI; change value on install |
N |
|
MOR_PASSWORD |
string |
<password> |
Password for Admin UI; change value on install |
N |
|
MOR_DBALIAS |
string |
<alias> |
Alias for the MOR database; change value on install |
N |
|
MOR_SCHEMA |
string |
< schema> |
MOR schema name |
N |
|
MOR_HOST_URL |
string |
<hostname> |
MOR hostname; change value on install |
N |
|
MOR_PORT |
string |
<port> |
MOR port; change value on install |
N |
|
MOR_SID |
string |
isab900 |
MOR system ID; change value on install |
N |
|
MOR_VERSION |
string |
9.0.1 |
MOR version number |
N |
|
scheduleItemGracePeriod |
int |
60 |
Number of minutes a scheduled item must have been past due for it to cause an error |
Y |
|
buildEvents |
int |
20 |
Maximum number of events of this type to keep in log |
UI |
|
MAXNUMPUCHASEINGSESS |
int |
20 |
The maximum number of purchasing sessions reports to keep per recommendation engine farm |
|
|
MAXNUMRECEFFREP |
int |
20 |
The maximum number of recommendation effectiveness reports to keep per recommendation engine farm |
|
|
MAXNUMITEMIZEDRECEFFREP |
int |
20 |
The maximum number of itemized recommendation effectiveness reports to keep per recommendation engine farm |
|
|
NUMOFITEMSINITEMIZEDRECEFFREPORT |
int |
20 |
The number of top-ranked items in itemized recommendation effectiveness reports |
|
|
IAS_HOSTNAME |
string |
|
Parameter used by report workflow to construct a URL for email notification |
|
|
IAS_SERVLET |
string |
|
Parameter used by report workflow to construct a URL for email notification |
|
|
IAS_SERVLET_ZONE |
string |
|
Parameter used by report workflow to construct a URL for email notification |
|
|
IAS_PORT |
string |
|
Parameter used by report workflow to construct a URL for email notification |
|
|
IAS_SERVLET_MOR_CONN |
string |
|
Parameter used by report workflow to construct a URL for email notification |
|
|
|
|
|
|
|
|
deployEvents |
int |
20 |
Maximum number of events of this type to keep in log |
UI |
|
reportEvents |
int |
20 |
Maximum number of events of this type to keep in log |
UI |
|
LOG_LEVEL |
int |
2 |
|
Y |
|
ALGS_TRACE |
int |
0 |
0=OFF, 1=LOW (detail), 2=MODERATE, 3=HIGH |
Y |
|
DMAPI_TRACE |
int |
0 |
0=OFF, 1=LOW (detail), 2=MODERATE, 3=HIGH |
Y |
|
PAR_TRACE |
int |
0 |
0=OFF, 1=LOW (detail), 2=MODERATE, 3=HIGH |
Y |
|
TNB_TRACE |
int |
0 |
0=OFF, 1=LOW (detail), 2=MODERATE, 3=HIGH |
Y |
|
UI_TRACE |
int |
0 |
0=OFF, 1=LOW (detail), 2=MODERATE, 3=HIGH |
Y |
|
UTIL_TRACE |
int |
0 |
0=OFF, 1=LOW (detail), 2=MODERATE, 3=HIGH |
Y |
|
WFJAVA_TRACE |
int |
0 |
0=OFF, 1=LOW (detail), 2=MODERATE, 3=HIGH |
Y |
|
MAIL_PREFERENCEFoot 1 |
string |
MAILHTML |
Format for email notifications; other possible value is MAILTEXT |
Y |
|
NLS_LANGUAGEFoot 2 |
string |
|
Supported values: AMERICAN, FRENCH, GERMAN, ITALIAN, SPANISH, BRAZILIAN PORTUGUESE, JAPANESE, KOREAN, SIMPLIFIED CHINESE |
Y |
|
NLS_TERRITORYFoot 3 |
string |
|
Supported values: AMERICA, FRANCE, GERMANY, ITALY, SPAIN, BRAZIL, JAPAN, KOREA, CHINA |
Y |
|
ADMIN_EMAIL_ADDRESS |
string |
Oracle. |
Email address of the Oracle Personalization administrator for email notifications |
Y |
Table 5-3 describes the configuration parameters for the OP Mining Table Repository (MTR). The table shows their data types, their default values, and a description for each. These parameters can be found in the MTR_CONFIGURATION table in MTR schema.
These parameters allow selecting different types of data to be synchronized to the MTR. At the end of an OP session, MTR synchronization adds data collected in the RE (during the session) to the data already stored in the MTR. In order for data synchronization to take place, the MTR must be configured to allow the various types of data to be synchronized.
|
1
Change these values only when the MTR is not being used. |
Installation and configuration of a recommendation engine (RE) must be tailored to the expected number of active users that it will support. The RE in this context refers to a single engine in a single Recommendation Engine Farm on a single database instance. If multiple engines in one or more RE farms are installed on the same database instance, the configuration parameters require adjustment.
Many factors go into the optimization of an RE. Some of these are set by the installation procedure, while others are techniques that may be used by the DBA. Configuration options fall into two broad categories:
System availability settings are those settings required by the RE to handle user load without failure. Performance settings are those settings that help maximize throughput.
The system availability settings for RE configuration depend on the number of anticipated users. If you know the number of users, it is possible to estimate the approximate system resource requirements and make database configuration recommendations. Since the REAPI maintains a connection pool of user connections, which can be reused, the number of required connections depends on how well user requests are being satisfied by the RE. That is, if for some reason there is a slowdown in the RE causing connection links to be held longer in the REAPI connection pool, the number of connections will tend to increase. As the number of connections increases, the number of actual database sessions increases. Each connection in the REAPI connection pool represents a database session.
The maximum number of connections in the REAPI connection pool is a configurable parameter in each RE. If this limit is exceeded, it may indicate that there are performance issues that need to be addressed other than simply increasing the size of the connection pool.
Each Web application user's client session results in database activity in the RE schema. First, configure the database to handle the number of anticipated simultaneous users. Depending on the amount of available memory and CPUs in the system the RE database is installed on, it may be possible to support 50-100 users in a dedicated server environment. In this environment, each user connection to the database would require its own dedicated Oracle server for database access. As the number of users extends beyond 100, it may be more appropriate to use Oracle's Multi-Threaded Server environment where database connections are pooled and serviced by shared database servers. The DBA responsible for the RE must decide whether the dedicated or shared server environment is used.
REAPI performance may be affected by several factors. On the client side, the REAPI runs in the JServer environment. Sufficient memory and CPU must be available to the client to handle the throughput for the active users. Communication with the RE from the REAPI clients is implemented through JDBC connections over Oracle's SQL*Net network. As the number of users grows, so does the demand on the network.
The recommendation engine requires certain database parameters to be set to a minimum value, as follows:
JOB_QUEUE_PROCESSES=2
(in ORACLEHOME/DBX directory)
ORACLEHOME/DBX/init_<SIDname>.ora
The parameters and values listed below, while not necessary, are strongly recommended:
|
BUFFER_POOL_KEEP |
50 @ 8192 bytes ea |
|
SORT_AREA_SIZE |
819200 bytes |
|
SORT_AREA_RETAINED_SIZE |
819200 bytes |
Table 5-4 suggests guidelines for database configuration parameters based on number of projected users. The table shows, for a specified number of users, whether multi-threaded servers (MTS) are recommended, and recommended values for the number of MTS dispatchers, shared MTS servers, sessions, the size of large pool, and the size of shared pool:
The table settings in Table 5-5 are based on the number of estimated simultaneous sessions. These parameters are set in the RE schema table RE_CONFIGURATION. The table shows, for a specified number of simultaneous sessions, the recommended connection pool size and data synchronization interval:
| Sessions |
Connection Pool Size (number of connections) |
Data Synchronization Interval (in seconds) |
|---|---|---|
|
100 |
128 |
300 |
|
1000 |
256 |
300 |
|
2000 |
512 |
300 |
|
3000 |
1024 |
180 |
|
4000 |
2048 |
180 |
The Mining Table Repository (MTR) database holds customer (demographic, purchasing, ratings, navigational data) and product data. Data mining models are built based on this data. Any data collected in the RE will be copied to the MTR at scheduled intervals. Customer profile data is also copied from the MTR into the RE when a customer begins a user session. All data transfer between the MTR and the RE is done using database links.
Table 5-6 offers guidelines for database configuration parameters based on the number of projected users. The table shows, for a specified number of users, whether multi-threaded servers (MTS) are recommended, and recommended values for the number of MTS dispatchers, the number of MTS servers, the number of sessions, and the size of the large pool:
| Users | MTS | MTS Dispatchers | MTS Servers | Database Sessions | Large Pool |
|---|---|---|---|---|---|
|
100 |
No |
N/A |
N/A |
100 |
Default |
|
1000 |
Yes |
2 |
10 |
100 |
25M |
|
2000 |
Yes |
3 |
20 |
200 |
50M |
|
3000 |
Yes |
4 |
20 |
300 |
100M |
|
4000 |
Yes |
50 |
30 |
400 |
150M |
Data synchronization moves user-specific data that is collected in the RE during a session to permanent storage, that is, to the appropriate table in the mining table repository (MTR). Session and recommendation data are always synchronized; other kinds of data are synchronized according to the way the RE Farm and MTR are configured. See "Data to Synchronize", later in this chapter, for configuration instructions. Customer data and visitor data are copied to the appropriate MTR tables. (There is one set of MTR tables for customer data and a different set for visitor data.)
Data is synchronized every DataSyncInterval, which is a configuration parameter that is specified for an RE Farm. Data synchronization is performed only for users whose sessions are inactive. A session is inactive if there has been no activity for a specified period of time or if the session has been explicitly closed. Note that a user can have more than one session at any time. A customer ID is deleted from RE_PROFILE_DATA only when all the customer's sessions are inactive.
After the data is copied to the MTR, the data is purged (deleted) from the RE tables. Data that cannot be synchronized for some reason (for example, data that has an invalid item ID) is also purged.
Data is collected in the RE_CURRENT_SESSION_DATA table and the RE_RECOMMENDATION_DETAIL table. The data source type of the data determines the MTR table to which data is copied.
Table 5-7 shows the four data source types and the MTR table for each.
RE_RECOMMENDATION_DETAIL data is copied to the MTR_RECOMMENDATION_DETAIL table and appropriate RE_ACTIVE_USER data is copied to MTR_SESSION table. RE_PROFILE_DATA is updated in the MTR_CUSTOMER table.
You specify two things: the synchronization interval for a Farm, and exactly what data to synchronized for a specific MTR connection:
In the Farms tab of the Administrative UI, select a farm, select Edit, and then click the Advanced Settings button. Specify an appropriate data synchronization interval for the selected farm. (You can also specify the timeout interval here.)
The default synchronization interval is 300 seconds (5 minutes). The synchronization interval should be adjusted for the number of users of the application. If there are many users and the synchronization interval is long, the REs will fill with data.
In order for data synchronization to take place, the MTR must allow that type of data to be synchronized. These rules are specified when you install OP.
You configure the MTR connection using the OP Administrative UI. At the top of the Farms tab, click Options, click MTR database connections, click Edit, and finally click the Sync settings button. The synchronization settings for this MTR are displayed. To change a setting click the appropriate checkbox.
The types of data that are allowed to be synchronized are indicated by a checkmark in the corresponding checkbox. If a selection is greyed out, the configuration of the MTR does not allow synchronization of that type of data.
By default, all four types of data are left unchecked, that is, no data is synchronized. You can choose to allow synchronization of any type of data for which the MTR allows synchronization. Any changes apply only to the current MTR connection.
|
 Copyright © 2001, 2002 Oracle Corporation. All Rights Reserved. |
|