Gluent

Gluent Advisor

Understand Your Databases

Say Hello to Gluent Advisor

“Where do I start?” It’s a question we hear from many customers wanting to migrate their data to the cloud and the reason we built Gluent Advisor. Our Advisor tool answers this question by identifying the best candidate data to offload.

Metrics are gathered from target databases via a simple open-text SQL script that extracts 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 will also produce the commands that will be used to offload tables and can even recommend optimization rules to help Gluent Data Platform perform more efficiently in your environment.

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

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. The overview takes into account things such as temporary 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 can be safely offloaded and dropped from the database 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 may be offloaded but that are not candidates for dropping from the database due to the amount/frequency of changes they are undergoing
  • Not Supported – tables types that are not supported such as materialized views, etc.

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 partitioned and where some of the partitions are considered “cold” enough to offload and remove from the database. The report allows the user to drill down into the owning schema and see the table names, partition names, recommended number of partitions that can be offloaded and dropped from the database, 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 dropping from the dataabase due to the fact that the tables are too 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. 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 see how much data you can move to the cloud?