This post concerns how you can employ an extremely resilient and high-performing architecture using the 19C SE database.
The original Oracle Standard Edition allowed you to have High Availability (HA) using the “Real Application Clusters” (RAC) option. This allowed you to install up to two instances of Oracle SE on two separate servers of 2 CPUs each. Then in SE1 (‘Standard Edition One’), Oracle removed that ability altogether, there was no HA option available. Once again, Oracle changed tact and with the release of SE2 (‘Standard Edition 2’), Oracle allowed the use of RAC again, but this time, only 1 CPU per server with a maximum of 2 servers (as SE2 cannot be installed on a server that has larger than 2 CPUs, the clustered servers is counted as a single server for licensing purposes by Oracle).
Therefore, you will understand that it is completely normal for Oracle to change the rules on what you can and cannot do or use with the database. As of 19C version of the database, RAC cannot be used with SE2. SE & SE1 editions of the database are also not available as of 19C, therefore it leaves users with a significant change ahead of them if they are not already on 19C. It also presents a fantastic opportunity to migrate to a high performing and highly resilient architecture.
The code base of the Enterprise Edition and Standard Edition releases of 19C are common, with the use of SE, there is a resource manager setting that only allows the database to consume a maximum of 16 Threads at any one time. Each CPU (sometimes referred to as ‘Socket’) has processing cores (‘Cores’) that can process a single thread of code execution. In the case of Hyper-threaded CPUs (which are the majority of server CPUs as this is dominated by Intel Xeons and AMD PCYC), then each Core can process 2 threads. Therefore, an 8 Core hyper-threaded CPU can have 16 Threads. Allowing for Threads to be consumed by non-Oracle workloads like the operating system and other tools or applications that may be running, employing a CPU of 12+ Cores will most likely result in processing capacity of 16 Threads being available to the Oracle database at all times. That is a lot of processing power!
Oracle Standard Edition is licensed by CPU, not by Cores like the Enterprise Edition database. The difference is drastic. Assuming a CPU that has 8 Cores, an Enterprise Edition database would have a perpetual license cost of 8 x 0.5 Oracle Core Factor (for licensing purposes) x AUD$83,836 including first year support. That is $335,344 whereas as only the single CPU for SE needs to be licensed, the 8 Cores are irrelevant, and this results in a license cost of $30,887. A very different outcome for 16 Threads of processing capability. The difference is even wider if you consider Enterprise Edition with RAC.
Another aspect worth noting is that the licensing of the Enterprise Edition database has to consider the Cores available to the database. This includes Cores that are used by the operating system and all other tools and programs on the server (or VM/Container). In our fictional example above, the database server might have 16 Threads available to it but because of other processes running (including the operating system), there might not be 16 Threads available at any one time. Whereas with Oracle SE, you can employ a larger CPU that has more than 16 Threads so that there is sufficient availability at any one time for your SE database.
The AMD EPYC CPUs are a perfect companion for this approach. These CPUs are considered more advanced than Intel by many and have a range of CPUs that have 12+ hyper-threaded Cores (up to 64 Cores and 128 Threads) and are available as single or dual core rack servers from Dell, HP and Lenovo.
Oracle permits the use of 19C SE across two separate servers of one CPU each with no restriction on the Cores. This is a fantastic opportunity to implement High Availability on the world’s leading database with throughput to match. You could point your applications to connect to the database through a load balancer to achieve High Availability that could tolerate a server outage. The below diagram illustrates a typical architecture:
Whilst Oracle Clusterware is available on Microsoft Windows and Unix/Linux flavours, we believe it is best deployed on Oracle Linux due to its low cost and high performance capabilities in an extremely stable operating system. It is installed as part of Oracle Grid Infrastructure.
Oracle refers to this as “SEHA”, Standard Edition High Availability. Combined with other technologies including high speed SAS SSDs or NVMe disks, fast network connections and single CPU servers that potentially may even use the lightning fast PCIe4 specifications and Oracle’s ASM disk management solution (another component of Oracle Grid Infrastructure), we can design and implement (or upgrade and/or re-platform) your current Oracle database to this modern and resilient architecture.
With Spatial & Graph and Data Mining also available as included capabilities on the 19C SE, the use of Enterprise Edition would only be considered in circumstances where other database options such as Partitioning, Diagnostics, Tuning, Advanced Compression or Advanced security are required. In regards to processing capability, the 19C SE database in a HA architecture will be able to meet many significant workloads, and combined with the ability to have Standby databases and low RTO backups, a comprehensive solution can be designed and deployed.
If you want to learn more regarding the architecture and designs of this post or any matter concerning the use of Oracle and Microsoft databases, please feel free to reach out to us at email@example.com or click here.