The snapshot jobs capture the metric data and store it in staging tables on the target databases. From there, it can be analyzed using the gauges and it is then replicated to the zztat repository. Snapshot jobs exist for each metric that exists on a target database, with the exception of replicate-only metrics which do not take snapshots. Snapshot jobs run only on target databases and are never run on the zztat repository database.
Snapshot jobs are commonly scheduled and run by the Oracle scheduler. The exception are snapshot jobs for on-demand metrics, which are executed by the zztat framework directly (commonly by the SYNC or REACT processes).
When a snapshot job runs it will automatically determine what triggered it: if the snapshot was executed via the Oracle scheduler, it will create its own task to be tracked by the SYNC process. If it was initiated by SYNC or REACT, it will update the corresponding task to enable it to be tracked.
The main function of SNAPSHOT is to execute the metric query and capture its output. There are several flags attributable to a metric which can alter the behavior of SNAPSHOT:
- AUTO_SYNC causes the metric to be managed by the framework as soon as snapshot completed: gauges are started automatically, and once they are completed, replicate is started automatically on the target.
- ON_DEMAND causes the metric only to be fired by the framework when needed. It will never be started by the Oracle scheduler.
- ON_UPGRADE causes the metric to fire when STATE_CHECK has detected a zztat version change or an Oracle database version change. It will never be started by the Oracle scheduler.
- SNAP_TWICE will cause the SNAPSHOT to take two data samples, one second apart. This is useful if you want your gauge to analyze the difference between two snapshots in a single run.
- STAGE_LATEST retains the snapshot metadata and data for the latest SNAPSHOT run on the target. If this flag is not present, the snapshot metadata is removed on the target after the snapshot completes, and only the metric data points remain.
- TRUNC_ON_SNAP causes the staging table to be truncated before taking a new snapshot. This is commonly used for on-demand metrics.
The staging tables used by the snapshot jobs are created on target databases automatically by the framework during metric synchronization. These tables automatically get all the constraints stripped that may exist in the repository's copy of the table, and they never contain any indexes.This is because snapshot data is always processed in bulk and as a single entity.
The illustration on the left shows the data flow of the SNAPSHOT processes:
- The metric query is parsed and executed.
- The data source can be any valid data source for an Oracle SQL query.
- The resulting data is stored in a staging table on the target database.