Metrics

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.



Overview

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.

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, $, #, _ ).
  • No reserved zztat words may be used to name a metric.
  • Metric names are automatically converted to uppercase when a metric is added.

Default and Database-Specific Metrics

A metric in zztat is uniquely identified by a combination of the DBID and the metric name. This allows a metric to exist multiple times, but with different attributes (for example different schedules) for different databases. Out of the box, all zztat metrics ship with a DBID of -1 which represents all databases, and is referred to as a default metric.

New metrics created can be specified as default metrics by not specifying a DBID, or as database-specific metrics by assigning them a given DBID. Default metrics can be copied to create database-specific metrics without having to re-create the metric.

Supported Metric Types

There are currently four major types of metrics supported by the framework. Some features of the different metric types may be combined to allow for further customization.

Standard Metrics

A standard metric is defined by the following characteristics:

  • A snapshot job is scheduled and executed by the Oracle scheduler. The metric definition must contain the schedule.
  • A replicate job is scheduled and executed by the Oracle scheduler. The metric definition must contain the schedule.
  • (optional) Any gauges on the target or on the repository that are defined for the metric are also scheduled independently and ran by the Oracle scheduler. The gauge definition contains the respective schedules.
  • It has no special flags assigned.

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, or through a third-party process.

A replicate-only metric is defined by the following characteristics:

  • There is no snapshot job.
  • A replicate job is scheduled and executed by the Oracle scheduler. The metric definition must contain the replicate schedule.
  • (optional) Repository-only gauges that are defined for the metric are also scheduled independently and are ran by the Oracle scheduler. The gauge definition contains the respective schedules.
  • It must have the REPLICATE_ONLY flag set.

Auto-Sync Metric

The auto-sync metric is one of zztat's most powerful features. It is fully automatic and is managed by the framework itself.

An auto-sync metric is defined by the following characteristics:

  • A snapshot job is scheduled and executed by the Oracle scheduler. The metric definition must contain the schedule.
  • When the snapshot job completes the SNAPSHOT process will post the SYNC process.
  • SYNC will create a new task group to track the auto-sync metric progress.
  • Any target-only gauges that are assigned to the metric are fired within a few seconds of each other. They have no schedules and are fired directly by the SYNC process.
  • Once the gauges have all completed, the SYNC process will trigger the REPLICATE process automatically.
  • After replication has completed, the repository-only gauges will fire automatically.

On-Demand Metric

An on-demand metric is either fired by the framework automatically or can be manually started by the user.

An on-demand metric is defined by the following characteristics:

  • A snapshot job exists and is on standby. It is not actively scheduled with the Oracle scheduler.
  • A replicate job exists and is on standby. It is also not scheduled.
  • On-demand metrics should not have any gauges attached.
  • The replicate job is fired automatically by the SYNC process whenever the snapshot job completes.

On-Upgrade Metric

The on-upgrade metric is a special type of on-demand metric. The zztat framework 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 or your gauges frequently access the same set of static data that you don't need to have constantly refreshed via a snapshot job.

Metric Metadata

There are various components which make up the definition of a metric:

  1. The metric DBID
  2. The metric name
  3. The snapshot interval, if applicable
  4. The replicate interval, if applcable
  5. The partitioning interval
  6. The flags controlling the type and behavior of the metric
  7. The metric SQL query
  8. A metric storage table

Metric Intervals

When specifying a snapshot or replicate interval for a metric, zztat supported the following attributes:

  • The interval must consist of a unit of time and an amount
  • Supported units of time are: SECOND(s), MINUTE(s), HOUR(s), DAY(S), MONTH(S), YEAR(S)

Partitioning

The zztat framework automatically maintains partition views and the underlying tables for long-term metric storage. When the metric is initially created, the metric storage table is analyzed by zztat, and integrated into the partition manager. Partitions are divided using an upper-bound constraint.

The supported partition intervals are:

  • DAY - creates a new table for every day's worth of data. Cut-off time is 00:00:00 UTC.
  • WEEK - creates a new table for every week's worth of data. Cut-off time is 00:00:00 UTC. The interval starts on the day the metric is added.
  • MONTH - creates a new table for every month's worth of data. This is the default.
  • NONE - does not create any tables and uses the table as-is. Use this if you have purchased Oracle's partitioning option and wish to use it instead. Note that on targets the corresponding staging table will not be partitioned (which should not be necessary).

Metric Queries

When writing SQL queries to collect the data for your metrics, you must adhere to the following guidelines:

  • The first two columns must be two bind variables placeholders for DBID and SNAP#
  • These two bind variables can only occur once in the query. If you need to specify them more than once, use a WITH clause where you specify the binds and then reference this subquery in your main query. See the query of the default zztat "SQL" for an example.
  • No other bind variables may occur in the query
  • The query should contain a comment to serve as a placeholder for the ##ZZHINT## substitution string
  • Tables referenced in the query must be accessible to the zztat user on the target database. In a future version this may happen automatically - but for now you are responsible that the proper grants are in place.
  • (Optionally) Tables referenced in the query should be accessible to the zztat user on the repository database. If they are not, query validation in the zztat UI may fail, which is safe to ignore.

You may use any valid Oracle syntax in the metric query. XML Query, JSON, aggregates, analytic functions, etc. should all pose no problem.

Metric Storage

Every metric requires a place to be stored. In the current version of zztat, metrics are stored each in separate tables which must be created before the metric is added. The metric table must adhere to the following rules:

  • The first two columns must be ZZ$DB NUMBER and SNAP# NUMBER.
  • Check constraints are not supported.
  • Primary key constraints and foreign key constraints are not supported.
  • Unique constraints are not supported.
  • NOT NULL constraints are supported but only retained on the repository. They are automatically removed when the table is created on target databases. The NOT NULL constraint name must include the table name.
  • LOB, XMLTYPE or UDT (user defined data types) are currently not supported. Let us know if you need this functionality: send us an email to info@zztat.net.