Prepping an Oracle Database for a Cloud Migration

There’s so much I need to get written down these days, but there’s only so many hours in a day and days in a week and I’ve totally failed in this area.  Well, I have a little time right now, so going to try to get something down.  It only took me four times to get this published! 🙂

I’m often asked how I migrate an Oracle database to Azure and although each database is unique, there are some things that are pretty consistent that need to be identified and some that should be resolved before migrating to the cloud.

Don’t Assume, Collect the Data

Assumption is the downfall of any project, and especially so for cloud migrations.  Marking something as an unknown is preferred to an incorrect assumption, so my recommendation is-  if you don’t know, don’t assume and when people ask you to guess, just let them know that guessing will just lead to wasted time.

Data to be collected about the database to be migrated:

1.  Database usage type, (OLTP, OLAP, DSS)
2.  Applications that access the database
3.  Current HA and DR requirements, (which is not the same as features/products that are in use.  Find out what the SLA, RPO and RTO requirements to be met.)
4.  Automatic Workload Repository, (AWR) Report that covers as much workload as possible.  One-week minimum and try to capture month ending or other critical processing if possible.
5.  Database size, as it’s not included in the AWR.

Architect

Using the first 3 in the above list, build out an architecture model that meets the environment requirements.

• This should include host VM, networking, application VMs for all applications that need to be included as part of the migration.
• Any networking requirements, (such as ExpressRoute) should be included.
• If HA is required, look into solutions around PaceMaker and SIOS, as Oracle RAC is not supported on any 3rd party cloud.  Oracle Active DataGuard and it’s automatic fast-start failover technology can often support this requirement, too.
• Don’t forget about Availability Zones in Azure and regional deployments, (LRS vs. ZLRS vs. GRS and RA-GRS) It’s worth the time to understand this part of Azure as an IaaS DBA.
• Build out a VM with an RMAN  repository.  Oracle DataGuard is available for DR and decide if Azure Site Recovery for VM snapshots is an option or a third party solution such as Azure NetApp Files or Commvault to have database consistent snapshots available.  Archaic backup solutions is a common downfall that should be easily worked around.

Review the Database

Once this is complete, then it’s time to see the health of the database and what needs to be potentially addressed before and as part of the migration.

Using the one-week, (or even one month if available.  8 days is default for the AWR retention on an Oracle database) report, collect the following information about the database:

1. Basic database information:  RAC/Single Instance, multi-tenant, OS version, database version, host memory, CPU/Core
2. Performance information:
   1. DB Time/Elapsed Time
   2. CPU % Busy
   3. SGA/PGA
   4. Read and Write IO Throughput and MB per second
   5. DB CPUs

I’ll point you again to the Azure Oracle sizing tool that uses an AWR report to translate an Oracle workload and size it out for Azure.

Review the following in the report:

• Top Events, focusing on those over 10% of DB Time spent
• Elapsed Time for SQL, focusing on those that are significant
• Look for performance impacts that will grow exponentially once the database moves to the cloud.
  • Queries that have large benefits with small amounts of tuning.
  • Poor logic in processes that need to be simplified.
  • Any physical tuning in the way of mviews, indexing, partitioning.
• Look for processing that has no need to run
  • space advisor job is a common high resource use feature that most DBAs don’t rely on.  Running nightly is a waste of resources.
  • Default stats collection on a large database that may do better as a more defined process to give more optimal performance.
  • Held over jobs that no one realized were running.
• Latency on system or sys objects
• heavy latency on background processing
• Review SGA and PGA advisors to locate what values should be vs. what they currently are.  Ensure that correct sizing is built into migration architecture sizing.
• Review the parameters and
  • Document any and all parameters starting with an “_”.  Ensure you understand the reasons for an underscore parameter and if they are required with the version or migrated version of database.
  • The goal is to have a default set of parameters and none that are outside of default ones unless they address a very clear bug and have been approved by Oracle Support DIRECTLY.
  • List out any parameters that are of interest, such as, but not limited to:
    • auditing
    • encryption
    • control file copies retained
    • database block size anything other than 8k
    • Any compatibility parameters below current database version

From this information, a list of recommendations can be created, broken down into three categories:

• Low-Effort Fix
  • Disabling unused jobs
  • Resizing PGA/SGA
  • Collecting Fixed/System Stats
  • Physical tuning options, such as indexes, etc.
  • Updating online parameters in spfile
  • Address latency on sys/system objects
• Medium-Effort Fix
  • Patching database to latest version
  • Researching and removing bug parameters from spfile
  • Some code optimization
  • Create new database in the cloud at 8k and importing in previous database.
• High-Effort Fix
  • Refactoring poorly designed complex code.
  • Remove compatibility parameters
  • Upgrading database to recent version from much earlier version

 

Fix Before You Shift

Many of these tasks the customer will want to correct BEFORE they migrate.  I think it’s easy to think they’ll migrate and upgrade in one step, but what will occur is confusion on what is the culprit behind performance and accessibility.  This is one of the most common causes of cloud migration failures is not separating technical debt from the migration project.

Address any issues around compatibility, versioning and patching BEFORE migrating to the cloud.  This will significantly decrease time while troubleshooting issues and increase the success for the migration to the cloud.

Tools to Ease the Transition

Ensure you bring over your Oracle tools with you-  there’s nothing keeping you from building Oracle Enterprise Manager 13c on an Azure VM.  I have clear instructions for this and am always glad to share.  The only management pack that I’d advise adding to the Tuning, Diagnostic and Cloud ones that would be expected, would be the Lifecycle Management Pack to simulate some PaaS features in the Azure cloud.

The Lifecycle management pack would offer you the opportunity to automate some of the patch management, scan for IP addresses to automate identification of potential targets and other advanced features of this infrastructure tool.  It also results in the Oracle DBA working with the tools they already know, which makes the cloud transition an easy hop, skip and jump for us.

Make use of your existing BASH scripts-  just because you’re going to Azure doesn’t mean you give up your Linux systems.  Azure is just as much Linux as it is Windows these days, so take your shell scripts with you and update them, recycling them to keep as much of your environment as it was initially.  I happen to use the Azure Cloud Shell with Azure cloud storage as my location for all my scripts and the Cloud Shell becomes my “jump box” to all my Linux VMs.  Make it easy on yourself.  There is no reason to reinvent the wheel.

Hopefully this was another reminder of how easy it is to work on Oracle on Linux in Azure and if you have any questions, definitely reach out.  I’m always glad to help!