Skip Headers
Oracle® Database Lite Administration and Deployment Guide
10g (10.0.0)
Part No. B12262-01
  Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

8 Managing Synchronization

The Mobile Server administrator uses the Data Synchronization Manager to manage synchronization tasks. This chapter includes:

8.1 Overview

The Mobile Server uses synchronization to replicate data between Oracle Database Lite databases (including those for Web-to-Go, Win32, Palm, and Windows CE platforms) and the Oracle database. For example, in a Web-to-Go application, when the user switches to offline mode, Web-to-Go replicates the user's applications and data from the Oracle database to Oracle Database Lite. When the user switches back to online mode, Web-to-Go replicates any Oracle Database Lite changes to the Oracle database.

8.2 The Data Synchronization Manager: An Introduction

The Oracle 10g Data Synchronization Manager provides a graphical user interface to manage the Sync service, monitor and analyze Sync service performance, administer Sync service configuration and tracing, browse the Sync service repository for publication and subscription information, and monitor and analyze MGP performance. These functionalities correspond to five tabs on the Data Synchronization home page named Home, Performance, Administration, Repository, and MGP.

The Home tab stores Sync service details and the Performance tab stores sync performance details. The MGP tab stores information related to MGP functions and performance. The Repository tab stores client information related to the In-Queues and Out-Queues. To set the configuration parameters for the whole system, the Administration tab provides the necessary controls.

As displayed in Figure 8-1, to view an overview of the Data Synchronization architecture, login to the Mobile Server and navigate to the Data Synchronization home page. Click Architecture.

Figure 8-1 Data Synchronization Architecture

Illustration of the data synchronization architecture.

The Oracle Lite database contains a subset of data that is stored in the main Oracle database, which is the back-end database. This subset is stored as a snapshot in the Oracle Lite database. Unlike a base table, a snapshot tracks changes made to it in a change log. As a user, you can make changes in the Oracle Lite database while the device is disconnected, and can then connect to the back-end Oracle database for synchronizing refreshed data within a snapshot.

The Data Synchronization component in the Mobile Server receives or uploads client transactions from the Oracle Lite database and applies these transactions to the back-end Oracle database. The Data Synchronization component composes the server-side changes for a client into transactions and sends or downloads them to the client Oracle Lite database.

The Data Synchronization component employs an asynchronous model and assigns the synchronization task to two sub-components called Sync service and MGP.

8.3 Managing the Sync Service

The Synchronization service (Sync service) feature is an HTTP servlet that listens to client synchronization requests. During every synchronization session, the Sync service receives or uploads client transactions in the Oracle Lite database and places them within the in-queues. The Sync service then sends or downloads server-side transactions from the out-queues to the client Oracle Lite database.

The Synchronization Manager enables users to view a table of active synchronization sessions, in which synchronization clients are connected with the Sync service and are engaged in uploading or downloading transactions. After the client disconnects, synchronization session details are stored in the synchronization history page if the SYNC_HISTORY instance parameter is set to TRUE, which is the default parameter value.

The Data Synchronization home page enables administrators to manage synchronization (Sync) service tasks such as starting the Sync service and checking for alerts that are registered in the Sync service. Using this page, administrators can manage active synchronization sessions and the synchronization history list. Topics include:

8.3.1 Starting/Stopping the Sync Service

To start the Sync service, navigate to the Data Synchronization home page as follow.

  1. Login to the Mobile Server using the appropriate user name and password.

  2. Locate the Mobile Server components table, and click Data Synchronization. The Data Synchronization home page appears.

    The Sync service's default status is Up. As displayed in Figure 8-2, the Data Synchronization home page displays the default status.

    Figure 8-2 Data Synchronization Home Page

    This image displays the Data Synchronization home page.

To stop the Sync service, click Stop. The Mobile Server displays a warning message that seeks your confirmation to stop the Sync service. Click Yes. You are returned to the Synchronization Service home page.

To stop the Sync service immediately, click Stop Immediately.

8.3.2 Checking Sync Service Alerts

The Sync service serves multiple clients that require synchronization. Clients cannot synchronize if the sync service encounters an exception. This occurrence is registered as a critical alert. In this situation, the Sync service displays details of the exception. As the Database Administrator (DBA), you must check such exceptions.

