by Joe Grant (@dba_jedi), Principal Architect
INSTALLING ORACLE WHEN REQUIRED BY COTS APPLICATIONS
Over the last few months, I have had several clients deploying Oracle Database for the first time, which is unusual for me. They were all deploying commercial-off-the-shelf (COTS) applications that required the use of an Oracle database as their data source and/or repository. As this was their first time deploying Oracle, they obviously had many questions. I told them “you now have the privilege of death by 1,000 decisions when purchasing, planning for, and deploying the Oracle Database”.
The clients in question relied heavily on their third-party application vendors, but the vendors were not able to answer all of their questions. Additionally, third-party vendors often have very little interest in providing the best answer for the end user, but rather give the answer that causes lowest number of support cases and/or other non-paid time to the client. As a result, third-party vendors may offer generic answers and support options that tend to be very expensive to implement.
But rather than focusing on that fact, let’s instead try to answer some of the 1,000 questions that need to be answered when deploying Oracle for the first time. I admit up front that this will not answer all of your questions, but it hopefully will at least get the ball rolling.
The first question I ask in this situation is “are there any options other than Oracle?”. If you do not already have an Oracle Database deployed in house, then implementing Oracle for a new application can be very overwhelming. If the app vendor supports any other database platform, especially if you already have that solution in place, I recommend going with that rather than installing Oracle.
Choosing the Best Edition
While there are many things to review, we have to start somewhere. For new deployments, there are two editions to consider: Enterprise Edition (EE) and Standard Edition 2 (SE2). Yes, past versions included Standard Edition and Standard Edition One, but as they are no longer offered, they are not relevant for new deployments.
If the application vendor requires EE, push back and ask why. Under most circumstances, SE2 will work and there are significant cost savings when using SE2. The variation of features (and their resulting costs) between the two editions could be its own article. Here is a quick reference on cost – EE counts cores to determine a number of processors, and SE2 simply licenses the physical processor regardless of the number of cores. An example for an x86_64 server with two sockets with 12 cores per socket is below.
EE – would require 12 processor licenses @ $47,500 each
SE2 – would require two processor licenses @ $17,500 each
Again, there is much more to choosing the best edition than just cost, but if SE2 will work, it can save you quite a bit of money. So, be sure to ask the app vendor which edition they require rather than just recommend.
Licensing Metrics – Processor & Named User Plus
Oracle offers two metrics for licensing – processor (as described above) and Named User Plus (NUP). When licensing by the processor metric, any number of users are allowed to use the database, or the software that accesses the database. When using the NUP metric, count the number of users who will be using the database (or the software accessing the database).
When licensing using the NUP metric, there are per processor minimums that need to be respected. You still count the number of processor licenses that are needed, and apply the per processor minimums, then count the number of users, and pay for whichever count is higher.
For EE, the minimum is 25 NUP licenses per processor. For SE2, the minimum is 10 NUP licenses per server. The break-even point is 50 NUP licenses per processor.
When counting users, it is all users “authorized” to use the system and not a concurrent count. Three shifts of 20 people would count as 60 users, not 20. When using an application to “front end” the database, you count all users of the application (not only the few application accounts that actually connect to the database).
The last point is that you only need to count a user once. Even if you have multiple databases in the environment, the user only counts once. If the user has multiple accounts within a database, they also only count once.
Determining the Version to Install
Once the edition has been determined, the next decision to be made is which version to install. The app vendor should have a version requirement, which is not usually the newest version available. This is due to the fact that the vendor needs time to certify that nothing within the database changed how their software works. The usual recommendation is to install the newest version allowed by the application vendor.
Another item worth mentioning is that Oracle version numbers can be a pain to deal with.
Starting in 2018, Oracle stole a page from Microsoft and started numbering their releases based on the calendar year. But, for 2018 and 2019 the release numbers were already set, so under the covers 18c is actually 12.2.0.2.0 and 19c is 12.2.0.3.0. Note that the 19c version is the terminal release for the 12.2 series. Starting with 20c however, the version under the covers starts with a 20. There is a conspiracy theory among some of us, who are not that invested in conspiracy theories, that Oracle did this simply to avoid having a version 13 of the database.
For database software there are five fields in the version number. They are:
- Major version
- Previously, maintenance release number, for 18c + release update
- Previously unused, for 18c + release update revision
- Previously, increment version (patch set)
- Used to denote which quarterly patch has been applied (this is a YYMMDD date string)
For example: 12.2.0.1.200414 and 18.10.0.0.200414
Confirming Operating System Certification
Oracle maintains a certification matrix for which operating systems are certified for which versions of the database software. While this information can be found in Oracle docs, the most up to date information is posted on the Oracle Support site, which creates a bit of a chicken and egg issue. When trying to use the Support site to get the information, you need to have an active support agreement before you get a Support login. To get around this issue, work with Oracle Sales or your app vendor as needed.
Windows and Linux are supported operating systems for the Oracle database. Once you know your database version, you back into which OS versions are allowed. Again, the basic recommendation here is to use the latest version of the OS allowed, as it saves on upgrades later. AIX and Solaris are also supported if you really want to use them.
Deciding on a Platform
This decision can be a lot more complicated. You have your basic options of physical servers, private cloud, and public cloud options. You also have the options of x86_64, POWER, and SPARC. Depending on how you choose to deploy, and on what physical servers, your licensing fees can get quite expensive, since you are required to license Oracle software anywhere the software is installed and/or running.
Just to keep things simple, let’s assume x86_64 deployments for our scenario.
You can deploy on physical servers, just like we all did before virtualization was much of a thing. In that case, counting licenses is simply, how many cores/processors are in the system? How many servers need to be licensed?
As most of you will likely deploy into a private cloud, or more simply described as a vSphere cluster. There is quite a bit of Oracle licensing misinformation on this point, and in my experience very few actually know the real answers. But a good place to start is the requirement of licensing anywhere software is installed and/or running. The main source of misinformation is the definition of the word “installed”. A quick example – if you have only one VM, you do not need to license the entire cluster. If someone is telling you something contrary to that statement, call us and we can help clear up any confusion.
For public cloud platforms, there are simply too many options with too many different rules that have significant consequences. Each public cloud vendor has slightly different rules associated with it, and those rules all have a different impact on cost. Currently with the Oracle Cloud Policy, if you are using AWS, Azure, or Oracle Cloud it is possible to license at the VM level rather than the host level, but it is not for the faint of heart. As of the current version of the policy, any cloud provider not listed specifically is treated as a private cloud.
Right-Sizing Your Resources
What resources will you need? This is the tough one to answer, as it is a new deployment and everything is an estimate or a complete guess, whichever applies. Most app vendors will offer some sizing guidelines, but be aware that they tend to be very inflated. This stems from the fact that they make recommendations based on what makes life easier for them, not necessarily what is in your best interest.
CPU sizing can have considerable consequences for costs. So, try to get real estimates, and have the vendor provide details of how their estimates were developed, and ask them for references from other customers. After all, once you purchase an Oracle license it is yours. While you can always buy more, you are not going to get a refund if you over purchase.
Planning for HA/DR
Planning for high availability (HA) and disaster recovery (DR) can add significant cost and complexity to your deployment. There are simply too many things to cover in this article, but here are a few things to remember:
- License anywhere the software is installed and/or running.
- In virtualized environments, do not pay for servers where the database software is not actually installed or running. You do not have to pay for all servers in a cluster.
- Your app vendor is not necessarily your friend here, as they tend to offer solutions that make their life easier.
- Ask questions and make them provide real answers. Take after my kids who ask “why?”… a lot.
- The “Oracle” solution is rarely (ok never) the cheapest option.
- It is likely that you can fit Oracle, and your new app, into your existing HA/DR plans.
Determining Support Needs
While technically the decision to pay for support is an option, it is not much of one, so pay for support. Also, Oracle will include support for the first year, so it is not actually an option. Oracle charges 22% of your purchase price (after discounts) annually for support. Upon renewal, on average your support fees go up about 3-5% annually. You pay for support upfront, which means you pay for a full year of support today and it covers the upcoming year. Again, there is no refund if you choose to stop using support early. The good news is that a benefit of paid support is you are entitled to version upgrades, so you do not have to re-purchase in order to upgrade.
Summary
Deploying Oracle Database for the first time is not quick and easy. There a variety of considerations along the way that greatly affect how much a project will cost, as well as the level of effort necessary to actually deploy. The items discussed in this article are just the beginning of death by 1,000 decisions, and I hope that it has helped you get the ball rolling. If you have any questions about the process, please contact us as we are happy to help.
