10
Administering Replication

10.4.1 MGP Cycles

MGP works in cycles. A 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 cycle, one for APPLY and one for COMPOSE. You can configure the delay in seconds between the cycles. For information on how to configure MGP, see Section 10.4.2, "Configuring MGP ".

For example, if ten users synchronized their data with the Mobile Server, MGP starts a cycle after a certain number of seconds (DELAY), applying and composing the data for those ten users. After this cycle, MGP pauses for the DELAY number of seconds and then starts another cycle, and so forth.

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

See Section 10.4.2, "Configuring MGP " for detailed information on how you configure the delay between MGP cycles and the number of cycles.

10.4.2 Configuring MGP

You cannot control the amount of time it takes MGP to finish a cycle because the length of a given MGP cycle depends on the data that is being synchronized and on other constraints.

You can, however, configure MGP by setting two parameters:

• DELAY in seconds between cycles

• NUMBER of cycles between restarts

You can either specify these two parameters when you run the MGP application from a DOS prompt or you can set them in the mgp.bat file.

If you want to specify the two parameters when you run the MGP application, use the following syntax:

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

For example:

mgp 60 10 mobileadmin manager

This example specifies that the delay between the cycles is 60 seconds and that the number of cycles is 10.

You can also set these two parameters manually in the mgp file (on Solaris) or the mgp.bat file (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 <ORACLE_HOME> with your actual Oracle Home.

Since MGP is multi-threaded, you can configure the number of threads by setting the MAX_THREADS parameter (static only).

You can set the parameters SLEEP_TIME and MAX_THREADS in the webtogo.ora file. To configure the time that a thread is in sleep mode, set the parameter SLEEP_TIME. When you set this parameter, it applies to a thread in the COMPOSE sub-process only. For example, let us assume that the Oracle database server is busy and that you do not want the MGP threads to COMPOSE data because composing requires signifficant CPU, RAM and I/O resources. In this case, you can provide a certain amount of relief to the server by putting the MGP threads in sleep mode for a while.

For example:

SLEEP_TIME = 20000

MAX_THREADS = 3

In this example, the paramter SLEEP_TIME specifies that the MGP process sleeps for 20000 millisecons between client procesings, and the parameter MAX_THREADS specifies that the number of threads spawned within the MGP process is three.

10.5.1 Synchronization Times for All Clients

To check the most recent successful synchronization times for all clients, you may retrieve that information from the all_clients table by using the following SQL script:

select client, lastrefresh_starttime, lastrefresh_endtime
from cv$all_clients

order by client

/

10.5.2 Failed Transactions for All Clients

To retrieve a list of failed transactions for all clients from the all_errors table, you can use the following SQL script:

select client, transaction_id, item_name, message_text

from cv$all_errors

where message_text is not null

order by client,transaction_id

/

10.5.3 Completely Refreshed Publications Items for All Clients

To retrieve a list of publication items for all clients, which were completely refreshed in the last synchronization, you can use the following SQL script:

select clientid, publication_item

from c$complete_refresh_log

order by clientid, publication_item

/

10.5.4 Publications Flagged for Complete Refresh for All Clients

To retrieve a list of publications for all clients, which are flagged for a complete refresh during the next synchronization, you can use the following SQL script:

select clientid, template as publication

from c$all_subscriptions

where crr = 'Y'

/

10.5.5 Clients and Publications where Subscription Parameters Are not Set

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

select client, name as publication, param_name, param_value

from cv$all_subscription_params

where param_value is null

order by client, name

/

10.5.6 Record Counts for Map-Based Publication Items by Client

To retrieve record counts for all clients in queues for map-based publication items, grouped by client, you can use the following SQL script:

select clid$$cs as client, count(*) as "RECORD COUNT"

from c$in_messages

group by clid$$cs

/

10.5.7 Record Count for Map-Based Publication Items by Store

To retrieve record counts for all client in queues for map-based publication items, grouped by store, you can use the following SQL script:

select clid$$cs as client, tranid$$ as transaction_id, store as item_name,

count(*) as "RECORD COUNT"

from c$in_messages

group by clid$$cs, tranid$$, store

/

10.5.8 All Client Sequence Partitions and Sequence Values

To retrieve a list of all client sequence partitions and current sequence values, use the following SQL script:

select clientid, name, curr_val, incr

from c$all_sequence_partitions

order by clientid, name

/

10.5.9 All Publication Item Indexes

To retrieve a list of all publication item indexes, use the following SQL script:

select publication as NAME, publication_item, conflict_rule as "INDEX_TYPE",

columns

from c$all_indexes

order by publication, publication_item

/