Assessing database migration complexities with migVisor

pritam sahoo
Google Cloud - Community
6 min readNov 26, 2022

We all understand that database migrations can be complex and challenging. Assuming that you have done discovery and scoping of database estate you must plan for assessing database migration complexities. In case you have missed my previous blog please have a look at my previous medium post on Comprehensive approach to Enterprise DB Migration. Link below

Link https://medium.com/google-cloud/comprehensive-approach-to-enterprise-database-migration-b242efc1ae98

Coming back on database assessment we at Google cloud leverage partner technology product from EPAM i.e. migVisor. migVisor is a SaaS cloud solution that helps you determine how easy or difficult it is to migrate a database to the cloud. With migVisor you can assess migration complexities and risks, accelerate database cloud migrations, and reduce migration costs. This is a super important step in the journey of heterogeneous database migrations, especially cross platform database change.

In short migVisor accelerates database migration assessments. It has got 2 parts. The first step is collection of source database information using migVisor collector (mMC). The second step is analyzing the features collected in the migVisor console(mConsole). This blog is focussed on analyzing capabilities of migVisor

To get started Login into the migVisor console @ https://console.migvisor.com/. The “Portfolio” section is the landing page for migVisor. It’s split into 2 sections on the left hand side you see “Database Feature Breakdown” and on the right hand side you see “Application Complexity Breakdown”. Screenshot below for your reference

In the left section of the above screenshot for “Database Feature Breakdown” depending on the selected source DB engine you will find top 10 most used features on the source database. In my case its Oracle Database is the source database. The source database features which don’t qualify for top 10 are listed in “other”. In my case you find “synonyms” are found at 96.7% for the source oracle database.

Let’s change the source DB engine to “SQL Server” you will find all together different stats on the source database. Screenshot below clearly highlights SQL Server has stored procedures with 18.1% as the most used feature.

Below screenshot shows tooltip with least used/found feature petal on SQL Server i.e. “Clustered Indexes” @3.1% to most found features i.e. “Stored Procedures” @18.1 % and others at 26.3%.

Let’s switch back to the earlier source database engine as Oracle DB for the time being and move to the “Database Analysis” Section in the bottom portion of the Portfolio page. In the screenshot below we are going to analyze “Oracle DB” and the target DB engine on Google Cloud in my case will be “GCP Cloud SQL Postgres 12”. We have selected all the sources i.e. 20 here. The below image highlights the degree of difficulty when migrating from oracle source database to Postgres 12 engine on Cloud SQL.

You can pick up the sources and limit as well as per subsequent screenshot.

Lets drill more into the Databases Analysis with “Databases Ranked by Migration Complexity”

As per screenshot below you can clearly see highlighted box that there are 2 sections i.e. “Absolute view” and “Relative View”.

Absolute view lists down the items by complexity level only whereas Relative view can be used to differentiate applications of similar complexities.

When you click on one of the discovered databases i.e. here on Oracle you can see what determines the complexity. In our case i.e. red arrow highlighted you can see on the right hand side you can Oracle proprietary features like Database Links, Oracle Text, RAC etc which makes this migration complex to high in red color while planning for migration from Oracle to Postgres 12 on Cloud SQL.

In the bottom section of the same portfolio page you can see the count of databases and associated versions in “DB Engine Versions”. In our case it’s 16 databases of oracle 11.2.

Similarly in “DB Engine Features” section you will find a scrollable list of all discovered features on Oracle database unlike top 10 features of source database discussed earlier. In our scenario its 48000 plus count of synonyms etc.

Each layer on the cylinder indicates the volume of data on the selected database. It can be categorized to low,medium and high volume. In our case as per the screenshot below its low volume of oracle database.

Lets hop to second section i.e. “Databases” after some analysis in the portfolio section. Select the filters to DB Engine as oracle and target as Postgres 12 and all sources. You can find out the Low, Medium and High Complexity databases.

Let’s drill down to one of the high complex database from the catalog section. Screenshot below. In our case ERPRPOD_US is the selected database.

Then you can see high,medium and low migration impact features. Also you can get the infra details hosting the databases i.e. number of cores, memory, os etc.

Lets focus on the high migration impact features. One such proprietary Oracle db feature is RAC(Real Application Cluster) associated with 2 instance IDs. Similarly Database Links, Orale Text and Synonyms increases the complexity of migration from oracle to postgres.

You also get info about how these high migration impact features like Real Application clusters for instance should be taken care of on Postgres 12 on Cloud SQL which means re-architecting required.

One interesting discovery on the middle section is that you can find workload types whether it’s OLTP orientated or Analytics oriented. In our case it tends to be the Analytics. Screenshot below, so it would be great to figure out whether Postgres on GCP’s new relational database offering AlloyDB can be a great fit for handling both OLTP and analytics workloads or BigQuery(Planet scale GCP’s Cloud native data warehouse) instead of Cloud SQL Postgres.

In the further bottom of the same page you can find the Schema section for the single database wise split and determine the complexity reasons. We find out one of the schema “Launch” has medium complexity due to the obvious reasons of discovery of proprietary oracle features.

Hope you enjoyed the readings and that’s not all from migVisor standpoint. Please stay tuned to the second series of migVisor coming shortly on your way !!!!!!!

--

--