Estate Explorer provides estate analysis, scores database readiness for Autonomous Database migrations, prioritizes least-effort database migrations, suggests remediation for premigration tasks, and provides TCO comparisons for target OCI Database environments.
Estate Explorer does not perform migrations. The tool evaluates individual databases and identifies specific premigration tasks that are necessary or optional. Oracle offers several migration tools and other resources to help you migrate to Oracle Cloud Infrastructure (OCI). Visit Migrate Oracle Databases to OCI for additional information.
Estate Explorer only scans Oracle Databases (including Oracle Exadata and Oracle Database SE) from release 11g onwards running on-premises, in Oracle Cloud Infrastructure, or on other public clouds.
Yes. The Estate Catalog contains a broad collection of useful management, operational usage, database deployment, and technical database metadata. Standard reporting plus self-service reporting allow you to visualize, filter, and group by dozens of data elements for insightful reporting.
Both tools are important for planning cloud database migrations and identifying premigration tasks. The difference is that Estate Explorer analyzes an entire or partial estate and scores and ranks each individual database according to its complexity and the premigration effort.
The estate-wide analysis includes a least-cost migration prioritization strategy. In short, Estate Explorer provides the first step in a cloud migration. Once the strategy and databases impacted are identified, then it is time to use CPAT.
There are two components to Estate Explorer: a set of scripts that capture database information, and a user interface for database assessment. The scripts are typically installed on-premises and require a shell. The Estate Explorer Oracle APEX application can be installed and run on-premises, in a VM, on a laptop, in an OCI tenancy, or in Autonomous Database. It is suitable for installation in the Oracle Cloud Free Tier.
Estate Explorer uses an Oracle 19c database using latest version of APEX. This database can be located nearly anywhere (on-premises, in a VM, OCI customer tenancy or the free tier, or with any cloud provider. The user is responsible for providing a suitable, licensed database.
The data capture scripts require a shell (e.g. bash or similar) and SQL*Plus as a minimum. If Oracle Enterprise Manager is available, then Enterprise Manager CLI can be used to build the database catalog.
Oracle APEX requires Oracle Database 19c and above, as well as an installation of Oracle REST Data Services. The database can be installed anywhere that Oracle Database can be installed. The Autonomous Database includes these prerequisites. For more information, see the installation guide.
No. However, Estate Explorer is integrated with Enterprise Manager. If Enterprise Manager is in use, Estate Explorer can use the Enterprise Manager repository as the foundation for the database catalog. If Enterprise Manager is not available, the catalog can be built from spreadsheets.
Yes, it can source data from multiple Enterprise Managers. Each Enterprise Manager extract provides a catalog of databases, and these can be combined within the tool into a single catalog.
For the catalog data capture, you will need privileges to run SQL*Plus as the SYSMAN database user. You will need to add the SYSMAN username, password, and connection string to the environment variables defined in oee_dbcatalog.sh. For the group extract, the user needs to have the SELECT ANY DICTIONARY system privilege; the user DBSNMP can be used for this purpose.
For the catalog creation, Estate Explorer captures essential characteristics of the databases and database hosts from the Enterprise Manager. When scanning the source databases, Estate Explorer collects information about the database from the data dictionary: V$ views, DBA_ views, and AWR tables.
Note that Estate Explorer only captures metadata from the data dictionary. For example, it needs to know if the database used index-organized tables and what those tables are called (as part of generating a list of preparation action) but it does not look at the data in the tables.
Yes. Scripts are human readable and can be inspected before they are run. The output is also human readable and can be inspected.
Minimal. Data collection is a small PL/SQL statement that takes 10 to 15 seconds to run on each database. The anonymous PL/SQL block runs around 25 small queries, and these are run without parallelism. The script is run in read-only mode. Only metadata is collected. For example, Estate Explorer needs to know if index-organized tables are used and the names of those tables (this information will be included in the report of potential remediation actions) but does not have any knowledge of the data contained in those tables.
A user can choose to run Estate Explorer themselves with no input from Oracle and with no visibility of any data to Oracle. All data collected is human readable (CSV files) and can be inspected before sharing (if a user wants to share with Oracle or anybody else).
Oracle (or a suitable partner) can help with data analysis or even run the analysis for you. To offer this service, Oracle or the partner would need access to the collected data. If you are comfortable running the analysis yourself, then there is no need to share the data with anyone else.
Professional DBAs will have no trouble understanding the individual database reporting. All database metadata and characteristics will be familiar. However, when considering the recommendations and guidance for an entire estate with a diversity of database versions and implementations, DBAs may need to rely on others with broader experience to understand the implications.
Yes. Production databases are primary candidates for cloud migrations. Estate Explorer requires minimal information for Oracle Database data dictionaries, which are generally static during production operations. Data gathering on high-transaction-rate databases averages 15 seconds per database. There are two data gathering steps: initial database identity (database links and properties) and then current production statistics (database size).
Data gathering occurs by groups of databases. A group can be the entire estate or it can be a subset. Groups are arbitrarily named and assembled by users. Databases can also exist in multiple groups. For example, you may have separate groups for marketing, production, on-premises, and cloud databases. Groups exist to summarize findings and to rank least-effort migrations.