Gluent

Gluent Advisor

Utilize Our Cloud Migration Assessment Tool to Better 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 Offload Advisor tool and cloud migration assessment answers this question by identifying the best candidate data to offload.

Metrics are gathered from target databases by Gluent Advisor Data Extractor, 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 Table

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.

Candidate Advisor Data Table

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 – table types that are not supported such as materialized views, etc.
Table Classification Summary

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.

Partial Offload Candidates Data

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.

Full Offload Candidates Data

No Offload (Modifies 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 Modified Tables

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.

No Offload Unsupported Tables

Want to see how much data you can move to the cloud with data integration tools from Gluent? Contact us today!