>>Gluent Advisor
Gluent Advisor 2018-05-18T12:50:53+00:00

Gluent Advisor

Gluent Advisor was originally developed as an internal tool to help us understand our customers’ databases and identify the best candidate data for offload. Today the Gluent Advisor has become a stand-alone product, included with Gluent Data Platform.

Data is gathered from target databases via simple SQL scripts that extract information about the database’s storage and workload from ASH, AWR and system level metadata. That data is then ingested by Gluent Advisor, analyzed and reports are generated.

Gluent Advisor is also capable of producing the commands that would be used to offload tables and can even recommend optimization rules that may help Gluent Data Platform perform more efficiently.

Below are extracts from a Gluent Advisor report. They show an overview of the database’s storage, what portion of that storage is a candidate for offload, and then presents details for the user to drill down into, including:

Request A Demo
Download Data Sheet

Offload Efficiency

The Offload Efficiency section provides an overview of the analysis done by Gluent Advisor. At this level you can see if the target database is a good candidate for storage offload.

Data Space Reconciliation

 

This section provides a breakdown of the storage in the target database environment. This overview takes into account things such as non-permanent tablespaces, allocated but not used free space, excluded (system level) schemas and provides an estimate of the amount of data that is candidate for offload.

Candidate Advisor Data

 

This section examines the Candidate Data and indicates how much of it is actually offloadable, based on various criteria. The section in green indicates the amount of data that could reasonably be offloaded and the orange indicates what should stay in the host database.

Table Classification Summary

The Table Classification Summary breaks down the tables scanned within the target database and classifies their ability to be offloaded.

 

Tables are classified as follows:

  • Partial Offload Candidates – tables that are range-partitioned and contain cold partitions that can be offloaded
  • Full Offload Candidates – tables that can be fully offloaded due to their relatively cold status
  • Unable to Offload – tables that are not candidates for offload due to their hot status
  • Not Supported – tables that have complex or esoteric datatypes, materialized views, etc.
  • Unable to Analyze – tables that were unable to be analyzed for some reason

Each breakdown provides an accounting of the storage that can be offloaded or that should be retained in the host database.

Table Classification Detail

The Table Classification Details provides specific information about individual tables, their ability to be offloaded, and information about data that should not be offloaded.

Partial Offload Candidates

 

This section breaks down, by owning schema, those tables that are range-partitioned and where some of the partitions are considered “cold” enough to offload. The report allows the user to drill down into the owning schema and see the table names, partition names, number of offloadable partitions, offload size and retained size.

Clicking on the icon adjacent to the Retained Partitions column will present a pop-up detailing what triggered these partitions to be retained.

Full Offload Candidates

 

This section breaks down, by owning schema, those tables that are candidates for full offload. The report allows the user to drill down into the owning schema and see the table names, partition types and offload size.

No Offload (Modified Tables)

 

This section breaks down, by owning schema, those tables that are not candidates for offload due to the fact that the tables are frequently modified. The report allows the user to drill down into the owning schema and see the table names, partition types and retained size.

Clicking on the icon adjacent to the Partition Type column will present a pop-up detailing what triggered these partitions to be retained and a list of statements that drove these changes.

No Offload (Unsupported Tables)

 

This section breaks down, by owning schema, those tables that are not candidates for offload due to unsupported datatypes. The report allows the user to drill down into the owning schema and see the table names, partition types, reason the table is unsupported and offload size.

Want to run Gluent Advisor against your own databases?

Get Advisor