For critical alerts that can be resolved, such as when the database is down, the DBA analyzes and resolves the problem, and then re-starts the synchronization service. Warning alerts are registered if an individual synchronization session fails. In this case, the DBA must check the Sync session details in the Sync history, where the details of the failure are recorded, and determine the reasons for failure. Alternatively, the DBA can report problems that are un-resolvable to Oracle support.

The Data Synchronization home page enables the DBA to check alerts that are registered in the Sync engine. It provides information such as the alert name, degree of severity, time when the alert was triggered, and time when the alert was last checked by a DBA.

The Data Synchronization home page displays Sync service exception alerts. To check other alerts, scroll down to the Alerts table and select the alert that you need to view in the select column. Click Check.

As described in Figure 8-3, the Synchronization History Sessions page displays failed and unchecked history sync sessions of User Sync Failure alerts.

The MGP tab displays MGP job exceptions. The MGP Apply/Compose Cycles page displays failed and unchecked History Cycles of MGP User Apply/Compose failures.

Figure 8-3 Synchronization History Sessions Page

The Synchronization History Sessions page.

To delete an alert, locate the Alerts table on the Data Synchronization home page. Select the alert and click Delete. As listed in Table 8-1, sample alert names and types are based on the corresponding severity.

Table 8-1 Alert Types

Name Type Severity
Sync Service Exception Sync Service CRITICAL
User Sync Failure(s) Sync Service WARNING
MGP Job Exception MGP CRITICAL
MGP User Apply/Compose Failure(s) MGP WARNING

8.3.3 Managing Active Sync Sessions

The Active Sessions table on the Data Synchronization home page displays the following active sync session information.

  • User Name

  • Device Type

  • Phase

  • Start Time

  • Duration

  • Upload and Download Duration (in seconds)

  • Upload and Download Record Count

  • Complete Refresh Publication Item Count

To terminate an active session, perform the following steps.

  1. Select the active session that you wish to terminate and click Kill. The Mobile Server displays a warning message seeking your confirmation to terminate the active session.

  2. Click Yes. The Mobile Server displays a confirmation message stating that the chosen session is terminated.

  3. Click OK. You are returned to the Data Synchronization home page.

The Active Sessions table on the Data Synchronization home page also displays session details. Select the active session that you wish to view and click Details. The Active Sync Session page displays the chosen session's publication items that have been uploaded or downloaded, waiting publication items, records and timing information, and the session trace file.

8.3.4 Managing the Session History List

The Data Synchronization home page displays the total number of sessions that are registered in the Session history list. The administrator can search, sort, and manage the session history list that is based on Session properties.

To display the session history list, click the number hyperlink that is displayed against the Session History. For example, click the number that is displayed as a hyperlink against Session History. As displayed in Figure 8-4, the Synchronization History Sessions page appears.

Figure 8-4 Synchronization History Sessions Page

The Synchronization History Sessions page.
  • To search the Session history list, enter your search criteria such as user name, date, and time in the corresponding fields. Click Search. The Session History page displays matched sync sessions in the Results section.

  • To sort matched sync sessions, click the Header Title of the sync session item that you wish to sort. For example, to sort sync sessions by user, click the User header title.

  • To delete a session, select the session that you want to delete and click Delete.

  • To view the details of a session, select the session and click Details. The Sync History Session page displays session details such as publication items that are uploaded or downloaded, records and timing information, and the session trace file.

  • The View and Download links are automatically enabled for viewing or downloading trace files that are available for the chosen session.

8.3.5 Displaying Operating System (OS) and Java Virtual Machine (JVM) Information

To display the OS and JVM info, click the Host hyperlink that is displayed against the Host. As displayed in Figure 8-5, the Host page displays host information such as host name, IP address, OS type, and OS user name. The JVM section displays the java classpath, java version, and heap memory size.

Figure 8-5 Host Page

This image displays the Host page.

8.4 Monitoring and Analyzing Sync Performance

This section describes how to monitor and analyze sync performance. Topics include:

8.4.1 Viewing Sync Statistics

The Performance tab displays statistics of the current session and statistics of history sessions that have occurred in the last 24 hours.

To view Sync Statistics, click the Performance tab. As displayed in Figure 8-6, the Performance tab appears.

