Terraform Modules Simplified
Terraform is probably already the de-facto standard for cloud deployment. I use it on a daily basis deploying and destroying my tests and demo setups ... Read More
Oracle ExaCC Gen 2 new features and improvements
Some time ago after the last Oracle Open World, Christine Kivi wrote a blog stating that this is not “your father’s Oracle” anymore. The rapid development and continuous improvements in the Oracle Cloud are one of the signs that Oracle is changing. The generation 2 Exadata cloud at the customer (ExaCC) was released on that last OOW 19 and initially had some limitations in options and interface. Oracle team promised to fix the issues and provide new functionality, planning some major updates in the next calendar year (2020). And so far as I can see Oracle team is working delivering the promised. Here I will try to review some of the new features implemented for the last several months. This is going to be a relatively long post. You can go to the bottom, read the summary and read in detail only about changes you are interested in.
Let’s start from March 31 when shared Oracle homes feature was introduced to the ExaCC Gen 2. Until that time we were able to create only one Oracle database per home and it put some limits to the potential number of the databases on the environment. After making the homes shareable it allowed to reduce the usage of the local file system and potentially reduce management overhead. It looked like a simple change but considering all the required updates in internal tools responsible for creating, updating, cleaning and patching the database and changes to OCI console it didn’t look like a small fix. Now you can create multiple databases using the same home but keep in mind if you want to patch the home you will need to update all containers using it. Also, be aware of the location for TDE wallet and dedicated sqlnet.ora and tnsnames.ora for each database.
[oracle@virt1 ~]$ cat testdb01.env | grep TNS TNS_ADMIN=/u02/app/oracle/product/19.0.0.0/dbhome_2/network/admin/testdb01; export TNS_ADMIN oracle@virt1 ~]$ srvctl getenv database -db testdb02 testdb02: TNS_ADMIN=/u02/app/oracle/product/19.0.0.0/dbhome_3/network/admin/testdb02 [oracle@virt1 ~]$
In May the improvements continued and we got some changes in the interface and functionality. One of the major changes was the option to choose a character set for your container database. In some cases, it is extremely important for earlier than 12.2 database releases. If you have 11gr2 or 12cr1 databases to migrate you have to be able to choose it. The option was theoretically available even before using “dbaasapi” tool but it didn’t work perfectly well for me. After adding support for the console it was working fine from both interfaces whether it was Web GUI or “dbaasapi” tool.
One more update was announced on the same day in May and was related to the local timezone. It allows you to specify a timezone for your Exadata infrastructure during creation. The default time zone before that was UTC.
The next update came about a month later in June and included two major updates in functionality. The first one was the long-anticipated option to create multiple VM clusters on ExaCC Gen 2. Let me explain in a couple of words what it means. The ExaCC behind the scenes is built on virtualized Exadata where host machines (Dom0) and storage managed by Oracle and the VM clusters (OVM based DomU) are managed by the customer. The initial release of ExaCC generation 2 allowed us to create only one VM cluster per machine. It means the VM (DomU) on each compute node was taking all available memory, local filesystem etc. With the update, you can virtually split your ExaCC to several VM clusters segregating network, storage and access for different environments. The change introduced new features in the OCI API and Web GUI console interface for the ExaCC.
We can specify CPU, Exadata storage, memory, local filesystem size per cluster. But it is not only that. If you try to go to the page of scaling the existing cluster it has all those values. So, you should be able to scale up and down OCPU, memory and storage allocation for your VM.
One more feature was introduced on the same day in June – offline OCPU scaling for VM clusters. It provided the ability to scale your OCPU allocation even when you don’t have connectivity to OCI. Of course, you will not be able to scale from Web GUI but you can use the “dbaascli” utility to do that. The command “dbaascli cpuscale update” will put a new number of OCPU per VM it will be synchronized with the Web console as soon as you get your connectivity back. So far it is available only in selected regions such us-ashburn-1, ap-hyderabad-1 and sa-sanpaulo-1.
The next major update came just a week after the previous one and made the Oracle Autonomous database available on ExaCC. That was a long-expected change promised when the generation 2 ExaCC was revealed to the public on the Oracle Open World 2019. The update allows us to create Autonomous Exadata VM Clusters and deploy Autonomous Container Databases and Autonomous Databases. I am sure most of us are aware of Oracle Autonomous databases but if you’ve missed it you can check it here. The deployment is similar to what you can have with Oracle Autonomous on dedicated Exadata Infrastructure. I have to note that we cannot mix non-Autonomous and Autonomous VM clusters on the same ExaCC. So, unfortunately, we cannot deploy a non-autonomous VM cluster and try the autonomous on the same ExaCC. The autonomous deployment will take all rac resources and after the deployment, we can have up to 12 Autonomous Containers. The max number of the actual Autonomous databases varies from 100 on a quarter rack ExaCC to 400 on the full rack. So the number is roughly the same as the number of available OCPU. I think it is a very promising step and look at that as the second step to proper PaaS databases.
The next update on July 14 enabled per-second billing for OCPU usage on ExaCC and a week after the same update came for Autonomous on ExaCC. Now, instead of paying for an hour even if you scaled up for several minutes, you are paying just for the time you were actually using the OCPU. The minimum billing is a minute, so if you’ve scaled your OCPU up for less than a minute you pay for a minute at least. I am not sure even if it is technically possible to scale up or down for less than a minute. I seriously doubt that.
The last known and publicly available update on July 28 introduced the new interface feature allowing you to patch GI and database homes from the OCI console. You need to have all nodes up and running and for a database, all instances up to perform the patching. It is not too much different from the requirements for the dbaascli tool. The main benefit I see is the ability to use Oracle OCI API to embed it into the other maintenance procedures in your OCI environment.
As a summary I am providing a list of changes in chronological order:
- March 31, 2020 – Shared Database Homes for Exadata Cloud at Customer Systems.
- May 7, 2020 – Character set and national character set can now be configured.
- June 13, 2020 – Create and manage multiple virtual machines per Exadata system.
- June 13, 2020 – Scale OCPUs without cloud connectivity.
- June 23, 2020 – Oracle Autonomous Database.
- July 14, 2020 – Per-Second Billing for OCPU Usage.
- July 28, 2020 – Oracle Grid Infrastructure and Oracle Database Patching.
It looks like the pace is gaining momentum and we are getting new updates almost every week now. What are we going to get in the next coming weeks? Let’s see.
More from this Author
New Kids on the Block – Rocky Linux
If you’ve been following the recent changes in the Linux world you probably remember how Red Hat and Centos announced in December 2020 that the ... Read More
