The involution of Standard Edition
Until the release of version 12.1.0.2, there were two “low cost” options for the Oracle database, Standard Edition One and Standard Edition, the second including RAC. SE1 allowed execution in up to two sockets and SE in a maximum of 4 with no cores limit in both cases. 12.1.0.2 brought the disappearance of SE1 and SE, and the presentation of SE2. Upgrading licenses to SE2 is necessary in order to update the software and apply new patches, at the corresponding cost to the owners of old licenses. SE2 imposes a limit of 2 processors, something that has already been a problem, for example, in clients with RAC over 2-socket servers. If you have 4 SE licenses for a production environment with a 2-node RAC with 2 processors each, you cannot upgrade to SE2 without previously modifying the hardware.Additionally, you must assume the price increase of the annual support, being the greater the economic impact on SE1 clients. In addition to the new reduced processor limit, since 12.1.0.2 SE2 it hasHard-coded a parallelism constraint for the entire instance of a maximum of 16 threads, thereby limiting scalability. The summary is a higher cost of licensing and support in exchange for restricting the processing capacity.
With 19c, it is possible that those who have evolved or acquired new licenses for SE2 with the intention of using RAC, may lose part of the value of that investment in the short term, the high availability and scalability of RAC, since 18c has the expiration date of first quarter of 2021 . From then on, there would be no new updates for that RAC. Moving to 19c would require a change of architecture and move to single instance (presumably at the same price).
Thus, if today we install the latest version available on-premise (18c) with RAC and buy new licenses for this environment, the life cycle of the solution will be less than 2 years, I may be buying a technology that will no longer be viable before to complete the expected repayment time.
What alternatives will Oracle give?
One possibility seems to be that it will be the recognition of SE2 licenses as a BYOL (Bring Your Own Licenses) option from the Autonomous Database, with a conversion that could be 4OCPUs for each licensed SE2 socket. If so, Oracle would be reinforcing the pressure on its customers to move to the cloud to compete mainly with AWS and Azure.
The cloud as a strategy
Oracle’s strategy is clear, bet on the cloud, specifically yours. Thus, these possible changes and license conversions would fit into this strategy of gaining a mass of customers in cloud services.
The cloud is today a large part of the present, and it will be even more so in the future, but at the moment there are still reluctance and technical limitations when it comes to moving to this type of service. In the case of a database, changing the model will imply additional changes in the form of performance and higher latencies, especially if we keep clients and application servers remote, which may not be acceptable to everyone.
The move to the cloud strategy also collides with the current bias of many customers. In the partner presentation webinar of the new 19c features that I was able to attend, one of the surveys conducted by Oracle was about the type of deployments that the customers of the partners we were attending are currently interested in.
18% of the attendees marked the cloud option, 36% on-premise, and 47% hybrid solutions, with all the ambiguity that this concept can become. It is an unreliable survey at a statistical level, and I do not even know the number of attendees, but it fits me in the daily life of our clients today.
This fact makes me think about how much of a solution (undoubtedly a lot) and how much of marketing cloud services, what changes arise in order to serve your customers, and what changes they make to mark the path you prefer them to follow.
In Oracle’s cloud vision, it is important to note that RAC is not supported by any cloud platform other than Oracle’s, yet another additional limitation on customer freedom of choice, similar to what happened with VMWare and support for virtualization and CPU partitioning recognition, a battle clearly lost by Oracle.
Next steps:
At this time, things seem clear, but they are not confirmed, and it would be very good news to discover that this interpretation is not correct and that we will be able to continue using RAC in 19c SE2, but there are several doubts to resolve in the short term:
Official response from Oracle. Is what we see in the documentation an error, and will we have RAC in 19c? At Arumel we are awaiting confirmation at a commercial level from Oracle Spain.
Availability of 19c on-premise. This will allow solving at least whether the SE2 installer allows deploying RAC. At the time of writing this post, only 19c is available in Cloud and Exadata.
RAC support for the 12c family. If it disappears, what happens to those who invested in licenses for a RAC installation over 12c with a life cycle that should end in 2026? Will this on-premise investment die 5 years ahead of schedule?
With the restrictions that we see these years, what is the future of SE2? Do we bet on Oracle as a “non-Enterprise” client or does it become a risk of a deck breakdown risk by the supplier when its strategy does not match that of the type of client of its products?
When you want to make a strong Oracle DBA career then you should be aware of database services and other database technology. Without having knowledge of Oracle internals, Oracle performance tuning, and skill of Oracle database troubleshooting you can’t be an Oracle DBA expert.
This expert DBA Team club blog always provides you latest technology news and database news to keep yourself up to date. You should need to be aware of Cloud database technology like DBaaS. All Oracle DBA tips are available in a single unique resource at our orageek. Meanwhile, we are also providing some sql tutorials for Oracle DBA. This is the part of Dbametrix Group and you would enjoy more advanced topics from our partner resource.
