With cloud deployments there is increasingly a general business-led impetus, to choose ‘one cloud’. This is to reduce complexity, perhaps costs, enforce standardisation and simplification. There are merits and demerits to this approach. One obvious disadvantage is vendor lock-in, but there are technical issues which may preclude a native or easy migration of an IT stack or application stack to a particular platform.
For example, you may see a VLE (very large enterprise) decide that they will deploy their business applications ‘only’ on Azure, regardless of the application-stack or underlying technologies. This is usually a ‘business’ not a technical decision which could infer and incur some serious technical constraints. The business may love Azure since Microsoft is giving away its services free or heavily discounted. The technical group, however, may state that some workloads and application stacks best belong in different clouds and that forcing Oracle (say RAC) onto Azure, is imprudent.
In this scenario you would move Oracle to AWS or perhaps the Oracle cloud, depending on your future strategy. For instance, if you eventually want to move off Oracle and into Aurora (to save massive license fees), you would first re-platform Oracle to AWS, then set up a migration plan to Aurora. However, ‘free’ is compelling for those with calculators and sharp pencils and they may decree to the lowly IT food chain, that Azure is the ‘main platform’. If the pointy-IT heads rightly state that Oracle license reduction provides a massive ROI, the pencil-people will declare that the Azure ROI is now, whilst the Oracle premised ROI is in the future.
Recent experience with the above is summarised below. There is a method to move Oracle (but not RAC) which necessitates a 3rd party layer) onto Azure.
Business Demands
- Migrate Oracle databases (upgraded to the latest version before-hand), non-RAC estate, to Azure
- Migrate current Oracle databases to Azure SQL database PaaS depending on the use case and testing results
- Also assess migrating the Oracle databases to Azure on VMs (IaaS) and self-managing the DBs
It may be that you will end up with a mix of PaaS and IaaS. The operational model to support IaaS needs to be well thought out before you migrate.
Technical Translations
Oracle is not ‘native’ on Azure. The following sections present some steps to overcome these challenges. Keep in mind that you need to prepare your Azure estate to receive the Oracle migration properly. DBA setup steps must be followed in their entirety.
Of course, you need to properly scope the project, set up an agile team composed of key stakeholders and skillsets, create an HLD, including the main principles of security of the stack, networking architecture, data encryption, end user access, SSO etc. There is usually networking and load issues with Oracle on Azure, when connecting from on-premise or a non-Azure network, so check the following:
- Test the network, bandwith and latency can be issues when connecting with a VPN or Route connection to the database.
- Identify the processes which demand heavy demands on the network. Look for applications that are not dependent on a data source in the cloud. This may cause you to rethink the placement of data sources. Most likely in this dependency analysis you should remove any data source or access constrains and reallocate resources to match access demands.
The following is the general approach.
Use the Right Tools
Azure has migration assistants that you need to use to understand which PaaS or IaaS configuration you will need (SQL Server vs Azure SQL).
- Use the SQL Server Migration Assistant, (SSMA) to perform a discovery and assessment, which will report on the current environment, including schemas, code and if there are any issues.
- Set up your Azure environment and networking and be prepared to do a few ‘competing’ POCs to see what the best design is (costs, access, latency, operational management).
If you are using advanced Oracle features that may not be supported in Azure, or with SQL Server 2017-2019, use the Oracle Extension Pack which will emulate these features in an Azure DB. This will include materialized-views and object-redesign. There are of course issues with emulation (latency) and technical trade-offs which should be documented and understood (in the HLD, and eventually the E2E).
Migrate 1 DB and patiently optimise
Migrate your first non-critical DB using native Oracle or Azure tools. Use the virtualised environments to improve your tools usage and look at more advanced automation if needed for application-development, testing and deployment. Usually you lift and shift first, re-platform, engage the steady state, optimise and add automation and tools over time. Don’t expect to create an automated pipeline in a short period of time.
Perform Tests and Compare by transaction Duration
Part of testing an Oracle application is to test for duration time. Oracle and Azure have optimisers to test latency based on transaction duration. Use these to understand performance differences. Azure also has an ‘advisor’ which can be very helpful in optimising the Oracle database, and isolate issues with duration. A key issue with Oracle DBs in Azure is that some firms don’t adequately test for duration (network, access, bandwidth, data loads, data transfers, interaction with the application, Web Logic issues etc.)
Read the Azure documentation
Azure and Oracle have a lot of documentation on moving an Oracle platform into Azure-cloud. The following are key links that should be used.
Microsoft Planning Assessment Tool Kit
Planning tool and assessment toolkit.
SQL Server Migration Assistant, (Hybrid) for Oracle
Connect to Oracle databases and report/migrate Oracle databases to SQL Server or Azure
Identified Oracle centric features and emulates them in Azure.
Support Document for SSMA Oracle Extension Pack
Support document to assist in installing and configuring
Licensing Document for Oracle to Azure
Always complicated, find a pricing expert to help
Some other links to help optimise the migration approach are given below.
Virtual Database Clones allows for large RDBMS to be migrated almost as fast an application.
Creating Read and Write Snapshots
Virtualization Example that will save on time and storage for initial testing without extensive downtime
Ability to test workloads and benchmark progress
Identifies and make recommendations across multi-tier environments
===END