Data currency reflects how up to date you want the copy tables to be. IBM Replication makes it very easy to control the Apply program processing interval and therefore the currency of the data. It is sometimes very tempting to start out wanting your copies to be as current as possible. In a test environment, you might be setting all frequency intervals to the minimum. When moving to production, it is advisable to start with a mid-range frequency value and "tune" your system from that point.
You can set an interval or relative timing schedule, or trigger the Apply program with events to start processing a replication subscription. Customers have devised many creative ways of controlling the replication subscription timing mechanism, but the most typical ways are interval and event-based timing.
You define subscription timing with the Subscription Timing notebook from the Control Center, and control the timing using time-based and event-based scheduling. These timing options can be used together or independently of each other. For example, you can set an interval of one day, but specify that an event can also trigger the subscription cycle.
Interval timing, copying on a specified interval, is the simplest method of controlling subscription timing. You determine a specific start time, date, and interval, which can be a set time interval (from one minute to one year) or continuous copying. The entire subscription set is replicated on the same frequency. Time intervals are approximate. The Apply program will begin processing the replication subscription as soon as it can, based on its work load and the availability of resources. You can set and change the interval with the Control Center or by using standard SQL against the subscription set control table.
Continuous timing replicates the subscription set as frequently as the Apply program can replicate the data.
Choosing a timing interval does not guarantee that the frequency will be exactly at that interval. When you decide on the refresh interval for the replication subscription, you should determine whether it is possible to refresh all tables in the replication subscription within the interval. To check this, determine the amount of data that the Apply program is likely to select for each interval and estimate the time that it will take to copy the data.
Event timing is copying that is triggered by an event. You specify an event name when you define the subscription in the Control Center, and then you have an application or a user populate the subscription events table with a timestamp for the event name. When the Apply program detects the event value, it begins replicating the replication subscription. You can use event-based timing together with interval timing for the same subscription.
The subscription events table, ASN.IBMSNAP_EVENT has three columns
as shown in Table 8.
Table 8. The Subscription Events Table
| EVENT_NAME | EVENT_TIME | END_OF_PERIOD |
| END_OF_DAY | 1997-12-01-17:00:00.000000 | 1997-12-01-15:00:00.000000 |
EVENT_NAME is the event that you specify while defining the replication subscription. The Control Center populates this column in the subscription set table after the replication subscription is defined. EVENT_TIME is the timestamp for the time when the Apply program begins processing the replication subscription. END_OF_PERIOD is an optional value that indicates that transactions after this time should be deferred until a future date. EVENT_TIME is set by the clock at the control server, while END_OF_PERIOD is set by the clock at the source server. These two databases may be on servers in different time zones, so this distinction is important.
In Table 8, END_OF_DAY is the event name that you specified while defining the replication subscription. The timestamp value, 1997-12-01-17:00:00.000000, is the time when the Apply program is to begin processing the replication subscription. The timestamp value, 1997-12-01-15:00:00.000000, is the transaction time when changes are no longer replicated; these transactions will be replicated on the next day's business cycle.
Your applications post events; the Control Center does not post events. You tie your applications to subscription activity through named events. If you post an entry using CURRENT TIMESTAMP for EVENT_TIME, then you trigger the event named by EVENT_NAME. Any replication subscription tied to this event is now eligible to run. You can post events in advance, such as next week, next year, or every Saturday. If the Apply program is running, the Apply program will start at approximately the time that you specify. If the Apply program is stopped at the time you specify, and then restarted later, it checks the subscription events table, notices the posted event, and begins processing the replication subscription.