Figure 8-6 Performance Page

This image displays the performance page.

To view additional statistics, click the Synchronization Statistics link in the General section of this page.

The Sync Statistics page contains search criteria such as user name, device type, and duration. Specify your criteria in the Search section and click Go. The Sync Statistics page displays results such as summary, upload phase, and download phase details.

8.4.2 Analyzing Performance of Publications

The Performance tab enables users to conduct a performance analysis using the Consperf utility.

The Consperf utility profiles Sync service publications. Application developers and administrators use this utility to analyze the performance of publications and identify potential bottlenecks during publication. This tool enables users to perform four primary functions:

  1. Generate timing statistics for publications

  2. Generate explain plans for publications

  3. Automatically tune publication properties

  4. Analyze Mobile Server objects for the Cost Based Optimizer

The Performance tab provides enhanced performance analysis and tuning capabilities and is more convenient than its command line counterpart. It enables users to start with a list of clients and choose the required subscription for performance analysis. Users can change parameter values before analyzing performance. The analysis results, which are timing and plan information are stored on the server and can be accessed by viewing the corresponding subscription.

To analyze Consperf, perform the following steps.

  1. Navigate to the Performance tab and click Users under the Consperf section. As displayed in Figure 8-7, the Users page displays a list of users.

    Figure 8-7 Users Page

    This image displays the Users page.
  2. Select a user and click Subscriptions. The Subscriptions page displays a list of subscriptions for the chosen user.

  3. Select a subscription and click Consperf Performance Analysis. The Consperf Performance Analysis page appears.

  4. Click the hyperlink Set consperf parameters and launch the consperf thread. The Run Consperf page appears.

    The Run Consperf page associates all the available parameters, their corresponding default values and descriptions. As a user, you can make the necessary changes to the parameter values and click Run Consperf. At this stage, the Consperf thread is started and the user is returned to the Consperf Performance Analysis page, which displays information related to the status of Consperf. Upon completion of the performance analysis, the Consperf Performance Analysis page displays hyperlinks to results of the analysis.

  5. To view performance analysis results conducted by Consperf, click the hyperlinks View Timing File or View Execution Plan File.

8.5 Administering the Synchronization Service

The Administration tab enables users to view and change synchronization parameters, trace settings, and trace files. This section describes the following topics:

8.5.1 Managing Configuration Parameters

There are two types of configuration parameters for the Sync service. They are: Shared and Instance. Shared parameters affect all instances. Instance parameters only affect a single instance. The Mobile Server can contain multiple instances that connect to the same repository.

The Sync manager provides a form to view and edit these parameters. It provides user access to current values, default values, and descriptions of these parameters. Users can also view and edit the parameter file directly on the web.

The following sections describe how to view parameter descriptions and edit existing parameter values.

Viewing Parameter Descriptions

To view parameter descriptions and other additional information, navigate to the Administration tab and click the Shared Parameters or Instance Parameters hyperlink. Based on your option, the Shared Parameters page or Instance Parameters page appears.

For example, click Shared Parameters. The Shared Parameters page displays existing parameters. To view the parameter description and additional information, click Show.

Editing Parameter Values

To edit parameter values, click the Shared Parameters or Instance Parameters hyperlink. Based on your option, the Shared Parameters page or Instance Parameters page appears. In the New Value field, edit the value and click Apply. Some parameter values do not take effect until the synchronization service is restarted.


Note:

The Instance Parameter table only contains the Need Restart column.

8.5.2 Managing Trace Settings and Trace Files

This section describes how to manage trace settings and trace files. Topics include:

Managing Trace Settings

  1. To manage trace settings, navigate to the Administration tab and click Trace Settings.

    As displayed in Figure 8-8, the Trace Settings page appears.

    Figure 8-8 Trace Settings Page

    This image displays the Trace Settings page.
  2. The Trace Settings page displays five components. To change trace settings, enter the modified data in the corresponding fields and click Apply.

  3. In the Filter section, select the required Level and Type. To specify a trace filter for users, enter comma separated user names in the Users field. In the Destination section, select Local Console to receive the trace file on your local console. To retrieve trace information to a file, select the File option. The File Size and File Pool Size fields display the values 10 and 2 by default. If required, enter the modified file size and file pool size. To implement the modified values, click Apply. To retain existing values, click Cancel.

