From zzat
Jump to: navigation, search

The replicate process collects the data produced by SNAPSHOT and archives it on the repository. Replicate jobs can either be executed by the Oracle scheduler, or by the SYNC process (for auto-sync metrics).

Similar to the SNAPSHOT process, the REPLICATE process is also aware of who triggered it and handles the corresponding tasks accordingly to allow its operation to be tracked by the framework.

The REPLICATE process' behavior can be altered through flags attributable to the metric:

  • AUTO_SYNC will change the metric to be managed by the framework instead of the Oracle scheduler. Replicate is triggered automatically as soon as all gauges have completed successfully.
  • REPLICATE_ONLY causes the replicate job to treat snapshot metadata as optional. If metadata data is not present, data is replicated using the static snapshot number 1.
  • REP_READ_ONLY forces the replicate job to treat the snapshot data as read-only and it is not removed after it has been replicated. This flag can be used if you wish to use your own logic to maintain the snapshot data retention on targets.
  • STAGE_LATEST retains the latest snapshot data on the target database.
  • SYNC_REACT will cause SYNC to wait for reactions to complete before starting REPLICATE for this metric.

When using standard metrics, it is important to consider the schedule of the SNAPSHOT, REPLICATE and GAUGE processes for any given metric. Otherwise, data may no longer be present once the gauge runs. For standard metrics, order of execution is determined by the schedule. When using auto-sync metric, the framework automatically handles the order of execution, which is always SNAPSHOT -> GAUGE -> REPLICATE.

Replicate - REPLICATE - PUSH.png

The diagram on the left shows the data flow:

  • Before replicate reads the data, the staging table is locked.
  • The replicate process reads the data from the staging tables.
  • The correct partition is obtained from the repository.
  • Data is inserted via the database link into archive tables on the repository.

Replication always happens on a per-snapshot basis. This means that if SNAPSHOT triggered multiple times and created several data points, they will be replicated one-by-one as a logical unit. REPLICATE will also replicate multiple snapshots automatically if there have been communication problems with the repository due to network issues, for example. REPLICATE will catch up automatically.

Once replication completes, a message it sent to the SYNC process on both the target and the repository database.