My understanding is that Oracle DB licensing is based on number of cores etc. If you use virtual machines (e.g.ldoms) you need to partition it properly otherwise, in theory you have to pay based on the host machine.
Can anyone confirm I'm right here? And explain it in bit more detail (i.e. things like multipliers etc).
We've got 4 T5-4s running Solaris 11. Each has a number of Ldoms some running Oracle DB some not. At the moment its all a bit of a mess to be honest.
It's been several years since I encountered this, but it is based on number of cores and core type, on the base hardware, plus user count. So you do not get into serious licensing problems, there is a support group at oracle that works on this problem.
Do not try to figure it out by yourself. Oracle has the legal right to run unannounced audits on their product's installation and run modes.
They will send you software to run as the root user on Solaris. It creates two files, as I remember. Oracle analyzes the output and then gives you precisely what you require for licensing.
The reason it is a mess, IMO, is that you can purchase oracle under several different licensing regimes, e.g., per user seat versus per core. And you can play mix and match. We actually were over licensed and saved about $US90k per year.
Thanks Jim - its even more confusing when you've ldoms involved.
Of course, if you've got multiple ldoms on, say a T5-4, with only one of these ldoms running oracle you dont want to pay a licence for the entire server.
---------- Post updated at 08:44 AM ---------- Previous update was at 07:25 AM ----------
Thing is if its a physical server all well and good but how does it work with virtual machines?
You might have a physical host with, say 2 cores, but this translates to 16 VCPUs that the ldoms use. Support an LDOM runs Oracle, and is partitioned to use just 4 VCPUs how does the licencing work then?
I am not that fit in Sun/Solaris at all, so bear with me if this is not relevant, but:
In AIX there is "Live Partition Mobility", meaning you can transfer a running virtual system from one hardware to another.
You buy licenses based on the cores of the virtual machine (instead of the underlying hardware nodes) as long as this number of cores is absolutely fixed (we call this "capped mode" and it is highly unusual otherwise). But when the LPAR is LPM-enabled and you use that feature you suddenly not only pay for all the cores in the source system but also all the cores on the target system too. LPM can be a cost-intensive activity this way. You had a 4-core LPAR and moved it from a 64-core hardware to another 64-core hardware - 128 processors to license.
The problem is that DB/2 license politics is even weirder than that and you can't even tune the damn thing as well as Oracle. Perhaps best is to search for one of the freeware databases (Mariah, ...), but i have no idea how well they scale in real big installations. My biggest DB system (one LPAR!) has ~4TB of RAM and 128 12-core processors. You hardly have such a system available to test-drive an alternative DB.
I hope this helps.
bakunin
You are making it complicated. And I do not think you fully understand it. Neither do I.
Go to oracle. Call your sales rep if nothing else. Get help. Period. Anything else will cost you a bundle of money later on if you make a mistake. I'm not kidding. A neighboring (near New Mexico) utility did not get licensing straight because they "knew" how it should be. They needed to upgrade and had to get oracle's help. That's when things got financially ugly for them. Audited. The bottom line of the final bill would have set up all of the people whose usernames are red on this forum with magnificent retirement package. I think they compromised, I do not know for sure.
How else do you think Larry Ellison was able to buy his very own island?
Do not assume how you want to count usage, or what you think is logical.
In a nutshell you must :
Put a whole-core constraint on ldom -> using set-core for number of cores paid.
If you have say, 16 VCPU, that's 2 core on T5-4, so you will use that number and set-core option, instead of set-vcpu.
Use a max-cores constraint with maximum number of cores paid.
Live migration is not to be used (this is quite dumb in my opinion).
T5-4 will cost you a 0.5 factor per core (this document is kept recent) :
Factor here is type of software (enterprise, standard db etc.)
A document with list prices :
http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf
So if you assign 2 core (set-core and max-cores) on ldom on T5-4 machine, you will have to pay oracle 1 processor licence to be compliant.
All above is subject to a change, so one should pay attention to those documents above every licence cycle.
Hope that helps
Regards
Peasant.
Thanks Peasant - I've been reading the docs and this is my understanding also.
My current client it appears, is using ldoms with oracle instances on but its NOT partitioned properly. Oh dear.
Also, how does named user plus work in a virtual environment (is it even allowed?). I understand its cores x users per licence. Can you still use a virtual partitioned core?
Types of licences do not matter AFAIK.
If your LDOM is hard partitioned with two SPARC cores, you must pay 1 processor to be legal.
You shall treat that 2 core LDOM same as you would treat physical machine with 2 sparc core.
That is the point of hard partitioning (among other things).
Problem of licence model determination has gone berserk in the past years.
Especially since most of machines are now multisocket/multithread.
This is not just Oracle, but other proprietary vendors.
Not even their own employees know how something should be licensed...
Oracle database has so many licence models and additional paid features.
One can, unintentionally .. not knowing, make an AWR report which will happily work, but will render your database not compliant if you haven't paid the database diagnostic licence.
Ask you Oracle rep about information if you can, it is his job to provide it.
Hope the helps
Regards
Peasant.
SPARC T systems run a hypervisor, so even the primary partition is virtualised!
Yes, named user plus works in a 'virtual' environment.
The caveats here are:
Acceptable technologies to 'hard' partition a Solaris 'instance' - according to Oracle - also include zones with either a dedicated-cpu or capped-cpu setting.
The dedicated-cpu setting apparently fixes the CPUs that will run RDBMS threads.
Ironically the capped-cpu setting caps concurrent threads. It allows Oracle RDBMS to run on any CPU core it can see, capping the concurrency.
The irony of this setting is that in a VMware cluster (not ESX server but whole cluster of them) Oracle claim that there is a potential for RDBMS threads to run on any CPU in the cluster and thus they total the CPUs in the cluster to calculate the licence fee.
Hmmm...
Note that the OS hardware and state are recorded in an audit table within an Oracle RDBMS. Oracle are happy to query that and back charge if you are tardy in getting your resource utilisation under control. Then there are licenced features... but you didn't ask about those in this post! 