Managing Trace Files

  • To manage trace files, navigate to the Administration tab and click the hyperlink Trace Files. As displayed in Figure 8-9, the Trace Files page appears.

    Figure 8-9 Trace Files Page

    This image displays the Trace Files page.
  • To view a trace file, select the trace file and click View.


    Note:

    When you view the trace file online, the View button truncates trace files that contain more than 10,000 lines. The Download button does not truncate the trace file.

  • To download the trace file, click Download.

  • To delete the trace file, click Delete.

Consolidator Components for Tracing

The Consolidator has been categorized into the following five components for tracing. Based on the requirement, you can customize these components.

MGP

This refers to the MGP process except that before an MGP Cycle ID is available, all the logs are covered by the parameter GLOBAL. If the TRACE_DESTINATION is set to the value TEXTFILE, all the generated logs are recorded in a log file named MGP_<cycle_id>.log under the following directory.

<Mobile_Server_Home>\Mobile\Server\ConsLog\MGP


Note:

The log file can be viewed directly from the Sync Manager.

MGPAPPLY

This refers to the APPLY phase in the MGP process. However, between the beginning of the APPLY phase till the availability of the MGP Client ID, the logs are covered by the component MGP. If the TRACE_DESTINATION is set to the value TEXTFILE, all the generated logs are recorded in a log file named MGPAPPLY_<client_id>_<cycle_id>.log under the following directory.

<Mobile_Server_Home>\Mobile\Server\ConsLog\MGPAPPLY


Note:

The log file can be viewed directly from the Sync Manager.

MGPCOMPOSE

This refers to the COMPOSE phase in the MGP process. Similar to the MGPAPPLY phase where the Client ID is not yet available, the logs are covered by the component MGP. If the TRACE_DESTINATION parameter is set to the value TEXTFILE, all the logs generated are recorded in a log file named MGPCOMPOSE_<client_id>_<cycle_id>.log under the following directory.

<Mobile_Server_Home>\Mobile\Server\ConsLog\MGPCOMPOSE


Note:

The log file can be viewed directly from the Sync Manager.

SYNC

This refers to the server side synchronization process. When a Sync session ID is not yet available, the logs will be taken care by component GLOBAL. If the TRACE_DESTINATION parameter is set to the value TEXTFILE, all the logs generated are recorded in a log file named SYNC_<cycle_id>.log under the following directory.

<Mobile_Server_Home>\Mobile\Server\ConsLog\SYNC

When the Client ID becomes available, the file is renamed to SYNC_<client_id>_<cycle_id>.log.


Note:

The log file can be viewed directly from the Sync Manager.

GLOBAL

This component logs tracing messages that are not specific to any of the above listed components. This component also includes logs that are generated during the execution of a Consolidator API program. If the TRACE_DESTINATION parameter is set to the value TEXTFILE, all the logs that are generated are recorded in a log file named GLOBAL_<file_number>.log under the following directory.

<Mobile_Server_Home>\Mobile\Server\ConsLog\Global


Note:

The <file_number> is used for file pooling.

Tracing Levels and Types

This section describes tracing levels and types that are used to set trace settings.

TRACE_LEVEL

This parameter controls the logging output. Before logging a message, Consolidator first checks if the component is set to a certain level. It then checks the TRACE_TYPE and USER settings. Trace types that are insensitive to the trace level are exceptional. In such cases, Consolidator ignores the trace level unless this parameter is set to OFF.

Trace Levels are ordered and have cascading effects. For example, the mandatory level is higher than the warning level. When a component is set up with a mandatory level, it generates mandatory logs only. But when the component is set up with a warning level, it generates mandatory and warning logs.

  • OFF: This parameter turns off the Tracing feature for the component.

  • MANDATORY: This parameter logs mandatory messages only. For example, Program Exceptions. Note that regardless of component settings, exceptions are logged in the err.log file, which is located in the ConsLog directory.

  • WARNING: This parameter logs warning (and the above mandatory level) messages. For example, Program Exceptions that users can ignore, messages that the program wants to warn the users with, and so on.

  • NORMAL: This parameter logs normal messages that the user should be informed about. It also logs messages with the above levels.

  • INFO: This parameter logs information messages. For example, Timing and messages with the above levels.

  • CONFIG: This parameter logs configuration messages and messages with the above levels.

  • FINEST: This parameter sets the finest level. This level can be used by developers for development purposes only.

  • ALL: This parameter logs all messages according to the other settings, i.e., Trace Type and Users.

