Oracle9i Lite Administration Guide
Part No. A95260-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 in the same way that you create a snapshot definition. For more information, see Oracle9i Lite Developer's Guide for Web-to-Go.
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.8, "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 Oracle8 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 can not 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 restart
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.bat file, which resides in the following directory:
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 Oracle8 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.