14/18

# A Configuration Files for the Mobile Server

The following sections describe configuration parameters for the mobile server:

- Section A.1, "Configuration Parameters for the MOBILE.ORA File"

- Section A.2, "Data Synchronization Requirements in INIT.ORA"

## A.1 Configuration Parameters for the MOBILE.ORA File

The mobile server uses the `mobile.ora` file to initialize the mobile server; thus, if you modify these parameters, you must restart the mobile server to receive the change.

The following sections define system-wide parameters for the mobile server in the `mobile.ora` file:

- Section A.1.1, "[APPLICATIONS]"

- Section A.1.2, "[MOBILE]"

- Section A.1.3, "[FILESYSTEM]"

- Section A.1.4, "[DEBUG]"

- Section A.1.5, "[CONSOLIDATOR]"

- Section A.1.6, "[EXTERNAL_AUTHENTICATION]"

### A.1.1 [APPLICATIONS]

Table A-1 lists the `APPLICATIONS` parameters and their usage definitions.

Table A-1 APPLICATIONS Parameters

Parameter | Definition
--- | ---
`PACK_HELP` | Location for the Packaging Wizard help file. This is only used with MDK. and only for the purpose of Debug / Support.
`XMLFILE` | Name of the XML file used by the Packaging Wizard to store the application information. This is only used for Debug / Support.

### A.1.2 [MOBILE]

