From zzat
Jump to: navigation, search

Repository And Targets

The zztat framework uses a central repository which controls all the monitored target databases. Every target obtains instructions from the repository to determine which metrics it is supposed to run. The repository serves as the single source of truth and configuration settings cannot be changed on target databases directly.

All communication between target databases and the repository database is fully one-directional. There are no connections being opened to the monitored target databases; targets may only connect to the repository but cannot receive connections from the repository.

Users and Security

The zztat framework uses different users, each with the minimum set of required privileges for the framework to function. On each target database, two database users are created. One user is the application user where the framework processes run, and the second user owns a private database link that points to the zztat repository database. These users' names are configurable at installation time, but cannot be changed later.

The database link user never runs any jobs, owns few objects and has a highly restricted set of database privileges.


The framework can be controlled through a PL/SQL API as well as the zztat user interface "ZUI". The graphical interface runs on top of the repository database and controls the entire framework from there. Connecting to the target databases is unnecessary. The PL/SQL API is externalized through the PL/SQL package zz$manage and its functions and procedures are available - with a few exceptions - on the repository only.

The API allows control of every aspect of the framework and enables full integration with management tools such as Puppet, Chef or Ansible.

Coming soon: chat APIs that allow alerts right in your favorite team chat and, optionally, framework commands to be triggered right from the chat. Support for Slack and Telegram in the initial version.

Process-Based Architecture

The following pages describe the core concepts of the zztat framework and how they work together to ensure an optimal framework operation. The framework uses a process-based architecture, with individual processes each performing their own dedicated tasks. It's very similar to the architecture of the Oracle database itself, where for example the PMON process is responsible for cleaning up dead processes; in zztat the STATE_CHECK process performs similar duties. The individual processes used by zztat and their roles are described in detail in the chapter on processes.

At the heart of the framework lies the Oracle scheduler which controls most of zztat's processes.

Metrics, Gauges and Reactions

One of the primary functions of the zztat framework is to collect data. This data can be any kind of data: anything that can be retrieved using Oracle SQL. In zztat, data points of interest are called metrics. An example metric is a query that collects data on active sessions, another example is a query that collect tablespace usage statistics. A metric in its simplest form consists only of a SQL query and a schedule. More complex metrics can be triggered under specific conditions such as by a reaction, or when a certain state arises, such as a database version change. The zztat framework is shipped with over 40 different metrics ready to be used. Metrics are fully customizable and the framework can further be extended by creating custom metrics.

Once data has been collected, the data is analyzed by gauges which evaluate the data points against a series of thresholds. The gauge complements the metric by acting as a trigger mechanism to fire reactions when a threshold has been met or exceeded. Similar to metrics, gauges are highly customizable and can also be created from scratch to add additional checks to the framework.

The third and final key component is the reaction. A reaction can be corrective or read-only. A typical example of a read-only reaction would be sending an alert by email; and an example of a corrective reaction would be terminating a session, or adding a data file to a tablespace that's about to run full. While the default reactions that are shipped with zztat can't be changed, the framework allows the creation of reaction chains using the default reactions, to enable full customization of what exactly happens. Furthermore, entirely custom reactions can be added into the framework, which can be written in Oracle PL/SQL and fully integrated into the framework at which point they can be used in all the same ways as the built-in default reactions.

Tasks And Control

Everything zztat does is represented as a task. Every process that starts is either triggered via a task or creates a task before it begins execution. This enables the framework to do self-healing and monitoring. It further allows tasks to be assigned to target databases from the zztat repository. Many of zztat's functionality is based on this task management, which enables a robust means of coordinating work across databases.


The framework has a self-patching mechanism built-in and is capable of patching both the repository and the target databases with a single command or click. The vast majority of zztat patches will be applicable using the zztat patcher, making administration a breeze. The patching mechanism is aware of dependencies between patches and is capable of managing both patch apply and rollback.