Trace_Type

This parameter sets the message type that must be traced. The following parameters can be used to set the trace type parameter.

  • SQL: This parameter logs SQL-related messages only. For example, SQL statements. Note that the TRACE_TYPE=SQL parameter is not trace level sensitive. This option prints all SQL-related messages with the trace level set to any level other than OFF.

  • TIMING: This parameter logs timing information only. You must note that the TIMING_TYPE parameter is trace level sensitive. When specifying MGP Cycle time and Synchronization time, choose the TRACE_LEVEL=INFO parameter.

  • DATA: This parameter logs data only. Note that this type is not trace level sensitive. This option prints all data with the trace level set to any level other than OFF.

  • RESUME: Messages dealing with Reliable Transport have a RESUME trace type. Components set with this parameter type can log messages associated with Reliable Transport. Note that this trace type is not trace level sensitive Therefore, choosing this type prints all the RESUME messages with the trace level set to any level other than OFF.

  • FUNCTION: This parameter displays the program flow by logging methods' entry, exit or invoke. When this trace type is turned on, ConsLogger logs the names of methods that have been called. For long methods, it logs the methods entry and exit; a simple invoke log otherwise. Note that this type is not trace level sensitive. Therefore, choosing this type prints all the FUNCTION messages with the trace level set to any other than OFF.

  • GENERAL: This parameter logs messages that do not belong to any of the above types. Note that this type is Trace level sensitive.

  • All: This parameter generates logs of all trace types.

Users

This parameter is used to limit the trace logging for certain users only. This parameter only affects user-sensitive logs; therefore, if a trace log is not specific to a user, it is logged irrespective of the trace setting in the trace users parameter. When this parameter is not set with any Consolidator Client ID, the program does not check further and log any messages. Otherwise, it checks if the log belongs to one of the Trace users and generates the log only if it does. Note that all invalid Consolidator Clients that are entered are ignored.

8.6 Browsing the Sync Repository

The Repository tab describes how to look up user information, publications, publication items, and the transaction queues that contain in, out, and error queue transactions. This section contains the following topics:

8.6.1 Viewing User Information

The Users page enables you to check application subscriptions, publication items, parameters, SQL scripts, java resources, sequences, and Consperf performance analysis.

  1. To view information about existing users, click the Repository tab on the Data Synchronization home page.

    As displayed in Figure 8-10, the Repository tab appears.

    Figure 8-10 Repository Tab

    This image displays the Repository page.
  2. To view information about existing users, click Users under the Users and Publications section. As described in Figure 8-11, the Users page appears.

    Figure 8-11 Users Page

    This image displays the Users page.
  3. To view the application subscriptions of individual users, click Subscriptions. The Subscriptions page displays existing subscriptions and controls to view publication items, parameters, SQL scripts, java resources, sequences, and Consperf performance analysis.

8.6.2 Viewing Publications

To view publications, click Publications under the Users and Publications section. As displayed in Figure 8-12, the Publications page appears.

Figure 8-12 Publications Page

This image displays the Publications page.

The Publications page displays controls to view publication items, parameters, SQL scripts, java resources, sequences, and users.

8.6.3 Viewing Publication Items

To view publication items, click Publication Items under the Users and Publications section.

As displayed Figure 8-13, the Publication Items page appears.

Figure 8-13 Publication Items Page

This image displays the Publication Items page.

To display details for a publication item, click Show.

8.6.4 Viewing Publication Queues

The Out Queue is organized by subscriptions. A subscription is based on users and publications. The In Queue and Error Queue are organized by transactions. The Repository tab contains controls to view these queues. To view transactions that are listed in queues, click the required hyperlink under the Queues section. For example, to view transactions that are listed in the Out Queue, click Out Queue.

Figure 8-14 displays the Out Queue Publications page.

Figure 8-14 Out Queue Publications Page

This image displays the Outqueue publications page.

To view the In Queue and Error Queue transactions, click the corresponding hyperlink on the Repository tab.

