Oracle

This is my submission for JoelKallmanDay, a community day planned by Tim every year on October 15th as a tribute to Joel Kallman. It is an old story that I am sharing. There was a customer that was using a Loan Management application and the back end was an Oracle database (a single instance, if I remember correctly). The hardware they were using was nearing EOL and they got an Exadata and moved the database there. They had high expectations and were expecting the application to be blazingly fast; it was a brand new Exadata, after all. But the experience was rather disappointing. There were application hangs, slowness and user complaints. When we (as a team) looked at the AWS/ASH reports from the system, there were things that needed immediate fixes. There were queries doing full tables scans and returning only a few rows. Then there were sequences where the cache size was set to zero. It appeared that the application was never tested with a RAC database. Creating the missing indexes and adjusting the cache sizes of the frequently used sequences appeared to be a low hanging fruit and it actually was. Fixing these two things gave a reasonable amount of relief. Of course, there was more that needed to be done to bring things on the track. ...

(Image from here) In part2, I summarized the Exadata platform based options available for DB deployment on OCI. In this post I will talk about the options available for deploying MySQL on OCI. MySQL from Oracle is available in two different flavours: Community Edition which is Open Source and two types of paid editions Standard and the Enterprise Edition. Enterprise Edition comes with additional features like TDE, Enterprise backup, HA etc. Both the Standard and the Enterprise Editions come with Oracle Premier Support. As it is with the Oracle database, MySQL can also be run as an IaaS option where you provision a compute instance, attach some block storage and install/configure the edition you need. There are options available on OCI Marketplace as well. ...

I was thinking about this while sitting in Vivek’s session at OCYatra in Gurgaon. He was talking about the techniques one can use to optimize badly performing SQLs. But there does exist the other side of this story i.e. throwing hardware at a performance problem to fix it. Of course, it works till a point only and it can’t solve every damn performance problem out there. But it is relatively easier to do (costs money, though) and depending upon where you are hosting your workloads, can be quicker too. You see CPU usage going up or users complaining, simple thing to do is to throw more cores at the database. If the system is CPU starved, it is going to give some temporary relief and you can control the situation. Same can be the case with the storage IOPS. In some extreme cases, you could even migrate the database to a more powerful hardware. With systems like Exadata being around which can make even a bad SQL do fairly well, this lever becomes even more powerful. But is it sustainable or is it the right way to deal with these kind of issues? ...

In part1, I summarized the options available for DB deployment on OCI and described the Base Database Service. In this post I will talk about the second group i.e. Exadata platform based services in detail and explore the possible deployment scenarios. When it comes to Exadata based options, it get a little complex as there are multiple ways to do it. To reiterate, there are two ways the deployment can be done. One is in the public cloud and another one is the private cloud (Exadata Cloud@Customer aka ExaCC) where the hardware is deployed in the customer’s data center. Let’s now explore the different offerings. ...