Oracle9i Lite Administration and Deployment Guide
Part No. A97376-01
This chapter provides information on how to administer replication. It includes a discussion of the following topics:
For managing replication and snapshots, see the Consolidator Admin API Specification.
A snapshot is a full set or a subset of rows of a table or view at a point in time. It is created by executing a SQL query against the base table. Snapshots are either read-only or updateable. They vary in complexity.
Read-only snapshots are used for query only. Changes made to the master table are replicated to the snapshot by the Mobile Client.
Updateable snapshots provide updateable copies of a master table. You can define updateable snapshots to contain a full copy of a master table or a subset of rows in the master table that satisfy a value-based selection criteria. You can make changes to the snapshot which the Mobile Sync propagates back to the master table.
A Snapshot is updateable only if all the base tables that the snapshot is based on have a primary key. If the base tables do not have a primary key, then the snapshot becomes read-only.
Your snapshot definition determines whether an updateable snapshot uses the complete or fast refresh method. The complete refresh method recreates the snapshot every time it is refreshed. The fast refresh method refreshes the snapshot's existing data. In general, the simpler your snapshot definition, the faster it is updated. For more information on the fast refresh method, see the Oracle9i Lite Developer's Guide for Web-to-Go.
Snapshots are application-based. Every client that goes offline uses the same snapshot definition. As a result, every client downloads the same application data. In some cases, you may want to specify the data your application downloads for each user. You can accomplish this by using snapshot templates.
A snapshot template is a SQL query, that contains data subsetting parameters. A data subsetting parameter is a colon (:) followed by an identifier name, for example:
When the Mobile Client creates the snapshots on the client machine, it replaces the variables with user-specific values. By specifying different values for different users, you can control the number of rows returned by the query.
You can use the Packaging Wizard to specify a snapshot template variable in the same way that you create a snapshot definition for any platform.
Data subsetting parameters cannot be part of a string and therefore should not be enclosed in single quotation marks ('). If you want to specify a string as the value of the data subsetting parameter, the string itself must contain single quotation marks. You specify the values for the template variables using the Mobile Server Control Center.
In the following examples, by specifying a different value (such as, 10, 20, or 'KING') for a particular user, the Administrator can control the behavior and output of the snapshot template.
select * from emp where deptno = :dno
select * from emp where ename = :ename
For more information on specifying data subsetting values using the Mobile Server Control Center, see Section 6.9, "Modifying Data Subsetting Parameters".
The Message Generator and Processor (MGP) is a mutli-threaded process. You can configure the number of threads with the parameter
MAX_THREADS in the CONSOLIDATOR section of the Mobile Server configuration file webtogo.ora. See Appendix B, "Mobile Server Configuration Parameters". This parameter specifies the number of threads spawned within the MGP process. You should set this parameter to be at least equal to the number of CPUs. For example,
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.
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>
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:
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.
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.
To monitor the status of synchronization, you may use any tool to check the pertinent information in the applicable tables, or you may use SQL scripts to retrieve the desired information.
The following sections present examples of the various SQL scripts that you may use to retrieve different types of information to help you monitor the progress of synchronization.
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 /
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 /
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 /
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' /
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 /
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 /
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 /
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 /