8.7 Scheduling MGP Cycles to Run Inside the Mobile Server

MGP is a background process that uses one or more Java threads to apply transactions that are listed in the In Queue to the back end Oracle database. It then composes server side changes for all clients into transactions and places them in the Out Queues. This process is called an Apply/Compose MGP cycle. In an Apply Only cycle, the Compose phase is omitted. As the Mobile Server administrator, you can schedule MGP cycles using the Job Scheduler. The MGP tab contains a hyperlink to access the Job Scheduler. Based on the Job Engine's status, this link appears as Job Scheduler(Up) or Job Scheduler(Down).

The Job Scheduler is the preferred way to run MGP. In this way, MGP runs threads in the Mobile Server.

Listed below are some advantages of running MGP.

There is a default MGP job called MGP_DEFAULT, that starts every one minute. Note that there can be only one MGP cycle at any given time. Hence, when an MGP cycle is running, a new MGP job cannot be started, even when it is due at a pre-scheduled time.

Using the Synchronization Manager, the Mobile Server administrator can view the current status of the MGP cycle. For instance, the administrator can check if the apply or compose cycle is running when the MGP cycle is in progress. Upon completion of the apply or compose cycle, the corresponding cycle details are stored in Cycle History if the MGP_HISTORY instance parameter is set to the default value TRUE and the cycle is not empty. This status denotes that there are client or server changes processed within an MGP cycle.

The MGP tab describes how to monitor MGP cycles, manage the cycle history, and view statistics of the Apply/Compose cycle.

Figure 8-15 displays the MGP page.

Figure 8-15 MGP Page

This image displays the MGP page.

To view the current MGP cycle, history cycles or more statistics, click the corresponding hyperlink displayed under the General section.

8.8 Running the Message Generator and Processor (MGP) from the Command Line

Starting with the Oracle Database Lite 10g Release 1 (10.1), the Job Scheduler is the preferred way to run MGP. However, MGP can still be invoked from the command line and be run as a separate OS process. This section describes the functions of the MGP and describes how to configure the MGP process. Topics include:

8.8.1 Overview

MGP is a multi-threaded process. As an administrator, you can configure the number of threads with the parameter MAX_THREADS in the CONSOLIDATOR section of the Mobile Server configuration file webtogo.ora. This parameter specifies the number of threads spawned within the MGP process.

For more information, see Appendix B, "Mobile Server Configuration Parameters".

8.8.2 MGP Cycles

MGP is a cyclical process. An MGP cycle is a large transaction where data is applied to and is composed from the Oracle database server for all users. There are two sub processes within one MGP cycle: one for APPLY and one for COMPOSE. Using the DELAY parameter, you can specify the delay duration between cycles in seconds.

For example, if ten users synchronize their data with the Mobile Server, MGP starts the next cycle after a specified delay in seconds, applying and composing data for these ten users. After this cycle, MGP pauses for the specified number of DELAY seconds and starts another cycle.

In certain situations, it is recommended that you shut down the MGP process completely (for example, to release memory) and restart. You can do this by specifying the total number of cycles that you want MGP to execute, before the MGP process stops.

8.8.3 Configuring MGP

The length of a given MGP cycle depends on the data that is being synchronized and on other constraints. As a result, users are not provided any control over MGP cycle time. Users can, however, configure the delay duration between cycles and the total number of cycles between restarts. The following section provides the requisite syntax to set the delay and restart parameters. Users can set these parameters from the command line or in the file mgp.bat.

Syntax

mgp <delay in seconds between cycles> <number of cycles between restart> <username> <password>

Example

mgp 60 10 mobileadmin manager

In this example, the delay duration between cycles is 60 seconds and the total number of cycles between MGP restarts is 10.

Setting Parameters Manually on Solaris and Windows

As the Mobile Server administrator, you can set the MGP configuration parameters manually in the file mgp (on Solaris) and in the file mgp.bat (on Windows). This file resides in the following directory, depending on the platform where the Mobile Server is running.

On Solaris

<ORACLE_HOME>/mobile/server/bin

On Windows

<ORACLE_HOME>/mobile/server/bin

Replace the <ORACLE_HOME> variable with the name of your Oracle home directory. Since MGP is multi-threaded, you can configure the number of threads by setting the MAX_THREADS parameter (static only).

