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 Oracle cloud is one of the signs that Oracle is changing. The generation 2 Exadata cloud at 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 details 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 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 about 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 the 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 you 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 with using “dbaasapi” tool but it didn’t work perfectly well for me. After adding support for console it was working fine from the 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 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. Initial release of ExaCC generation 2 allowed 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 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 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 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 about 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 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 requirements for the dbaascli tool. The main benefit I see is the ability to use Oracle OCI API to embed it to the other maintenance procedures in your OCI environment.
As a summary I am providing 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.