Amardeep Sidhu's Tech blog

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. ...

So, you are looking to run a database on Oracle Cloud Infrastructure (OCI), right ? Great ! But then you login, and suddenly you are faced with a whole range of services that can feel a bit…overwhelming. It’s not always obvious which one’s the right fit, especially for someone new to the OCI database landscape. That’s why I wanted to start this series of posts where we will walk through all the options that OCI throws at us for deploying databases. ...

While provisioning compute instances in OCI, you may come across scenarios which need more memory and cores than what the standard shapes provide. Extended memory VMs are meant to solve that problem. Such VMs are able to access cores and memory across a single physical socket and it allows them to go beyond the limits of standard shapes. There are no additional charges for using this specific feature. Customer is charged on the basis of total number of cores and total amount of memory used. ...

Last week, got this issue reported by a DBA that he wasn’t able to su to oracle user from root on a Oracle Base Database VM in OCI. The login of opc user worked fine and he could do sudo su to root but he couldn’t su to oracle. When he did it just came back to root shell. [root@xxx ~]# su - oracle Last login: Fri Jan 12 10:20:38 UTC 2023 [root@xxx ~]# There was nothing relevant in /var/log/messages or /var/log/secure. I tried it for some other user and it worked fine. Then I suspected something with the profile of oracle user and voila ! The .bashrc looked like this ...

A customer is using an Exadata X8M-2 machine with multiple VMs (hence multiple clusters). I was working on adding a new storage cell to the configuration. After creating griddisks on the new cell and updating cellip.ora on all the VMs, I noticed that none of the clusters was able to see the new griddisks. I checked the usual suspects like if asm_diskstring was set properly, private network subnet mask on new cell was same as the old ones. All looked good. I started searching about the issue and stumbled upon some references mentioning ASM scoped security. I checked on one of the existing cells and that actually was the issue. The existing nodes had it enabled while the new one hadn’t. Running this command on an existing cell ...

A customer who is using an Exadata X8M-2 with multiple VMs had Smokescreen deployed in their company recently and they reported an issue that one of the Smokescreen decoy servers in their DC was seeing traffic from one of the Exadata VMs on a certain port. That was rather confusing as that port was the database listener port on that VM and why would a VM with Oracle RAC deployed try to access any random IP on the listener port. Also it was happening only for this VM. Nothing for so many other VMs. ...

I was working on configuring a new database for backup to ZDLRA and hit this issue while testing a controlfile backup via Enterprise Manager -> Schedule backup. It could happen in any environment. Unable to connect to the database with SQLPlus, either because the database is down or due to an environment issue such as incorrectly specified... If the database is up, check the database target monitoring properties and verify that the Oracle Home value is correct. The 2nd line clearly tells the problem but since the Cluster Database status in EM was green, so it took me a while to figure it out. Issue turned out to be a missing / in the end of ORACLE_HOME specified in monitoring configuration of the cluster database. The DB home specified was /u01/app/oracle/product/11.2.0.4/dbhome_1 instead of /u01/app/oracle/product/11.2.0.4/dbhome_1 /. ...

It was actually funny. So thought about posting it that sometimes how we can miss the absolute basics. This customer is using a virtualized Exadata with multiple VMs. One VM hosts the database meant to be used for dbfs and another VM connects to this DB over IB to mount dbfs file system using dbfs_client. One day VMs were rebooted and due to some reason the dbfs filesystem didn’t mount on startup. It went on for few days and they couldn’t mount it. One day I got a chance to look at it and the error they were facing was: ...

To put it in bit of an Indian context, database is not your daughter-in-law that you can blame it for every performance issue that occurs in the environment. But it does happen. Most of the time it is the database that is blamed for all such issues. Many times, the issues are in some other layer like OS, network or storage. Faced this issue recently at one of the customer sites where performance in one of the databases went down suddenly. It was a 2 node RAC on 12.1.0.2 running on Linux 7 using some kind of Hitachi SSD storage array. There were no changes as per DBA, application, OS and storage teams. But something must have changed somewhere. Otherwise why would performance degrade just like that. I & my colleague checked some details and found that something happened in the morning a day before. Starting from that point in time, the execution time for all the commonly run queries shot up. Generally speaking, when all the queries are doing bad and you are sure that nothing has been changed on the database side, the reasons could be outside the database. But being a DBA, it is not easy to prove that. We took AWRs from good and bad times and the wait events section looked like this: ...