Configuring MGP Threads

As the Mobile Server administrator, you can set the parameters SLEEP_TIME and MAX_TIME in the file webtogo.ora. The parameter SLEEP_TIME refers to the duration between individual client compose cycles. MGP_DELAY is the duration between each MGP cycle, after all the clients have been composed.

To configure the duration of a thread in sleep mode, set the parameter SLEEP_TIME. When you set this parameter, it applies the COMPOSE sub process. For example, situations may occur where the Oracle database server is busy and composing requires significant CPU, RAM, and I/O resources. In this case, you can provide some relief to the server by setting the MGP threads to sleep mode for a minimum duration.

Example

SLEEP_TIME = 10000

MAX_THREADS = 3

In the above example, you can specify the duration between client processes in milliseconds. The parameter MAX_THREADS specifies that the number of threads spawned within the MGP process is 3.

8.9 Monitoring Synchronization Using SQL Scripts

To monitor mobile application status during synchronization, you may use any tool to check for pertinent information in the applicable tables, or you may use SQL scripts to retrieve the desired information.

To help you monitor progress of the synchronization process, the following sections present examples of various SQL scripts that you may use to retrieve different types of information. Topics include:

8.9.1 Shared Maps

It is very common for publications to contain publication items that are used specifically for ÒlookupÓ purposes. In other words, the server may change these snapshots but the client would never update them directly. Furthermore, many users often share the data in this type of snapshot. For example, there could be a publication item called Òzip_codesÓ that is subscribed to by all mobile users. The main function of Shared Maps is to improve scalability for this type of publication item by allowing users to share record state information and, thus, reduce the size of the resulting replication map tables.

Shared Maps can also be used with updatable snapshots if the developer is willing to implement their own conflict detection and resolution logic.

8.9.2 Synchronization Times for All Clients

Using the following script, you can check the latest successful synchronization times for all clients by retrieving such information from the all_clients table.

select client, lastrefresh_starttime, lastrefresh_endtimefrom cv$all_clientsorder by client/

8.9.3 Failed Transactions for all Clients

Using the following script, you can retrieve a list of failed transactions for all clients from the all_errors table.

select client, transaction_id, item_name, message_textfrom cv$all_errorswhere message_text is not nullorder by client,transaction_id/

8.9.4 Completely Refreshed Publication Items for all Clients

Using the following SQL script, you can retrieve a list of all publication items for all clients which were completely refreshed during the last synchronization process.

select clientid, publication_itemfrom c$complete_refresh_logorder by clientid, publication_item/

8.9.5 Publications Flagged for Complete Refresh for All Clients

Using the following SQL script, you can retrieve a list of publications for all clients that are flagged for a complete refresh during the next synchronization process.

select clientid, template as publicationfrom c$all_subscriptionswhere crr = 'Y'/

8.9.6 Clients and Publication where Subscription Parameters are Not Set

Using the following SQL script, you can retrieve a list of clients and their publications where the subscription parameters have not been set.

select client, name as publication, param_name, param_valuefrom cv$all_subscription_paramswhere param_value is nullorder by client, name/

8.9.7 Record Counts for Map-based Publication Item by Client

Using the following script, you can retrieve record counts for all clients in queues for map-based publication items, that are grouped by clients.

select clid$$cs as client, count(*) as "RECORD COUNT"from c$in_messagesgroup by clid$$cs/

8.9.8 Record Count for Map-based Publication Items by Store

Using the following SQL script, you can retrieve record counts for all client in-queues for map-based publication items, that are grouped by store.

select clid$$cs as client, tranid$$ as transaction_id, store as item_name,count(*) as "RECORD COUNT"from c$in_messagesgroup by clid$$cs, tranid$$, store/

8.9.9 All Client Sequence Partitions and Sequence Values

Using the following SQL script, you can retrieve a list of all client sequence partitions and current sequence values.

select clientid, name, curr_val, incrfrom c$all_sequence_partitionsorder by clientid, name/

8.9.10 All Publication Item Indexes

Using the following SQL script, you can retrieve a list of all publication item indexes.

select publication as NAME, publication_item, conflict_rule as "INDEX_TYPE",columnsfrom c$all_indexesorder by publication, publication_item/