Maybe you have realized that when you deploy a compute instance in your favourite cloud environment that the “hardware” clock is set to UTC - which is the coordinated universal time. And that of course totally makes sense, since your cloud provider is operating a global business. That also isn’t a problem if you handle your times and dates in your Oracle database application properly with a timezone component. For this you can save time related data in the TIMESTAMP WITH TIME ZONE datatype. So you can easily at any time present the value in the desired timezone value.
Oracle lately introduced the Oracle Database Appliance Software Release 19.22 with the usual fixes and updates to all of it’s components. It also provides an eagerly awaited fix to the included ASR manager, so now you can use that again. But where’s light, there also may be some shadow. If you are using a newer version of PuTTY on Windows, a recent version of OpenSSH on macOS, you might get the following errors after patching the system to 19.22.
In the recent months I was involved in a large project that is run in Oracle Cloud Infrastructure and of course includes some Oracle databases on Exadatas. As per best practice I have set up an operations compute instance that is used to run maintenance scripts against the databases running on these machines. To use that I have installed SQLcl from the official Oracle Linux repositories because the tool would get updated automatically when the host is updated via os management. I also installed the instant client via the repositories for the same reason.
Recently I was restructuring my Oracle OCI private tenant to be only built using terraform. I mainly did this because I need to learn that beast for work but I am also interested in the technology by myself. Of course my main hosting machine for the blog is a nice little Ampere A1 VM that resides in a private subnet, let’s call it web01. The internet facing part is a free load balancer that handles all the TLS encryption. To access the internal VM via SSH I didn’t want to use the OCI Bastion service, because it is limited to a session duration of 3 hours and I don’t want to always create a new session when I’m working on the server.
The Good Recently I discovered a critical issue when installing a new Oracle cluster for a customer on Oracle Linux systems. The hardware are shiny new blade systems and I started with the latest and greatest software components which are certified for the Oracle Enterprise Edition and Real Application Cluster. Of course the OS would be Oracle Linux 8.7 with the famous Unbreakable Enterprise Kernel which is at version 7 since this year. In April 2023 Oracle relased the release update 1 which of course brings some enhancements and fixes. Business as usual as you would think.
When working with Oracle databases the common recommended methods to restrict the usage of cpu resources are the so called instance caging and hard partitioning using something like Oracle Linux Virtualization Manager. The last one comes with some resource wastage though, because you have to handle multiple operating systems for multiple databases. So let’s assume that is some sort of last resort for the licensing dilemma. Instead, many of us like to have multiple databases coupled together in one operating environment and want to have some measures to tame the herd. For that there are several layers where you can put constraints on your databases, beginning with limiting the number of sessions a database can handle. But to reduce a databases cpu usage to a specific load and/or a subset of your Multi-Core/Multi-Stocket system, there currently are two methods commonly used. Look at the end of this article to see how I implemented the testing method.