[The following `MOBILE` parameters control the behavior of the mobile server.

Table A-2 lists `MOBILE` parameters and their usage definitions.

Table A-2 MOBILE Parameters

Parameter | Definition
--- | ---
`ADMIN_PASSWORD` | Encrypted user password. Users must not try to edit the encrypted password. This parameter can be set by navigating to the following URL. `<server>/mobile/console/startup`
`ADMIN_PORT=8080` | Admin port for starting the mobile server.
`ADMIN_JDBC_URL=<jdbc_url>` | JDBC URL that the mobile server uses to connect to the mobile server repository in the back-end Oracle database. For a description of the syntax for the JDBC URL, see Section 2.2, "Connecting to the Back-End Oracle Database".
`ADMIN_USER` | Encrypted user name. Users must not try to edit the encrypted user name. This parameter can be set by navigating to the following URL. `<server>/mobile/console/startup`
`DM_AUTO_SYNC_CACHE` | Set to YES to turn on this feature to force the DeviceManager to synchronize the cached data on user-related events, such as create, edit or delete user.
`INSTALLATION_TYPE` | Mobile Server Installation Type, which describes the application server type where the mobile server is running. Do NOT modify, for internal use only.
`IP_CONFIG` | Set this parameter to designate what type of IP address the client uses. If you are using a dynamic (DHCP) dynamic IP address, set the parameter to `DYNAMIC`; the default is `STATIC` for a static IP address. If using DHCP, the underlying code needs to know to not use the IP address that was used for the previous connection/synchronization. If you are using DHCP and have set this parameter to `STATIC`, synchronization may never occur, since it is trying to synchronize to an IP address that is no longer valid for this device. Internally, the `IP_CONFIG` defines if IP address caching occurs in the JVM. Thus, if the `IP_CONFIG` parameter is set to `DYNAMIC`, the JVM security property `networkaddress.cache.ttl` is set to "0", which determines that the JVM always requests a naming service lookup to retrieve the IP address for the client. Disabling Java IP caching may effect performance with the additional DNS lookups. In addition, there is a risk of DNS spoofing. See the Oracle Java documentation for more information.
`MAX_THREAD_POOL` | Limits the number of threads available in the connection pool. If threading problems occur, set this parameter to 0 or 1.
`ORACLE_HOME` | Location of the Oracle Home where the mobile server is installed.
`PORT=80` | The port number on which the mobile server is running.
`RESTRICTED_ADMIN_HOSTS=<list of comma separated IP addresses>` | This parameter provides security for accounts with administrator access. With this parameter, the mobile server can be configured to allow login requests to a specified set of IP addresses for accounts with administrator access. With this parameter, you can also restrict access to the Mobile Server Startup feature. Only valid login requests from a browser that runs on machines whose IP address is listed as a value of this parameter will be granted access. For example, `RESTRICTED_ADMIN_HOSTS=144.125.127.150,144.125.127.101` Note: Users who have administrator access should not connect through a proxy server.
`REVERSE_PROXY=http://<proxyhost>:<port>/mobile` | Set this parameter if a Reverse proxy is used with the mobile server. See Section 9.6.1, "Using a Reverse Proxy to Communicate from Internet to Intranet" for details.
`SSO_ENABLED` | Turn this parameter on (TRUE) if you want to enable Oracle Single Sign on (SSO) authentication on the mobile server. If this parameter is turned on then the users trying to connect to the mobile server in the online mode will receive the login page from the SSO server.
`SQL_RETRIES=5` | Number of attempts to modify a JDBC connection before timing out.
`SSL=YES` | If this parameter is set to `YES`, then the mobile server runs in SSL mode.
`THIN_JDBC_URL=<jdbc_url>` | This URL is used by applications to connect to the mobile server repository database. For a description of the syntax for the JDBC URL, see Section 2.2, "Connecting to the Back-End Oracle Database".
`USE_SYSTEM_CLASSPATH=YES` | If set to yes, searches for Java classes in the computer's classpath before searching the mobile server repository.

### A.1.3 [FILESYSTEM]

The following `FILESYSTEM` parameters control the behavior of the mobile server repository.

Table A-3 lists `[FILESYSTEM]` parameters and their definitions.

Table A-3 FILESYSTEM Parameters

Parameter | Definition
--- | ---
`ROOT_DIR=``ORACLE_HOME``/MOBILE/SERVER/REPOSITORY` | Root Directory. Valid only for OS file system. This directory path format applies to the environment where the mobile server runs on Solaris. Replace `ORACLE_HOME` with your actual Oracle Home.
`ROOT_DIR=``ORACLE_HOME``\MOBILE\SERVER\REPOSITORY` | Root directory. Valid only for OS file system. This directory path format applies to the environment where the mobile server runs on Windows NT. Replace `ORACLE_HOME` with your actual home.

### A.1.4 [DEBUG]

The following `DEBUG` parameters control the debugging messages in the mobile server.

Table A-4 lists `DEBUG` parameters and their definitions.

Table A-4 DEBUG Parameters

Parameter Name | Definition
--- | ---
`TRACE_DESTINATION` | Trace destinations are `CONSOLE` and `FILE`. The administrator can set this parameter to any of these destinations. `CONSOLE` generates trace output to the console screen. `FILE` generates trace output to a file. For more information, see `TRACE_FILE_ NAME, TRACE_FILE_SIZE,` and `TRACE_FILE_POOL_SIZE`.
`TRACE_ENABLE` | Used to turn the trace feature on (`YES`) or off (`NO`). When the Trace feature is off, trace output is not generated.
`TRACE_FILE_NAME=trace.log` | Used as base name to arrange trace files in sequential order starting from `1` to `FILE_TRACE_POOL_SIZE`. For example: If you set the following parameters. `TRACE_FILE_NAME=mytrace.log` `TRACE_FILE_POOL_COUNT=5` then, the Trace files will be named `mytrace1.log, mytrace2.log, mytrace3.log, mytrace4.log, mytrace5.log`, based on how you set the `TRACE_FILE_PER_USER` parameter. Sample Value: `trace.log`
`TRACE_FILE_PER_USER=YES` | Used to specify an individual trace file pool for every individual user. Applicable only when the File option is the Trace destination. If set to `YES`, then every traceable user has an own trace file pool, and the trace file name includes the user's name. In addition, the system trace output goes to the user's system trace file. If set to `NO`, all traceable users share the same trace file pool, the actual trace file does not contain any user name. Example: `TRACE_FILE_POOL_PER_USER=No`
`TRACE_FILE_POOL_SIZE=5` | The default value is 5. This parameter specifies the number of files in the trace file pool. If the pool limit is reached, the trace output is overwritten to the first file in the pool. See also `TRACE_FILE_NAME, TRACE_FILE_POOL_SIZE,` and `TRACE_FILE_PER_USER`
`TRACE_FILE_SIZE=10` | Used as the maximum file size in MB for trace files. If the threshold value is about to be reached, the trace feature generates output to the next trace file in the pool. For more information, see `TRACE_FILE_NAME`, `TRACE_FILE_POOL_SIZE`, and `TRACE_FILE_PER_USER`.
`TRACE_LEVEL=1` | There are three levels of trace messages: `1(binary 00000001), Basic Trace`: General system information. `2 (binary 00000010), Function Trace`: Traces the function sequence being called, mostly used by Data Synchronization. `4 (binary 00000100), SQL Trace`: Traces SQL queries being executed, mostly used by Data Synchronization. In addition, all errors and exceptions are sent to level -1, which have the binary 11111111. All Java `System.out` output are sent to level 9. Both these two levels are always generated as output, if the user is not filtered out. For more information, see `TRACE_USER`.The parameter value for `TRACE_LEVEL` is used to do a `Bitwise AND` operation against all 3 trace levels. If the result is greater than 0, then trace output of that level will be generated as trace output. The parameter value for `TRACE_LEVEL` used to do a `Bitwise AND` operation against all 3 trace levels. If the result is greater than 0, then trace output of that level will be generated as trace output. EXAMPLE: If you set the following parameters, `TRACE_LEVEL=3,` then the Basic and SQL level trace output is generated, but not Function level trace as the `&` character is a `Bitwise AND` operator.
    3 & 1 (Basic) = 1 > 03 & 2 (SQL)  =  2 > 03 & 4 (Function) = 0 = 0
`TRACE_REMOTE_HOST` | The trace output is generated to the named machine, on which the synchronized trace can be viewed using the `wsh -m %TRACE_REMOTE_PORT%`. Example: `TRACE_REMOTE_HOST=adminhost`
`TRACE_REMOTE_MACHINE` | Machine name where `wsh -m` is running. The Mobile Server sends the debug output to the machine where `wsh` `-m` is running.
`TRACE_REMOTE_PORT` | Trace output is generated to the named port on the `%TRACE_REMOTE_MACHINE%` on which the trace output can be viewed using `wsh -m TRACE_REMOTE_PORT%`.
`TRACE_USERS` | List of valid user names. The user trace and system trace information which is listed is generated as trace output. If the value is an empty string `""`, then every user is traced. If the value is or contains `TRACE_NO_USER`, then no actual user is traced. Only the system trace information is generated as trace output. Note: As the administrator, you must not use the `TRACE_NO_USER` value as the user name. Example: If you set this parameter as follows, `TRACE_USERS=jane,jack,` then only jane and jack's trace information is generated and displayed as trace output.

### A.1.5 [CONSOLIDATOR]

The `CONSOLIDATOR` parameters control the behavior of Data Synchronization. The values that are listed in the following table are default values.

- Section A.1.5.1, "Data Synchronization Parameters"

- Section A.1.5.2, "Data Synchronoization Tracing and Logging"

#### A.1.5.1 Data Synchronization Parameters

Table A-5 Consolidator Parameters

Parameter Name | Definition
--- | ---
`APPLY_TRIES_DELAY` | Specifies in seconds the delay between successive attempts to apply a client's In Queue. Related to the `MAX_APPLY_TRIES` parameter.
`CACHED_USERS` | Comma-separated list of users, where each user's downloaded data is cached.
`CLIENT_RESEND_CHECK` | If set to `YES`, then all client resend sessions requests are rejected. This is the default. If a client uploads a transaction and the server receives and processes it correctly, but the client is not notified, then the client will send the transaction again. To avoid having this transaction be processed again, the resend session request is rejected. However, if you are developing an application and you are executing a test, such as a performance test, you will resend the same client request to the server repeatedly to test how the server responds under heavy load. Only in this case would you want to set this parameter to `NO`.
`COMPOSE_TIMEOUT=300` | Specifies in seconds the MGP timeout for the compose phase for each user to complete. If the compose phase for this user does not complete, MGP retries the compose phase for this user in the next cycle. If the compose consistantly fails then increase timeout value. Monitor the MGP logging to evaluate how long the compose takes to complete; then add 50% to the value ensure that slightly larger datasets compose completely.
`CONN_CHECK_ON_RESERVE` | Configure whether to validate a database connection before retrieving (borrowing) it from the connection pool. By default, this value is YES.
`CONN_CHECK_ON_RELEASE` | Configure whether to validate the database connection before releasing it back to the connection pool. By default, this value is YES. If the examination determines that the connection is not valid, then it is destroyed instead of being returned to the connection pool.
`CONNECTION_POOL=YES` | Enables pooling of database connections if set to YES.
`DO_APPLY_BFR_COMPOSE` | By default, before the MGP processes the Compose phase for a user, it checks to see if user data has been uploaded into the In Queue. If so, then the Compose is not performed to ensure that user data is not overwritten. Instead, the Compose phase is not executed until the MGP runs the Apply/Compose phase again. Setting `DO_APPLY_BFR_COMPOSE` to `true` modifies this behavior. If data for a user is in the in queue, MGP will execute a second Apply to commit all user data and then will execute the Compose for that user.
`IN_QUEUE_INDEX_ATTRIBUTES` | Specify the index attributes for the In Queue table indexes, which exist in the back-end Oracle database. These can include the storage characteristics and the following attributes: `TABLESPACE`, `PCTFREE`, `PCTUSED`, `INITRANS`, and `MAXTRANS`. See the Oracle Database SQL Reference for more information on these properties.
`IN_QUEUE_TABLE_PROPERTIES` | Specify the physical and/or table properties for the In Queue tables, which exist in the back-end Oracle database. These can include the storage characteristics and the following properties: `TABLESPACE`, `PCTFREE`, `PCTUSED`, `INITRANS`, and `MAXTRANS`. See the Oracle Database SQL Reference for more information on these properties.
`JDBC_URL` | This is the `JDBC_URL` used by the Sync Service and the MGP for connections to the mobile server repository. If absent, it defaults to the `ADMIN_JDBC_URL` in the `MOBILE` section of the `mobile.ora` file.
`JOB_ENGINE_AUTO_START` | If set to `YES`, the Job Scheduler is started up at mobile server start time.
`JOB_ENGINE_SLEEP_TIME` | The amount of time in seconds that the Job Scheduler sleeps in each loop.
`LOG_LOCK_DELAY` | Specifies in the number seconds the delay between successive attempts to lock the log tables. Related to the `MAX_LOG_LOCK_TRIES` parameter.
`MAGIC_CHECK` | Control the magic number checking of publication items. If enabled, and there is a mismatch between the server and the client magic numbers, the publication item receives a complete refresh. If set to `ALL`, then the magic check is enabled, which is the default. If `NONSHARED`, then the magic check is enabled only for publication items that are not shared among users. If set to `SHARED`, the magic check is enabled only for shared publication items. A shared publication item has the following characteristics: Read only The publication item query either has no parameters or all users share the same parameter values.
`MAP_INDEX_ATTRIBUTES` | Specify the index attributes for the map table indexes, which exist in the back-end Oracle database. These can include the storage characteristics and the following attributes: `TABLESPACE`, `PCTFREE`, `PCTUSED`, `INITRANS`, and `MAXTRANS`. See the Oracle Database SQL Reference for more information on these properties.
`MAP_TABLE_PROPERTIES` | Specify the physical and/or table properties for the map tables, which exist in the back-end Oracle database. These can include the storage characteristics and the following properties: `TABLESPACE`, `PCTFREE`, `PCTUSED`, `INITRANS`, and `MAXTRANS`. See the Oracle Database SQL Reference for more information on these properties.
`MAX_APPLY_TRIES` | Specifies the maximum number of times the MGP retries to apply the client In Queue data before terminating the apply phase.
`MAX_BATCH_SIZE` | JDBC performance parameter which defines the number of DML records (inserts only) to send from the mobile server to the back-end Oracle database at one time. Without batching, each record is sent to the database one at a time. These records are originally from client. This only applies to insert, and not to delete or update records.
`MAX_LOG_LOCK_TRIES` | Specifies the number of attempts to lock the logs before giving up the compose phase.
`MAX_THREADS=3` | Specifies the number of threads spawned within the MGP process. This parameter value should be set to an equivalent number of CPUs. We recommend this value is set to 1.5 times the number of CPUs. The default is 3.
`MAX_U_COUNT` | The `MAX_U_COUNT` parameter controls the number of SQL statements that are executed together in a SQL batch statement while performing the map cleanup. The default value for the `MAX_U_COUNT` parameter is 256. However, if the value is 256 during the map cleanup, then a maximum of 256 SQL statements can be executed together in a batch. Modify this parameter and restart the mobile server to enable a larger batch of SQL statements to be processed during map cleanup. You may want to modify the `MAX_U_COUNT` parameter before the synchronization starts. See Section 2.7.1.10, "BeforeSyncMapCleanup" in the Oracle Database Mobile Server Developer's Guide for more information.
`MGP_CYCLES_BEFORE_INS_CHK` | How often should MGP compose phase look for map table records that are marked for deletion but have been re-added to the subscription. By default, this is set to 1. If the application logic guarantees that such records never exist, then this check may be skipped altogether by setting the value to –1, which improves MGP compose performance.
`MGP_HISTORY` | If set to `YES`, enables MGP history recording, which can be viewed in the Data Synchronization section of the Mobile Manager.
`REPORT_ALL_ERRORS` | If set to `YES`, then the MGP attempts to detect and report all apply transaction errors. If set to `NO`, which is the default, only the first error is reported.
`RESUME_FILE` | This is a server-side parameter that defines the filename of the resume buffer for the client users. By default, we use memory mapped file; however, with this parameter, users can provide their own storage files. The size of this file is specified by the `RESUME_FILE_SIZE` parameter. For more information on how to use `RESUME_FILE` and `RESUME_FILE_SIZE`, see Section 5.7, "Resuming an Interrupted Synchronization".
`RESUME_FILE_SIZE` | Set the maximum size of the resume file in MegaBytes (MB).
`RESUME_MAXACTIVE` | The `RESUME_MAXACTIVE` parameter controls the maximum number of connections that the mobile server handles at a single time. If more clients try to connect, they are queued until existing connections complete. The default is 100 connections. You can enable maximum concurrent clients by setting `RESUME_MAX_WAIT` and `RESUME_MAXACTIVE`. This limits the maximum number of concurrently synchronizing clients to `RESUME_MAXACTIVE`; additional incoming clients wait `RESUME_MAX_WAIT` before timing out. To eliminate the resume feature, set `RESUME_TIMEOUT` to 0.
`RESUME_MAXCHUNK` | The `RESUME_MAXCHUNK` parameter causes the server to drop the connection after sending the specified data size, in KB. This forces the client to reconnect and inform the server on how much data it already has. The server can the discard all data before that offset. The fault value is 1024 KB.
`RESUME_MAX_WAIT` | The `RESUME_MAX_WAIT` parameter specifies the number of MINUTES a new client waits for a connection if the `RESUME_MAXACTIVE` threshold has been reached. Default is 30 minutes.
`RESUME_CLIENT_TIMEOUT` | The `RESUME_CLIENT_TIMEOUT` parameter specifies the number of SECONDS the client will try to resume before it gives up and returns an error.
`RESUME_TIMEOUT` | The `RESUME_TIMEOUT` parameter indicates time in MINUTES the server will keep client data while the client is not connected. The default is 0, which means that resume is disabled and after disconnection, the client data is discarded. A short timeout, such as 15 minutes, is suitable to resume any accidentally dropped connections. A longer timeout may be needed if users explicitly pause and resume synchronization to switch networks or use a dialup connection for another purpose.
`SKIP_INQ_CHK_BFR_COMPOSE` | By default, before the MGP processes the Compose for a user, it checks to see if user data has been uploaded into the In Queue. If so, then the Compose for the user is not performed to ensure that user data is not overwritten. Instead, the Compose phase is not executed until the MGP runs the Apply/Compose phase again. Setting `SKIP_INQ_CHK_BFR_COMPOSE` to `true` modifies this behavior. Even if data is in the in queue, MGP executes the Compose for the user. The data that was uploaded to the In Queue must be data that will not be compromised by downloading data from the server to the client.
`SLEEP_TIME=20000` | Specifies how long (in milliseconds) the MGP sleeps before scheduling the next client's apply phase. By default, it is set to 2 milliseconds.
`STMT_CACHE_SIZE` | The number of prepared statements to be cached for each connection. These statements are not re-parsed by the database when they are prepared again. To turn off caching, set this variable to `-1`.
`SYNC_HISTORY` | If set to `YES`, enables synchronization history recording, which can be viewed in the Data Synchronization section of the Mobile Manager.
`SYNC_SERVICE_AUTO_START` | If set to `YES`, the Sync Server is started automatically at mobile server startup. The client cannot synchronize until the Sync Server is started. So, if you want to prevent the client from synchronizing, then set this parameter to `NO` and then start and stop the Sync Server manually through the Mobile Manager after you have completed the tasks that you want to perform while the client is unable to synchronize. For example, you do not want a client to synchronize if you are re-publishing the client's application.
`TEMP = C:\TEMP` | Specifies the directory where the binary trace file, which includes the request and response data, is written. This file is created to cache the data in transport, so that if a failure occurs, Oracle Database Mobile Server can recover. You initialize this binary trace file by selecting the Data Trace Type checkbox.
`USE_JVM_COMPRESSION` | Specifies whether the JVM implementation of ZIP or the Oracle pure Java version for compression should be used. This is a performance parameter, where depending on a particular environment, each implementation may have different performance results. By default, this is set to YES to use the JVM implementation.

#### A.1.5.2 Data Synchronoization Tracing and Logging

Data Synchronization uses a log engine that supports the following parameters for logging:

- `GLOBALLogger`

- `SYNCLogger`

- `MGPLogger`

- `MGPAPPLYLogger`

- `MGPCOMPOSELogger`

Each parameter sets up a logger for a component which you can use to specify the trace level, trace type, trace destination, trace file pool size, trace file size, and trace users in the following sample format.

`<X>Logger=TRACE_LEVEL=<``trace_level``>|TRACE_TYPE=<``trace_type[,trace_type...]``>|TRACE_DESTINATION=<``trace_destination``>[|TRACE_FILE_POOL_SIZE=<``trace_file_pool_size``>|TRACE_FILE_SIZE`=<`trace_file_size``>|TRACE_USER=<``trace_users``>]`

Note:

- Separate each parameter with the '`|`' symbol. Separate values with a comma '`,`'.

- If there are any invalid values in the definition, the whole definition is ignored.

- For each logger, the trace level, type, and destination parameters are mandatory.

- The parameters `TRACE_FILE_POOL_SIZE` and `TRACE_FILE_SIZE` are only applicable for the `GLOBALLogger` only.

- If you define the `LOCAL_CONSOLE`, then you must also define `SYNCLogger` and `GLOBALLogger`.

Table A-6 lists the parameters for each logger.

Table A-6 Acceptable Parameter Values

Parameter | Description
--- | ---
`TRACE_LEVEL` | Trace Level parameter can be set to the following trace message levels: `MANDATORY`: This option logs mandatory messages only. For example, Program Exceptions. Regardless of component settings, this option logs exceptions in the error log file (`err.log`) located in the `Conslog` directory. `WARNING`: This option logs warning messages and messages at the Mandatory level. For example, Program Exceptions that users can ignore, messages that the program wants to warn the users with, and so on. `NORMAL`: This option logs normal messages that the user must be informed with and messages at the Mandatory and Warning level. `INFO`: This option logs information messages and messages at the Mandatory, Warning, and Normal levels. Examples: Timing of synchronization: When the `SYNCLogger` is set to the `TRACE_TYPE=TIMING` and `TRACE_LEVEL=INFO`. MGP Apply: When the `MGPAPPLYLogger` is set to the `TRACE_TYPE=TIMING` and `TRACE_LEVEL=INFO`. MGP Apply must be started with `Timing of`. COMPOSE must be started with `Timing of MGP Compose`. MGP must be started with `Timing of`. COMPOSE: When the `MGPAPPLYLogger` is set to the `TRACE_TYPE=TIMING` and `TRACE_LEVEL=INFO`. Status of MGP: When the MGPLogger is set to the `TRACE_TYPE=GENERAL` and `TRACE_LEVEL=INFO`. `CONFIG`: This option logs configuration messages and messages at the Mandatory, Warning, Normal, and Info levels. For example, JDBC driver version. `FINEST`: The finest level. This level is used for developers only. `ALL`: This option logs all messages according to the other settings such as Trace Type and Users.
`TRACE_TYPE` | `SQL`: This option logs SQL-related messages only. For example, SQL statements. Note: This option is not trace level sensitive. `TIMING`: This option logs timing data only. Note: This option is trace level sensitive. For MGP Cycle time and Synchronization time, use the Trace Level `INFO` option. If the MGPLogger is set to `TIMING` and `INFO`, it will log the MGP Cycle time. If the `SYNCLogger` is set to `TIMING` and `INFO`, it logs the synchronization time. `DATA`: This option logs data only. Note: This option is not trace level sensitive. This option prints all data with any trace level other than the `OFF` option. `RESUME`: Messages dealing with Reliable Transport have a `RESUME` trace type. This option only logs messages with Reliable Transport. Note: This option is not trace level sensitive. This option prints all the `RESUME` trace type messages with any trace level other than the `OFF` option. `FUNCTION`: This option displays the program flow by logging methods such as Entry, Exit or Invoke. For Long methods, this option logs the method's entry or exit; which is a simple invoke log. Note: This option is not trace level sensitive. This option prints all the `FUNCTION` trace type messages with any trace level other than the `OFF` option. `GENERAL`: This option logs messages that do not belong to any of the above listed trace types. Note: This type is trace level sensitive. `ALL`: This option generates logs of all trace types.
`TRACE_DESTINATION` | The administrator can set this parameter to any of these destinations: `LOCAL_CONSOLE` or `TEXTFILE`. The Console option generates trace output to the Console screen. The `TEXTFILE` option generates trace output to a file. See also `TRACE_FILE_SIZE`, and `TRACE_FILE_POOL_SIZE`. Sample Value: `TRACE_DESTINATION=TEXTFILE`
`TRACE_FILE_POOL_SIZE=2` | The default value is 2. This parameter specifies the number of files in the trace file pool. If the pool limit is reached, the trace output is overwritten to the first file in the pool. See also `TRACE_FILE_POOL_SIZE`.
`TRACE_FILE_SIZE=1` | Used as the maximum file size in MB for trace files. If the value is about to be reached, the trace feature generates output to the next trace file in the pool. For more information, see `TRACE_FILE_POOL_SIZE`.
`TRACE_USERS` | List of valid user names. The listed user trace information and system trace information is generated as output. If the value is an empty string `""`, then every user is traced.

The new log engine does not support the parameters that have been used in the old log engine. They are:

- `TRACE_REMOTE_PORT`

- `TRACE_REMOTE_MACHINE`

- `TRACE_REMOTE_HOST`

### A.1.6 [EXTERNAL_AUTHENTICATION]

The parameters in Table A-7 are used for configuring external authentication.

Table A-7 EXTERNAL_AUTHENTICATION

Parameter | Description
--- | ---
`CLASS`=`<sampleAuthenticator>` | The external `Authenticator` JAVA class name.
`EXPIRATION` = `<numberOfSeconds>` | The mobile server caches the user instantiated through the external authenticator for a period of time in order to improve efficiency. Provide the number of sections for this period. The default expiration time for the cached user object is 30 minutes (or 1800 seconds).

## A.2 Data Synchronization Requirements in INIT.ORA

The following sections describe the Data Synchronization requirements for Oracle and Oracle parameter settings in the `init.ora` file:

- Section A.2.1, "Relationships Between Relevant Parameters"

- Section A.2.2, "Values for Processes and DML Locks"

### A.2.1 Relationships Between Relevant Parameters

You should set the following parameters in the file `init.ora` as given below:

Table A-8 lists parameters that must be set in the file `init.ora`:

Table A-8 init.ora Parameter Settings

Parameter Name | Definition
--- | ---
`PROCESSES` | Default value: 59 to 200.
`SESSIONS` | Default value: Derived: `1.1 * PROCESSES + 5`
`TRANSACTIONS` | Default value: Derived: `(1.1 * SESSIONS`)
`DML_LOCKS` | Default Value: Derived: `(4 * TRANSACTIONS)`

### A.2.2 Values for Processes and DML Locks

Check values for processes and `DML_LOCKS`. Massive concurrent synchronization processes use the maximum amount of resources. For each one of the concurrent clients, Data Synchronization requires one database connection (one session, one transaction). Therefore, the parameter value of `PROCESSES` must be set to be no less than the maximum number of concurrent clients.

During the sync, the Data Synchronization will make changes to the publication map tables. One DML lock is needed for each client and changed publication:

`DML_LOCKS` = (Number of changed publications) * (Maximum number of concurrent clients)

During the first and second sync, all publication map tables are changed for each client. So, the required DML locks are:

`DML_LOCKS` = (Number of publications) * (Maximum number of concurrent clients)

If you have a large number of publications, the default `DML_LOCKS` may not be sufficient. You should set it explicitly in the file `init.ora`. For example, CRM has approximately 50 publications. For 30 concurrent first syncs, Data Synchronization needs 1500 DML locks. The default value for `DML_LOCKS` with `PROCESSES` set to 200 is 1000.