From zzat
Jump to: navigation, search


A zztat metric is all about data. The metric defines what data to collect, how to collect it, and how to store it.

There is a variety of default metrics that come with zztat - some are enabled by default, but most are disabled by default. This allows zztat to run safely on virtually any Oracle database, regardless of its size or design, without adversely impacting its operation. But don't worry, enabling additional pre-defined metrics is quick and easy.

Here is a list of default zztat Metrics what they can do, and whether or not they are enabled out of the box.

One key attribute of the zztat framework is that it's highly configurable. Metrics illustrate this right from the start. A metric can be what is referred to as a standard metric, a replicate-only metric, an auto-sync metric, or even an on-demand on-upgrade metric. How a metric behaves is controlled by the flags that are attributed to it. But what all metrics have in common is that they govern two major components of the zztat framework:

  • How snapshots are taken
  • How data is replicated from the targets to the repository

Metric Naming

A metric name must adhere to the following rules:

  • Maximum 12 characters in length. Use the comments field to enter more descriptive text.
  • Only characters which are valid Oracle unquoted identifiers for object names such as table names can be used (A-Z, a-z, 0-9, $, #, _ )

To get started, let's first take a look at a standard metric and how this works.

Standard Metrics

A standard metric is defined by the following characteristics:

  • A snapshot job is scheduled and executed by the Oracle scheduler
  • A replicate job is scheduled and executed by the Oracle scheduler
  • (optional) Any gauges that are defined for the metric are also scheduled independently and ran by the Oracle scheduler.

Sample script to create a standard metric:

create table zz$ts_space ( tablespace_name, user_gb, total_gb ) pctfree 0
  name => 'TS_SPACE',
  snap_interval => 1,
  snap_unit => 'HOUR',
  replicate_interval => 1,
  replicate_unit => 'DAY',
  part_interval => 'MONTH',
  query => q'[
select tablespace_name, 
       round(sum(user_bytes)/1024/1024/1024,2) as user_gb, 
       round(sum(bytes)/1024/1024/1024,2) as total_gb 
  from dba_data_files]',
  comments => 'Example tablespace free space metric'
Note: for a more complete example on how to add your own metrics and other zztat components - refer to the Quick Guides.

Above code sample will produce a metric with the following properties:

  • No flags are attributed to the metric
  • Snapshot job is fired once per hour by the Oracle scheduler.
  • Replicate job is fired once per day by the Oracle scheduler and replicates all snapshots it finds.
  • There is little to no communication happening between the zztat processes for this type of metric.
  • Any gauges added to this metric will run on their own schedule
  • Since the metric has no DBID specified, it will automatically be synchronized to all target databases and start collecting data.

Replicate-Only Metric

A replicate-only metric is very similar to a standard metric. The key difference is that there is no snapshot job. This type of metric allows you to populate the staging table through any means you choose - for example through a job in the operating system's crontab.

Auto-Sync Metric

This is where the real power of the zztat framework comes into play. An auto-sync metric is fully automatic and can be lightning fast.

When an auto-sync metric's snapshot job is fired by the Oracle scheduler, this is what happens:

  • The snapshot collects data and stores it in the staging tables on the target database
  • Once complete, the SNAPSHOT process will post the SYNC process
  • After SYNC sees that this is an auto-sync metric, it will create a new task group:
    • SYNC will create a new task request for each gauge for this metric
    • Each gauge will fire at the same time
    • Any warning- or critical-threshold violations that occur while the gauge runs, are collected, and will trigger reactions to start upon completion of the gauge.
    • Each completed gauge will report back to SYNC
    • Once SYNC receives acknowledgement that all gauges have completed, it will then create a final task on the target database to initiate replication of the snapshot data to the repository
    • After replicate has completed, it will notify SYNC on both the target and the repository database
    • SYNC on the target database then closes the task group - its job is done
  • Once the SYNC process on the repository database sees that newly replicate data has arrived, it will then fire any repository-only gauges that exist for the given metric by creating a new task group.
  • Once the final cycle has completed and all gauges have completed, the task group is closed, and the auto-sync metric run is complete.

On-Demand Metric

The final type of metric is the on-demand metric. This metric can be fired by zztat on specific conditions, or can be fired manually by the user.

On-Upgrade Metric

The on-upgrade metric is a special type of on-demand metric. zztat uses this internally to refresh static data that's version-dependent, such as v$event_name, v$metricname, etc. You may of course add your own if you find one that's missing.

Metric Queries