Jumping from Exadata to Cloud? Let the Migrator Beware

    By: James Czuprynski on Oct 05, 2018

    By Jim Czuprynski and Bert Scalzo | Edited by April Sims

    Synposis. Numerous Cloud providers continue to accentuate the positive implications of moving Oracle databases from enterprise systems like Exadata to a Cloud-centric environment such as Amazon AWS, Microsoft Azure, or the Oracle Cloud. However, promises of lower licensing costs, improved application workload performance, and simpler system governance and orchestration have often been dashed when reality sets in. Join Bert Scalzo and Jim Czuprynski, Oracle ACEs and experienced Oracle database administrators (DBAs), for a casual give-and-take on what they have recently seen in the current Cloud marketplace … as well as some timely advice for considering what you’ll need to do when moving to the Cloud.

    Jim: I hear that recently you’ve been helping people move their Oracle databases to the Cloud. Have you identified any patterns or trends of note?

    Bert: Yes, actually I’ve observed three main trends worth mentioning.

    First, it’s surprising that most Oracle DBAs are new to the Cloud and therefore do not fully understand all the deployment options available to them. Moreover, those options continue to evolve at a rapid pace as the various Cloud providers continue to leapfrog each other with regard to new capabilities seemingly on a quarterly basis.

    Second, many IT organizations with Oracle databases running on enterprise systems seem to be looking for an Exadata alternative via the Cloud, whether they have deployed their databases as multi-instance Real Application Cluster (RAC) environments or a large single-instance. I can’t say with any certainty why this objective presents itself frequently, other than it seems to be part of the overall cost reduction that organizations assume they will obtain by moving to the Cloud.

    Third, as IT organizations attempt to move their database from on-premises Exadata to non-Exadata in the Cloud, they unreasonably expect acceptable application performance results without doing anything. They seem to forget that the loss of Exadata features such as Smart Scan, query offloading and storage indexes almost always requires revisiting their database’s logical and physical design, including the partitioning and indexing schemes they’ve deployed (or haven’t deployed at all!).


    "As IT organizations attempt to move their database from on-premises Exadata to non-Exadata in the Cloud, they unreasonably expect acceptable application performance results without doing anything."


    Jim: Can you explain what kind of issues IT organizations are encountering when they attempt to make the transition to a Cloud-based strategy?

    Bert: While most senior DBAs have years of experience selecting and configuring physical hardware and virtual machines for hosting their databases, for many DBAs the whole concept of running databases and database applications within a Cloud environment is still relatively a new thing; however, this shouldn’t be seen as criticism, just an observation of how much all of us still have to learn about this brave new world. With that said, let’s discuss the typical first choice that needs to be made: what image type and size should be chosen. Unfortunately, all of the Cloud vendors offer many different options for configuration of the underlying compute nodes and storage, plus the choices continue to evolve at a rapid pace.

    For example, here are the choices that Amazon AWS offers, which should make clear just how overwhelming this can be. Should the DBA select a “General Purpose” image type for non-special or typical databases? And if so, how does one choose among the numerous image sizes? What if the DBA will be using in-memory tables, does that then necessarily mean selecting a “memory Optimized” image type? Moreover if the database is very large such as with a data warehouse, does that indicate utilizing a “Storage Optimized” image type? Finally what if you desire to use in-memory for portions of a data warehouse, how do you select an image type to accommodate both special needs? Confused yet? Now how do these plethora of options compare or map against the Exadata you might be trying to replace?


    Table 1. AWS Cloud Options Available

    Exadata to Cloud_Table1.PNG

    If this was not challenging enough, the DBA must then choose the networking and storage options. But not all choices work with all image options, so the DBA next has to navigate this complex chart to understand exactly what configurations are possible. And as Table 2 below shows, the complexity doesn’t end there; you still have to decide upon what type of networking and storage setup you desire. The defaults may suffice for simple development or basic functional testing, but for stress or acceptance testing one needs to select from these cloud options with as much attention to detail as if ordering hardware when doing on-premise depolyments. While not everyone may require NVMe disks, it’s just as probable that all EBS storage only will suffice in order to maintain performance and for both current and future needs. Of course the selections from Table 2 must be weighed against costs, as well.

    Table 2. AWS Cloud Options Available

    Exadata to Cloud_Table2.PNG

    * The root device volume must be an Amazon EBS volume.

    Confused yet? Now remember that both Microsoft Azure and Google Cloud offer similar smorgasbords of very complex options to choose from. Plus all of these cloud vendors continue to evolve the options available and their various bundling. What you picked last month may no longer be the best choice this month. You simply must review all the current choices whenever you deploy that database to the cloud.

    Jim: Your experience jibes with mine as well, Bert. I taught the Exadata Database Machine administration classes for about four years to about 200 Oracle DBAs and even some of the Oracle sales teams starting with X2-2 back in 2006. In those early days, we strongly recommended discarding indexes that had been put in place purely for improving selectivity for queries – or at least making them invisible for a while when making the initial migration to Exadata and then discarding them once workload performance throughput improvement was proven.

    Whether Exadata or Cloud, Be Prepared to Adjust. You, Too, Developers.

    Jim: I remember teaching a group of DBAs from a large insurance firm with a huge data warehouse who had complained about their Exadata environment’s performance. I offered to help with some ancillary training and consulting. During the initial “meet and greet” conference call with their lead data architect and CIO about their issues, I asked whether they had followed the recommended best practices at the time – scrutinizing unnecessary indexes, making sure their table extents conformed to multiples of the 4MB ASM disk group AU size, and so forth – and found out that they’d done actually followed none of them.  

    Needless to say, I felt a bit like the psychiatrist who mistakenly took a wrong turn into a Star Trek convention hall: “So much to do, so little time.” I eventually led a performance tuning workshop with their DBAs and their application developers to help them understand how to wring the best performance from their Exadata environment, and claims reporting performance improved significantly afterwards.

    Bert, you also mentioned that you’re seeing many people looking for an Exadata alternative in the Cloud. What exactly are they looking for and why?

    Bert: My opinion is that most IT organizations on older generation Exadata database machines – say, the X4-2 and X5-2 line  must now either decide to upgrade to the current generation Exadata machines like the X7-2 line or find another alternative. Don’t get me wrong  this isn’t a criticism of Exadata; rather, it’s simply human nature to investigate potential alternatives when contemplating the time and effort that typically goes into a major upgrade. These organizations seem to hope that simply moving to the Cloud with its elastic, on-demand capacity can accommodate their performance requirements.

    This dilemma is exasperated by all the Cloud choices mentioned above available to DBAs, many of who have yet to acquire sufficient experience or adequate time to benchmark their current application workloads so that they can formulate the best possible decision. However, I do think that with proper preparation and expectations being defined, these people are exercising prudent planning by investigating all their options – including those in the Cloud.

    I might even suggest that this is no different than in the old days, circa 1990’s or early 2000’s, when DBAs would compare all the server and storage vendor hardware combinations possible. It’s just back then we were comfortable with such comparisons. It’s likely that in a few short years we’ll be far more comfortable with this new way of doing things.

    "With proper preparation and expectations being defined, these people are exercising prudent planning by investigating all their options – including those in the Cloud."

    Expecting Performance Improvements Without Adequate Cloud Experience

    Jim: That answer mentions expectations which you quoted as part of the third issue: IT organizations attempt moving their database from on-premises Exadata to non-Exadata in the Cloud, yet they unreasonably expect equal or at least acceptable application performance without making any changes to their databases. Can you provide some examples of what you’ve seen?

    Bert: Let’s start by reiterating precisely why Exadata is such a great system for delivering extremely fast performance: the separation of database operations into essentially two parts, the database and storage servers, plus all the “special sauce” mechanisms such as Smart Scan, query offloading, and storage indexes. It’s been designed from the ground up with both hardware and software to expedite Oracle database processing. Some people may drop indexes when they make the move to Exadata, plus they also may create fewer (or no) indexes as they design new database objects on Exadata. They do so to properly leverage Smart Scan, offloading, and storage indexes.

    So when they try to move off Exadata, they should certainly expect to review all their database object designs: new or different indexes may be required, new or different partitioning may be required; and database configuration changes may also be necessary. Furthermore, the same types of changes might be designed differently depending on the Cloud choices made. Finally, it might be necessary to leverage some new or different database features not previously used like placing tables within Database In-Memory) in order to overcome the loss of Exadata’s advanced capabilities.

    The key point is that it’s simply unreasonable to move a database from Exadata to the Cloud with no modifications and expect acceptable results. I had one customer where their test workload ran in two hours on Exadata, five hours or 2.5X slower on a single large instance in the Cloud, and seven hours or 3.5 slower on a RAC database in the Cloud. They had been expecting the RAC option to have come closest rather than last. So they simply gave up.

    I honestly believe that with proper review of the Cloud options they had selected - as well as reviewing database instance configuration, partitioning, indexing, statistics collection, and other basic tuning steps - we could have likely achieved a large, single instance in the Cloud that was far closer to the Exadata time. However, you must be willing to expect to totally re-architect your deployment when undertaking such a major migration. The bottom line is that you cannot simply move off Exadata and scale a Cloud image to meet it without doing lots of homework and hard work. There’s a reason why Exadata commands a premium.

    Jim: I hear you, Bert. The massive parallelism that the huge number of processors provide in even a two-node, eighth rack X7-2 environment are often misunderstood as well. When combined with all the features of parallelism like partition-wise joins and partition pruning, Exadata tends to make extremely short work of divvying up workloads that can leverage partitioning. Many shops, however, seem to have ignored these basic shifts in strategy for Exadata performance … and your experience, Bert, appears to be the result.

    It’s also important to really understand how all the different features of the Exadata “stack” – including Smart Scan, storage indexes, Smart Flash Cache, SFC Logging (for OLTP applications), and even how hash joins are transformed into Bloom filters that relieve the need for index usage – integrate to provide superior performance for just about any workload.

    Wrapping It All Up: Choose Wisely To Avoid Disappointment

    Finally, we should note that based on our mutual experience, Exadata itself isn’t always a cure-all. As Jim has noted in his presentations this year on using Database In-Memory in concert with Exadata, it’s not unlikely to encounter some queries that will still not obtain any performance benefits even when the features we’ve mentioned are enabled and recommended guidelines for Exadata have been fully implemented. For example, a query which leverages star transformation – especially when the database model has been tuned specifically for that – is likely to perform differently when the database is moved to Exadata and ancillary bitmap join indexes are eliminated. Of course, the solution is to test everything in as realistic a fashion – hopefully by reproducing the precise application workload(s) with a tool like Oracle Database Workload Capture and Replay before making that final decision to shift to Exadata is undertaken.



    About the Authors

    Bert Scalzo is an Oracle ACE, blogger, author, speaker and database technology consultant. He has a BS, MS and Ph.D. in computer science, an MBA, and has worked for over 30 years with all major relational databases, including Oracle, SQL Server, DB2 LUW, Sybase, MySQL, and PostgreSQL. Moreover, Bert has also has worked for several of those database vendors. He has been a key contributor for many popular database tools used by millions of people worldwide, including TOAD, Toad Data Modeler, ERwin, ER/Studio, DBArtisan, Aqua Data Studio, and Benchmark Factory. In addition Bert has presented at numerous database conferences and user groups, including SQL Saturday, SQL PAAS, Oracle Open World, DOUG, ODTUG, IOUG, OAUG, RMOUG and many others. He has written for Oracle Technology Network (OTN), Oracle Magazine, Oracle Informant, PC Week (eWeek), Dell Power Solutions Magazine, The LINUX Journal, LINUX.com, Oracle FAQ, and Toad World. Moreover Bert has written an extensive collection of books on database topics, focusing mainly around TOAD, data warehousing, database benchmarking, and basic introductions to mainstream databases. 

    Jim Czuprynski has nearly four decades of professional experience in his career in information technology, serving diverse roles at several Fortune 1000 companies before becoming an Oracle DBA in 2001. He was awarded the status of Oracle ACE Director in March 2014 and is a sought-after public speaker on Oracle Database technology features, presenting often at Oracle OpenWorld, IOUG COLLABORATE, ODTUG Kaleidoscope, Hotsos Symposium, Oracle Development Community tours, and Oracle User Group conferences around the world. Jim has authored over 100 articles focused on facets of Oracle Database administration to his credit since 2003 at databasejournal.com and IOUG SELECT. He has also co-authored four books on Oracle database technology. Jim’s blog, Generally … It Depends (http://jimczuprynski.wordpress.com), contains his regular observations on all things Oracle.

    Released: October 5, 2018, 11:23 am | Updated: April 3, 2019, 1:08 pm
    Keywords: Feature | SELECT Journal | cloud | cloud migration | Exadata | SELECT | SELECT Journal

    Copyright © 2019 Communication Center. All Rights Reserved
    All material, files, logos and trademarks within this site are properties of their respective organizations.
    Terms of Service - Privacy Policy - Contact

    Independent Oracle Users Group
    330 N. Wabash Ave., Suite 2000, Chicago, IL 60611
    phone: 312-245-1579 | email: ioug@ioug.org

    IOUG Logo

    Copyright © 1993-2019 by the Independent Oracle Users Group
    Terms of Use | Privacy Policy